Netzwerk: TCP/IP

UDP-Protokoll: verbindungslos, schnell und missbrauchsanfällig

UDP ist das verbindungslose Gegenstück zu TCP. Es gibt keine Verbindung, keine Bestätigung, keine Reihenfolge – ein Paket wird abgeschickt und vergessen. Das klingt nach einem Nachteil, ist aber genau der Grund für seine Bedeutung.

Der Vergleich zu TCP

Merkmal                TCP                     UDP
-------------------------------------------------------------
Verbindung             ja (Handshake)          nein
Zuverlaessigkeit       Bestaetigung + Wiederh. keine
Reihenfolge            garantiert              keine
Kopfzeilen             mind. 20 Byte           8 Byte
Durchsatz              langsamer               schneller
Verzoegerung           hoeher (Handshake)      minimal
Ueberlastkontrolle     ja (Gegensteuern)       nein
Verbreitung            Web, Mail, SSH, SQL      DNS, VoIP, Streaming,
                                                VPN, Spiele, DHCP

Merksatz:
  TCP  = "Ich muss ankommen, vollstaendig und in der
          richtigen Reihenfolge."     (Dateien, Nachrichten)
  UDP  = "Wenn es ankommt, dann schnell. Sonst nicht."
                                       (Echtzeit, Abfragen)

Warum UDP nicht dasselbe Problem hat

Bei einer Datei ist ein fehlendes Byte ein Defekt.
  -> Die Bestaetigung von TCP ist unverzichtbar.

Bei einem Sprachstrom ist ein 200 ms spaet eintreffendes Paket
WERTLOS. Die Bestaetigung wuerde es sogar noch verzoegern.
  -> Besser ein kurzes Knistern als eine Unterbrechung.
  -> Bei einem DNS-Aufruf ist die Antwort meist in einem Paket:
     entweder sie kommt oder man fragt erneut.
     Kein Handshake, keine Verbindung, halbe Verzoegerung.

Wer Zuverlaessigkeit braucht, baut sie OBERHALB von UDP ein:
  QUIC (HTTP/3)   - eigene Bestaetigungen, Reihenfolge, Ueberlast
  VoIP (RTP/RTCP) - eigene Qualitaetsmessung
  DTLS             - TLS auf UDP
Das ist der moderne Ansatz: Nur das, was wirklich gebraucht wird.

Praxis: UDP beobachten

# Lauschende UDP-Sockets
ss -ulnp

# UDP-Verbindungen ("connected" nur bei connect() gesetzt)
ss -uanp

# DNS-Abfrage - das klassische UDP-Beispiel
dig +noall +stats example.org
#   Standard: UDP, Port 53. Antwort passt fast immer in ein Paket.

dig +tcp example.org              # Wechsel zu TCP erzwingen
dig +short +time=2 +tries=1 example.org

# UDP-Verkehr mitlesen (Root noetig)
tcpdump -i any -n udp port 53
tcpdump -i eth0 -n udp and port 123          # NTP
tcpdump -i any -n "udp and (port 443 or port 80)"   # QUIC

# UDP-Statistik
ss -uan | wc -l
cat /proc/net/snmp | grep -A1 Udp
#   InErrors steigt -> Pakete kommen an, aber Pruefsumme/Puffer stimmt nicht
#   RcvbufErrors steigt -> Puffer zu klein (haeufig bei DNS unter Last!)

# UDP-Paketverlust messen
nstat -az | grep -i udp

UDP-Puffer: der häufigste Engpass

# Standardpuffer sind oft zu klein fuer hohe DNS-Last
sysctl net.core.rmem_default    # Empfang, Standard
sysctl net.core.wmem_default    # Senden, Standard
sysctl net.core.rmem_max        # Obergrenze
sysctl net.core.wmem_max

# Anheben (in /etc/sysctl.d/99-udp.conf)
#   net.core.rmem_max = 16777216
#   net.core.wmem_max = 16777216
#   net.core.rmem_default = 262144
#   net.core.wmem_default = 262144
#   net.core.netdev_max_backlog = 5000

# Zeichen fuer "RcvbufErrors" im /proc/net/snmp: Puffer zu klein.
#   Bei einem DNS-Server unter Last ist das der erste Wert,
#   den man pruefen sollte.

# Anwendungssicht: Puffergroesse explizit setzen
#   socketserver.setsockopt(SOL_SOCKET, SO_RCVBUF, 4*1024*1024)

Typische Anwendungen

  • DNS (Port 53): Anfrage und Antwort je ein Paket. Fällt die Antwort größer als 512 Byte aus (früher) bzw. größer als die ausgehandelte Größe, wechselt der Client auf TCP. DNSSEC vergrößert Antworten und macht den TCP-Fallback häufiger – weshalb Poart 53/TCP offen bleiben muss.
  • DHCP (67/68): Kein Handshake möglich, weil der Client ja noch keine Adresse hat. UDP ist hier die einzige Wahl.
  • NTP (123): Ein Paket je Abfrage. Der Zeitstempel im Paket erlaubt die Laufzeitmessung.
  • VoIP (RTP): Echtzeit; Verzögerung ist schlimmer als Verlust. Ein kleiner Verlustpuffer in der Anwendung fängt Schwankungen ab.
  • VPN (WireGuard, OpenVPN): WireGuard nutzt standardmäßig Port 51820/UDP. Kein Handshake auf Netzebene – die Zuverlässigkeit kommt aus der Verschlüsselungsschicht.
  • QUIC / HTTP/3 (443/UDP): Baut auf UDP auf, implementiert aber alles, was TCP und TLS boten, selbst – in der Anwendung, damit Änderungen schneller möglich sind.
  • Spiele und Streaming: Latenz entscheidet. Ein verlorenes Bild ist besser als ein angehaltenes.

Sicherheitsaspekt: UDP ist leicht zu missbrauchen

Ohne Handshake kann eine gefaelschte Quelladresse nicht geprueft
werden. Das ermoeglicht Verstaerkungsangriffe:
   Kleine Anfrage -> sehr grosse Antwort an die gefaelschte
   Adresse des Opfers.

Typische Verstaerkungsfaktoren:
  DNS  (ANY-Abfragen)      sehr hoch   -> ANY-Abfragen abschalten
  NTP  (Monlist)           hoch        -> veraltete Anweisung, pruefen
  Memcached (Port 11211)   extrem hoch -> NIEMALS ins Internet!
  SSDP/UPnP                hoch        -> im Internet abschalten
  SNMP                     mittel      -> nur intern
  LDAP                     hoch        -> nur intern

Gegenmassnahmen:
  1. Keine UDP-Dienste ohne Grund ins Internet stellen.
  2. Antwortgroesse begrenzen (DNS: "minimal-responses").
  3. Abfrageart einschraenken (DNS ANY verbieten).
  4. Ratenbegrenzung pro Quelladresse (DNS: "rate-limit").
  5. Antwortraten ueberwachen - ein Angriff laeuft unbemerkt,
     wenn niemand die ausgehenden Raten ansieht.
  6. Egress-Filter: Nur erlaubte ausgehende UDP-Ziele zulassen.

Prüfliste

  1. Ist der UDP-Empfangspuffer für Dienste mit hoher Last angepasst?
  2. Steigen RcvbufErrors oder InErrors in /proc/net/snmp?
  3. Antwortet der Dienst auch über TCP, wo ein Fallback möglich ist (DNS)?
  4. Ist Port 53/TCP zusätzlich offen (DNSSEC-große Antworten)?
  5. Sind UDP-Dienste ohne Betriebsgrund im Internet abgeschaltet?
  6. Sind die ausgehenden UDP-Raten im Monitoring sichtbar?
  7. Ist die maximale Paketgröße im Pfad bekannt (MTU-Fallen bei Fragmentierung)?

Häufige Fehler

  1. UDP-Puffer zu klein. Unter Last verliert der Dienst Pakete, ohne dass die CPU ausgelastet wirkt. RcvbufErrors zeigt es.
  2. Nur UDP in der Firewall geöffnet, TCP nicht. TCP-Fallback für DNS schlägt fehl, Zonenübertragungen und DNSSEC brechen ab.
  3. Fragmentierung. Große UDP-Pakete werden unterwegs verworfen. Diagnose: ping -M do -s 1472 .
  4. Annahme, UDP sei „schneller“ und daher immer besser. Ohne Überlastkontrolle kann UDP das Netz fluten. QUIC baut die Kontrolle bewusst wieder ein.
  5. Verstärkungsangriff über eigene Dienste. Siehe oben. Ein DNS-Server mit offener Rekursion ist die häufigste Ursache.
  6. Kein Monitoring der UDP-Raten. Ein ausgelagerter Angriff über eigene Infrastruktur fällt erst auf, wenn der Anbieter sich meldet.

Verwandte Grundlagen: TCP, DHCP, DNS-Dienste, VPN.