{"id":191,"date":"2007-07-19T17:05:21","date_gmt":"2007-07-19T15:05:21","guid":{"rendered":"http:\/\/security-planet.de\/2007\/07\/19\/practical-packet-analysis\/"},"modified":"2007-07-19T17:05:21","modified_gmt":"2007-07-19T15:05:21","slug":"practical-packet-analysis","status":"publish","type":"post","link":"https:\/\/cyber-fi.net\/index.php\/2007\/07\/19\/practical-packet-analysis\/","title":{"rendered":"Practical Packet Analysis"},"content":{"rendered":"

Vor kurzem ist bei NO STARCH PRESS<\/strong> das Buch \t\t\t \t\t\t“Practical Packet Analysis”<\/strong><\/a> erschienen. Dieses Buch, das den Untertitel “Using Wireshark to Solve Real-World Network Problems” hat, wurde von Chris Sanders<\/a> geschrieben, das technische Review wurde von Gerald Combs<\/a> (dem Sch\u00f6pfer von Ethereal\/Wireshark) durchgef\u00fchrt.<\/p>\n

Das klang gut genug, um das Buch sofort zu bestellen. Die Ern\u00fcchterung stellte sich ziemlich schnell ein. Zum einen hat das Buch nichts mit “solving real-world problems” zu tun, zum anderen ist es auch technisch teilweise fragw\u00fcrdig.<\/p>\n

Aber alles der Reihe nach, ob positiv oder negativ:<\/p>\n

Die ersten 25 Seiten<\/strong> (das Buch hat effektiv nur 150 Seiten) sind eine Einf\u00fchrung in Netzwerktechnik, OSI, Hubs und Switches. Wer das nicht kennt, kommt vermutlich nicht auf die Idee, \u00fcberhaupt ein Buch \u00fcber Paketanalyse anzufassen.<\/p>\n

Die n\u00e4chsten 23 Seiten<\/strong> und zwei Kapitel besch\u00e4ftigen sich mit der Installation, einer Einf\u00fchrung in Wireshark und das Arbeiten mit Captures. Meiner Meinung nach k\u00f6nnte der Part mit den Capture- und Display-Filtern deutlich ausf\u00fchrlicher und mit mehr Beispielen versehen sein. Denn die ben\u00f6tigt man sicher am h\u00e4ufigsten.<\/p>\n

10 Seiten<\/strong> “Advanced Wireshark Features” schlie\u00dfen sich an. Das sind Funktionen wie Following TCP-Streams, Statistics, Endpoints, Conversations und IO-Graphs.<\/p>\n

Im Kapitel 6<\/strong> geht es dann um Common Protocols. Ab jetzt ben\u00f6tigt man die im Internet verf\u00fcgbaren Beispiel-Capture-Dateien, um den Beispielen folgen zu k\u00f6nnen. Die im Buch abgedruckten Screenshots sind nicht komplett, so werden bei der Erkl\u00e4rung von DHCP z.B. nur Discover, Offer und Ack angezeigt. Und wer mit TCP\/IP nicht ganz sattelfest ist, k\u00f6nnte sich bei dem Beispiel auch fragen, warum der DHCP-Server sein Offer an eine IP 192.168.0.10 sendet, obwohl der Client noch keine IP-Adresse hat. Dieses Beispiel war zwar nicht schl\u00fcssig, das gesamte Kapitel zeigt aber ganz gut das Verhalten von einigen wichtigen Protokollen.<\/p>\n

Im Kapitel 7<\/strong> geht es um “Basic Case Scenarios”. Captures zu TCP-Retransmits, Unreachables, und fragmentierten Paketen werden vorgestellt.<\/p>\n

Dann kommen<\/strong> aber die “Cases” und es wird etwas sonderbar. Zum Beispiel, dass Wireshark in vielen Beispielen direkt auf den Endger\u00e4ten installiert wird. Im “About the Author” wird Chris Sanders als Admin von 1800 Workstations und 20 Servern beschrieben. Bei Problemen wird man in solch einer Umgebung wohl kaum einen Sniffer auf den PCs der User installieren.
\nIm Beispiel “No Connectivity” wird dann ein Problem mit einem falsch konfigurierten Default-Gateway analysiert und gel\u00f6st. Als Admin w\u00fcrde ich mir bei dem Screenshot allerdings mehr Sorgen dar\u00fcber machen, dass zwei PCs dieselben MAC-Adressen haben.
\nEin paar “Cases” weiter wird mit Wireshark “bewiesen”, da\u00df es nicht am Netz liegt, wenn der User nicht erfolgreich auf einen Webserver zugreifen kann. Der “Beweis” ist die mitgesnifferte Webseite mit der IIS-Fehlermeldung, die der Server zur\u00fcckliefert. Ob man daf\u00fcr wirklich einen Sniffer auf dem User-PC installieren mu\u00df, wenn man die Fehlermeldung doch auch im Browser sieht, halte ich mal wieder f\u00fcr fraglich.<\/p>\n

Im Kapitel 8<\/strong> gehen die Cases unter dem Motto “Fighting a slow Network” weiter. Es werden Features wie die Expert-Infos und der TCP-Stream-Graph angesrochen, leider werden diese leistungsf\u00e4higen Funktionen nicht n\u00e4her erkl\u00e4rt.
\nKriminell wird es dann im Case “a slow Route”. Mit Hilfe von Wireshark wird “bewiesen”, da\u00df der Grund f\u00fcr ein langsames Netz der lokale Router ist. Der Beweis ergab sich daraus, da\u00df der Router nicht auf ICMP-Echo-Requests antwortet. Aha!
\nBesser wird es auch nicht im Case “Double Vision”. Ein Computer ist sehr langsam, alle Pakete werden doppelt angezeigt, aber mit unterschiedlichen TTL-Werten. Die L\u00f6sung soll eine falsch konfigurierte Subnet-Mask gewesen sein. Eine Erkl\u00e4rung wird aber f\u00fcr dieses Ph\u00e4nomen nicht gegeben.
\nGenauso im Case “A Torrential Downfall”, in dem der Edge-Router unter der Last vieler Verbindungen leidet. Nach dem Durchscrollen vieler Pakete kommt man dann irgendwann zum Paket 99, in dem der Client eine Multicast-DNS-Anfrage nach einer BitTorrent Adresse stellt. Das Problem ist damit gel\u00f6st, auf geht es zum n\u00e4chsten Case.
\nIn diesem (POP goes the E-Mail-Server) wird Wireshark dann auf dem Mail-Server installiert, um zu erkennen, warum die Mailzustellung um bis zu 15 Minuten verz\u00f6gert ist. In dem Capture zeigt sich dann, da\u00df der Server unter der SPAM-Last leidet. Andere Admins h\u00e4tten vielleicht einfach erstmal auf die Mail-Queue geschaut, bevor sie eine extra Software auf einem kritischen Server installiert h\u00e4tten.<\/p>\n

Kapitel 9<\/strong> widmet sich dann der “Security-based Analysis”. Da wird dann ein kompromittierter Client identifiziert, weil dieser kaputte Druckjobs zu einem Printserver sendet. Desweiteren wird mit Wireshark herausgefunden, warum ein PC nach dem Start sofort meldet, da\u00df er in 60 Sekunden heruntergefahren wird (der Blaster eben). Damit noch nicht genug: Zwei kriminelle Mitarbeiter werden \u00fcberf\u00fchrt, weil sie sich gegenseitig angepingt haben (die haben es auch nicht besser verdient, wenn sie einen unverschl\u00fcsselten Covert-Channel verwenden).<\/p>\n

Das Kapitel 10<\/strong> kann dann zwar wieder etwas gut machen, denn die Ausf\u00fchrungen “sniffing into thin air” erkl\u00e4ren recht gut das Sniffen in Wireless Netzen. In diesem Kapitel werden nicht nur ein paar Eigenheiten von WLANs erl\u00e4utert sondern auch die Filter, die man ben\u00f6tigen k\u00f6nnte.<\/p>\n

Gibt es denn auch etwas gutes an diesem Buch? Ja, da ist nat\u00fcrlich das Wireless-Kapitel, das mir recht gut gefallen hat. Ansonsten kann das Buch “genau richtig” sein, wenn man sich noch nie mit Paket-Sniffern besch\u00e4ftigt hat und einen Einstieg in die Benutzung von Wireshark sucht. Mit dem Buch als Anleitung kann man seine ersten Sniffing-Gehversuche starten<\/p>\n

Wenn man aber schon vorher mit Wireshark oder auch einem anderen Protokoll-Analyser gearbeitet hat, ist das Buch sicher keine lohnende Investition.<\/p>\n