TCP Aufzeichnung - Testlauf

Derzeit beschäftige ich mich damit einen Netzwerksniffer zu schreiben, der Informationen über alle gesendeten und empfangenen Nachrichten in einer MySQL Datenbank speichert. Aus den gespeicherten Informationen wird dann ein Multigraph erstellt, der zwischen jedem Knotenpaar mit Kanten Kommunikation über einen Port darstellt. Dazu gemessen werden soll die Länge der Verarbeitung der Nachricht, was bei der Verarbeitung gemacht werden kann, indem die nächste Nachricht gesucht wird, die vom Empfänger gesendet wird. Im Graph wird die Anfrage eingetragen (also in der Richtung vom Fragenden zum Server).

Mein Testnetzerk besteht aus vier virtuellen Debian-Installationen; auf dem ersten ein Apache-Webserver, der ein PHP-Skript abspulen soll, was wiederum auf einem MySQL-Server (auf dem zweiten Knoten), einen FTP-Server (auf dem dritten) und wiederum auf einen Webserver (auf dem vierten) zugreifen soll. Das PHP-Skript des vierten Rechners greift dabei wiederum auf den MySQL-Server zu. So erhält man einen recht einfachen Graphen mit fünf Knoten (vier Rechnern und einem "outside", also außerhalb des verteilten Systems) und 5 Kanten.

Der Agent wird auf jedem Knoten eingerichtet und schnüffelt ab dem Programmstart alle Nachrichten mit, die am Netzwerkgerät ankommen oder abgesendet werden. Im Testlauf wurden alle Nachrichten auf einem MySQL-Server außerhalb des Systems gespeichert und Nachrichten, die dorthin gehen bzw. von dort kamen direkt durch die pcap-Filter ausgefiltert. Auf dem konkreten System entsteht damit der unten stehende Graph. Auffällig sind dabei die Kanten in Rückrichtung, die eigentlich nicht da sein dürften, und daran die Ports im fünfstelligen Bereich. Wo kommen die her?

Eine mögliche Begründung könnte sein, dass eine Bibliothek, die ich verwende zusätzliche Nachrichten versendet. Aber welche Bibliothek sollte das warum tun? Das sieht im ersten Moment aus, als würden die Agenten Peer 2 Peer miteinander kommunizieren. Aber wiederum nicht alle mit allen. Eine andere Möglichkeit ist, dass diese Nachrichten TCP-Nachrichten sind, die die Verbindung steuern. Erinnern wir uns, dass die Agenten nur Nachrichten aufzeichnen, und Informationen über TCP-Verbindungen völlig verloren gehen. Dh. wir zeichnen auch Nachrichten auf, die für den Auf- und Abbau der TCP-Verbindung verantwortlich sind oder die eine Bestätigung des Erhalts sind (ACK). Da ist es natürlich klar, dass diese Nachrichten genau in Gegenrichtung entstehen, werden doch Antworten des Server quittert.

Eine Veränderung des pcap-Filter, sodass keine TCP-Kontrollnachrichten mehr aufgesammelt werden, könnte also Abhilfe bringen. Dahingehend muss ich allerdings noch einmal nachlesen, inwiefern diese Kontrollinformationen an Nachrichten mit Payload gesetzt sein können, oder ob SYN, FIN, ACK,... immer an leeren Nachrichten verwendet werden.