Die alten Herren von der Piratenpartei

Hallo Lutz,

ich als Admin der BundesIT bin gerade etwas verwirrt:
- Der erste Trace zeigt das dort offensichtlich kein Problem mit fehlerhaft konfigurierten Netzen vorlag, schließlich ging die Anfrage über ein Gateway und versackte nicht im lokalen Netz.

Die geblockten ICMP Anfragen sind auf Grund von div. Netz-Sniffern von mir etabliert worden. Kann man drüber streiten, aber definitv keine böse Sache.

Und ein ratelimit gibt es bei uns für ICMP gar nicht.

Also: Woher hast du diese Informationen?

Manches in der Aussage ist korrekt, anderes totaler Humbug.

Hallo Lutz, ich bin ein wenig verwirrt. Entweder drückst Du Dich unklar aus, oder Du hast vergessen wie traceroute funktioniert. Die "Sternchen" unterwegs können ja auf Grund der Funktionsweise von traceroute überhaupt nicht auf eine Ursache beim Zielhost zurückzuführen sein, da diese Pakete auf Grund der eingeschränkten TTL gar nicht so weit gekommen wären. Wenn man sich die Hosts nach den "Sternchen" ansieht, sind das Router noch weit vor dem Piratennetz (der eine fehlende Hop ist noch in Thüringen, der andere im Netz von Lambda). Wenn von dort keine "TTL exceeded" ICMPs zurückkommen, dann liegt das mit an Sicherheit grenzender Wahrscheinlichkeit nicht an irgendwelchen ICMP-Pfuschereien bei der Piratenpartei.

Ok, ich sehe den Denkfehler. Der erste Traceroute ist VON einem Server der Piratenpartei. Aber auch dann müssen die fehlenden Hops nicht an der Limitierung liegen. Dass zu beliebigen Zielen unterwegs mal einzelne Hops fehlen beobachte ich ständig und die Ursachen dafür sind vielfältig.

Nimm einen der anderen Quellen von traceroute.org (im Text verlinkt), die zeigen alle konsistente Traces ohne diese Daueraussetzer.

Wer bei einem Traceroute selbst von seinem lokalen Router und den direkt danach folgenden Routern keine Antworten sieht, hat ein lokales Problem. Die sporadischen Verteilung tatsächlich durchkommender Antworten legt ein Rate Limit von ICMP am Border Router / Firewall so nahe, daß ich das als sicher annahm und dieses unwidersprochen mehrfach kommuniziert habe.

Alle Aussage von mir sind ein "educated guess".

Ja, nicht das ganze Netz war "classful", sondern nur einige Server. Deswegen konnte man von anderen Systemen tracen, bekam aber keine Antwort u.a. vom Webserver.

Vielleicht habt ihr auch eine ganz andere Infrastruktur und es war ein interner Router. Du kannst ja mal die Netzpläne online stellen.

... lalala ...
Was macht eigentlich so ein 'gegen ping gesichertes Netz', wenn man ein paar 'Päckchen' mehr schickt? Etwa so:

#!/bin/bash
clear
echo "Thou shalt not ..."
echo "...do anything illegal with this little script!"
read -p "target IP or domain.tld ? " target
read -p "packetsize in bytes (0-65535)? " packetsize
read -p "how many instances ? " instances
sleep 1
echo "the instances will now be started sequentially ... let´s let the shit hit the fan ;3"
counter=0
while [ "$counter" != "$instances" ]; do
nohup>/dev/null ping -s $packetsize -i 0.3 $target &
counter=`expr $counter + 1`
echo "instance $counter is up and firing ... "
done
echo "mission accomplished ;3"
echo "all instances are now firing as they´re told ..."
echo "if you´d like to stop the fire ..."
echo "just press ALT+F2 and type »killall ping« and press ENTER ;3"
sleep 2
echo "bye!"
sleep 5

Kann man dann vielleicht wenigstens eine Fehlermeldung herauskitzeln? Habe bislang nur mit virtuellen Maschinen herumspielen können, weil mir zum spielen in der 'Wildnis' die notwendige Einwilligung fehlte, konnte aber lokal bis 40G Bit/s Last erzielen... da war dann auch für Fehlermeldungen kein Platz mehr. ;)

Aber grundsätzlich würde mich schon interessieren, wie man ggf. die IPs der 'Star-Hops' herausfinden kann, insbesondere im Kontext von QoS bei mobilen Internetanschlüssen. Ich bin auch für freundliche RTFM-Hinweise dankbar - mit Angabe von zu suchenden Stichworten oder Literaturverweisen - ich lerne gern (selbstständig!) dazu. Danke!

So long!

"educated guess" aha sehr schön, dann mach es kenntlich und stelle es nicht als Tatsachen-Behaupting ins Netz.

Und BTW: Wenn ich nachts zum 30x mal an einem Tag nenn dämlichen nmap Portscan auf die gesammte Range entdecke mach ich nun mal IMCP8 dicht.

Und was eine Classfull Theorie betrifft: Wir haben alle öffentlichen IP's NUR, ich wiederhole NUR auf den Firewalls.

Also, stell das doch bitte einfach mal deutlich dar, dass du nur geraten hast.

Danke.

Wenn traceroute nicht geht, nehm ich halt tcptraceroute. Das hat bei Euch prima funktioniert. Die ICMP Typ 8 (Echo Request, aka Ping) Sperre ist lächerliches Sicherheitstheater.

Die Aussage, daß bei Euch öffentliche Adressen nur auf der Firewall vorliegen, verwundert mich allerdings wirklich. Wie kann dann ein Traceroute aus Eurem Netz funktionieren, während der daneben stehende Server die Daten nicht zustellen kann? Habe Ihr mehrere Firewalls und den Test aus einem ganz anderen Netzsegment gemacht? Warum debuggt Ihr das Problem, daß seit dem 11.1. bei Euch bekannt ist (siehe Twitter), nicht dort wo es auftritt?

BTW: Bist Du die gleiche Person, die https://piratenpad.de/p/PiratenITVerriss-TheAnswer geschrieben hat? Oder handelt es sich bei dem Pseudonym um einen Role Account?

Wenn ein Traceroute auf bestimmten Positionen keine Antworten liefert, versucht man es von anderen Stellen aus, deswegen gibt es die Webseite traceroute.org. Und wenn andere Meßstellen keine Probleme mit einem sauberen Traceroute haben (und die wenigen Antworten, die man selbst sieht auch dort auftauchen), dann liegt das Problem fast immer an einem selbst.

<blockquote>
Und BTW: Wenn ich nachts zum 30x mal an einem Tag nenn dämlichen nmap Portscan auf die gesammte Range entdecke mach ich nun mal IMCP8 dicht.
</blockquote>
Dämlich ist es, ein IDS auf dem externen Interface einer Firewall laufen zu lassen. Genauso dämlich wie nmap ohne "-Pn" zu verwenden - wegen der unbedarften Admins, die ping sperren.

Ich fasse noch einmal zusammen. Erst mal das eigentliche Thema:

- dein erster hier veröffentlicher Traceroute zeigt, das wir von der bemängelten IP dich nicht erreichen konnten. ein "classfull" Problem war es aber auch nicht, da der trace offensichtlich geroutet wurde
-- Ergo: Es GAB ein Peering Problem
- Das traces aus anderen Ecken der Welt gehen ist bei einem Peering Problem nicht weiter verwunderlich
- Nachdem wir gestern noch einmal die Fehlermeldung erhielten, haben wir noch einmal, den selben Test gemacht. Und erhielten diesmal ein anderes Bild, denn das Routing hat schon bei uns nicht funktioniert. Wir haben das Problem behoben und seit dem geht alles wieder.
-- Ursache war eine Änderung NACH dem 11.1

Ich weiß ja nicht wo du deine Infos her beziehst, und wie du auf die Idee kommst, das zum selben Zeitpunkt jemals ein Trace ging wärend am anderen Ende keine Daten angekommen sind ( aus den Traces lies sich das nicht wirklich schließen, die sehen aber zugegeben seltsam aus)

Und nun nur noch kurz zu den "Vorwürfen" in den Kommentaren:
- Es gibt kein IDS, aber Idioten die nicht nur -PN vergessen sondern auch gleich noch ein -sV anmachen. Um das zu erkennen reicht die Log eines Dienstes ...
- Ja, ich bin die selbe Person die auch TheAnswer online gestellt hat, nun kann ich dich auch wieder zuordnen.

DU bist doch die Person die Behauptet ein VPN wäre Blödsinn und man hängt natürlich alle Systeme incl. Testumgebungen oder Windows-Systeme mit Personenbezogenen Daten und einem offenenen RDP Port direkt ins Netz!

Mir stellte sich die Sache so dar:
- Ich erhalte vom Kunden eine Fehlerbeschreibung (mehrtägige Nichterreichbarkeit).
- Der Fehlerbeschreibung liegen beiden Traces und die Aussage "Peering Problem" bei.
- Ich muß annehmen, daß die Traces mit dem Problem zu tun haben und im Rahmen des Analyse, die zu "Peering Problem" geführt hat, entstanden sind.
- Ich muß weiterhin davon ausgehen, daß ein als akut beschriebenes Problem nicht zwischenzeitlich mehrfach gefixt und anderweitig neu verursacht wurde.

Der Trace von einem System in der Nähe des Webservers aus zeigt massive Paketverluste quer durch alle Hosts. Die Symptome dieses Paketverluste lassen sich am einfachsten (und in der Regel auch zutreffend) durch einen ICMP (Rate-Limit) Filter kurz vor der tracenden Stelle erklären.

Erst nachdem lokale Probleme für meine Begriffe (ich mache zuviele Fehler selbst, um sie sofort anderen in die Schuhe zu schieben) ausgeschlossen werden konnten, habe ich das Problem auf verschiedene Weisen nachgestellt und dann gezielt mit Peers und Uplinks gesprochen.

Am Ende waren wir uns alle einig, daß die Antwortpakete auf TCP/80 Anfragen an den Webserver zwar hingeschickt, aber nicht eingehend beobachtet werden können. Wohl aber kommen die letzten Pakete von Eurem ISP aus dem Tcptraceroute beobachtbar zurück.

Erst dann habe ich versucht, einen Kontakt zu jemanden zu finden, der sich um den Webserver und das Netz kümmert. Ich bin zu altmodisch, um die von der BundesIT vorgeschlagenen Kommunikationswegen nutzen zu können. IRC, Usenet, Web, E-Mail und Telefon sind meine typischen Kommunikationsformen. Außerdem hatte ich nicht vor, einen Rattenschwanz an zusätzlichen Problemen loszutreten, nur weil ich die offiziellen Kanäle benutze und dort das passende Shibboleth nicht kenne.

Glücklicherweise gab es Leute, die über ein oder zwei Ecken dann jemanden erreichten, der die falsche Netzmaske bemerkte. Auf diese Weise konnte das Problem gelöst werden. Hier hätte Schluß sein können.

Als ich aber so meine Erkennisse (alles "educated guess") kommunizierte, habe ich Zustimmung zur Analyse und Entsetzen über die Art des Umgangs mit diesem Problem erleben dürfen. Deswegen habe ich darüber geblogt: Weil es für mich unfaßbar ist, das mit so viel Unverstand in produktiven Netzen gestochert wird.

Deine Kommentare zeigen mir zweierlei:

1) Du mußt ruhiger werden. Alle machen Fehler. Oft genug noch viel haarstäuberendere als Classful Addressing. Aber Du bist auf einer öffentlichen, ja politischen, Bühne. Dort kann man sich diese Entgleisungen nicht leisten.

2) Das, was Du technisch für richtig oder unrichtig hälst, wurde von anderen vor Deiner Zeit erdacht, erstellt und benutzt. Diese Leute waren nicht dumm oder lebten nur in ihrem Elfenbeintum. Es lohnt sich herauszufinden, warum Dinge sind, wie sie sind. Vor allem, bevor man sie verändert oder (wie Du) wegfiltert.