US-Zoll kopiert Notebook-Festplatten

Wie man Anfang November lesen konnte, kopiert der US-amerikanische Zoll bei Einreisen in die USA den Inhalte von Notebook-Festplatten und PDAs. Man solle sich dagegen durch das Verschlüsseln der Daten schützen. Mir stellt sich die Frage, wie die USA darauf reagieren würden, wenn dies bei der Einreise in die EU mit US-Bürgern genauso durchgeführt würde. Ich halte jede Wette, dass nicht jeder US-Bürger das klaglos akzeptieren würde.

Never touch a running system oder: Niemals mit dem T-Com Support Kontakt aufnehmen, wenn es denn nicht unbedingt nötig ist

Ich hatte ja seinerzeit wegen der Paketverluste auf dem Weg zu meinem vServer eine Meldung bei der T-Com aufgemacht. Nun wurde zweimal meine Leitung durchgemessen und mit bestätigt, dass es nicht an der Leitung liegt. Super, dass wusste ich aber bereits.

Aber dafür bricht die Signal to Noise Ratio nun drastisch ein. Wie man in der Grafik sieht, geschieht dies viel heftiger, als es früher der Fall war.DSL-SNR

Bis auf 2dB geht die SNR zurück. Ich bin mal gespannt, wann die Leitung tot ist ….

Luftraumüberwachung für jedermann

Mit Hilfe des SBS-1 ist es nun für jedermann möglich, Flugdaten von Flugzeugen, die sich in der Nähe befinden, in Echtzeit zu empfangen und auszuwerten. So senden Flugzeuge, die das System ADS-B (Automatic Dependent Surveillance Broadcast) zur Kollisionswarnung an Bord haben, kontinuierlich ihre Flugaten, wie Flugnummer, Position und Höhe.

Dieser Empfänger bietet sich auch für Bürgerinitiativen an, die gegen Unterschreitungen der Mindestflughöhe beim An- und Abflug in der Nähe von Flughäfen, Daten sammeln wollen. Nachteil dabei ist, dass nicht jedes Flugzeug mit diesem Sender ausgestattet ist. Einem Artikel bei FAZ.net zufolge kann man aber recht schnell viele Daten sammeln.

Auf der anderen Seite stellt sich natürlich die Frage, ob die ausgestrahlten Daten nicht wenigstens sensitiv sind und vielleicht nicht so großzügig verteilt werden sollten. Es lassen sich sicherlich Szenarien konstruieren, in denen diese Daten missbraucht werden.

Eine interessante technische Spielerei ist das Gerät aber allemal. Für 780 Euro kann man das Gerät erwerben. Der Gebrauch ist in Deutschland angeblich aus zulässig.

Weitere Erkenntnisse

Mich wunderte, warum die Paketverluste nur in einer Richtung festzustellen sind. Ich bat daher Herrn Vollmar, mir ein Traceroute aus seiner Richtung zu senden. Das Bild sieht damit wie folgt aus:

1 83.151.25.1 (83.151.25.1) 1.181 ms 0.756 ms 0.668 ms
2 RS8000.AS33956.v-bone.net (80.244.255.241) 0.743 ms 0.248 ms 0.410 ms
3 nbg-s1-rou-1071.DE.eurorings.net (134.222.107.33) 0.545 ms 0.707 ms 0.538 ms
4 nbg-s1-rou-1073.DE.eurorings.net (134.222.228.78) 12.685 ms 176.699 ms 11.064 ms
5 ffm-s1-rou-1021.DE.eurorings.net (134.222.228.69) 4.611 ms 4.358 ms 4.118 ms
6 ffm-s1-rou-1022.DE.eurorings.net (134.222.231.142) 4.484 ms 4.425 ms 4.324 ms
7 ffm-s2-rou-1001.DE.eurorings.net (134.222.231.214) 4.969 ms 4.574 ms 4.491 ms
8 ffm-s2-DTAG-gw.DE.eurorings.net (134.222.105.234) 4.404 ms 4.007 ms 4.189 ms
9 F-EA3.F.DE.net.DTAG.DE (193.158.5.21) 9.031 ms 8.824 ms 9.169 ms
10 f-ea1.F.DE.net.DTAG.DE (62.154.17.182) 9.848 ms 9.893 ms 10.129 ms
11 217.0.66.1 (217.0.66.1) 20.557 ms 13.207 ms 9.917 ms

Man sieht, dass der Rückweg ein völlig anderer ist als der Hinweg. Hier kommt der vermeintliche Problempunkt 62.156.139.98 nicht vor. Allerdings sollten die Rückpakete diesen beim Rückweg passieren und dann Gefahr laufen, verworfen zu werden.

Neues gibt es auch vom Ticket bei der T-Kom zu berichten: Ich erhielt gestern nachmittag eine Mail, dass kein Fehler bei meinem DSL-Anschluss festgestellt werden konnte und das Ticket daher nun geschlossen werde. Als Krönung stand (allerdings erst ca. 2 Stunden später) statt der 6 Mbit/s nur ca. 1-2 MBit/s zur Verfügung. Nach weiteren 4 Stunden hat sich dies aber von alleine behoben. Mir sagte früher mal ein T-Com Techniker, dass die Anschlüsse immer erst auf 1 MBit/s gestellt werden und dann innerhalb von 24 Stunden ihre richtige Einstellung erhalten.

Ich habe nun heute mein Glück nochmal mit einer neuen Meldung versucht. Mal schauen, vielleicht liest sie ja diesmal einer.

 

Ein Telefonat mit der T-Com Hotline

Gestern abend habe ich dann eine Störungsmeldung aufgemacht. Dies ging leider nicht über meine Kundennummer. Es gab nur die Meldung

Unser System kann leider die von Ihnen eingegebenen Daten nicht finden. Bitte überprüfen Sie Ihre Eingaben auf Richtigkeit und versuchen Sie es erneut.

Naja, also alles händisch eingegeben. Ich habe alles beschrieben und darauf hingewiesen, dass es wohl kein Problem des DSL-Anschlusses ist.

Nach dem Absenden gab's eine Mail, ich möge doch bitte im Internet den Status verfolgen. Gesagt – getan. Leider klappte das noch immer nicht. Ich rief daraufhin bei der Hotline an, um klären zu lassen, wieso das denn nicht geht. Nach 5 Minuten in der Warteschleife (das war das erste Mal, dass es mir bei der Telekom so erging!) mit der Ansage, ich möge es doch bitte im Internet versuchen, hatte ich einen Mitarbeiter in der Leitung. Er konnte mir nicht erklären, warum das im Internet nicht geht. Er wollte mir gleich bei meinem eigentlichen Problem helfen. Ich habe es ihm dann nochmal geschildert. Da erkannte er, dass er ja gar nicht meinen Anschluss durchmessen muss. Richtig, sagte ich ihm. Mir sei schon klar, dass er mir im Zweifel nicht direkt helfen kann. Er möge aber doch bitte das Problem an die passende Stelle weitergeben. Er versprach, sich kundig zu machen und mir bescheid zu geben.

In der Tat rief er zehn Minuten später an und meinte, es gebe tatsächlich eine Stelle, die dafür zuständig sei. (Wäre auch traurig gewesen, wenn es sie nicht gäbe…) Aber dahin könne ich mich nicht direkt wenden. Er werde dies tun. Man werde sich bei mir melden.

Dies ist der Stand von gestern 20:10 Uhr. Seitdem hat sich nichts getan….

Stand der Dinge Thema „Anbindung vServer“

Dieses Thema wird immer verworrener: Heute gab es den ganzen Tag eigentlich kaum eine Zeit, in der die Anbindung konstant war. Die folgende Smokeping-Grafik verdeutlicht dies:

Smokeping

Nur nachts von 0:00 Uhr bis morgens bis ca. 9:00 Uhr "rauchte" es nicht und es traten keine Paketverluste auf. Dies passt zu der seit gestern abend durchgeführten Messung per Smokeping auf ICMP-Basis:

Smokeping ICMP

Nachts ist alles im Lack; es treten keine Paketverluste auf. Tagsüber raucht es zwar nicht mehr, aber statt des Grüns wird die Kurve türkis: Paketeverluste.

Betrachten wir nun mal den Lauf der Pakete genauer. Ein mtr -r -c 250 www.jerrywho.de erbrachte eben die folgenden Daten:

HOST: firewall                    Loss%   Snt   Last   Avg  Best  Wrst StDev
1. ??? 100.0 250 0.0 0.0 0.0 0.0 0.0
2. 217.0.66.2 0.0% 250 6.5 7.0 6.0 86.0 5.1
3. l-eb1.L.DE.net.DTAG.DE 0.0% 250 13.2 13.5 12.1 91.8 5.3
4. 62.156.139.98 5.2% 250 14.0 15.0 13.8 93.0 5.2
5. kpn.dhk.nbg.v-bone.net 6.8% 250 14.8 15.4 13.8 94.3 5.9
6. AS33956.RS8000.v-bone.net 12.8% 250 15.5 107.4 14.3 3779. 500.0
7. m15s09.vlinux.de 6.8% 250 14.7 15.8 14.1 95.2 9.0

 

  • Diese Daten habe ich direkt von meiner Astaro Firewall aus gewonnen. Da bei der Astaro normalerweise kein mtr mitgeliefert wird, habe ich auf einem anderen Linux-System das mtr statisch kompiliert. (Per LDFLAGS=-static ./configure -without-gtk –with-curses )
  • Von einem System hinter der Firewall findet man Paketverluste direkt von der Firewall. Das kann ich nicht ganz nachvollziehen, da selbst ein Flood-ping (per ping -f) zu keinen Paketverlusten führt. Da ich aber diesen Effekt, vom ersten Hop Paketverluste gemeldet zu bekommen, auch auf einem ganz anderen System in einem anderen Netz gesehen habe, tippe ich hier auf einen Fehler im mtr.

Betrachtet man sich die Hops oben, so sieht man, dass das Übel an der vierten Stelle am Hop 62.156.139.98 seinen Lauf nimmt. Dieser gehört noch zum Netz der DTAG. Die Paketverluste aller dahinterliegenden Hops lassen sich durch den Fehler weiter vorne erklären.

Aber wie kann es dann sein, dass der sechste Hop (AS33956.RS8000.v-bone.net) mehr Paketverluste vorzuweisen hat als der siebente (m15s09.vlinux.de)? Sollte dies ein Einzelfall sein?

Smokeping 2 ICMP

Hier sieht man, dass bei diesem Hop immer Paketverluste bestanden, auch zu den nächtlichen Stunden, an denen der dahinterliegende Hop keine Paketverluste hatte.

Herr Vollmar von vollmar.net, der mir immer innerhalb kurzer Zeit antwortet, richtete auch ein Smokeping ein, das von seiner Seite den aus seiner Sicht letzten Hop überwacht. Dies ist nicht etwa die 217.0.66.2 sondern die 217.0.66.1. Er tippt auf ein Problem bei der DTAG in Frankfurt. Der augenscheinliche Überltäter (62.156.139.98) scheint dem Namen des nächsten Hops nach aber bereits in Nürnberg zu stehen.

Ich bin von der Theorie noch nicht überzeugt, dass es ein Problem in Ffm mit dem DSL-Anschluss ist. Sieht man sich das HTTP-Smokeping an, das auf einen Frankfurter Server geht, so sieht man, dass da alles im grünen Bereich ist. (Achtung andere Zeitskala!)

Smokeping 2

Mal schauen, was denn die T-com zu meinem Phänomen sagt.

Übersicht diverser VPN-Techniken auf heisec.de

Auf heisec.de finden sich fünf Mitschnitte im WMV-Format heise Security Konferenz. Es handelt sich um den Beitrag von Jürgen Schmidt, seines Zeichens Chefredakteur bei heise Security zum Thema VPNs.

Er geht zunächst auf pptp ein und dass man es in Neuinstallationen nicht mehr einsetzen sollte. Als nächstes beschreibt er den "Platzhirsch" IPsec.

Daraufhin stellt er als Alternativen SSL-VPNs, als einfache Variante für den http-Bereich und OpenVPN als vollwertiges VPN vor. Leider wurde bei diesem Beitrag es versäumt, regelmäßig auf die Folien umzuschneiden.

Dennoch handelt es sich um ein paar sehenswerte Filmchen für diejenigen, die sich bisher noch nicht mit dem Thema VPN auseinander gesetzt haben.

Noch immer abends erhebliche Paketverluste

Auch heute abend treten wieder erhebliche Paketverluste auf. Ich habe nochmal Kontakt zu meinem vServer-Provider vollmar.net aufgenommen. Herr Vollmar gab mir den Tipp, die DTAG mit Support-Anfragen "zu nerven", damit sie endlich in die Pötte kommt. Ich habe allerdings wenig Hoffnung, dass ich als armer DSL-Nutzer dort etwas ausrichten werde.

Zur Verdeutlichung des Problems hier nochmal ein aktuelles Bild meines Smokepings:

Smokeping

Ich habe neben dem HTTP-Ping nun auch noch ein normales Smokeping laufen, das "normale" ICMP-Pakete verschickt. Auch dort sehe ich die Paketverluste. Aus der Gegenrichtung sieht man sie angeblich nicht.