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 🙂
Autor: kernel-error (Seite 25 von 47)
Der IPv6 Kongress ist gerade zu Ende und das Thema IPv6 ist mal wieder etwas mehr im Rampenlicht, oder besser gesagt es bekommt durch die viele Presse mal wieder ein klein Wenig mehr Aufmerksamkeit als normal. So ist ebenfalls das Thema Verbreitung noch einmal etwas aufgewärmt worden.
Google hat hier meist eine ganz gute Übersicht: http://www.google.de/ipv6/statistics.html
Eine sicher noch bessere Auflistung findet sich hier: https://www.vyncke.org/ipv6status/detailed.php?country=de
Zusammengefasst kann man sagen, nach über 15 Jahren IPv6 ist die „Umstellung“ noch immer nicht weit genug. Alle Empfehlungen von Experten wurden ignoriert, es gab halt bisher noch keine Nachfrage…. Dumm nur dass inzwischen den ISPs, vor allem den Kabelnetzbetreibern, die IPv4 Adressen ausgehen! Wer in Deutschland einen neuen Internetzugang bei einem Kabelnetzbetreiber bekommt, der bekommt einen Carrier Grade NAT (CGN) Anschluss. Das bedeutet man bekommt nur noch eine private IPv4 Adresse vom ISP und geht bei diesem über einen zentralen Router ins Internet. Dieses versteckt sich oft hinter den Bezeichnungen DS-Lite oder DS64-Lite. Bei einer Lösung bekommt man direkt eine private IPv4 Adresse aus dem Netz des ISP bei der anderen Lösung bekommt man eine über das IPv6 Netz getunnelte private IPv4 Adresse des ISP.
Testen ob man hinter so einem Anschluss sitzt lässt sich schnell über folgenden Link: http://ip.bieringer.de/cgn-test.html
Beide Lösungen helfen zwar dem ISP beim sparen von IPv4 Adressen (im Mobilfunk-Internet wird dieses seit Jahren praktiziert, nur ohne IPv6), es bringt nur leider noch mehr Probleme mit.
Viele Probleme finden sich bei CGN-Anschlüssen im Detail. Als Beispiel: Jede TCP/IP Verbindung verbraucht bei der abgehenden IP-Adresse mindestens einen Port. Ports sind 16-Bit-Zahlen (Portnummern) und reichen von 0 bis 65535. Ports von 0 bis 1023 sind reserviert und werden von der IANA vergeben. Das bedeutet es können maximal 65535-1023=64512 gleichzeitige Verbindungen aufgebaut werden. OK, mal angenommen man nutzt den reservierten Bereich ebenfalls um abgehende Verbindungen zu realisieren ist es etwas mehr, einen höheren Wert als 65535 wird man denn noch nicht überschreiten können. Das ist schon nicht viel, vor allem baut ein User ja schnell mehrere Verbindungen gleichzeitig auf. E-Mails abrufen, Messanger auf, Surfen (aktuelle Browser bauen gleichzeitig mehrere Verbindungen zum Webserver auf um direkt mehrere Teile der Webseite gleichzeitig zu laden!), usw. usw… Da kommt ein User schnell auf 50 und mehr offenen Verbindungen. Jede Verbindung kann zwar sauber geschlossen werden, denn noch kommt es nicht selten vor das Verbindungen nicht sauber geschlossen werden. Das bedeutet die jeweilige Verbindung ist bis zum Ablauf des Timeouts offen. Das kann schon mal ein paar Minuten sein!
Unter Linux lassen sich die offenen Verbindungen schnell anzeigen mit:
$ netstat -tapen
Sind alle möglichen Verbindungen aufgebaut, können keine weiteren mehr aufgebaut werden. Um dieses zu verhindern, könnte man als ISP am Router an den Verbindungen arbeiten… So könnte man bestehende Verbindungen nach 10 Minuten einfach hart zurücksetzten… Dann müsste der jeweilige Client halt eine neue Verbindung aufbauen, wenn sie noch benötigt wird. Was alles passieren kann, wenn bestehende Verbindungen einfach zurückgesetzt werden, kann man sich selbst schnell ausmalen. Ein weiterer Punkt wäre auch die maximale Anzahl gleichzeitiger Verbindungen von einer IP. Jeder der schon einmal einen Web oder Mailserver konfiguriert hat, ist irgendwann sicher an dem Punkt angekommen an welchem er die Zahl der maximal gleichzeitigen Verbindungen von einer IP Adresse beschränken konnte/musste. Lässt man von einer IP Adresse zu viele gleichzeitige Verbindungen zu, kann ein möglicher Angreifer bereits mit sehr wenigen Systemen einen wirkungsvollen DDoS-Angriff auf das eigene System durchführen. Ein einziger Client kann also so schnell einen größeren Teil der vorhandenen Systemressourcen binden. Dieses möchte man als Diensteanbieter nicht, daher beschränkt man oft die Anzahl der gleichzeitigen Verbindungen von einer IP. Schiebt ein ISP seine Kunden über CGN ins Internet. Kommen zwangsläufig mehrere Verbindungen von ein und der selben IPv4 Adresse. Es könnte also passieren das Dienste einfach nicht mehr erreichbar sind. Das ist doof! Dabei darf man jetzt auf keinen Fall mit dem Finger auf den ISP zeigen!!! Der Schuldige sitzt nämlich an anderer Stelle…
So jammert zum Beispiel der VoIP-Anbieter Sipgate das seine Kunden hinter CGN-Anschlüssen sich bei ihm (also Sipgate) beschweren dass ihre Sipgate-Anschlüsse nicht sauber arbeiten. Schaut mal hier: http://www.sipgateblog.de/sipgate-am-ipv6-kabelanschluss/ Oh, die Kommentare sind zum Teil lesenswert! Zurück zum Thema…. Man muss sich nun also auf der Zunge zergehen lassen was hier gerade abläuft:
Sipgate „beschwert“ sich darüber das Unitymedia CGN nicht ganz ~korrekt~ implementiert hätten und hoffen nun darauf das sich jemand von Unitymedia bei ihnen meldet, damit man zusammen das Problem analysieren könnte. Na habt ihr es schon? Nein… Ok, dann noch mal anders!
Unitymedia hat für Diensteanbieter, welche es 2014 trotz vieler Warnungen und jahrelanger Vorlaufzeit, noch immer nicht geschafft haben ihre Dienste IPv6 fähig zu machen, einen Workaround eingerichtet, damit deren Dienste überhaupt noch irgendwie erreichbar sind. Unitymedia (sowie viele andere ISPs auch) haben nun also auf eigene Kosten (klingt dramatischer als es ist) eine Sonderlösung geschaffen. Dann kommt so ein Sipgate und sagt. Toll was du da gemacht hast, es klappt mit unserem System nur leider nicht ganz perfekt. Kannst du da bitte noch mal etwas nachstellen?
LEUTE…. Kommt aus den Puschen und macht eure Dienste IPv6 fähig. Da schieben die Jungs von Sipgate den schwarzen Peter weiter an den ISP und machen ein Fass auf, nur weil sie es noch immer nicht geschafft haben ihre Dienste fähig für die Realität zu machen. Dann rennen die Jungs da im Kreis und blubbern was von keiner Nachfrage?!?!? Aaaarrrrrggghhhhh.
Wenn ihr also gerade hinter einem CGN-Internetanschluss sitzt und dadurch Probleme mit einigen Diensten oder dem Internet generell haben (told you so) dann lasst bitte euren ISP in ruhe sondern geht dem jeweiligen Diensteanbieter auf die Nervern mit der Frage: „IPv6, was da los?“
Das für heute!
WOOOOHOOOOO… Ich habe auch mal so eine E-Mail bekommen 🙂
CERT-Bund Reports <noreply@reports.certbund.net> schrieb am 27.05.2014 11:31:10:
Von: CERT-Bund Reports <noreply@reports.certbund.net>
An: registry@domain.tld
Datum: 27.05.2014 11:31
Betreff: [CERT-Bund#2014052612345678] Gestohlene FTP-Zugangsdaten
Sehr geehrte Damen und Herren,
CERT-Bund hat von einer vertrauenswürdigen externen Quelle eine Liste
gestohlener FTP-Zugangsdaten für in Deutschland gehostete Server erhalten.
Die Zugangsdaten wurden im Rahmen der Analyse eines Botnetzes gefunden
und werden offenbar dazu verwendet, um in mit dem FTP-Account
verbundene Webseiten schädlichen Code einzuschleusen, welcher auf
Drive-by-Exploits verweist. Es liegen leider keine Informationen vor,
wann und wie die Zugangsdaten ausgespäht wurden.
Nachfolgend senden wir Ihnen eine Liste der Zugangsdaten für Server in
Ihrem Netzbereich. Die Passwörter wurden sanitarisiert.
Format: ASN | IP-Adresse | FTP-Login
Wir möchten Sie bitten, den Sachverhalt zu prüfen und Ihre Kunden
entsprechend zu informieren.
Bitte bestätigen Sie den Eingang dieser Benachrichtigung und
informieren Sie uns über die von Ihnen getroffenen Maßnahmen.
Liste der Zugangsdaten für Server in Ihrem Netzbereich:
12345 | 123.123.123.123 | benutzername:IG******@ftp21.domain.tld
Mit freundlichen Grüßen
Team CERT-Bund
Bundesamt für Sicherheit in der Informationstechnik (BSI) Referat C21 –
CERT-Bund Godesberger Allee 185-189
D-53175 Bonn
————————————————————————
Dies ist eine automatisch generierte Nachricht.
Bitte beachten Sie beim Antworten die Reply-To Adresse.
Achtung, böser YouTube-Link!
Ich habe vor einiger Zeit ein „Will haben Gerät!“ gesehen… Bzw. den Prototyp eines solchen Gerätes. Zu dem Zeitpunkt wurde noch Geld für das Projekt gesammelt. Inzwischen ist die nötige Summe mehr als vorhanden und es geht seinen Weg…
Das Teil nennt sich Pockethernet, ein Video gibt es unten und einen Link zum Projekt gibt es hier: http://pockethernet.com/
Klar wird es kaum mit einem guten Fluke Gerät mithalten können… Für viele kleine Tests scheint es aber mehr als ausreichend zu sein. Schaut einfach mal ins Video! Wer will es noch?
Mein Jabber Server hat gerade neue Zertifikate bekommen. Die alten waren ausgelaufen…. Ich spare mit die Fingerprints, prüft bitte per TLSA 😀
So long…
Zur Prüfung von TLSA RECORDS gibt es inzwischen viele lustige Tools und Webseiten im Internet. Wenn man es aber einmal selbst gemacht hat, dann wird einem klar was überhaupt passiert.
In meinem Beispiel geht es um die Prüfung des TLSA-RECORDS meines Mailservers. Dazu baue ich erst per openssl eine Verbindung zu Postfix auf und starte dann mittelst STARTTLS die gesicherte Verbindung. Dabei wird das Serverzertifikat übermittelt (Bild).
$ openssl s_client -starttls smtp -connect smtp.kernel-error.de:25
Hier kopiert man sich nun den Zertifikatsteil heraus und speichert diesen einfach in einer Textdatei zwischen (Bild). Als nächstes erstelle ich die SHA256 Checksumme über das öffentliche Zertifikat meines Postfix.
$ openssl x509 -in test.crt -outform DER | openssl sha256 (stdin)= 94c8e1bdfff4f6d3fec0c4e2f26293d78870650bfd3534e77b93cdaccb77eb95
Als Vergleich muss nun der TLSA-RECORD herhalten. Diesen hole ich mir mit dig aus der DNS-Zone. Die 1 beutet dabei das die komplette Zertifikatskette gültig sein muss, damit dieses Zertifikat als gültig angesehen wird. Die 0 bedeutet das die Checksumme über das komplette Zertifikat erstellt wurde und die 1 bedeutet das es eine SHA256 Checksumme sein muss.
$ dig _25._tcp.smtp.kernel-error.de IN TLSA +short 1 0 1 94C8E1BDFFF4F6D3FEC0C4E2F26293D78870650BFD3534E77B93CDAC CB77EB95
Nun vergleiche ich die beiden Checksummen:
94c8e1bdfff4f6d3fec0c4e2f26293d78870650bfd3534e77b93cdaccb77eb95 94C8E1BDFFF4F6D3FEC0C4E2F26293D78870650BFD3534E77B93CDACCB77EB95
Sind sie identisch, ist alles perfekt. Möchte man nun einen TLSA RECORD eines anderen Anbieters prüfen greift man sich am besten zuerst dessen TLSA RECORD aus dem DNS. Dann sieht man welche Checksumme in welcher Art erstellt werden muss. Ebenfalls wird klar ob man die komplette Zertifikatskette prüfen muss oder nicht.
Viel Spaß!
Ich hatte es ja bereits erwähnt… Wer „einfach“ testen möchte ob sein Mailserver bzw. seine RECORDS für diesen korrekt sind, nutzt am besten posttls-finger:
# posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de posttls-finger: initializing the client-side TLS engine posttls-finger: using DANE RR: _25._tcp.smtp.kernel-error.de IN TLSA 1 0 1 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95 posttls-finger: setting up TLS connection to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25 posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL" posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 verify=1 subject=/description=y0xkuso3gx7t8h0o/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=smtp.kernel-error.de/emailAddress=postmaster@kernel-error.de posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 matched end entity certificate sha256 digest 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95 posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: subject_CN=smtp.kernel-error.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=E1:92:93:D4:CA:E9:5D:44:B5:CC:A4:15:1F:12:A6:E0:B5:C2:97:56, pkey_fingerprint=E9:84:8E:51:47:99:90:53:0B:2C:2E:1E:70:6E:DE:CA:A4:65:8A:C5 posttls-finger: Verified TLS connection established to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
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 🙂
Bei mir ist gerade die Frage aufgeschlagen was man denn bitte in seine DNS Zone vom Bind schreiben muss, wenn man eines oder mehrere dieser wunderbaren Microsoft Lync, Office 365 oder Exchange benutzen möchte.
Während des Registrierungsprozesses kommt man an die Stelle an welcher man einen TXT RECORD in der Zone veröffentlichen soll um den besitzt der Domain/Zone zu bestätigen. Etwas später müssen dann für die einzelnen Dienste ebenfalls Records gesetzt werden, damit am Ende das Outlook Autodiscover, Lyncdiscover sowie die Lync Federation funktionieren. Nutzt man Exchange Online muss natürlich noch der MX RECORD geändert werden, damit die E-Mails alle bei Microsoft „einlaufen“.
Nun ist es für ungeübte nicht immer direkt zu durchschauen was gemacht werden muss, daher hier ein kleines Beispiel an der Domain: kernel-error.com
Die zu setzenden RECORDS werden einem dann auf der Webseite von Microsoft wie im Beispiel unten Angezeigt.
Exchange Online
| Typ | Priorität | Hostname | Verweist auf die Adresse | Gültigkeitsdauer |
| MX | 0 | @ | kernel-error-com0i.mail.protection.outlook.com | 1 Stunde |
| CNAME | – | autodiscover | autodiscover.outlook.com | 1 Stunde |
| Typ | TXT-Name | TXT-Wert | Gültigkeitsdauer | |
| TXT | @ | v=spf1 include:spf.protection.outlook.com -all | 1 Stunde | |
| Alias oder Hostname | Ziel | Gültigkeitsdauer | ||
| kernel-error.com | MS=ms12345678 | 1 Stunde |
Lync Online
| Typ | Dienst | Protokoll | Port | Stärke | Priorität | Gültigkeitsdauer | Name | Ziel |
| SRV | _sip | _tls | 443 | 1 | 100 | 1 Stunde | kernel-error.com | sipdir.online.lync.com |
| SRV | _sipfederationtls | _tcp | 5061 | 1 | 100 | 1 Stunde | kernel-error.com | sipfed.online.lync.com |
| Typ | Hostname | Verweist auf die Adresse | Gültigkeitsdauer | |||||
| CNAME | sip.kernel-error.com | sipdir.online.lync.com | 1 Stunde | |||||
| CNAME | lyncdiscover.kernel-error.com | webdir.online.lync.com | 1 Stunde |
Zusätzliche Office 365-Einträge
| Typ | Hostname | Verweist auf die Adresse | Gültigkeitsdauer |
| CNAME | msoid.kernel-error.com | clientconfig.microsoftonline-p.net | 1 Stunde |
Ich LIEBE es ja, immer wenn Microsoft solche Dinge ins Deutsche übersetzten 
Im Folgenden nun als kleines Beispiel das Zonenfile vom Bind für kernel-error.com mit den gesetzten Records.
$ORIGIN .
$TTL 86400 ; 1 day
kernel-error.com IN SOA ns1.kernel-error.de. root.kernel-error.de. (
2014010101 ; serial
15000 ; refresh
1800 ; retry (30 minutes)
604800 ; expire (4 weeks)
86400 ; minimum (1 day)
)
NS ns1.kernel-error.de.
NS ns2.kernel-error.org.
$TTL 1H
IN TXT "MS=ms12345678"
IN TXT "v=spf1 include:spf.protection.outlook.com -all"
IN MX 0 kernel-error-com0i.mail.protection.outlook.com.
_sip._tls.kernel-error.com. IN SRV 1 100 443 sipdir.online.lync.com.
_sipfederationtls._tcp.kernel-error.com. IN SRV 1 100 5061 sipfed.online.lync.com.
$ORIGIN kernel-error.com
$TTL 1H
autodiscover IN CNAME autodiscover.outlook.com.
sip IN CNAME sipdir.online.lync.com.
lyncdiscover IN CNAME webdir.online.lync.com.
msoid IN CNAME clientconfig.microsoftonline-p.net.
Prüfen lassen sich alle gesetzten DNS-RECORDS natürlich wie immer schnell mit dig!
TXT @ v=spf1 include:spf.protection.outlook.com -all 1 Stunde
$ dig +nocmd +noall +answer kernel-error.com IN TXT @ns1.kernel-error.de kernel-error.com. 3600 IN TXT "MS=ms12345678" kernel-error.com. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com -all"
MX 0 @ kernel-error-com01.mail.protection.outlook.com 1 Stunde
$ dig +nocmd +noall +answer kernel-error.com IN MX @ns1.kernel-error.de kernel-error.com. 3600 IN MX 0 kernel-error-com0i.mail.protection.outlook.com.
SRV _sip _tls 443 1 100 1 Stunde kernel-error.com sipdir.online.lync.com
$ dig +nocmd +noall +answer _sip._tls.kernel-error.com. IN SRV @ns1.kernel-error.de _sip._tls.kernel-error.com. 3600 IN SRV 1 100 443 sipdir.online.lync.com.
SRV _sipfederationtls _tcp 5061 1 100 1 Stunde kernel-error.com sipfed.online.lync.com
$ dig +nocmd +noall +answer _sipfederationtls._tcp.kernel-error.com. IN SRV @ns1.kernel-error.de _sipfederationtls._tcp.kernel-error.com. 3600 IN SRV 1 100 5061 sipfed.online.lync.com.
CNAME – autodiscover autodiscover.outlook.com 1 Stunde
$ dig +nocmd +noall +answer autodiscover.kernel-error.com IN A @ns1.kernel-error.de autodiscover.kernel-error.com. 3600 IN CNAME autodiscover.outlook.com.
CNAME sip.kernel-error.com sipdir.online.lync.com 1 Stunde
$ dig +nocmd +noall +answer sip.kernel-error.com IN A @ns1.kernel-error.de sip.kernel-error.com. 3600 IN CNAME sipdir.online.lync.com.
CNAME lyncdiscover.kernel-error.com webdir.online.lync.com 1 Stunde
$ dig +nocmd +noall +answer lyncdiscover.kernel-error.com IN A @ns1.kernel-error.de lyncdiscover.kernel-error.com. 3600 IN CNAME webdir.online.lync.com.
CNAME msoid.kernel-error.com clientconfig.microsoftonline-p.net 1 Stunde
$ dig +nocmd +noall +answer msoid.kernel-error.com IN A @ns1.kernel-error.de msoid.kernel-error.com. 3600 IN CNAME clientconfig.microsoftonline-p.net.
Noch Fragen? Dann fragen 🙂 Sonst wünsche ich noch „viel Spaß“ mit dem neuen Microsoft Online Produkten….
Ich habe gerade ein kleines IPv6 Quiz gefunden. Es stellt 10 einfache Fragen und man hat 10 Minuten Zeit. Wer also Lust auf ein kleines Quiz hat: http://www.proprofs.com/quiz-school/story.php?title=NTkwODc3
Die iX feiert bald das 25-jährige Jubiläum. Um den Lesern etwas Gutes zu tun möglichst viele darauf aufmerksam zu machen und um ein paar statistische Daten für die kommende Ausgabe zu sammeln, gibt es eine Verlosung mit tollen Preisen.
Wenn also jemand einen Preis gewinnen möchte der iX bei ihrer Datensammlung helfen möchte, folge dieser bitte einfach dem nun folgenden Link: https://umfrage.heise.de/limesurvey/index.php/55238/lang-de
Damit die Gewinner benachrichtigt werden können, muss neben der E-Mail Adresse und dem Namen selbstverständlich ebenfalls die volle Adresse angegeben werden. Na ja, zumindest werden die Daten per TLS übertragen!
Bin ich heute wieder zu böse?
