Meine letzten IPv6-Tunnel werden langsam überflüssig. Seit letzter Woche haben wir auch im Büro natives IPv6. Die Telekom hat uns auf einen NGN-Anschluss umgestellt.

Setup

• Zugang zum Internet über VDSL der Telekom mit statischer IP
• Speedport als VDSL-Modem
• Linux-Box mit Debian terminiert PPPoE und verteilt es an zwei Subnetze

IPv6 aktivieren

Kurz zusammengefasst

Für den IPv6-Zugang muss der pppd IPv6 auf der PPP-Verbindung aktivieren. Die Telekom benutzt dann Router-Advertisements (radv) um dem ppp0-Device eine IPv6-Adresse zu geben. Soll IPv6 im LAN weiterverteilt werden, bekommen wir Präfixe hierfür über Präfix-Delegation per DHCPv6. Letzteres kann aber nicht als Ersatz für die Router-Advertisements genutzt werden, da die Telekom nur Präfixdelegation darüber macht.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Wer einen authoritativen Nameserver betreibt sollte die eigenen Zonen mit DNSsec sichern. Hier zeige ich euch, wie ihr einen rekursiven Nameserver so einrichtet, dass der DNSsec-Signaturen prüft. Was ist der Unterschied? Authoritative Nameserver sorgen beim Besitzer einer Domain, dass diese gefunden werden kann. Rekursive Nameserver suchen für einen Internetanschluss die richtige Verbindung zu fremden Domains.

Warum soll ich DNSsec aktivieren?

• Ich schütze mich damit gegen Angriffe auf Schwachstellen des DNS-Protokolls. 2008 entdeckte Dan Kaminsky eine Sicherheitslücke bei der über Cache Poisoning DNS-Einträge gefälscht werden können. Ohne DNSsec ist man nicht mehr sicher, dass das DNS die richtige IP-Adresse zu einer Domain liefert.
• Ich kann das DNS nutzen um andere Daten gegen Manipulation geschützt ablegen. Die ssh-Fingerprints-Einträge im DNS sind nicht mehr fälschbar; das Zertifikat für meinen Webserver lässt sich auch überprüfen, wenn ich der ausstellenden Zertifizierungsstelle nicht vertraue. Sogar selbst signierte Zertifikate lassen sich überprüfen. DANE oder TLSA heißt der Standard. Er hat das Potential die Verbreitung von Kryptografie im Internet zu fördern. Das erste Mal überhaupt können nun [Zertifikate beim Mailserverbetrieb wirklich getestet werden.)[https://www.heise.de/netze/meldung/Verschluesselter-Mail-Transport-Posteo-setzt-als-erster-Provider-DANE-ein-2187144.html) Zuvor musste ein Mailserver jedem Zertifikat vertrauen oder konnte nur Verbindungen zu einem engen Zirkel anderer Provider testen.
• DNSsec schützt gegen Spam, den der Provider anzeigt, wenn ich mich bei einer Webadresse vertippe. Immer mehr Provider fälschen DNS-Ergebnisse und zwingen ihre Nutzer bei Tippfehlern in der Webadresse damit auf die eigenen Werbeseiten. Im Web nervt dies nur, andere Dienste haben viel größere Probleme, wenn eine nicht existierende Domain aufgelöst werden kann. Das Internet ist nicht nur Web!
• Ich lerne mehr über die Technik, die ich nutze. Ganz nach persönlicher Einstellung kein Argument oder das wichtigste von allen. Im Moment sind Admins, die sich mit DNSsec auskennen, ihren Kollegen noch zwei Kopflängen voraus. Wer Erfahrung hat kann damit als Experte punkten und blickt in die Zukunft des Internets.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Vor ein paar Tagen habe ich bereits über einen Teil meines Nameserver-Setups mit Bind geschrieben. Ich habe erklärt, wie DDNS mit bind verwendet werden kann um beispielsweise Kunden die Möglichkeit zu geben Änderungen an Ihren Zonen über ein standardisiertes Protokoll durchzuführen oder die sich häufiger ändernde IP des Internetanschlusses zuhause immer aktuell im DNS zu hinterlegen. Dabei habe ich erwähnt, dass ein interessantes Argument für den Einsatz von DDNS zum Updaten von Zonen auch ist, dass bind in diesem Fall sich automatisch darum kümmert diese erneut zu signieren. Wie dieses Setup funktioniert möchte ich in diesem Artikel beschreiben.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Der Nameserver Bind bringt von Hause aus die Möglichkeit mit, dass Änderungen in Zonen dynamisch durchgeführt werden können. Dies kann zum Beispiel genutzt werden um selbst etwas wie DynDNS zu realisieren. In der Tat nennt sich das was Bind da implementiert auch DDNS. Spezifiziert ist das Protokoll in RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE).

Da ich heute eh den größten Teil dieses Textes als Mini-HOWTO für einen Kollegen geschrieben habe, möchte ich ihn auch hier auf meinem Weblog für andere zur Verfügung stellen. Alle hier verwendeten Befehle sind Befehle von Bind. Unter Debian sind diese Utility-Befehle im Paket dnsutils verpackt. Aktuell benutze ich die Version 9.8.4 von Bind.

Ich zeige in diesem Artikel:

1. wie man einen kryptografischen Schlüssel zur Sicherung des Zugriffs erstellt,
2. wie die Konfiguration von Bind angepasst wird,
3. wie dynamische Updates an Bind geschickt werden und
4. was zu beachten ist, wenn weiterhin auch klassische Updates an der Zone durchgeführt werden sollen.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Aufgrund der Tatsache, dass die Hardware mit denen Public-Key-Schlüssel angegriffen werden kann immer leistungsfähiger wird, ist es notwendig, dass auch die Größe der eingesetzten Schlüssel immer weiter vergrößert wird.

Für den Einsatz mit qualifizierten digitalen Signaturen in Deutschland veröffentlicht beispielsweise die Bundesnetzagentur jährlich den sogenannten Algorithmenkatalog. In ihm steht jeweils welche Mindestschlüssellänge bis zu welchem Zeitpunkt als ausreichend angesehen werden kann.

Aktuell wird für den Einsatz von RSA-Schlüsseln bis Ende 2018 beispielsweise empfohlen, dass diese mindestens 2048 Bit lang sein sollten.

Dies betrifft aber natürlich nicht nur qualifizierte Signaturen sondern beispielsweise auch die verschlüsselte Übertragung von Webseiten mit dem HTTPS-Protokoll. Auch hierfür werden meistens RSA-Schlüssel eingesetzt. Üblicherweise trifft man auf Webservern dabei meistens Schlüssel der empfohlenen Länge an. (Ergebnis einer nicht repräsentativen Überprüfung einiger Websites durch mich.)

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Diese Woche bekomme ich einen Anruf von einem Bekannten: er entwickelt gerade eine Website für einen Kunden. Und obwohl die Seite noch nicht fertig ist, taucht sie schon im Suchindex von Google auf. Er hatte vergessen die Seite während der Entwicklung mit einem Passwortschutz zu versehen. Er fragte mich, ob ich eine Idee habe, wie er dieses Versäumnis so schnell als möglich korrigieren könne.

Wir sind nun gemeinsam ein paar Möglichkeiten durchgegangen das Problem zu beheben:

• Site jetzt mit Passwortschutz versehen: es kommt zwar niemand mehr auf die Seite, allerdings ist sie noch in Google (und vermutlich anderen Suchmaschinen) gelistet,
• robots.txt auf die Seite laden, die allen Suchmaschinen sagt, dass die Site nicht gelistet werden möchte: wer die Adresse kennt kommt trotzdem noch darauf oder
• manuell über die Google Webmaster-Tools die Löschung beantragen: allerdings hatte Google schon über 10.000 Treffer auf der Site.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Ich greife mit zwei E-Mail-Programmen auf meinen Mailaccount zu. Das eine ist mutt, das andere ist Thunderbird. Während ich mit mutt keine Probleme habe, kann ich seit zwei Tagen mit Thunderbird nicht mehr auf mein E-Mail-Konto zugreifen.

Wenn ich es probiere, dann sehe ich Thunderbird für etwa 20 Sekunden versuchen eine Verbindung mit dem Mailserver aufzubauen. Nach diesen 20 Sekunden stellt sich Thunderbird wieder so als hätte es nicht versucht E-Mails abzufragen. Es kommt also auch keine Fehlermeldung oder dergleichen.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Die IPv4-Adressen gehen aus – so ließt man. Im Februar 2011 wurde die letzte freie Adresse in Europa vergeben. Was seitdem getan wird: nichts. Trotzdem leiste ich meinen Beitrag: ich spare IPv4-Adressen mit virtuellem Hosting auch für HTTPS.

HTTPS und die IP-Adressen

Der wichtigste Grund warum ein Webserver mehrere IP-Adressen hat ist HTTPS. Für jede HTTPS-Domain brauchte man bisher eine eigene IP-Adresse. Die Verschlüsselung von HTTPS wird aktiviert bevor der Webbrowser dem Server sagt welche Webadresse er abrufen möchte. Das Problem dabei: das Zertifikat welcher Domain soll der Server nun benutzen? Verwendet er das falsche meckert der Browser. Eine rote Seite erscheint und warnt den Internetnutzer, dass da etwas nicht stimmt und die Seite vielleicht unsicher ist. Das wollen wir nicht!

Die Lösung bisher: jede Domain hat eine eigene IP-Adresse. Muss ein Webserver eine HTTPS-Anfrage beantworten, schaut er welche IP-Adresse angesprochen wurde. Kein Problem, das kann er. Für jede IP-Adresse weiß er die zugehörige Domain. Er kann das richtige Zertifikat nutzen.

Schon 2003 aber wurde Server Name Indication (engl. für „Andeutung des Servernamens“) erfunden RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions Moderne Browser übermitteln hiermit schon bevor verschlüsselt wird welche Domain sie erwarten. Wenn sich der Browser an diesen Standard hält, dann kann der Webserver auch ohne verschiedene IP-Adressen erkennen welches Zertifikat er nutzen muss.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

PGP-signed version of this history.

There exist some even older keys that I have never used in the internet and that only contain FidoNet addresses. These keys are completely lost. I neither have the public nor the private keys anymore.

Change history

2006-08-10: Marked key AA839AF9 as revoked, updated signing-expire-date for key 4E59C7E6, added new key 70D6C898
2003-12-04: Updated expiry information for 4e59c7e6

IMUnified hat vor etwa zwei Jahren angekündigt, ein Protokoll zu schaffen, das es ermöglichen soll, verschiedene Instant Messaging Systeme mit einem Client zu benutzen. Gründungsmitglieder waren unter anderem MSN, Odigo und Yahoo!.

Inzwischen ist es wieder ruhig geworden, ob IMU jemals ernsthaft eingesetzt wird, wird wage ich fast zu bezweifeln. Aber immerhin kann beispielsweise der Yahoo!-Messenger das Protokoll, man muss es nur mit ein paar Registry-Änderungen unter Windows einschalten. Danach hat man die Möglichkeit, sich zusätzlich zu Yahoo! auch in andere IM Dienste anzumelden.

Dies habe ich zum Anlass genommen, mir IM Unified doch einmal anzuschauen und habe ein paar Sessions mit einem Network-Sniffer protokolliert. Das Protokoll ist an sich sehr einfach aufgebaut und erinnert etwas an Protokolle wie SMTP oder HTTP.

Alle Daten werden über eine TCP/IP-Verbindung ausgetauscht. Der Client konnektiert hierzu auf den Port 11319 des Servers. Über diese Verbindung macht er zunächst ein Login-Handshake und tauscht danach Daten aus. Der Austausch erfolgt in Blöcken.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

In 2000, IM Unified announced to create a protocol that enables an instant messaging client to join different IM services. Founding members were MSN, Odigo, Yahoo! and others.

Since then I have not heard much of IMU. I don't even think that their IMIP protocol will ever be used really. But it does exist and e.g. the Yahoo! messenger client supports it. You only have to change some values in the Windows registry. Afterwards, you're client is able to join other IM services like Odigo with the Y! messenger.

For no other reason than to see how IMIP works I've dumped some IMIP sessions with a network sniffer. The IMIP protocol is very simple structured and looks a bit like SMTP or http.

All data is exchanged over a TCP/IP connection. The clients connects to port 11319 at the server. Firstly, it performs the login handshake and afterswards, it is exchanging messages, presences and other data. All data is exchanged in blocks.

All blocks have a structure of lines. Every line is finished by \r\n (carriage return, line feed). The first line contains the type of a block, the second line contains the size of the block (first two lines not counted). It is a decimal ASCII number containing the size in bytes. Starting at the third line, there are head lines, optionally followed by an empty line, optionally followed by a block body. If the body is empty, the empty line can be absent. (The Y! messenger is allways sending the empty line, the Odigo server isn't.)

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »