Verbindungsanalyse anhand connection-Tracking

SYN / ACK anhand vom Connection Tracking (in TCP)

Connection Tracking (z. B. im Linux-Kernel/Netfilter → conntrack) beobachtet und analysiert den Zustand einer Verbindung
 – besonders bei TCP – damit das System weiß, ob ein Paket zu einer bestehenden, neuen oder hinfälligen Verbindung gehört.

Wir gehen es sauber durch:

1. Ausgangspunkt: Ein TCP-Handshake

Eine neue TCP-Verbindung beginnt immer mit:

    Client  →  Server:   SYN
    Server  →  Client:   SYN-ACK
    Client  →  Server:   ACK


Sobald das erste SYN auftaucht, erkennt das Conntrack-Modul:

- das ist eine neue Verbindung

- noch nicht bestätigt

- es wird ein Eintrag in der Connection-Tracking-Tabelle angelegt

Status in conntrack: SYN_SENT

2. Nach SYN: die nächsten Pakete

Phase für jedes Paket aus Sicht des Trackings:

1) Paket kommt an → conntrack prüft:
Gibt es schon einen State-Eintrag in der Tabelle?

ja: zuordnen
nein: neuer State


2) Ein SYN-ACK kommt zurück
Jetzt wird der Status angepasst:

SYN_SENT  →  SYN_RECV

Conntrack weiß: die Gegenstelle lebt.

3) Das finale ACK

Damit ist die Verbindung etabliert:

SYN_RECV → ESTABLISHED

Und jetzt dürfen normale Datenpakete fließen.

3. Wieso ist das wichtig?

Weil ein Firewall-Regelwerk normalerweise sagt:

- Neue Verbindungen NUR von innen nach außen
- Schon bestehende Verbindungen dürfen immer durchgehen


Das bedeutet: das System merkt sich:

- source/destination IP
- Ports
- Protokoll
- TCP-Flags
- Zeitstempel

#Beispiel eines Eintrags:
tcp  ESTABLISHED  src=192.168.1.100 dst=93.184.216.34 sport=53218 dport=443

4. Wie geht es nach dem Handshake weiter?

Während Daten laufen:

- ACK, PSH, FIN, RST werden beobachtet
- Reihenfolge und TCP-Flags werden ausgewertet
- alle Pakete werden dem State zugeordnet
<//pre>


=== 5. Verbindung schließen ===
<pre>
Normal:
FIN → ACK → FIN → ACK

conntrack wechselt:
FIN_WAIT → CLOSE_WAIT → LAST_ACK → CLOSED

Oder abrupt:
RST
=> sofortiger Abbruch, Eintrag wird gelöscht.

6. Timeouts

Ist kein Traffic mehr da:
- TCP connections bleiben eine Zeit lang im State TIME_WAIT.
- Dann fliegt der Eintrag raus

Beispiele (sehr grob):
- NEW: wenige Sekunden
- ESTABLISHED: mehrere Minuten
- TIME_WAIT: ca. 2 Minuten

7. Wichtig: conntrack unterscheidet 3 grundlegende Pakettypen

Paket kommt an und ist …

Typ Erklärung NEW neue Verbindung ESTABLISHED gehört zu einer bestehenden RELATED z.B. FTP Datenkanal, ICMP-Antworten

Daher funktionieren Firewall-Regeln wie: iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Zusammenfassung in einem Satz

Nach dem ersten SYN legt conntrack einen Verbindungs-State an, passt ihn bei jedem nächsten TCP-Flag an (SYN-ACK, ACK, FIN, RST) 
und entscheidet so, ob Pakete zu einer gültigen Verbindung gehören.

Connection Tracking in UDP

bei UDP ist Connection Tracking völlig anders als bei TCP, weil UDP:
- kein Handshake hat,
- keine Sessionzustände über Flags hat,
- verbindungslos ist.

Trotzdem behandelt conntrack UDP „quasi-verbindungsorientiert“. 

Wie läuft Connection Tracking bei UDP wirklich ab?

1. Erstes UDP-Paket kommt an

Wenn das erste UDP-Paket gesehen wird, erstellt conntrack sofort einen State-Eintrag:

State = NEW

Beispiel (vereinfacht):
src=10.0.0.1:50000 → dst=8.8.8.8:53


Der Kernel merkt sich:
- Quell-IP + Port
- Ziel-IP + Port
- Protokoll UDP
- Timestamp


2. Sobald eine Antwort zurückkommt

conntrack wechselt nach:
State = ESTABLISHED

Ja, obwohl es bei UDP keine echte Verbindung gibt.

Warum macht Linux das?

Damit deine Firewall Regeln wie diese benutzen kann:

--ctstate ESTABLISHED,RELATED

und dann geht z. B. DNS-Traffic problemlos:
Anfrage → NEW
Antwort → ESTABLISHED

UDP hat nur 3 relevante States

       UDP State	Bedeutung
       NEW	        erstes Paket gesehen
       ESTABLISHED	es gab ein Rückpaket
       UNREPLIED	keine Antwort kam

Wenn also ein Paket nur in eine Richtung geht:
UNREPLIED

Erst wenn eine Antwort kommt:
ESTABLISHED

Wichtigster Unterschied zu TCP: Timeouts

TCP-Conntrack hält lange Einträge.
UDP dagegen sehr kurz.
Typische Linux-Defaults (können variieren):

       /proc/sys/net/netfilter/nf_conntrack_udp_timeout = 30
       /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream = 180

Bedeutung:
- Wenn nur in eine Richtung Traffic kommt ➜ Eintrag nach 30s weg.
- Wenn bidirektional ➜ bis zu 180s im Table.

Was passiert genau beim Ablauf?

Timing-Diagramm:

Client ---- UDP Packet ----> Server
           conntrack: NEW (UNREPLIED)

Server ---- UDP Packet ----> Client
           conntrack: ESTABLISHED

… weiter Daten …
<pre>

<pre>
Wenn nach x Sekunden kein Paket mehr kommt:
Entry removed.

Keine FIN/RST wie bei TCP.

Wann gilt ein UDP-Paket als „connected“?

Sobald conntrack beide Richtungen gesehen hat.

Das bedeutet:
- Firewall kann zuverlässig Rückpakete erkennen.
- NAT weiß, wohin Rückpakete gehen müssen.

Sonderfall: One-Way-Traffic

UDP-Protokolle wie syslog, RTP, VoIP, SNMP:

Nie ein Response? → bleibt UNREPLIED
Timeout löscht Eintrag

Wie beobachten?

Voll live:
conntrack -E -p udp

Oder Einträge ansehen:
conntrack -L -p udp

Zusammengefasst in 20 Sekunden:

- Erstes UDP-Paket → NEW/UNREPLIED
- Antwort kommt → ESTABLISHED
- Kein Handshake, keine Flags
- Nur Timeouts entscheiden, wann gelöscht wird

Zusammenfassung für UDP

- UDP kennt kein ACK-Flag

- Ein UDP-Datagramm besteht nur aus:

        * Source IP/Port
        * Destination IP/Port
        * UDP-Header
        * Payload

- Es gibt keine Stati wie SYN, ACK, FIN, keine Sequencen, kein Acknowledgement.
- Also kann Conntrack auch kein “ACK” erkennen.

Was gilt dann als „Antwort“?

Conntrack erkennt eine „Antwort“ nur dadurch, 
dass ein Datagramm in die umgekehrte Richtung kommt mit passenden Parametern:

Client -> Server : UDP 50000 -> 53
Server -> Client : UDP 53 -> 50000  ← das ist die Antwort

Damit wechselt der State:
NEW/UNREPLIED  →  ESTABLISHED

Es ist also egal, was im Paket steht.
Nur Richtung und 5-Tuple zählen:
- Source IP
- Destination IP
- Source Port
- Destination Port
- Protocol (UDP)

Keine Flags. Kein Handshake. Kein ACK.