Wireshark-Entwickler im Interview: Er war dumm genug, es zu versuchen

Anlässlich des Wireshark Releases 4.4.0 sprachen wir mit Gerald Combs, dem Ideengeber und Hauptentwickler von Wireshark. Neben den Neuigkeiten haben wir uns auch mit einigen grundlegenden Entwicklungen von Wireshark beschäftigt.

Pfister: Warum denken Sie ist Wireshark eines der beliebtesten Protokoll-Analysetools der Welt? Worin unterscheidet sich Wireshark von anderen Tools?

Combs: Einer der Gründe für unsere Beliebtheit ist, dass wir Open Source sind. Vor Jahren erwähnte einer meiner Chefs Wireshark. Er sagte, Wireshark sei das perfekte Open-Source-Projekt, weil es ein Werkzeug ist, dessen Quellcode frei verfügbar ist. Jeder kann dazu beitragen.

Unsere Branche ist so strukturiert, dass jeder, der sich mit einem bestimmten Protokoll auskennt, einen Beitrag leisten kann – und typischerweise kennt sich jemand, der sich mit einem bestimmten Protokoll auskennt, auch mit Programmierung aus. Leute können also einen horizontalen Beitrag leisten und das Tool ausbauen und auf diese Weise auf Protokollebene neue Funktionen hinzufügen.

Wireshark hat im Laufe der Zeit Unterstützung für eine ganze Reihe verschiedener Protokolle angehäuft, und zwar genau aus diesem Grund: weil es so einfach ist. Man kann einfach hinzustoßen und Protokoll-Dissektoren – so nennen wir sie – hinzufügen.

Ich habe schon früh bei dem Projekt bemerkt, dass wir genug Dissektoren gesammelt haben. Nennen wir es eine kritische Masse von Dissektoren. Wireshark wurde für die Leute sehr nützlich – und von da an ging es bergauf.

Pfister: Die Wireshark-Organisation wurde letztes Jahr in eine Stiftung umgewandelt. Können Sie uns die Gründe dafür nennen?

Combs: Das hatten wir schon sehr lange diskutiert. Bis zum Wechsel zur Stiftung wurde Wireshark von meinem damaligen Arbeitgeber gesponsert. Wir hatten also im Laufe der Jahre verschiedene Sponsoren, und ich will hier betonen, dass jeder meiner Arbeitgeber das Projekt auf wunderbare Weise unterstützt hat, worüber ich und die Community sehr froh sind. Gleichzeitig war das der Single-Point-of-Failure und deshalb haben wir darüber nachgedacht, vielleicht zu einer anderen Open-Source-Dachorganisation zu wechseln oder eine eigene Organisation zu gründen.

Schließlich kamen wir zu dem Schluss, dass es in unserem Fall am besten wäre, eine eigene Stiftung zu gründen. Denn wir haben unsere eigene Konferenz und viele andere Dinge, die auf uns zugeschnitten sind, und wir mussten das irgendwie vereinheitlichen. Die Geschäftsführerin der Stiftung hat großartige Arbeit geleistet, um sie auf die Beine zu stellen und das SharkFest – unsere Anwender- und Entwicklerkonferenz – weiterzuführen.

Aber die andere Änderung ist, dass ich durch eine solche Organisation nicht mehr der einzige Ansprechpartner zwischen dem Unternehmen, dem das Vermögen der Organisation gehört, und der Community bin. So war das nämlich früher, als mein Arbeitgeber das Projekt unterstützte.

Ich war die einzige Person, die für diese Firma gearbeitet hat, und Teil des Projekts war. Also war ich auch ein Single-Point-of-Failure. Stattdessen haben wir jetzt ein formelles Verwaltungsmodell. Wir haben eine Gruppe von Leuten, die verschiedene Aufgaben übernehmen können. Sollte ich mich von dem Projekt zurückziehen müssen, ist die Situation jetzt viel besser.

Pfister: Was sind denn die aktuellen Herausforderungen in der neuen Stiftung?

Combs: Wie bei jeder Organisation dieser Art müssen Sponsoren gefunden werden, um den Betrieb aufrechtzuerhalten. Darüber hinaus haben wir all diese Initiativen, die wir auf den Weg bringen und weiterführen wollen.

Um das zu tun, brauchen wir Geldmittel. Dafür haben wir jetzt einige wirklich gute Sponsoren, die Teil des Projekts sind, und ich hoffe, dass wir das weiter ausbauen können. Außerdem überlegen wir, ob wir ein oder zwei Zuschüsse oder so etwas bekommen, um bestimmte Initiativen zu finanzieren.

Pfister: Was waren denn Ihre ursprünglichen Ideen hinter der Entwicklung von Wireshark?

Combs: Ich brauchte einen Protokollanalysator. Am Anfang meiner Karriere arbeitete ich an einer Universität. Ich studierte, arbeitete gleichzeitig an der Uni und arbeitete außerdem als Teil des Netzwerkteams. Letzteres mit einem Gerät, das Sniffer genannt wurde.

Dieser Kasten kostete so viel wie ein Luxusauto. Ich musste ihn über den Campus tragen und ihn an das Netzwerk anschließen und versuchen, Probleme zu finden. Nach der Universität habe ich für einen kleinen ISP gearbeitet, der sich schlicht keinen Sniffer leisten konnte.

Wir hatten natürlich TCPDump und Kommandozeilen-Tools – ich benutze tcpdump bis heute. Aber gleichzeitig brauchte ich einen interaktiven Analysator, etwas mit einer schönen Benutzeroberfläche und so.

Ich hatte gerade meinen Abschluss in Informatik gemacht und dachte, na ja, ich kann das auch. Und ich war dumm genug, es zu versuchen. Ich veröffentlichte die erste Version, und nach ein oder zwei Tagen habe ich Beiträge von Leuten aus der ganzen Welt erhalten. Seitdem ist es meine Aufgabe und eine Herausforderung, mit der Entwicklergemeinschaft Schritt zu halten.

Pfister: Wie viele Mitarbeiter arbeiten derzeit aktiv an Wireshark mit?

Combs: Ich schätze, man könnte die Contributors in zwei Hauptgruppen aufteilen. Wir haben das Core-Developer-Team. Das sind diejenigen, die Änderungen am Quellcode im Repository vornehmen dürfen – wahrscheinlich etwa 10 oder so.

Aber wir haben auch Mitwirkende aus der allgemeinen Gemeinschaft und einige von ihnen tun das regelmäßig – aber viele von ihnen nenne ich Vorbeifahrer, weil sie bloß eine neue Funktion oder ein neues Protokoll benötigen und hierzu Code beitragen. Im Anschluss hört man nie wieder etwas von ihnen.

Pfister: Wie viele Protokolle und Dissektoren sind in der aktuellen Version von Wireshark implementiert?

Combs: Zurzeit unterstützen wir etwa 3000 verschiedene Protokolle. Jedes Mal, wenn Wireshark ein Paket für eines dieser Protokolle empfängt, zerlegt er es in seine Bestandteile und wendet sogenannte Anzeigefilter an. Davon gibt es aktuell 300.000.

Pfister: Wenn wir schon über Anzeigefilter sprechen: Ich habe in den Versionshinweisen zu Version 4.4 einige Neuigkeiten über Anzeigefilter in Bezug auf Profile gesehen. Können Sie uns dazu etwas sagen?

Combs: Der Kern von Wireshark ist die Dissection Engine. Sie nimmt alle Pakete, die Informationen aus verschiedenen Protokollen enthalten, zerlegt sie und zeigt dann jedes Detail über jedes Paket, sofern sie das kann.

Mit jeder neuen Version verbessern wir die Dissection-Engine. Ich stelle es mir gerne als eine Art Zinseszins vor, bei dem man im Laufe der Zeit diese kleinen, schrittweisen Veränderungen vornimmt, aber so immer weiter wächst. Und so macht man am Ende diese riesigen Sprünge.

Aber nun zum konkreten Release: Wir haben Verbesserungen bei der Behandlung von so genannten Wertestrings vorgenommen. Innerhalb eines Protokolls kann es vorkommen, dass ein Wert, der durch eine kleine Zahl dargestellt wird, tatsächlich übereinstimmt.

Was aber in der Protokollspezifikation häufiger vorkommt, ist, dass der Text dazu passt, und deshalb haben wir diese gemeinsame Datenstruktur, die wir Value String nennen, und mit der wir all diese Dinge handhaben. Die jüngsten Änderungen an der Anzeigefilter-Engine ermöglichen jetzt einen Abgleich mit dem Text der mit der Zahl verknüpft ist, anstatt mit der eigentlichen Zahl.

Wir haben zudem die Makros für Anzeigefilter verbessert: Statt eines Anzeigefilters, der mit dem einzelnen Element übereinstimmt, kann Wireshark jetzt abstrakte Dinge extrahieren und Makros und dergleichen einrichten.

Hinzu kommen Änderungen an der Art der Anzeigefilter sowie Verbesserungen der benutzerdefinierten Spalten. In der Paketliste von Wireshark gibt es Spalten, in denen man die Zeit oder die Quelladresse, das Protokoll und solche Dinge sehen kann. Sie lassen sich also gut miteinander verketten, zum Beispiel Anzeigefilterwerte.

Man kann jetzt Arithmetik in diesen benutzerdefinierten Aufrufen machen. Eines der grundlegenden Felder, ist die Framelänge in Bytes. Sagen wir, ich will das in Bits, dann kann ich sagen: Nimm die Frame-Länge, multipliziere sie mit 8, und jetzt habe ich das in Bits. Ein sehr einfaches Beispiel, aber man kann auch komplexere Arithmetik machen.

Pfister: Was denn ist der Grund, dass Sie Version 4.3 überspringen und von Version 4.2.6 direkt auf Version 4.4.0 gehen?

Combs: Die ganze Nummerierung wird sich in der nächsten Version ändern. Vor Jahren hatten viele Open-Source-Projekte, vor allem der Linux-Kernel, ein Versionssystem mit geraden und ungeraden Versionsnummern. Die gerade Nummer war eine stabile Version, die ungerade war die Entwicklungsversion.

Pfister: Wo sehen Sie aktuell Schwierigkeiten bei der Analyse auf Paketebene oder bei der Analyse in Netzwerken im Allgemeinen?

Combs: Es gibt zwei große Herausforderungen. Die eine ist, dass der interessante Verkehr immer weniger zugänglich ist. Wir hosten immer mehr in der Cloud. Aber wie erfasst man den Datenverkehr in der Cloud? Auf unserem SharkFest wird das viel diskutiert. Wie bekomme ich Dinge aus der Cloud und aus diesen unzugänglichen Umgebungen heraus?

Hinzu kommt die Verschlüsselung: Sie macht unsere Arbeit schwieriger, aber sie ist auch sehr wichtig und nützlich. Ich bin froh, dass es sie gibt. Aber gleichzeitig ist das eine Herausforderung, der wir uns stellen müssen.

Was geht also in diesem undurchsichtigen Blob von Bytes vor? Wir müssen uns irgendwie damit arrangieren, diese Daten zu entschlüsseln. Dazu gibt es unterschiedliche Methoden. Aber es erschwert am Ende den Arbeitsablauf für Protokollanalytiker.

Pfister: Und immer mehr Verkehr wird über HTTPS gekapselt – was es noch komplexer macht. Wir arbeiten also nicht mehr mit klar zugeordneten Protokollen, die wir auswerten können, wie HTTP, FTP, SMTP und so weiter. Wir sehen also nur noch HTTPS.

Combs: Ja, genau. Jeder scheint heutzutage alles in JSON über HTTPS zu packen, anstatt separate Protokolle zu nutzen.

Pfister: Wenn wir uns also diese Herausforderungen ansehen, was sind dann Ihre nächsten Pläne mit Wireshark?

Combs: Wir orientieren uns an den Anforderungen der Nutzer: Am Beispiel der TLS-Entschlüsselung für HTTPS sieht man es sehr gut. Das wird meistens durch eine SSL-Schlüsselprotokolldatei gehandhabt. Sie können eine Verschlüsselungsbibliothek einschalten, die die privaten Schlüssel für eine Sitzung protokolliert – ein manueller Prozess. Aber mit der Zeit werden wir Wege finden, um diesen Prozess zu vereinfachen.

Eine weitere unserer Herausforderungen bei Wireshark ist es, mit den modernen Datenraten Schritt zu halten, die mit der Zeit immer höher werden – und ich denke immer, dass wir unsere Grenzen erreicht haben, wenn es darum geht, eine Liste von Paketen zur gleichen Zeit anzuschauen.

Doch dann arbeiten wieder Leute daran und fügen mehr Funktionen hinzu, mit denen man diese großen Datenmengen betrachten kann. Unsere Community ist am Ende viel schlauer als ich, und kommt mit diesen erstaunlichen Lösungen für verschiedene Probleme und das Projekt wächst und wächst.

Pfister: Gerald, vielen Dank für Ihre Zeit und Ihre großartige Unterstützung bei der Erleichterung der Analyse auf Paketebene für alle.

(Das Gespräch wurde auf Englisch geführt und anschließend übersetzt.)

(fo)