Die Universität von Amsterdam hatte eine Studienarbeit zu Vergleichstest zwischen Ansätzen zur Eindämmung von DNS Amplification Angriffen ausgeschrieben. Das Ergebnis liegt jetzt vor.

Getestet wurde vor allem das Response Rate Limiting, eine Technik, die sehr spezifisch Angriffsmuster abwehrt ohne dabei legitime Anfragen komplett zu unterdrücken. Entwickelt wurde RRL, um die Nameserver der großen TLDs zu sichern. Erwartungsgemäß gelingt es in diesem Fall eine Verringerung des Verstärkungsfaktors von typischen 1:30 auf 1:0.2 zu reduzieren. Schon leichte Modifikationen im Angriff (Variiern von Namen oder Recordtypen) beschränken die Wirkung von RRL auf dann immer noch wirksame Verstärkungen von 1:8 bis 1:10. Bedienen die Nameserver mehr Zonen authoritiv sinkt der Effekt extrem schell. Für Massenhoster wird RRL als wirkungslos eingestuft:

Erfreulicherweise hat man meinen Ansatz (hier der richtige Patch) ebenfalls einer Betrachtung würdig gefunden. Obwohl nur kurz angetestet, freut mich der eingetretene Erfolg: 

Selbstverständlich ist DNS Dampening keine Universallösung. Es ist sehr leicht möglich, legitime Kommunikation per Spoofing so zu unterbinden, daß die gehosteten Zonen von bestimmten Providern aus gar nicht mehr aufgelöst werden können. Die Autoren der Arbeit empfehlen also doch noch einen gewissen Anteil an Anfragen zu beantworten:

Dann nehme ich das mal als Ansporn.

Die Prüfsummenberechnung der grundlegenden IP Protokolle benutzt das Einerkomplement. Wenn man, wie ich, gern an Paketen rumspielt, sollte man die Prüfsummenberechnung beherrschen.

Ein Ruf aus alten Tagen

Nach einem längeren Studium von Online-Quellen, die durch die Bank unergiebig waren, verwies man mich auf TAoCP Band 2. Verdammt. Das steht vor mir. Leider ist es diesmal nicht mehr als eine Sammlung von Stichpunkten. Knuth benutzt für MIX eine Darstellung mit getrenntem Vorzeichenbit.

Richtig erklärt (lesen!) wird das Einerkomplement von den Entwicklerns und Nutzern der Univac.

Kurz gesagt bietet das Einerkomplement eine einfache Ausführung von Negation (bitweises nicht), Addition (Volladdierer), Subtraktion (modifizierter Volladdierer), Multiplikation (nach links schieben) und Division (nach rechts schieben) vorzeichenbehafteter Zahlen. Diese Vorteile werden durch ein umlaufendes Carry, sowie zwei Darstellungen der Null (+0 und -0) erkauft.

Beim wesentlich bekannterem Zweierkomplement entfallen die Probleme mit der doppelten Null und dem umlaufenden Carry. Im Gegenzug scheitert die Multiplikation und Division mit negativen Zahlen und man bekommte eine Zahl für die es kein Inverses gibt.

Altlasten oder Designziel?

Die Auswahl des Einerkomplements für die Prüfsummen der IP-Protokolle gründet sich auf zwei Eigenschaften:

• Es bildet eine abelsche Gruppe: Man kann beliebig umsortieren, vertauschen, umgruppieren und es gibt eine Umkehroperation. Man kann subtrahieren.Veränderungen an dem IP-Paket sind so ohne komplexe Neuberechnung in Änderungen an der Prüfsumme umrechenbar. Die Prüfsumme wird zum Abschluß negiert und ist Bestandteil der Berechnung, so daß der Empfänger bei korrekten Paketen eine -0 erhalten muß.
• Invarianz gegen Endianess: Durch das umlaufende Carry ist es egal, ob die Zahlen auf Big oder Little Endian Systemen verarbeitet werden. Solange der Überlauf die Bits in der gleichen Reihenfolge durchläuft, ist das Ergebnis immer das Gleiche.

Beide Eigenschaften zusammen gestatten den Einsatz größerer Berechnungseinheiten, ja sogar massiv parallele Berechnungen durch Vektoroperationen. Es ist so möglich extrem schnell und einfach die Berechnungen vorzunehmen.

Desweiteren kann die Prüfsummenberechnung auf praktisch allen damals existierenden Plattformen ohne Konvertierungsaufwand durchgeführt werden. Was erstmal nicht geht, sind middle-endian Systeme wie die PDP11. Die Begrenzung der Prüfsumme auf 16bit gestattet auch der PDP11 mit einer konsitenten Endianess und damit ohne Konvertierungsaufwand zu arbeiten.

Besonders relevant ist diese Invarianz, da Netzwerke big-endian (lesen!) sind, während viele Prozessoren little-endian (lesen!) einsetzen.

Die Existenz einer +0 und einer -0 gestattet es, zu signalisieren, ob eine Prüfsumme berechnet wurde oder nicht. So kann man die Prüfsummenberechnung aktiv auslassen um UDP-Pakete auch mit leichten Fehlern durchzulassen. Dies ist beispielsweise bei VoIP nützlich, wenn Bitfehler weniger Schaden anrichten als komplett verlorene Pakete. +0 signalisiert hier die Abwesenheit von Prüfungen.

Interessant ist die Tatsache, daß man zum Zeitpunkt der UDP-Norm noch beide Nullen als mögliche Ergebnisse der Rechnung in Erwägung zog und explizit behandelt. Bei TCP und IP gibt es keine Sonderbedeutung von ±0. Man hielt es nicht für notwendig, auf solche Besonderheiten im Standard einzugehen.

Erst mit der Zeit hat man erst erkannt, daß verschiedene Tricks der inkrementellen Berechnung das Nullproblem gar nicht erkannt hatten. Der Standardcode kann gar keine +0 generiern. Warum das so ist, erkläre ich weiter unten. Wie sehr die beiden Nullen in Vergessenheit geraten sind, offenbart Code, der die legitim auftretende -0 als Fehlerkennung verwendet.

Andererseits kann man die Berechnung der Prüfsumme der Netzkartenhardware überlassen. Beim "Checksum Offloading" muß entschieden werden, ob die Hardware die Prüfsumme berechnen soll oder nicht. Auch hier signalisiert nur die +0 im Checksum-Feld den Wunsch nach Berechnung. Eine zwangsweise Neuberechnung der Prüfsumme würde die Fehlererkennung (insbesondere beim Routing) ad absurdum führen.

Betrachtet man die Alternativen, klären sich weitere Vorbehalte:

• CRC Prüfsummen sind zwar sehr gute Fehlerdetektoren, sind aber keine Gruppen. Dadurch erfordern aber selbst kleine Änderungen vollständige Neuberechnungen. Das TTL Feld könnte dann nicht Bestandteil der Prüfsumme sein. Auch NAT hätte es vermutlich nicht (so schnell) gegeben.
• Das Zweierkomplement ist heute die dominierende Implementierung der Binärarithmetik. Sie ist aber nicht endianess invariant. Zur Prüfsummenberechnung wäre also stets eine Konvertierung der Daten notwendig.
• Einfaches XOR erfüllt ebenfalls alle Anforderungen, ist aber deutlich schwächer bei der Fehlerdetektion. Da es damals rechenmäßig kaum einen Unterschied zwischen Einerkomplement und XOR gab, wurde das stärkere Verfahren bevorzugt.

Das magische "End Around Carry"

Zunächst sind noch einige Überlegungen notwendig, um sich elementare Eigenschaften des Einerkomplements zu vergegenwärtigen. Die Additionsstufe des Einerkomplements entspricht der des Zweierkomplements mit dem Unterschied, daß das Carry rückgekoppelt ist. Beim Zweierkomplement wird das Carry aus einem extra CPU-Flag eingeschoben und nach der Addition wieder dort verstaut. Dieses CPU-Flag gibt es bei Einerkomplement-CPUs schlicht nicht.

Das umlaufende Carry kann jedoch nicht zu einer Endlosschleife führen. Jeder Volladdierer muß (das Carry sei c) nur die Kombinationen 0+0+c = 0c, 1+1+c=1c sowie den 1+0+c=c(~c) bzw. 0+1+c=c(~c) bearbeiten. In den ersten beiden Fälle wird das ausgehende Carry Bit zwangsweise auf einen festen Wert gesetzt. Die Mischfälle sind interessanter, aber hier wird das Carry unverändert durchgereicht. Es gibt keinen Fall, wo die Rückkopplung des Carry zu einem Widerspruch, also einem flappenden Bit führen kann. Die Einerkomplementaddition ist also trotz umlaufenden Carry ist also binnen einer Runde stabil.

Von besonderem Interesse ist eine Eingabe, bei der nur die Mischfälle 1+0 oder 0+1 auftreten. In diesen Fällen gibt es keinen Volladdierer, der den Wert des Carry festlegen könnte. Ist das umlaufende Carry eins, so lautet das Ergebnis der Addition +0. Ist das umlaufende Carry null, so lautet das Ergebnis stattdessen -0. Beides sind valide Ergebnisse, die von Architektur, Algorithmus und Kontext der Berechnung abhängen. Dieses umlaufende Carry und die Existenz der zwei Nullwerte sind also unmittelbar verwand. Ja, sie sind der gleiche Effekt. Die ±0 ist die explizite Darstellung des umlaufenden Carry.

Andererseits ist es bei der Implementierung der Addition auf Zweierkomplement-Architekturen nicht möglich, Bits zu verlieren. Eventuelle Überläufe werden später hinzuaddiert und nicht rückgekoppelt. Einmal gesetzte Bits (z.B. die IP Version) leaken bis zum Ergebnis durch. Die Algorithmen zur Prüfsummenberechnung auf Zweierkomplementsysteme haben so durch die normative Kraft der Faktischen die Generierung der +0 verhindert.

Summiert man die Carries durch 32bit Arithmetik in den höherwertigen Bits auf, so kann man die Einerkomplement Rechnungen auch im Zweierkomplement ausführen. Alle Carry-Bits, die man vergessen hatte, liegen in den höherwertigen 16bit. Wieviele solche Additionen kann man ausführen, ohne daß einem der Carry-Speicher selbst überläuft? Im schlimmsten Fall hat jede Addition ein unverarbeitetes Carry. Man kann also 2¹⁶-1 Additionen ausführen. Dies entspricht einem Speicherbereich von 2¹⁷-2 Byte. also 130 kByte. Für IP-Pakete ist das unbedenklich, da diese maximal halb so groß werden dürfen. Problematisch bei IPv6 sind paketübereifende Payloads, deren Prüfsummen länger werden dürfen, als ein Paket an Daten faßt. Man kann also mit 32bit Arithmetik bedenkenlos paketweise rechen.

Eigener Code

Jetzt sind die Voraussetzungen geschaffen, eignen Einerkomplement-Code zu schreiben. Das steht dann aber in einem extra Artikel.

Es ist schön, wenn Kunden ihre eigenen Netze überwachen. Das Tool der Wahl heißt meist Nagios, Cacti oder Zabbix. Und das kann Auslastungsgraphen von Interfaces anzeigen. Ein Problem gibt es, wenn dieser Graph etwas völlig anderes anzeigt, als der des Providers.

Chaotische Graphen

Eine typische Interfacegraphik des Kunden sieht so aus. Auffällig sind die heftigen Ausschläge tagsüber. In der Nacht schaut der Graph dagegen ganz vernünftig aus.

Von Seiten des Providers ergibt sich ein ganz anderes Bild. Der Tagesgraph folgt eher der Erwartung an gewisse Stetigkeiten.

Selbstverständlich gibt es nun Streit: Wer hat Recht? Warum sind die Messungen so unterschiedlich?

Das 32-bit Ideal

Durch Rücksprache mit dem Kunden stellt sich heraus, daß die Messungen alle fünf Minuten erfolgen. Bei 100Mbps werden in diesem Zeitraum 3,8GB umgesetzt. Moment mal! War nicht bei 4GB eine Grenze für 32bit Werte? 64bit-Zähler laufen dagegen nur alle 4700 Jahre über.

Ich habe deswegen den providerseitigen Graphen noch einmal generieren lassen. Diesmal allerdings modulo 2³². Und dieser Graph entspricht ziemlich genau dem Graphen des Kunden. Er hat die gleiche maximale Bandbreite, ist nachts stetig und tagsüber chaotisch.

Die Überraschung beim Kunden ist groß, denn die Software verspricht mit 64bit Werten umgehen zu können. Auch die ausgelesenen Werte am Cisco-Gerät sind die 64bit-Zähler. Evtl. Fehler sind eigentlich schon lange behoben.

Es sieht akutell danach aus, daß das Rechnungen intern mit 32bit ablaufen. Bei PHP sieht das beispielsweise so aus:

$ php -r 'echo PHP_INT_MAX;'
2147483647

Auf einer 64bit Installation dagegen hat man eher eine Chance.

$ php -r 'echo PHP_INT_MAX;'
9223372036854775807

Also steht nun die Frage, welche Module eingesetzt werden und welche Software wann was und wo verarbeitet. Da warte ich mal auf Antworten.

Standardeinstellungen

Defaultmäßig ist Cacti auf 32bit-Zähler eingestellt, Anpassungen sind an mehreren Stellen nötig. Bei Cacti gibt es eine nützliche Hilfe, alles korrekt einzustellen: fix64bit.

Das Standardtemplate von Zabbix benutzt allerdings die 32bit Zähler. Ein 64bit Template ist aber verfügbar.

Reale Einbrüche

Ein ähnliches Bild ergibt sich allerdings auch, wenn man providerseitig geeignet aggregiert. Da sind ebenfalls Einbrüche zu sehen, diese aber in ganz anderen Dimensionen. Hier ein Beispiel von einer Transitlokation, wo eingehend und ausgehend übereinander gelegt wurde.

Der Grund für diese Einbrüche im Graphen ist allerdings viel simpler. Eine Meßstelle (c7201) war CPU-mäßig überlastet und hat schlicht sporadisch keine Werte liefen können. Aggregiert man dann über die Meßstellen, wirken sich die Fehlstellen massiv aus. Der summarische Wert ist ja nicht mehr ungültig oder nicht vorhanden, sondern die Summe wird kleiner. So hat man statt "Lücken"  nun richtig sichtbare "Einbrüche" im Graphen.

Durch Beseitigung der Störquelle verschwindet die Überlast und damit auch die Spikes im Graphen.

Ein Kunde berichtete über eine Nichterreichbarkeit des Webservers der Piratenpartei. Die Störung sah aus wie ein Routingproblem, aber es war viel viel schlimmer.

Zusätzlich zu der Nichterreichbarkeit der Webseite waren auch zwei Traceroutes mitgeliefert worden. Einer aus Kundensicht und einer vom Webserver aus. Die sehen so aus (IP Adresse des Kunden durch die eines Routers ersetzt)

traceroute from 178.19.71.117 to 178.19.224.1
 1  178.19.71.1 (178.19.71.1) [AS29551]  0.673 ms * *
 2  * * *
 3  * * *
 4  80.81.193.74 (80.81.193.74) [AS6695]  0.660 ms * *
 5  * * *
 6  * * 217.71.99.134 (217.71.99.134) [AS13237]  8.215 ms
 7  109.73.31.194 (109.73.31.194) [AS196714]  8.227 ms * *
 8  * * *
 9  * * *

Sowie

traceroute from 178.19.224.1 to 178.19.71.117
 1  rudo1-g01-115 (217.17.207.161)  18.793 ms  1.234 ms  5.662 ms
 2  NUE-2.de.lambdanet.net (217.71.100.33)  4.153 ms  4.303 ms  4.192 ms
 3  xe0-0-0.irt1.fra44.de.as13237.net (217.71.96.73)  7.408 ms  7.421 ms  7.426 ms
 4  decix.fra2.tng.de (80.81.192.83)  12.095 ms  12.027 ms  12.094 ms
 5  t4-1.decix.rt02.of.aixit.net (83.141.1.187)  12.080 ms  12.286 ms  12.279 ms
 6  v7.rt03.boe.aixit.net (83.141.0.249)  12.015 ms  12.500 ms  13.041 ms
 7  v3-rt01.boe.aixit.net (83.141.1.97)  12.021 ms  12.247 ms  12.502 ms
 8  * * *
 9  * * *

Führt man Traces von anderen Systemen aus, so scheint alles ok zu sein.

Nach direktem Kontakt zu einem Admin der BundesIT (vielen Dank für die Geduld mit meinen doch sehr erstaunten Fragen) stellte sich heraus.

• Eingehende ICMP-Pakete sind bei der Firewall der Piratenpartei rate-limited.
• Einige Server dort hatten die falsche Netzmaske, deswegen glaubte der Webserver, die Antworten im lokalen Netz ausliefern zu können.

Wie kommt man zu einer falschen Netzmaske? Ganz einfach: Die Server waren classful konfiguriert. 178.19.224.1 und 178.19.71.117 liegen nun mal im gleichen /16 (ehemals Class-B Netz).

Ob des Ratelimits weist der Traceroute die Sterne unterwegs auf: Die Antworten erreichen die tracende Maschine gar nicht.

Nebenbei stellte sich auch heraus, warum Ping komplett gesperrt und ICMP rate-limited ist: Man könnte ja herausbekommen, welche IPs benutzt werden.

Und das Problem wird schon länger gesucht, wie eine Diskussion auf Twitter zeigt.

Auf dem 5. Deutschen IPv6 Gipfel habe ich die Ehre, einen Vortrag zu den Ankündigungen der letzten Jahre zu halten.

Hier die Folien: Fünf Jahre IPv6 im Rückblick (PDF)

Auszüge

Stand der deutschen ISPs zu heitigen Tag (Quelle RIPEness):

• 1/3 hat sich gar nicht mit IPv6 beschäftigt
• 1/3 hat kein IPv6 anliegen
• 1/3 könnte sich mit IPv6 befassen
  • 1/3 davon bietet sichtbar Dienste an (DNS, Mail, Web)
  • Drei Handvoll Provider mit IPv6 im Hosting
  • Eine Handvoll Provider mit IPv6 im Access

Das ist einfach nur peinlich.

Aktueller Stand beim IPv6 Rat

• DAX30: 0 (in Worten: Null)
• Alexa 100: 12
• Exemplarisch GMX
  • Kein IPv6
  • Rate-Limits per IP (CGNs ausgeschlossen)
• Exemplarisch BITKOM, Fortinet, 1&1, O2
  • Nur DNS und beim IPv6 Day
• Exemplarisch DTAG
  • DNS, Web und Mail seit IPv6 Launch Day aktiv
  • Seit August 2012 Ausfall von SMTP über IPv6
  • AAAA für MXe sind immer noch im DNS

Wo stehen wir im Projektplan?

• Planung: 1996-2000
• Begeisterung: 2000-2006
• Ernüchterung: 2006-2011
• Massenflucht der Verantwortlichen:2011-2014
• Bestrafung der Unschuldigen: 2014-2017
• Auszeichnung der Nichtbeteiligten: 2017-2020

Und wer ist für die Auszeichung eigentlich geeignet?

• DE-CIX für IPv6 Peerings ab 2001
• SpaceNet für IPv6 im Access ab 2003
• DTAG für die Ankündigung von IPv6 im Access bis zum Jahresende seit 2004
• DTAG für die Vorstandsentscheidung: "IPv6 ist Infrastruktur, kein Produkt" im Jahr 2006
• Strato für IPv6 im Hosting seit 2009
• Tagesschau für den Aprilscherz im Jahre 2010

Neue Technik, neues Glück. Die Alarmierung hat vor geraumer Zeit neue SIM-Karten bekommen, um SMS zu versenden. Einige Handys zeigen statt SMS "SIM-Nachrichten" an.Warum? Die Lösung im zweiten Versuch, denn eine erste Erklärung war falsch.

Ominöse Nachrichten

Neue Verträge erzeugen neue SIM-Karten und neue SIM-Karten haben neue Voreinstellungen. Warum sendet aber die Karte im M20 Modul des Alarmsystems statt SMS an einige Handies "SIM-Nachrichten"? Warum nicht an alle? Was sind überhaupt "SIM-Nachrichten"? Werden nun wirklich SMS versendet und wandelt das empfangende Handy die um, oder ist es umgekehrt?

Die Symptome der "SIM-Nachrichten" sind:

• Auf einem älteren Nokia sind es einfach SMS, die ankommen.
• Auf einem neueren Nokia sind die "SIM-Nachrichten" wie normale SMS zu empfangen. Sie sehen so ähnlich aus, aber wenn man sie nicht gleich bearbeitet, sind sie weg.
• Man kann auf diese Nachrichten nicht antworten, die Funktion fehlt einfach im Kontext-Menü. Man kann aber die "SIM-Nachricht" in einen Ordner verschieben und da ist es dann eine normale SMS.
• Die "verschwundenen" Nachrichten findet man nicht in einem Ordern unter "Nachrichten". Man muß bei "Nachrichten" die "Optionen" öffnen, um dort den Ordner "SIM-Nachrichten" zu finden.
• Auf einem Samsung ist es weniger schwierig, da sich die "SIM-Nachrichten" wie SMS verhalten. Sie haben nur ein anderes Symbol (eine SIM-Karte statt einem Brief). Man kann aber darauf antworten und sie löschen.
• Kürzlich verweigerte dieses Samsung die Annahme von "SIM-Nachrichten" mit einem dezenten leisen Pieps, während SMS normal eintrudelten. Eine Systemmeldung informierte mich darüber, daß die SIM Karte voll sei.
• Erst beim versuchsweise Öffnen der E-Mail Anwendung "Wollen Sie die Anwendung einrichten?" "Nein, abbrechen" "Dann lösche ich mal die SIM-Nachrichten, ok?" löste sich der Knoten.

SIM ist und bleibt SIM

Die SIM-(Subscriber Identity Module)-Karte speichert Nachrichten. Mit Secure Instant Messaging haben die Nachrichten nichts zu tun. Das war ein Irrweg bei der Problemlösung.

Was ist geschehen?

• Nachrichten, die am M20-Modul versand werden, können im Text oder im PDU Modus gesendet werden.
• Im Text-Modus hängt es von der Mitteilungszentrale ab, welches Ergebnis auf dem Handy ankommt. Möglicherweise gibt es Defaults, die man setzen kann. Dies habe ich nicht verfolgt.
• Im PDU-Modus übermittelt man die Nachricht einschließlich der Header, die die Mitteilungszentrale, die Zielrufnummer, die Zeichensatzkodierung usw. usf. definieren können.

Die Versendesoftware benutzt eine alte, geradezu antike Bibliothek, die aber stabil funktioniert und deswegen nie angefaßt wurde. Diese Software enthält für die PDU Generierung einen Binärblob als Header.

Dekodiert man diesen Header, so findet sich dort ein Wert 0xF2 für das Data Coding Scheme. Die letzen beiden Bits besagen, wie die Nachricht final zugestellt werden soll:

• 00 - Sofortige Anzeige
• 01 - Ablegen an der Mobilschnittstelle (ME)
• 10 - Ablegen auf der SIM Karte (SM)
• 11 - Ablegen in der Datenverarbeitungseinheit (TE)

Welch eine Überraschung! Die Nachricht sollte auf der SIM landen.

Stellt man den DCS auf 0xF1 um, landet die Nachricht als SMS im Handy. Und erstaunlicherweise tut es dann auch!

Witzigerweise werden Nachrichten mit einem DCS von 0xF0 tatsächlich nur angezeigt, aber nicht in irgendeinem Speicher abgelegt. Speichert man die Nachricht nicht sofort bei der Anzeige, ist sie weg. Auch ein nützliches Feature.

Sendet man mit einem DCS von 0xF3, so legen einige Handies die Daten auf der SIM ab, um sie später dem evtl. angeschlossenen Computer übermitten zu können.

Erklärungen

Bleibt nun auch die andren Effekte zu erklären:

• Auf einem älteren Nokia gibt es keine Trennung zwischen SMS und Handy: Alle Nachrichten landen auf der SIM und werden dort bearbeitet. Das erklärt, warum auf diesen Geräte nach ca. zehn SMS einfach Schluß war.
• Auf neueren Geräten existieren beide Speicher und so landen die Nachrichten als "SIM-Nachrichten" auf der SIM. Der Rest sind dann Mängel der SMS-Software.
• Zu glauben, diese Mängel könne es nicht real geben - es müsse stattdessen eine andere Software geben, die das richtig macht - war Auslöser der Suche am falschen Ende.
• Der Effekt trat nicht deswegen so spontan auf, weil die SIM Karte im M20 getauscht wurde, sondern weil auch alle anderen Handys getauscht wurden: Die Empfangsgeräte hatten nun erstmals die Möglichkeit, die Nachrichten so zu verarbeiten wie sie seit Jahren gesendet wurden.

Es war eine lehrreiche und instruktive Suche an der falsche Stelle. Drei Umstellungen (Sender, Mitteilungszentrale, Empfänger) hatten sich überlagert, die Suche ging anfangs in die Irre.

Cisco responded to the IPv4 shortage with a clever approach: Extended PAT. But it has drawbacks when used in real 

From NAT to CGN

Classical NAT does use a different port number on the global site for each connection. This allows to map other external sources to reach the same internal host. If such additional mappings are generally allowed it is called "Cone NAT". Otherwise "Restricted NAT". Even in "Restricted NAT", the mapping can be allowed if approbriate protocol helpers are in action.

Extended PAT does allow a port number of a NAT global address to be reused for multiple connections, i.e. different internal clients, as long as they try to reach different external addresses. So you can map much more than 60000 connections to a single public address. For CGN that means you can add an order of magnitude more customers to the same pool of public addresses than before.

Of course extended PAT does not allow any kind of additional mappings. Cisco describes clearly which protocol helpers will not work anymore.On the other hand, the port mappings become more sticky, so there is a much greater chance to get the same global port as used internally. Using round robin pools help a lot to further increase this chance. A lot of port-sensible protocols does benefit from this port stickyness.

Practical Issues

After running extended PAT for a few days, the system was going to collaps today. Memory is running short:

The config was changed two and a half days ago and started to consume memory quickly. After putting more and more customers on the platform the memory run out this afternoon.

Cisco troubleshooting hints does not help much: "During normal operation, the free memory on the ASA should change very little, if at all. Typically, the only time you should run low on memory is if you are under attack and hundreds of thousands of connections go through the ASA."

There are not an unusual amount of connections. But even "show memory" and "show blocks" does not reveal more than the usual memory footprint. A memory leak?

No, the extened NAT does require more (and dynamically more) memory, because it depends on the number of possible ports (number of IPs in the round robin pool mulitiplied by the number of ports usable) times the number of used destinations. That's a huge number.

So reverting the "extended" and "round-robin" entries results in instant solution ...The free memory jumps back to the typical value.

Problem solved.

Die Cisco ASAs können auf dem (stateful) Failover Interface auch mit IPv6 reden. Was liegt also näher als Link Local IPv6 Adressen dort zu nehmen?

Lokale Kommunikation

Die Doku beschreibt, dass man auf dem Failover Interface Adressen setzen muß. Aber welche Adressen nehme ich? Das Netz ist ja rein intern. Lokale IPv4 Adressen könnten sich mit verschiedenen Kunden beißen, schließlich benutzen ja alle solche. Globale IPv4 Adressen sind rar.

Also IPv6 Adressen. Aber welche? Globalen IPv6 Adresse laufen Gefahr, extern erreichbar zu sein. Das ist für interen Kommunikation unerwünscht. Ja, die ASA ist eine Firewall, aber dieser Traffic ist ja intern relevant. Wer weiß, was da passiert, wenn die gefakte Failoverkommunikation anderswo einkommt. Oder wenn die Pakete versehentlich doch falsch rausgehen, so würden sie normal geroutet.

Dieser Anwendungsfall schreit geradezu nach Link Local Adressen. Also frisch drauflos konfiguriert.

asa(config)# failover interface ip xlink fe80::55:3/64 standby fe80::57:3

primary# show failover interface
        interface xlink GigabitEthernet0/3
                System IP Address: fe80::55:3/64
                My IP Address    : fe80::55:3
                Other IP Address : fe80::57:3

secondary# show failover interface
        interface xlink GigabitEthernet0/3
                System IP Address: fe80::55:3/64
                My IP Address    : fe80::57:3
                Other IP Address : fe80::55:3

primary# show failover
Failover On
Failover unit Primary
Failover LAN Interface: xlink GigabitEthernet0/3 (up)
Version: Ours 8.4(5), Mate 8.4(5)
Last Failover at: 12:33:59 UTC
        This host: Primary - Active
                Active time: 7025 (sec)
                slot 0: ASA5520 hw/sw rev (2.0/8.4(5)) status (Up Sys)
                  Interface management (xxx.13/fe80::55:0): Normal (Monitored)
                  Interface outside (yyy.165/fe80::55:1): Normal (Monitored)
                slot 1: empty
        Other host: Secondary - Standby Ready
                Active time: 0 (sec)
                slot 0: ASA5520 hw/sw rev (2.0/8.4(5)) status (Up Sys)
                  Interface management (xxx.14/fe80::57:0): Normal (Monitored)
                  Interface outside (yyy.168/fe80::57:1): Normal (Monitored)

Das schaut doch gut aus!

Reboot tut gut

Nach einem Reboot des Standby-Gerätes passiert allerdings seltsames:

• Nach dem Boot kommt die Meldung, dass auf dem Failover-Link eine aktive Gegenstelle gefunden wurde.
• Danach wird die Konfiguration vom aktiven Gerät übertragen.
• Die Übertragung der Konfiguration kommt nicht zum Ende
• Nach dem Failover-Timeout erkennen beide ASAs auf "Failover Link failed"
• Die frisch gebootete ASA übernimmt als aktives Gerät.

Damit sind zwei Geräte aktiv und benutzen die gleichen IP Adressen. IPv6 wird auf allen Dateninterfaces der gebooteten ASA deaktiviert, weil die gleiche IPv6 Adresse schon in Benutzung ist. Man möge die Interfaces kurz "shutdown" nehmen und wieder aktivieren.

Offenbar können die Geräte nicht miteinander reden. Obwohl beide die korrekten IPs haben. Oder haben sie die etwa nicht?

primary# show ipv6 interface xlink
xlink is up, line protocol is up
  IPv6 is enabled, link-local address is fe80::55:3
  No global unicast address is configured

secondary# show ipv6 interface xlink
xlink is up, line protocol is up
  IPv6 is enabled, link-local address is fe80::eab7:48ff:fe3d:1b5
  No global unicast address is configured

Was ist denn das?! Ganz offenbar wird die Link-Lokal Adresse beim Secondary nicht gesetzt.

Lösung

Man nehme auf dem Failover-Interface IPv4 Adressen oder globale IPv6 Adressen.

Man behandle die Routingfragen, insbesondere auch das Leaken der Routen in dynamische Protokolle wie OSPF, sehr sorgfältig und setzte vorausschauend entsprechende Filterregeln, um den versehentlichen Zu- und Abgriff der Failoverkommunikation zu verhindern.

So ein dummer Bug.

Neue Technik, neues Glück. Die Alarmierung hat vor geraumer Zeit neue SIM-Karten bekommen, um SMS zu versenden. Nach anfänglichen Schwierigkeiten, wie der fehlenden Freischaltung der "Messaging Allnet Flat" SIM-Karte für SMS, scheint alles zu gehen. Nur einige Handys zeigen statt SMS "SIM-Nachrichten" an. Das Problem wurde kürzlich akut, als mein Handy die Annahme von Nachrichten des Alarmsystems verweigerte.

Ominöse Nachrichten

Neue Verträge erzeugen neue SIM-Karten und neue SIM-Karten haben neue Voreinstellungen. Warum sendet aber die Karte im M20 Modul des Alarmsystems statt SMS an einige Handies "SIM-Nachrichten"? Warum nicht an alle? Was sind überhaupt "SIM-Nachrichten"? Werden nun wirklich SMS versendet und wandelt das empfangende Handy die um, oder ist es umgekehrt?

Da das Problem nie wirklich drückend war, blieb erstmal alles wie es war. Ja, es ist umständlich mit den "SIM-Nachrichten" umzugehen:

• Auf einem älteren Nokia sind es einfach SMS, die ankommen.
• Auf einem neueren Nokia sind die "SIM-Nachrichten" wie normale SMS zu empfangen. Sie sehen so ähnlich aus, aber wenn man sie nicht gleich bearbeitet, sind sie weg.
• Man kann auf diese Nachrichten nicht antworten, die Funktion fehlt einfach im Kontext-Menü. Man kann aber die "SIM-Nachricht" in einen Ordner verschieben und da ist es dann eine normale SMS.
• Die "verschwundenen" Nachrichten findet man nicht in einem Ordern unter "Nachrichten". Man muß bei "Nachrichten" die "Optionen" öffnen, um dort den Ordner "SIM-Nachrichten" zu finden.
• Auf einem Samsung ist es weniger schwierig, da sich die "SIM-Nachrichten" wie SMS verhalten. Sie haben nur ein anderen Symbol. Man kann aber darauf antworten und sie löschen.
• Kürzlich verweigerte dieses Samsung die Annahme von "SIM-Nachrichten" mit einem dezenten leisen Pieps, während SMS normal eintrudelten. Eine Systemmeldung informierte mich darüber, daß die SIM Karte voll sei.
• Erst beim versuchsweise Öffnen der E-Mail Anwendung "Wollen Sie die Anwendung einrichten?" "Nein, abbrechen" "Dann lösche ich mal die SIM-Nachrichten, ok?" löste sich der Knoten.

SIM ist nicht SIM

Das Geheimnis ist simpel: Die SIM-(Subscriber Identity Module)-Karte speichert SIM-(Secure Instant Messaging)-Nachrichten.

Die Frage ist also nur, warum tut sie das und wo kommen die her? Also die Kette von Anfang an:

• Die SIM-Karte im M20 sendet SMS aus.
• Dazu nimmt sie Kontakt zu einer Mitteilungszentrale über das GSM Netz auf. Neuere SIM-Karten haben einen anderen Default für die Mitteilungszentrale als alte Karten.
• Die Mitteilungszentrale stellte die Nachrichten im am besten passenden Format den Empfängern zu. Neuere Mitteilungszentralen beherrschen mehr Formate als alte Zentralen.
• Die SIM-Karte des Empfängers legt die Nachrichten standardmäßig auf der Karte ab, es sei denn eine Anwendung definiert einen anderen Zustellpfad, z.B. die direkte Auslieferung an das Handy.
• SIM-Nachrichten benötigen einen aktiven Instant Messanger auf dem Handy, anderenfalls werden sie vom SMS-Programm in einem Kompatibilitätsmodus angezeigt und verwaltet.

Das ist schon die ganze Geschichte, so man sie erst einmal eruiert hat.

Im Kern stellt sich also heraus, daß Vodafone zwei Mitteilungszentralen betreibt, die unterschiedlich viel Geld kosten. Die +491722270000 ist die alte Zentrale, und +491722270333 ist die Neue, die manchmal noch der Firma Dr. Materna zugerechnet wird. Im Prinzip kostet die -333 fast das Doppelte wie die -000. Dafür kann man dort verschiedenste Gatewayfunkionen aktivieren. Aber Achtung: SMS in fremde deutsche Mobilfunknetze sind - je nachdem wieviele SMS man sendet - mal teuerer und mal billiger über die -000.

Also habe ich kurzerhand die Mitteilungszentrale am Sendegerät auf die -000 umgestellt und nun kommen überall SMS an. Wie früher halt, als die alte Karte sich auch an die -000 gewand hatte. Man hat halt keine Möglichkeit eine Nachricht so zu senden, daß sie als SMS weitergereicht wird. Das liegt allein in den Händen der Mitteilungszentrale.

Was war aber auf Empfangsseite geschehen? Tja, wenn man ein Smartphone hat, es aber nicht ausspielt, sondern nur zum Telefonieren benutzt, dann fehlt halt der Instant Messanger und der Kompatibilitätsmodus greift um sich. Diese ist aber nur sehr rudimentär implementiert, wie ich leidvoll erfahren durfte.

Insbesondere beim Samsung hilft es beispielsweise nicht, die SIM-Nachrichten zu löschen. Das geht zwar, tut aber nicht unbedingt etwas auf der SIM-Karte. Erst die E-Mail-App hat die Löschung dann entgültig vollzogen. So lief der SIM-Nachrichten-Speicher der SIM-Karte voll und sei verweigerte die Annahme neuer Nachrichten.

Und die Kosten? Ein Blick auf die Rechnung beruhigt: Der "Messaging Allnet Flat" ist tatsächlich im Rahmen des Nachrichtenaufkommens pauschal. Es ist also egal, welche Mitteilungszentrale man nimmt. Allerdings berechnet der Anbieter eine montliche Strafgebühr wegen Nichtnutzung der Telefonie.

Man kann halt nicht alles haben.

 Neue Technik, neues Glück. Die Alarmierung hat vor geraumer Zeit neue SIM-Karten bekommen, um SMS zu versenden. Nach anfänglichen Schwierigkeiten, wie der fehlenden Freischaltung der "Messaging Allnet Flat" SIM-Karte für SMS, scheint alles zu gehen. Nur einige Handys zeigen statt SMS "SIM-Nachrichten" an. Das Problem wurde kürzlich akut, als mein Handy die Annahme von Nachrichten des Alarmsystems verweigerte.

Ominöse Nachrichten

Neue Verträge erzeugen neue SIM-Karten und neue SIM-Karten haben neue Voreinstellungen. Warum sendet aber die Karte im M20 Modul des Alarmsystems statt SMS an einige Handies "SIM-Nachrichten"? Warum nicht an alle? Was sind überhaupt "SIM-Nachrichten"? Werden nun wirklich SMS versendet und wandelt das empfangende Handy die um, oder ist es umgekehrt?

Da das Problem nie wirklich drückend war, blieb erstmal alles wie es war. Ja, es ist umständlich mit den "SIM-Nachrichten" umzugehen:

• Auf einem älteren Nokia sind es einfach SMS, die ankommen.
• Auf einem neueren Nokia sind die "SIM-Nachrichten" wie normale SMS zu empfangen. Sie sehen so ähnlich aus, aber wenn man sie nicht gleich bearbeitet, sind sie weg.
• Man kann auf diese Nachrichten nicht antworten, die Funktion fehlt einfach im Kontext-Menü. Man kann aber die "SIM-Nachricht" in einen Ordner verschieben und da ist es dann eine normale SMS.
• Die "verschwundenen" Nachrichten findet man nicht in einem Ordern unter "Nachrichten". Man muß bei "Nachrichten" die "Optionen" öffnen, um dort den Ordner "SIM-Nachrichten" zu finden.
• Auf einem Samsung ist es weniger schwierig, da sich die "SIM-Nachrichten" wie SMS verhalten. Sie haben nur ein anderen Symbol. Man kann aber darauf antworten und sie löschen.
• Kürzlich verweigerte dieses Samsung die Annahme von "SIM-Nachrichten" mit einem dezenten leisen Pieps, während SMS normal eintrudelten. Eine Systemmeldung informierte mich darüber, daß die SIM Karte voll sei.
• Erst beim versuchsweise Öffnen der E-Mail Anwendung "Wollen Sie die Anwendung einrichten?" "Nein, abbrechen" "Dann lösche ich mal die SIM-Nachrichten, ok?" löste sich der Knoten.

SIM ist nicht SIM

Das Geheimnis ist simpel: Die SIM-(Subscriber Identity Module)-Karte speichert SIM-(Secure Instant Messaging)-Nachrichten.

Die Frage ist also nur, warum tut sie das und wo kommen die her? Also die Kette von Anfang an:

• Die SIM-Karte im M20 sendet SMS aus.
• Dazu nimmt sie Kontakt zu einer Mitteilungszentrale über das GSM Netz auf. Neuere SIM-Karten haben einen anderen Default für die Mitteilungszentrale als alte Karten.
• Die Mitteilungszentrale stellte die Nachrichten im am besten passenden Format den Empfängern zu. Neuere Mitteilungszentralen beherrschen mehr Formate als alte Zentralen.
• Die SIM-Karte des Empfängers legt die Nachrichten standardmäßig auf der Karte ab, es sei denn eine Anwendung definiert einen anderen Zustellpfad, z.B. die direkte Auslieferung an das Handy.
• SIM-Nachrichten benötigen einen aktiven Instant Messanger auf dem Handy, anderenfalls werden sie vom SMS-Programm in einem Kompatibilitätsmodus angezeigt und verwaltet.

Das ist schon die ganze Geschichte, so man sie erst einmal eruiert hat.

Im Kern stellt sich also heraus, daß Vodafone zwei Mitteilungszentralen betreibt, die unterschiedlich viel Geld kosten. Die +491722270000 ist die alte Zentrale, und +491722270333 ist die Neue, die manchmal noch der Firma Dr. Materna zugerechnet wird. Im Prinzip kostet die -333 fast das Doppelte wie die -000. Dafür kann man dort verschiedenste Gatewayfunkionen aktivieren. Aber Achtung: SMS in fremde deutsche Mobilfunknetze sind - je nachdem wieviele SMS man sendet - mal teuerer und mal billiger über die -000.

Also habe ich kurzerhand die Mitteilungszentrale am Sendegerät auf die -000 umgestellt und nun kommen überall SMS an. Wie früher halt, als die alte Karte sich auch an die -000 gewand hatte. Man hat halt keine Möglichkeit eine Nachricht so zu senden, daß sie als SMS weitergereicht wird. Das liegt allein in den Händen der Mitteilungszentrale.

Was war aber auf Empfangsseite geschehen? Tja, wenn man ein Smartphone hat, es aber nicht ausspielt, sondern nur zum Telefonieren benutzt, dann fehlt halt der Instant Messanger und der Kompatibilitätsmodus greift um sich. Diese ist aber nur sehr rudimentär implementiert, wie ich leidvoll erfahren durfte.

Insbesondere beim Samsung hilft es beispielsweise nicht, die SIM-Nachrichten zu löschen. Das geht zwar, tut aber nicht unbedingt etwas auf der SIM-Karte. Erst die E-Mail-App hat die Löschung dann entgültig vollzogen. So lief der SIM-Nachrichten-Speicher der SIM-Karte voll und sei verweigerte die Annahme neuer Nachrichten.

Und die Kosten? Ein Blick auf die Rechnung beruhigt: Der "Messaging Allnet Flat" ist tatsächlich im Rahmen des Nachrichtenaufkommens pauschal. Es ist also egal, welche Mitteilungszentrale man nimmt. Allerdings berechnet der Anbieter eine montliche Strafgebühr wegen Nichtnutzung der Telefonie.

Man kann halt nicht alles haben.

An operator from an unnamed hosting provider did collect some data about DNS amplification attacks and send me a copy. This data draws a horrible picture of the real situation out there.

They scanned 157322 IPs of their hosting customers with DNS queries. 10917 of them run an open, unsecured DNS resolver which processes recursive questions from anybody. So nearly 7% of all hosted systems are potential reflection and amplification relays.

Further scanning those systems with Nessus/nmap reveals an awful number of really old systems:

The customers might not know or notice that they are misused, but they accumulate an impressive amount of bandwidth. So let's have a look at the traffic on port 53 crossing the border of this autonomous system:

RZ2 is the oldest location containing most of the oldest servers. Obviously there are the majority of unpatched and vulnerable systems.

If you like, please share your data with me.