-=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)

IP Reverse Map Delegation: Einrichtung und Fehlerbehebung

17. Oktober 2014 / / Keine Kommentare
IP-Reverse-Map-Delegation nach RFC 2317 mit Provider-Zone, Kunden-Subzone, CNAME-Verweisen, PTR-Antwort und Troubleshooting-Hinweisen.

Reverse Map Delegation nach RFC 2317 klingt komplizierter als es ist. Es löst ein konkretes Problem: Wer ein kleines IP-Netz hat (kleiner als /24), kann normalerweise keine eigene PTR-Zone betreiben. Mit Reverse Map Delegation geht es doch.

Warum man es braucht

In der guten alten Zeit bekam man ein /24 (256 Adressen). Da legt man einfach eine Zone 3.2.1.in-addr.arpa. an und fertig. Heute bekommt man, wenn überhaupt, ein /29 (8 Adressen). Und da liegt das Problem: DNS-Zonen werden am Punkt getrennt. Bei einem /24 passt das, bei einem /29 gibt es keinen Punkt an dem man die Zone aufteilen kann.

Der Provider behält also die /24-Zone und richtet für das kleine Subnetz CNAMEs ein, die auf eine „Sub-Zone“ des Kunden zeigen. Der Kunde kann dann seine PTR-Records selbst verwalten.

Die Provider-Seite

In der /24-Zone des Providers wird für das Subnetz 1.2.3.0/29 eine Delegation eingerichtet. Jede IP-Adresse bekommt einen CNAME in die Sub-Zone des Kunden:

$ORIGIN 3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.kernel-error.de.
         IN NS  ns2.kernel-error.org.

; Delegation für 1.2.3.0/29 an den Kunden
0/29     IN NS    ns1.vandemeer.de.
0/29     IN NS    ns2.vandemeer.de.
0        IN CNAME 0.0/29.3.2.1.in-addr.arpa.
1        IN CNAME 1.0/29.3.2.1.in-addr.arpa.
2        IN CNAME 2.0/29.3.2.1.in-addr.arpa.
3        IN CNAME 3.0/29.3.2.1.in-addr.arpa.
4        IN CNAME 4.0/29.3.2.1.in-addr.arpa.
5        IN CNAME 5.0/29.3.2.1.in-addr.arpa.
6        IN CNAME 6.0/29.3.2.1.in-addr.arpa.
7        IN CNAME 7.0/29.3.2.1.in-addr.arpa.

Die Kunden-Seite

Der Kunde richtet auf seinem DNS-Server die Sub-Zone ein und kann dort seine PTR-Records setzen wie gewohnt:

$ORIGIN 0/29.3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.vandemeer.de.
         IN NS  ns2.vandemeer.de.

0        IN PTR netzadresse.vandemeer.de.
1        IN PTR router.vandemeer.de.
2        IN PTR mailin.vandemeer.de.
3        IN PTR imap.vandemeer.de.
4        IN PTR webserver.vandemeer.de.
5        IN PTR frei.vandemeer.de.
6        IN PTR frei.vandemeer.de.
7        IN PTR broadcastadresse.vandemeer.de.

Ergebnis

Eine Reverse-Lookup-Abfrage für 1.2.3.4 läuft jetzt über den CNAME zum DNS des Kunden und liefert den gewünschten PTR-Record:

dig -x 1.2.3.4 +short
4.0/29.3.2.1.in-addr.arpa.
webserver.vandemeer.de.

Probleme

Wäre ja zu schön, wenn es keine gäbe.

Laut RFC darf ein PTR-Record eigentlich kein CNAME sein, außer in genau diesem Fall. Das RFC ist von 1998, aber es hat sich nicht überall herumgesprochen. Man muss seinem Gegenüber gelegentlich RFC 2317 erklären, bevor die Diskussion weitergeht.

Außerdem macht Postfix Ärger, wenn man reject_unknown_client in den smtpd_restrictions hat. Diese Prüfung erwartet, dass PTR und A/AAAA-Record zueinander passen. Bei Reverse Map Delegation tun sie das nicht, weil der CNAME dazwischen steht:

450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7]

Wer einen größeren Mailserver betreibt, sollte auf der Mail-IP kein Reverse Map Delegation einsetzen, sondern den PTR direkt beim Provider setzen lassen. Spart Arbeit und Ärger.

Fragen? Einfach melden.

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.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑