nicht angemeldet
Sniffer für Linux einfach zu bedienen gesucht
Hallo Forum,
ich suche ein Linuxtool mit dem ich HTTP Kommunikation mitloggen kann, ich möchte die Kommunikation zwischen einem Java-Applet und einem Webserver beobachten.
Das ganze sollte nicht allzu kompiziert zu installieren und zu gebrauchen sein, und nicht unbedingt mit anderen Features überladen.
bin dankbar für jeden Tip
Marko
-
Sup!
man tcpdump
Gruesse,
Bio
-
Hi Bio,
danke für den Tip, aber ich brauche den HTTP Request als Klartext, tcpdump scheint aber nur die TCP Informationen rauszurücken. Oder muss ich einfach die manpage noch etwas genauer lesen ?
Gruss
Marko
P.S.: Ich gestehe nur eine Schwache Grundvorstellung vom OSI-Modell zu haben, und sehr wenig über TCP/IP und HTTP zu wissen.
-
Hi Bio,
danke für den Tip, aber ich brauche den HTTP Request als Klartext, tcpdump scheint aber nur die TCP Informationen rauszurücken. Oder muss ich einfach die manpage noch etwas genauer lesen ?
Die Option -s ist dein Freund. Damit kannst du die Anzahl der Bytes hochsetzen, die angezeigt werden. Setze sie auf die Länge, die du für den HTTP-Request vermutest, plus 68 Byte für den TCP-Header. Bei Ethernet ist die maximale Paketgröße irgendwas kleiner 1600 Byte, mit -s 1600 sammelst du also die kompletten Informationen der Übertragung.
Wichtig ist, daß du durch Angabe eines Filters wirklich nur den Datenverkehr zwischen dem Webserver und dem Java-Client beobachtest (Filtern - das ist der Teil über "expression" in der Man-Page). Andernfalls ertrinkst du im Datenstrom. Beschränke die Ausgabe auf den Port 80 des Webservers (oder auf den Port, auf dem er läuft), und falls der Webserver noch anderen Clients was liefert, auch noch auf die Adresse des Javaclients (ohne Portbeschränkung).
Gruss
Marko
P.S.: Ich gestehe nur eine Schwache Grundvorstellung vom OSI-Modell zu haben, und sehr wenig über TCP/IP und HTTP zu wissen.
Das OSI-Modell wurde auch nur in ein oder zwei heutzutage seltenen Netzwerkarchitekturen umgesetzt. TCP/IP ist nicht 100% OSI-konform, weil es Schichten zusammenfaßt, die laut OSI getrennt sind (oder sein müßten). Während OSI sieben Schichten hat, sind es bei TCP/IP eigentlich nur vier (oder fünf?).
HTTP ist die oberste Schicht, und für dich interessant (auf gleichem Level laufen FTP, Telnet, SMTP, POP3 etc...). TCP ist darunter angesiedelt, und läuft auf dem gleichen Level wie auch UDP, ICMP, IGMP etc. IP ist unter TCP angesiedelt und hat (außer den IP-Adressen) eigentlich keine für dich interessanten Aspekte mehr. Ganz zuunterst ist dann die Übertragung über ein Netzwerkmedium (was man vielleicht nochmal in zwei Schichten, analog zu OSI, aufteilen könnte).
- Sven Rautenberg
-
Sup!
Tja, und die Ethernet-Protokolle teilen dann die zweite Schicht oft noch in zwei Schichten auf, und irgendwo dort liegt normalerweise auch der Übergang zwischen Hardware- und Softwarelösung.
Und bei ATM gibt es vier Schichten, wobei das QoS und das Netzwerkmanagement-Protokoll (Quality of Service == QoS) sich einfach jedes soundsovielte Paket aus dem Datenstrom klauen und weitere Pakete mit irgendwelchen Netzwerkverwaltungsinformationen reinschummeln können, so daß diese Schichten an jedem Schichtenmodell vorbei operieren können.
Böse moderne Netzwerkkarten und Betriebssysteme erdreisten sich zudem, sich alle Schichten darauf einigen zu lassen, in welchem Speicherbereich Pakete zusammengebaut werden sollen (so daß alle Schichten auf den gleichen Speicher zugreifen und dort ihre Header hinschreiben, anstatt daß jede Schicht von der Vorgängerschicht das Paket bekommt, kopiert, und mit weiteren Headern an die nächste weiterschickt - daas macht man aus Performance-Gründen, denn sieben Mal kopieren ist nicht schnell genug), was strenggenommen das Schichtenmodell ebenfalls ad absurdum führt, weil eigentlich die Schichten von der Existenz der anderen "nichts wissen" sollten, und weil so die Schichten nicht mehr unabhängig voneinander sind, so daß die ganzen Schichten im Prinzip untrennbar zu einem Klumpen verbunden und zusammengepresst sind.Gruesse,
Bio
(Ist es nicht toll, über Netzwerkprotokolle zu räsonieren? Was haltet ihr vom Slotted-Aloha-Protokoll?)
-
-
-
-
Hi,
Wenn du KDE hast, benutz ksnuffle. Ist wirklich kinderleicht zu bedienen und hat außerdem eine nette GUI.
Achte aber darauf, dass du alle Plugins mitinstallierst, damit du die HTTP-Kommunikation auch richtig dargestellt bekommst.Grüße,
Crunch -
Moin
ich suche ein Linuxtool mit dem ich HTTP Kommunikation mitloggen kann, ich möchte die Kommunikation zwischen einem Java-Applet und einem Webserver beobachten.
Das ganze sollte nicht allzu kompiziert zu installieren und zu gebrauchen sein, und nicht unbedingt mit anderen Features überladen.Also mein Liebling was sniffer angeht ist ja immer noch ethereal. Benutzt zwar auch tcpdump im Hintergrund hat dafür aber eine schöne Oberfläche im Vordergrund.
Wenn du nur die Verbindung zu einem Port überwachen willst, solltest du den gleich als Filter vor dem Starten des capture-Vorgangs angeben (mit "port 80" etwa, ist übrigens der gleiche Filter den tcpdump nehmen würde). Wenn du dann die gesamte 'Unterhaltung' schön übersichtlich dargestellt haben willst, musst du einfach auf eins der Pakete der Verbindung rechtsklicken und "Follow TCP Stream" auswählen. Dann kriegst du ein neues Fenster dass die gesamte Konversation enthält.--
Henryk Plötz
Grüße aus Berlin