wer kann mir die Code Bits: URG, ACK, PSH, RST, SYN, FIN erklären?

[flyingjoker]

also ich möchte gerne genauers über den aufbau des netzwerkes wissen habe aber keine seite gefunden oder jemanden gefunden der mir die Code Bits: URG, ACK, PSH, RST, SYN, FIN genau erklären kann und wofür sie da sind.

vieleicht noch in verbindung mit dem OSI referenzmodell?


mfg
werner

 

[hackemaier]

hättest vielleicht dazu schreiben können um welches protokoll es sich handelt...

also ich tippe mal auf tcp

hier sind die verantwortlichen rfc dafür: http://www.faqs.org/rfcs/rfc793.html such da mal nach "TCP Header Format" und scroll dann ein wenig nach unten


hab hier noch eine präsentation gefunden wo auch drin beschrieben steht wofür die einzelnen sachen da sind http://trojaner-und-sicherheit.de/tcp-ip-schulung/sld110.htm

auf wikipedia steht das osimodell eigentlich recht gut beschrieben http://de.wikipedia.org/wiki/Osi

solltest du noch fragen haben meld dich nochmal

 

[cuda]

Es handelt sich um IP-Protokol.

Beim Verbindungsaufbau:

Der Client schickt eine Verbindungsaufforderung zum Server (hier handelt es sich um einen Paket mit dem gesetzten "SYN"-Flag). Dann wenn der Server das Paker kriegt, muss er ja den Empfang quitieren und schickt ein Paket mit dem gesetzten "ACK-Flag" und um den Traffic zu sparen wird bei dem Paket auch noch der "SYN-Flag" gesetzt. Wenn der Client das Paket empfängt, quitiert er ihn mit einem Paket, bei dem "SYN-Flag" gesetzt ist.

Wie man hier sieht, wird die Verbindung jeweils von beiden Teilnehmer aufgebaut. Von jedem jeweils die Hälfte. Darum auch die Paketabfolge: "Aufforderung" --> "Quitierung und Aufforderung" --> "Quitierung". Das nennt sich auch "Three-Way-Handshake".

Flags bei IP
RST: Dient dem zurücksetzen einer Verbindung.
FIN: Dient dem Beenden einer Verbindung (hier läuft es genau so wie beim Verbindungsaufbau, FIN-->ACK,FIN-->ACK)
PSH (oder PUSH): Das heisst einfach, dass die Daten sofort nach der ANkunft an die nächsthöhere Eben des ISO/OSI-Models gegeben werden.
URG: Heisst glaube ich "Urgend Pointer" oder so. Wenn er gesetzt ist, muss der Urgend Pointer beachtet werden.

'cuda

 

[D€NNIS]

Es kann sich dabei nur um TCP handeln denn UDP ist "stateless" und ICMP Flags sehen anders aus.
-------------------------------
@joker

Die von dir genannten TCP Flags bezwecken die Statusbeschreibung eines Datagrams bzw einer Reihe zusammengehöriger Datagrame.

Wenn du dich etwas mit dem TCP Protokollstack beschäftigst eventuelll dich der Hyperlinks von meier bedienst wirst du feststellen das es gewisse Mechanismen gibt die zur Initiierung einer auf TCP/IP basierenden Verbindung ablaufen respektive bei abrupter Beendigung oder ordnungsgemäßer.

Hier mal das Beispiel wie eine TCP Verbindung zustande kommt (statefull)

Client sendet Paket an 212.0.0.0

tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
dport=1031 use=1


192.168.1.5 sendet das erste Paket an 192.168.101.35
Das SYN Flag ist gesetzt da es dieses Paket die Verbindung initiiert.
Logischerweise ist das erste Paket unbeantwortet da die Gegenstelle ja noch keine Gelegenheit dazu hatte.

tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
use=1

Jetzt haben wir ein SYN/ACK als Bestätigung der Gegenstelle erhalten und der Connection Status wechselt in SYN RECEIVED wenn alles ordnungsgemäß abläuft wovon wir ausgehen.

Da dieser Eintrag nun in beide Richtungen verschickt werden gilt er als beantwortet und der letzte Teil im 3 Way Handshake folgt das finale ACK Flag was den Aufbau der Verbindung letztendlich bestätigt und die Verbindung letztendlich in einen etablierten Zustand versetzt.

tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
sport=23 dport=1031 use=1

Zur Beendigung einer Verbindung läuft es analog ab nur eben nicht mit SYN sondern eben mit dem FIN Flags für finish oder eben Beendigung einer TCP/IP Verbindung.
RST bedeutet infolge dessen Connection refused was einem Timeout und somit einer nicht ordnungsgemäßen vollendigung einer Verbindung gleich kommt
Beispiel könnte zum Beispiel sein das eine Firewall die Pakete verwirft (DROP)

Weitere Flags:

URG= URGENT für eilige Pakete

Und letztendlich veranlasst das PSH Paket den Router oder die Firewall das betreffende Paket an den Application Layer im OSI Modell (höchste Stufe im Sinne von der letzten) weiterzureichen.

P.S: Die obig genannten Einträge sind aus der Connection Tracking Machine eines Linux Kernels.

edit: Gut das sollte dann mit den anderen beiden Erklärungen wohl reichen

 

[flyingjoker]

hättest vielleicht dazu schreiben können um welches protokoll es sich handelt...

also ich tippe mal auf tcp

hier sind die verantwortlichen rfc dafür: http://www.faqs.org/rfcs/rfc793.html such da mal nach "TCP Header Format" und scroll dann ein wenig nach unten


hab hier noch eine präsentation gefunden wo auch drin beschrieben steht wofür die einzelnen sachen da sind http://trojaner-und-sicherheit.de/tcp-ip-schulung/sld110.htm

auf wikipedia steht das osimodell eigentlich recht gut beschrieben http://de.wikipedia.org/wiki/Osi

solltest du noch fragen haben meld dich nochmal

das osi referenzmodell kenn ich schon, habe ich ja in der schule gelernt.
die präsentation ist ganz nett.

@dennis um es in anderen worten wiedzugeben ist es dann so?:

Es muss ein Fluss überquert werden (von Mrs. Daten).

Zwei Leute (Mr. Client und Mr. Server) müssen dafür ein Seil halten (die Verbindung).

Mr. Client und Mr. Server verständigen sich zunächst über Zurufe (ICMP und UDP-Protokoll, Datagramme) über den genauen Standpunkt am jeweils anderen Ufer (IP-Adresse und TCP-Port-Nummer). Dann auch über die Dicke des Seiles (MTU-Size). In wie viele Stücke müssen wir Mrs. Daten zerlegen? Andere Typen (die stehen in der Mitte des Flusses (die Server im Internet) reden da auch noch ein Wörtchen mit.

Wenn die sich dann alle einig sind, wird einander zugerufen (SYN -ACK).

Dann wird Mrs. Daten über das Seil geschickt (nach SYN-ACK). Das geht dann über das Seil (TCP).

Jetzt aber kommt Mr. Server auf die Idee, das Seil loszulassen und Mrs. Daten fällt in den Fluss (Filesharingprogramm abgeschaltet).

Der Kerl hat aber niemandem zugerufen, dass er das Seil loslassen wird!

Mr. Client steht fassungslos da (er bekommt kein FIN). Die Kerle im Fluss wissen auch von nichts.

Mr. Client ist sogar so dumm, weiter zu fragen (der ist zu blöd oder zu kurzsichtig, um zu erkennen, dass Mr. Server abgehauen ist).

Alle stehen jetzt mit dem Seil in der Hand und machen ein dummes Gesicht. Eine Zeitlang. Manche lassen dann irgendwann das Seil fallen und haben keinen Bock mehr (Timeout). Der andere früher, der andere später.

Wenn Mr. Server wieder früh genug auf den Gedanken kommt, das Seil wieder aufzunehmen, hat er Glück (und Mrs. Daten auch).

Wenn nicht, stehen alle bis zum Hals im Wasser. Für nichts und wieder nichts.

Aber Mr. Client will auch in diesem Falle immer noch Mrs. Daten (pie@friends).

Die Jungs im Fluss halten immer noch das Seil hoch.

Mr. Server ist weg. Mr. Router - ja was macht Mr. Router?

Siehe oben. Port 4662 ist beim RFC nicht angemeldet.
Zwar freigeschaltet bei mir. Die private Ports liegen aber in einem ganz anderen Bereich!

Verbindung besteht auch nicht mehr. Muss also ein Hacker-Angriff sein.






ich versuche es auf netzwerk,router und filesharing programm zu überleiten. weil filesharing programme dafür bekannt sind router abstürzen zu lassen, und daher wollte ich wissen wie es zu stande kommt.
liege ich damit richtig?
in welcher osi schicht ist ein router?
in schicht 3?


mfg
werner

ps: ich freue mich das es hier welche gibt die sich damit auskennen, bzw. wo ich auch mal tiefere materie lernen kann, weil einiges was ich mal gelernt habe ich verlorengegangen weil man es so gut wie nicht braucht.

 

[hackemaier]

genialer text...

bis hier hin stimme ich dir zu.

Jetzt aber kommt Mr. Server auf die Idee, das Seil loszulassen und Mrs. Daten fällt in den Fluss (Filesharingprogramm abgeschaltet).

Der Kerl hat aber niemandem zugerufen, dass er das Seil loslassen wird!

Mr. Client steht fassungslos da (er bekommt kein FIN). Die Kerle im Fluss wissen auch von nichts.

Mr. Client ist sogar so dumm, weiter zu fragen (der ist zu blöd oder zu kurzsichtig, um zu erkennen, dass Mr. Server abgehauen ist).

Alle stehen jetzt mit dem Seil in der Hand und machen ein dummes Gesicht. Eine Zeitlang. Manche lassen dann irgendwann das Seil fallen und haben keinen Bock mehr (Timeout). Der andere früher, der andere später.

Wenn Mr. Server wieder früh genug auf den Gedanken kommt, das Seil wieder aufzunehmen, hat er Glück (und Mrs. Daten auch).

Wenn nicht, stehen alle bis zum Hals im Wasser. Für nichts und wieder nichts.

Aber Mr. Client will auch in diesem Falle immer noch Mrs. Daten (pie@friends).

Die Jungs im Fluss halten immer noch das Seil hoch.

Mr. Server ist weg. Mr. Router - ja was macht Mr. Router?

Siehe oben. Port 4662 ist beim RFC nicht angemeldet.
Zwar freigeschaltet bei mir. Die private Ports liegen aber in einem ganz anderen Bereich!

Verbindung besteht auch nicht mehr. Muss also ein Hacker-Angriff sein.

Wie du schon sagst vergisst man einiges von dem, weil man es nicht braucht. Von daher hoffe ich ich erzähl jetzt keinen Schwachsinn.

Ein Router arbeitet normalerweise nur auf Layer 3, also nur mit IP. Sobald wir uns aber auf der Port Ebene befinden sind wir in Schicht 4 bei TCP. Bei Portforwarding muss der Router also auch TCP können.

Wenn ich nun mein Filesharing-Proggi in die ewigen Jagdgründe schicke dürfte aber der TCP-Datenfluss nciht automatisch gekillt werden. Das Filesharing Tool müsste sich ja frühestens in der fünften Schicht befinden.
Das Filesharing-Proggi greift ja nur auf einen Dienst zurueck den das Betriebsystem bereitstellt in dem Fall hier TCP.
Ich denke wenn man das Applikation beendet, beendet TCP die Datenverbindunng nicht sofort, sondern führt eine korrekte Trennung durch.
Das Filesharing-Proggi des jenigen der gerade bei dir gesaugt hat, versucht dann wahrscheinlich eine neue Verbindung aufzubauen. Der Router nimmt die anfragen dann an und sendet diese dann weiter an den rechenr auf den der Port geforwarded ist. Da auf dem Port kein Programm mehr "lauscht" werden die Anfragen nicht beantwortet.

Um nun rauszubekommen was wirklich passiert müsste man mal den Datenverkehr der in dem Moment über die Leitung geht sniffern.

Deine Theorie würde ich eher ansetzten wenn ein Rechner abstürzt (Stromauffall oder andere art des totalen abstürzens).

Mein (Linux) Router ist bisher noch nicht abgestürzt wegen sowas, aber ich bin auch nicht der hardcore sauger. Ich würde da eher auf eine Überlastung des Routers tippen, da bei filesharing-programmen wahrscheinlich sehr viele Pakete beim Router ankommen und verschickt werden müssen.