-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Networking (Seite 6 von 12)

Mosh – mobile shell

10. September 2014 / / Keine Kommentare

Langsame SSH Verbindungen sind nicht nur nervig, sie regen mich auf und reizen mich unnötig. Ich werde verrückt, wenn ich etwas in ein Terminal tippe und versetzt eine Rückmeldung über meine Eingaben bekomme. Und wehe man hat sich vertippt.

Besonders wenn man „mal eben“ unterwegs die Welt retten muss und das Terminal hängt oder durch die wechselnde IP Adresse am mobilen Client gleich die ganze Verbindung gekillt wird.

OK, gegen die gekillte Verbindung hilft screen und gegen Vertipper, aufpassen und der Umweg über ein Textfile (copy & paste). Beides sind Notnägel, nicht wirklich dafür gedacht und nicht DIE Lösung.

Vor kurzem hatte ich das Problem auf einigen, weit entfernten, Systemen arbeiten zu müssen. Auf dem Weg dort hin hatte ich leider mit 60 – 80% Paketverlust zu kämpfen. So ist natürlich kaum ein Arbeiten möglich. Glücklicherweise erinnerte ich mich daran mal etwas von Mosh gelesen zu haben. Mosh ist ein sehr guter Name, denn er ist in meinem Hirn hängen geblieben.

Ich bin so begeistert von dem Programm, dass ich es einfach einmal kurz verlinken muss.
https://mosh.mit.edu/

Es lässt sich grob bedienen wie ssh, muss auf dem Client und dem Server installiert sein und arbeitet am Ende mit UDP Paketen. UDP?!?!? Japp UDP…. Genau erlesen kann man es auf der Webseite vom Projekt und dort werden direkt ein paar Bedenken erschlagen hinsichtlich Verschlüsselung und Konsistenz.

Auf meinen Arbeitsplätzen gehört es in jedem Fall ab jetzt zur standard Ausstattung.

So long….

Fragen? Einfach melden.

Google will sicheres Internet.

13. August 2014 / / Keine Kommentare

In den letzten Tagen häufen sich die Meldungen über Google bezüglich verschlüsselter Webseiten. Zugegeben… Etwas überraschend für mich! So hat Google angekündigt künftig Webseiten, die verschlüsselt HTTPS ( also per SSL / TLS ) erreichbar sind. In seinem Ranking bei den Suchergebnissen zu bevorzugen. (HTTPS as a ranking signal)

Na da werden sich wohl einige CAs die Hände reiben und die SEOs wieder viel arbeiten haben. Hoffen wir mal das inzwischen alle Hoster SNI können, sonst wird diese Aktion sicher dem IPv4 Pool noch mal ordentlich etwas abziehen. BTW. Habe ich schon gesagt das es Zeit ist sich mit IPv6 zu beschäftigen?

Jetzt lese ich gerade das Google eine kleine Liste für seinen Browser Chrome führt. Eine Liste für HTTPS only Seiten. In genau diese Liste kann sich nun jeder mit seiner Webseite eintragen, der dafür gesorgt hat, dass seine Webseite nur per HTTPS zu erreichen ist. Dazu setzt Google auf HSTS (HTTP Strict Transport Security). Das Thema Stirct Transport Security habe ich ja bereits, unter anderem, vor einigen Wochen hier beschrieben: Apache und sichere SSL / TLS Verschlüsselung

Nun kann man sich also über diese Seite https://hstspreload.appspot.com/ in die Liste eintragen. Dabei erwartet Google zum Header max-age noch includeSubDomains und preload. Ist die Seite eingetragen bedankt sich Google und verweist als nächsten Schritt zur SSLlabs Testseite um ggf. vorhandene Probleme mit seiner SSL/TLS Konfiguration zu beheben.

Google tut dieses alles ganz sicher nicht aus Nächstenliebe, denn noch wird es die allgemeine Sicherheit, vor allem aber das Theme selbst, mehr in den Vordergrund ziehen. So wird sich vielleicht der eine oder andere „Entscheider“ nun doch mit einer positiven Rückmeldung zu dem Thema bei der IT melden!

Fragen? Einfach melden.

Samsung Galaxy S2: Überhitzung durch defekten BCM4330 und Mainboard-Tausch

6. Juli 2014 / / Keine Kommentare

Das ärgert mich jetzt. Es hat tatsächlich einige Zeit gedauert, bis ich mich überhaupt zu einem Smartphone habe hinreißen lassen. Damals fiel die Wahl auf das Samsung Galaxy S II. Es lief ein paar Jahre tadellos, vor allem mit CyanogenMod 11.

Das Problem

Irgendwann hielt der Akku nicht mehr den ganzen Tag. Es ging so schleichend, dass ich es zunächst nicht bemerkt habe. Als es dann massiv wurde, dachte ich natürlich zuerst an den Akku selbst, der hatte ja bereits zwei Jahre auf dem Rücken. Beim Laden wurde das Handy besonders warm, um nicht zu sagen heiß.

Also einen originalen Samsung-Akku über eBay besorgt. Leider änderte sich damit nichts. Dann habe ich gelesen, dass Dreck an der USB-Buchse zu Kriechströmen führen kann. Buchse gereinigt, nichts. Netzteil getauscht, nichts.

Die Fehlersuche

Also aufgeschraubt. Inzwischen verbrannte das Gerät selbst im abgeschalteten Zustand so viel Strom in Wärme, dass es trotz angeschlossenem Ladegerät nicht mehr reichte, den Akku zu laden. Ich wollte herausfinden, welches Bauteil die Hitze erzeugt.

Unter einer Schirmung mit der Aufschrift GT-I9100 #4 vermutete ich die Quelle zuerst. Es stellte sich aber heraus, dass es der IC auf der anderen Seite des Mainboards war: SWB-B42. Das ist der Broadcom BCM4330, zuständig für WLAN, Bluetooth und FM-Radio. Meine Hoffnung, dass nur die nahe am Mainboard verlötete CMOS-Batterie ein Problem hatte, war damit dahin.

Reparatur-Optionen

Den BCM4330 bekommt man für etwa 15 Dollar plus Porto. Mit drei Wochen Wartezeit und 30 Euro Einsatz wäre das machbar gewesen. Den alten IC mit Heißluft lösen, neuen auflöten. Viel Arbeit, und gemacht haben sollte man es auch schon mal.

Ich habe mich stattdessen für ein neues Mainboard entschieden. Neu lag ich bei 150 bis 200 Euro. Zu teuer. Aber auf eBay fand ich ein Galaxy S2 mit defektem Display, irgendjemand war wohl draufgetreten. 50 Euro. Gekauft, Mainboard getauscht.

Ergebnis

Es funktioniert. So blieb mir das Galaxy S II doch noch eine Weile erhalten.

Fragen? Einfach melden.

Openfire und IPv6: NumberFormatException bei S2S-Authentifizierung

20. Juni 2014 / / Keine Kommentare

Openfire hat ein Problem wenn in der /etc/resolv.conf der Nameserver als IPv6-Localhost eingetragen ist (::1). Der Java-DNS-Client kann die IPv6-Adresse nicht parsen und wirft eine NumberFormatException. Das Ergebnis: Keine S2S-Verbindungen, keine Authentifizierung mit Remote-Servern.

Fehlerbild

Im /var/log/openfire/error.log findet sich:

org.jivesoftware.openfire.session.LocalOutgoingServerSession
  - Error authenticating domain with remote server: jabber.ccc.de
java.lang.NumberFormatException: For input string: ":1"
    at java.lang.Integer.parseInt(Integer.java:492)
    at com.sun.jndi.dns.DnsClient.(DnsClient.java:125)
    at org.jivesoftware.openfire.net.DNSUtil.srvLookup(DNSUtil.java:192)
    at org.jivesoftware.openfire.session.LocalOutgoingServerSession
        .createOutgoingSession(LocalOutgoingServerSession.java:270)

Java versucht ::1 als Portnummer zu parsen und scheitert an dem Doppelpunkt. Der Bug steckt in Javas DnsClient-Klasse die IPv6-Adressen in der resolv.conf nicht korrekt behandelt.

Lösung

In der /etc/resolv.conf den Nameserver von ::1 auf 127.0.0.1 umstellen:

# vorher
nameserver ::1

# nachher
nameserver 127.0.0.1

Openfire neu starten. Der lokale DNS-Resolver lauscht in der Regel auf beiden Adressen, die Namensauflösung funktioniert über IPv4 genauso. Neuere Java-Versionen haben den Bug behoben, aber wer eine ältere Version nutzt oder nicht updaten kann, ist mit dem IPv4-Workaround auf der sicheren Seite.

Weitere Openfire-Probleme mit S2S-Verbindungen: 404 Remote Server Not Found behandelt fehlende Intermediate-Zertifikate.

Fragen? Einfach melden.

DNSSEC-fähiger Registrar

18. Juni 2014 / / Keine Kommentare

In der letzten Zeit häufen sich bei mir die Anfragen, mit welchem Registrar ich zusammenarbeite. Vor allem im Hinblick auf DNSSEC und die DS-Records, die man beim Registrar hinterlegen muss.

Hier kann und möchte ich gerne die SpeedPartner GmbH aus Neuss empfehlen. Damals habe ich dort gerne mit Herrn Metz zusammengearbeitet. Es war immer jemand erreichbar, und auch etwas ungewöhnliche Dinge ließen sich schnell umsetzen. Das Webinterface konnte 2014 noch keine DS-Records entgegennehmen, der Weg per E-Mail funktionierte aber binnen Minuten.

Es kommt selten vor, dass ich hier Werbung für ein Unternehmen mache — dieses hatte es damals verdient.

Mehr zu DNSSEC und BIND gibt es im DNSSEC-HowTo. Fragen? Einfach melden.

TLSA DANE Record für E-Mail in Postfix prüfen: Schritt-für-Schritt-Anleitung

3. Juni 2014 / / Keine Kommentare

Habe ich ganz aktuell gesehen dass sich über die Webseite ssl-tools.net nun ebenfalls die DANE RECORDS testen lassen. Also einmal ob sie vorhanden sind und natürlich auch die Gültigkeit des RECORDS. Zu dem Thema bin ich ja bereits ein paar mal gefragt worden, da „einfache“ Test Tools noch rar waren. Was sich ja inzwischen endlich zu ändern scheint.

KLICK: https://de.ssl-tools.net/mailservers/kernel-error.de

Siehe auch: TLSA und DANE manuell prüfen

Fragen? Einfach melden.

IPv6 und Carrier Grade NAT: Warum nicht der ISP schuld ist

30. Mai 2014 / / Keine Kommentare

Nach dem IPv6-Kongress 2014 war die Verbreitung mal wieder kurz im Rampenlicht. Nach über 15 Jahren IPv6 war die Umstellung noch immer nicht weit genug. Alle Empfehlungen von Experten wurden ignoriert. Es gab ja keine Nachfrage. Bis den ISPs die IPv4-Adressen ausgingen.

Carrier Grade NAT

Wer in Deutschland einen neuen Internetanschluss bei einem Kabelnetzbetreiber bekommt, bekommt oft einen Carrier Grade NAT (CGN) Anschluss. Das bedeutet: Keine eigene öffentliche IPv4-Adresse mehr. Stattdessen eine private Adresse hinter einem zentralen NAT-Router des ISPs. Versteckt wird das hinter Bezeichnungen wie DS-Lite oder DS64-Lite.

Das Port-Problem

Jede TCP-Verbindung verbraucht auf der abgehenden IP-Adresse einen Port. Ports sind 16-Bit-Zahlen, maximal 65.535. Abzüglich der reservierten Ports bleiben rund 64.500 gleichzeitige Verbindungen pro IP. Ein einzelner Benutzer baut schnell 50 und mehr Verbindungen gleichzeitig auf: E-Mail, Messenger, Browser mit parallelen Requests. Dazu kommen Verbindungen die nicht sauber geschlossen werden und bis zum Timeout offen bleiben.

Offene Verbindungen anzeigen:

netstat -tapen

Wenn sich hunderte Kunden eine öffentliche IP teilen, sind die Ports schnell aufgebraucht. Der ISP könnte bestehende Verbindungen nach einer Zeit hart zurücksetzen. Oder die maximale Anzahl gleichzeitiger Verbindungen pro Kunde begrenzen. Beides führt zu Problemen.

Dazu kommt: Viele Webserver und Mailserver begrenzen die Anzahl gleichzeitiger Verbindungen pro IP-Adresse, als Schutz gegen DDoS. Wenn hundert Kunden hinter einer IP sitzen, trifft dieses Limit schnell.

Wer ist schuld?

Ein gutes Beispiel war Sipgate. Der VoIP-Anbieter beschwerte sich öffentlich darüber, dass seine Kunden hinter CGN-Anschlüssen Probleme mit ihren Sipgate-Leitungen hatten. Sipgate schob den schwarzen Peter an Unitymedia und hoffte, dass sich jemand meldet um das Problem gemeinsam zu lösen.

Was dabei unterging: Unitymedia hatte auf eigene Kosten einen Workaround eingerichtet, damit Dienste die es nach Jahren noch nicht geschafft hatten IPv6 zu unterstützen überhaupt noch erreichbar waren. Und dann kommt ein Diensteanbieter und sagt: Dein Workaround funktioniert nicht perfekt mit unserem System, bitte nachbessern.

Facepalm reaction GIF about IPv6 adoption delays

Der Schuldige ist nicht der ISP. Der Schuldige ist der Diensteanbieter, der es nach über 15 Jahren Vorlaufzeit nicht geschafft hat seinen Dienst IPv6-fähig zu machen. Wer Probleme mit seinem Internetanschluss hat die auf CGN zurückzuführen sind: Nicht den ISP anrufen, sondern den Diensteanbieter fragen wann IPv6 kommt.

Fragen? Einfach melden.

dnssec validator Browser Plugin

9. Mai 2014 / / Keine Kommentare

Veraltet: Das DNSSEC Validator Browser-Plugin wird nicht mehr gepflegt und ist in aktuellen Firefox-/Chrome-Versionen nicht mehr verfügbar. DNSSEC-Validierung sollte auf dem DNS-Resolver stattfinden, nicht im Browser.

Na schau mal einer an… Das Browser Plugin für den DNSSEC Validator kann nun auch DANE / TLSA und er zeigt es angenehm übersichtlich an.

https://www.dnssec-validator.cz/pages/download.html
Ist in jedem Fall noch mal einen Klick wert.

systemd und ntp

21. April 2014 / / Keine Kommentare

Man ist das hässlich… Da sitze ich hier an einem Sabayon System und bekomme keine saubere Uhrzeit. Zwar sollte ntpd.service beim Start die Uhrzeit abgleichen.. Der Dienst verkackt aber seinen Starten, weil er „noch“ kein Netzwerk hat. Dabei ist sogar hinterlegt dass es er erst nach dem Netzwerkmanager startet, denn noch scheint der Netzwerkmanager so schnell keine Verbindung zu bekommen. Der initiale Abgleich vom ntpd.service schlägt daher fehlt, der Dienst bleibt aus und es probiert es auch später nicht mehr. Grütze..

$ systemctl --failed
UNIT            LOAD   ACTIVE SUB    DESCRIPTION
ntpdate.service loaded failed failed Set time via NTP using ntpdate

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Ich lasse jetzt mal das Bughunting und setzte einfach auf chrony. Nur für Zeitsync ist das ok für mich!

$ equo search chrony
╠  @@ Suche...
╠      @@ Paket: net-misc/chrony-1.29.1 Branch: 5, [sabayonlinux.org] 
╠          Verfügbar:      Version: 1.29.1 ~ tag: NoTag ~ Version: 0
╠          Installiert:    Version: Nicht installiert ~ tag: n/a ~ Version: n/a
╠          Slot:           0
╠          Homepage:       http://chrony.tuxfamily.org/ 
╠          Beschreibung:   NTP client and server programs 
╠          Lizenz:         GPL-2
╠   Schlüsselwörter:  chrony
╠   Gefunden:         1 Eintrag

Gefunde und dann  installieren….

$ equo install chrony
╠  @@ Berechne Abhängigkeiten...
╠  ## [N] [sabayonlinux.org] dev-libs/libedit-20130712.3.1|0
╠  ## [N] [sabayonlinux.org] net-misc/chrony-1.29.1|0
╠  @@ Pakete die installiert/aktualisiert/entfernt werden müssen: 2
╠  @@ Pakete die entfernt werden müssen: 0
╠  @@ Download Größe: 413.1kB
╠  @@ Benutzter Festplattenspeicher: 715.6kB
╠  @@ Du brauchst zumindest: 1.5MB freien Speicherplatz
╠  ::: >>>  (1/1) 2 Pakete
╠    ## downloaden: 2 Pakete
╠    ## ( mirror #1 ) [dev-libs:libedit-20130712.3.1.3556f679066ec7d787573f08ac74ef24922243b2~0.tbz2] @ http://na.mirror.garr.it
╠    ## ( mirror #1 ) [net-misc:chrony-1.29.1.98ee02f66d56c49e1fdc4d713b2cea5ff23d775e~0.tbz2] @ http://na.mirror.garr.it
╠   ## Sammeldownload: 2 Artikel
╠    # [1] na.mirror.garr.it => dev-libs:libedit-20130712.3.1.3556f679066ec7d787573f08ac74ef24922243b2~0.tbz2
╠    # [2] na.mirror.garr.it => net-misc:chrony-1.29.1.98ee02f66d56c49e1fdc4d713b2cea5ff23d775e~0.tbz2
╠    ## Überprüfe Paketprüfsumme...
╠    ## Überprüfe Paketprüfsumme...
╠       : [net-misc:chrony-1.29.1.98ee02f66d56c49e1fdc4d713b2cea5ff23d775e~0.tbz2] GPG validated
╠       : [dev-libs:libedit-20130712.3.1.3556f679066ec7d787573f08ac74ef24922243b2~0.tbz2] GPG validated
╠       : [net-misc:chrony-1.29.1.98ee02f66d56c49e1fdc4d713b2cea5ff23d775e~0.tbz2] SHA1 validated
╠       : SHA256 deaktiviert
╠       : [dev-libs:libedit-20130712.3.1.3556f679066ec7d787573f08ac74ef24922243b2~0.tbz2] SHA1 validated
╠       : SHA512 deaktiviert
╠       : SHA256 deaktiviert
╠       : SHA512 deaktiviert
╠    ## ( mirror #1 ) [dev-libs:libedit-20130712.3.1.3556f679066ec7d787573f08ac74ef24922243b2~0.tbz2] erfolgreich @ http://na.mirror.garr.it
╠    ## ( mirror #1 ) [net-misc:chrony-1.29.1.98ee02f66d56c49e1fdc4d713b2cea5ff23d775e~0.tbz2] erfolgreich @ http://na.mirror.garr.it
╠    ##  angehäufte Transferrate: 658.3kB/Sekunde
╠  +++ >>>  (1/2) dev-libs/libedit-20130712.3.1
╠    ## Entpacke: dev-libs:libedit-20130712.3.1.3556f679066ec7d787573f08ac74ef24922243b2~0.tbz2
╠    ## Installiere Paket: dev-libs/libedit-20130712.3.1
╠    ## [BSD replacement for libreadline.]
╠    ## Updating installed packages repository: dev-libs/libedit-20130712.3.1
>>> Regenerating /etc/ld.so.cache...
╠    ## Aufräumen: dev-libs/libedit-20130712.3.1
╠  +++ >>>  (2/2) net-misc/chrony-1.29.1
╠    ## Entpacke: net-misc:chrony-1.29.1.98ee02f66d56c49e1fdc4d713b2cea5ff23d775e~0.tbz2
╠    ## Installiere Paket: net-misc/chrony-1.29.1
╠    ## [NTP client and server programs]
╠    ## Updating installed packages repository: net-misc/chrony-1.29.1
╠    ## Aufräumen: net-misc/chrony-1.29.1
╠  @@ Installation vollständig.
╠  @@ No configuration files to update.

Beim Boot soll er in Zukunft gestartet werden!

$ systemctl enable chronyd.service
ln -s '/usr/lib64/systemd/system/chronyd.service' '/etc/systemd/system/multi-user.target.wants/chronyd.service'

Och ja, am besten sollte der Dienst direkt gestartet werde…

$ systemctl start chronyd.service

Bevor ich es vergesse, den hässlichen ntpd.service will ich beim Start nicht mehr sehen!

$ systemctl disable ntpd.service

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑