PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : **packetanalyse**



randy
16.02.04, 13:59
Ich hoff hier funkt es besser als im LINUX-Allgemein Teil

Ich hab ein Schul-Protokoll über Paketanalyse geschrieben und mich würde interessieren ob das alles stimmt was da drin steht , evt. verbesserungsvorschläge,....

thx
randy²

protokoll (http://mitglied.tripod.de/toymachine03/prot.pdf)

D_O_Z_E_R
16.02.04, 15:40
hallo,

sieht doch ganz gut aus...

würde vielleicht in den arp teil noch schreiben, das heutige netzverteiler(switches) anhand dieser arp tabellen adressieren, und somit ein einsatz von ethereal in einem solch geswitchten netz nicht viel bringt. (Da es ja auch ums sniffen geht)

Freekazonid
16.02.04, 16:00
finde ich gut gelungen, 2 sachen nur die mir so aufgefallen sind

- Aufbau EINES netzwerkes und dadrunter das bild ist etwas unglücklich, das schaut so aus als wäre ein jedes netzwerk aufgbaut aus 2 rechner mit einem sniffer. die erklärung unten klärt das natürlich, aber zunächst verwirrst ( beheben zb mit überschrift "Das Versuchs Netzwerk" oder irgendwie sowas was darauf hinweist )

- ich verstehe nicht warum in dem text 3 ständig dadrauf hingewiesen gut das ein hub eingesetzt wird das es nur mit nem hub geht usw; mit nem switch gehts genauso gut ( stichwort ettercap )

randy
16.02.04, 16:01
an dem protokoll gehört sowieso noch gefeilt
(ein paar sätze ergeben keinen sinn (grammatik)) das weis ich

noch ne frage: beim arp request packet: wieso ist da die MAC addresse 00:00:00:00:00:00 ? was bedeutet diese MAC-addresse?

Beweis:

randy
16.02.04, 20:11
Original geschrieben von D_O_Z_E_R
hallo,

sieht doch ganz gut aus...

würde vielleicht in den arp teil noch schreiben, das heutige netzverteiler(switches) anhand dieser arp tabellen adressieren, und somit ein einsatz von ethereal in einem solch geswitchten netz nicht viel bringt. (Da es ja auch ums sniffen geht)

ich seh da nicht so den zusammenhang, wieso ich das schreiben sollte.
ich schreibe es wahrscheinlich nicht weil es eigentlich schon grundwissen sein sollte,.. naja vielleicht überleg ich mir noch...

switches addressieren anhand der mac-addresse (ich hoff das stimmt)
switches stellen ne punkt zu punkt verbindung der beiden rechner her.
somit empfängt sniffer nur arp broadcasts (ich hoff das stimmt auch)
somit ist ethereal für geswitches netzte unbrauchbar (stimmt)
stattdessen kommt ettercap ins spiel....



mfg
randy²

gibt es ftp header und icmp header oder bezeichnet man sowas anders?
ich uppe gleich die nächste version und dort hab ichs drinstehen

randy
16.02.04, 22:18
Original geschrieben von randy
noch ne frage: beim arp request packet: wieso ist da die MAC addresse 00:00:00:00:00:00 ? was bedeutet diese MAC-addresse?

Beweis:

das mit der mac adresse hat sich schon erübrigt:
dadurch das es ein arp request ist weis z.B.: rechner A noch nicht die Mac adresse des Rechners B (die will rechner A ja erfahren) somit bleibt das target mac -address feld leer (00:00:00:00:00:00)
so simple sachen (da bin ich wohl auf der leitung gestanden):ugly:

gegenfrage: was bedeutet nun ff:ff:ff:ff:ff:ff ? broadcast-mac? wie kann das funtkionieren ?

mfg
randy²

ps:entschuldigt mich für die vielen posts

D_O_Z_E_R
16.02.04, 22:30
hallo,

ich würde es halt nur der vollständigkeit wegen schreiben, ansonsten könnte man auch fragen was denn noch alles zum grundissen gehört.

wegen der mac adresse kann ich auch nur mal raten...

hat sich wohl erledigt ;)

RapidMax
16.02.04, 22:32
Original geschrieben von randy
gegenfrage: was bedeutet nun ff:ff:ff:ff:ff:ff ? broadcast-mac? wie kann das funtkionieren ?
Genau. Ein Broadcast auf MAC Ebene wird von allen an diesem Broadcast-Segment angeschlossenen Teilnehmern empfangen. Switches leiten solche Meldungen an alle Ports. Erst ein Router (Layer 3) stoppt einen solchen Broadcast.

Gruss, Andy

randy
16.02.04, 22:41
Original geschrieben von RapidMax
Genau. Ein Broadcast auf MAC Ebene wird von allen an diesem Broadcast-Segment angeschlossenen Teilnehmern empfangen. Switches leiten solche Meldungen an alle Ports. Erst ein Router (Layer 3) stoppt einen solchen Broadcast.

Gruss, Andy

das habe ich mir irgendwie auch gedaucht, ich war mir halt nicht sicher. die mac-bc werden also nur durch router geblockt.
thx




Original geschrieben von D_O_Z_E_R
hallo,

ich würde es halt nur der vollständigkeit wegen schreiben, ansonsten könnte man auch fragen was denn noch alles zum grundissen gehört.

wegen der mac adresse kann ich auch nur mal raten...

hat sich wohl erledigt ;)

Das wegen Grundwissen ist so ne sache. würde ich kein grundwissen voraussetzen wäre das protokoll mehr als 100 seiten groß. ich mache das meistens nach gefühl.
im grund genügt bei uns ein protokoll mit 10 seiten. und die hab ich jetzt ja schon erreicht (die laborübung dauert übrigens 3 stunden)
trotzdem steuer ich nen neuen rekord an :ugly: :cool:

thx
randy²

Doh!
16.02.04, 23:04
Original geschrieben von RapidMax
Erst ein Router (Layer 3) stoppt einen solchen Broadcast.



Ein Router stoppt den Broadcast nicht, er leitet ihn nicht weiter. Kleiner Unterschied ;)

randy
17.02.04, 19:35
hab ein neues update gemacht

ich werde noch ping und ftp analyse hinzufügen
weis da vielleicht jemand etwas über den ftp vorgang(steuerkanal,sendekanal) (vielleicht was genaueres)?

mfg
randy²

randy
18.02.04, 19:06
ich will nicht nerven:ugly:

passt das so?


Grundlagen Internet Control Message Protocol (ICMP)
IP hat ein verwandtes Protokoll, das Internet Control Message Protocol (ICMP). Dieses wird vom Netzwerkcode des Kernels verwendet um Fehlermeldungen und ähnliches an andere Hosts weiterzugeben. ICMP ist im Network Layer angesiedelt, ist aber eigentlich kein wirklich eigenständiges Protokoll, da die Übermittlung von ICMP-Nachrichten durch IP-Pakete erfolgt und dazu dient, die Übertragung von den eigentlichen Daten zu steuern.

Man kann sich das so vorstellen: Wenn man eine FTP Session mit einem anderen Host starten will aber am Port 21 (bei FTP Steuerkanal) kein Prozess lauscht (es läuft kein FTP- Server) und auf diesem Rechner das erste FTP Paket ankommt erkennt dies Netzwerkschicht dieses Rechners und schickt umgehend eine ICMP Nachricht zurück um mitzuteilen das dieser Port nicht erreichbar ist (ICMP Nachricht vom Typ „Destination unreachable“).

ICMP stellt verschiedene Nachrichten zur Verfügung von denen viele Fehlermeldungen behandeln. Darunter befindet sich auch eine sehr interessante Nachricht names „REDIRECT“. Diese wird vom Routing Modul erzeugt, wenn es erkennt, dass es von einem anderen Host als Gateway verwendet wird, obwohl es einen viel kürzeren Weg gibt. Der Gateway, welcher erkennt, dass es eine kürzere Route gibt schickt eine ICMP Nachricht mit der besseren Route an den Rechner mit der zu verbessernden Routing Tabelle. Es gibt aber auch einige Sachen wo es nicht gut ist sich auf so ein dynamisches Routig-Schemata zu verlassen. Auf dieses Thema will ich im Zuge dieser Laborübung nicht weiter eingehen.

Arten von ICMP Datagrammen

Die ICMP Datagrammarten sind in RFC (Request for Comments) 1700 (Assigned Numbers RFC) definiert.

TYPE Nr. iptables Mnemonic Beschreibung
0 echo-reply Antwort auf ein Echo request
3 destination-unreachable Ziel nicht erreichbar
4 source-quench Quelle drosseln
5 redirect Umleitung (Routing)
8 echo-request Echo Anforderung
11 time-exceeded Das TTL-Feld hat den Wert 0
12 parameter-problem Ungültiges Header Feld
13 timestamp-request Aufforderung eines Zeitstempels
14 timestamp-reply Zeitantwort
15 none Informationsanforderung
16 none Informationsantwort
17 address-mask-request Adressmasken-Anforderung
18 address-mask-reply Adressmasken-Antwort

Für diese Laborübung ist vor allem die Typ Nummer 0x00 und 0x08 interessant. Diese werden für den ping Befehl benötigt. WICHITG: Es gibt keine Ping-Pakete. Dazu wird ein ICMP echo request an den Zielrechner geschickt, dieser sendet ein ICMP echo reply zurück, wenn er denn verfügbar ist.



mfg
randy²

READY
18.02.04, 23:10
Original geschrieben von randy
hab ein neues update gemacht

weis da vielleicht jemand etwas über den ftp vorgang(steuerkanal,sendekanal) (vielleicht was genaueres)?

mfg
randy²

Hallo,
das ist kein Geheimnis welches per Mundpropaganda verbreitet wird:ugly:
Siehe: http://www.faqs.org/rfcs/rfc959.html ;)
Kongrete Fragen zu den Kanälen würde ich dir auch beantworten.

Der Vorgang ist in etwa so zu beschreiben:

Alle Kommandos gehen über den Steuerkanal, Listings/Datenverbindungen bzw Down-/Uploads über einen Datenkanal, bei passivem FTP verbindet sich der Client zum Server auf einem im CMD Kanal abgesprochenen Port, beim Aktiven initiiert der Server die Verbindung zum Client auf einen im CMD Kanal abgesprochenen Port, was bei Masquerading zu einem Problem werden kann.

Als konstruktive Kritik zu deiner FTP Beschreibung: Wieso beschreibst du die Kommandos eines beliebigen FTP Clienten in deinem Protokoll? Ich würde eher auf die RFC konformen Befehle eingehen da man diese ja auch im Sniffer zu sehen bekommt.
Und in Ethereal lässt sich das Passwort um einiges leichter rausfischen wenn man von der Analyze Funktion "Follow TCP Stream" gebrauch macht.

-ready

randy
18.02.04, 23:26
thx
es hat sich schon einiges erübrigt :

wir haben heute in der schule im unterricht über ftp gesprochen ( was für ein zufall :D )
was ich vielleicht nicht so ganz kappiert hab , war das mit den ports
da war irgendwie sowas wegen einer änderung des ports beim datenkanal glaub ich (da man als normaler user nicht auf den port 20 zugreifen kann)

kannst mir das erklären ?

mfg
randy²

edit:wie sieht das bei einem ftp-server aus bei dem viele gleichzeitig zugreifen wegen den ports? öffnet der ftp-server da mehrere ports?
thx

PROTOCOL FILE UPDATED

READY
19.02.04, 00:11
Ich nehme an du sprichst von einer passiven FTP Verbindung.
Dem FTP Server stehen dafür mehrere Ports, gewöhnlich im highport Bereich zur Verfüngung, bei manchen FTP Servern lässt sich eine "passive range" einstellen welche den Portbereich für Passivverbindungen festlegt. Für alles was eine Passivverbingung benötigt, wie bereits genannt, Listings/Datentransfers öffnet der Server einen neuen Port und schliesst ihn wieder nach dem die Übertragung beendet wurde. Normalerweise bekommt man immer einen anderen Port auf der Serverseite für eine neue Datenverbindung zugewiesen, dH wenn du ein Listing machst und der passive Port auf der Serverseite bspw 45232 ist wird es beim nächsten Listing/Download mit hoher Warscheinlichkeit nicht der selbe Port sein mit dem dann übertragen wird.
Die Portabsprache kannst du ja dem CMD Kanal entnehmen, da wirst du das auch feststellen.
Daraus ergibt sich die Antwort auf die Frage wie das ist wenn mehrere Benutzer etwas zB herunterladen, es wird eben ein Port aus dem "Pool" vergeben.

Das ein User nicht auf Port 20 einen Listener anlegen kann ist klar, deswegen wird eben der Highport Bereich dafür verwendet (>1024), in welchem dies erlaubt ist.
Was mir jetzt nicht so ganz klar ist, ist warum du von Port 20 sprichst und nicht von Port 21, ich nehme mal an es handelt sich um einer Verwechslung.

-ready

randy
19.02.04, 17:17
nein das hab ich shon so gemeint
auf port 20 lauscht ja der listener
der rechner baut dann mit port 21 vom ftp-server eine verbindung auf (steuerkanal)
wenn ich user bin und nicht auf port 20 zugreifen kann muss ich dem ftp server mitteilen dass er den datenkanal auf einen anderen port zu mir legen soll.

stimmt das?

mfg
randy²

randy
22.02.04, 01:03
ich hab da nen artikel über ftp gefunden,
für alle diejenigen dies interessiert

wikipedia : http://de.wikipedia.org/wiki/FTP

mfg
randy²

randy
22.02.04, 15:54
ok das protokoll is schon fast fertig.
(pdf-file update)

mir fehlt nur noch die beschreibung einer ftp-session
vielleicht könnt ihr mir da nochmals helfen?
thx
wenn nicht muss ich da ein bisschen improvisieren

trotzdem
danke

mfg
randy²

ps : das file hat 1.8mb

so schaut das kapitel aus bie dem ich steck:

Wir starteten nun eine FTP-Session mit dem Befehl ftp [Hostname]. Das FTP verlangt nun eine Anmeldung mit Benutzername. Wir authentifizierten uns als root mit dem Passwort root!?. Nach der Anmeldung kam ein FTP-Promt. Mit quit beendeten wir die Session.

Anhand der Analyse mit Ethereal lässt sich feststellen, das das erste Packet, welches nach dem Aufruf des ftp-Befehls verschickt wird kein ftp-Packet ist sondern ein TCP-Packet. Dies lässt sich ganz einfach erklären, wenn man die Grundlagen von FTP verstanden hat.

READY
25.02.04, 14:25
Evtl hilft dir das: http://www.proftpd.de/7.0.html

Der 20er Port (bzw FTP Port-1) wird nur bei einer aktiven FTP Verbindung verwendet.

-ready

randy
25.02.04, 17:16
ich schaus mir gerae an, ich werd heut sicha wieda ne nachtschicht einlegen müssen :(

vielleicht noch letzte bemerkungen zum gesamteindruck und von eventl. fehlern ?
morgen muss ichs nämlich abgeben

trotzdem mal thx für euere hilfe

mfg
randy²

edit: diese dok hab ich mir eh schon vor ein paar tagen ausgedrückt. es war halt nur von ner anderen seite und ein pdf file