iptables: DROP vs REJECT und ufw deaktivieren

Kategorie: Firewall · Channel: #iptables

DROP vs REJECT – Der Unterschied

DROP:
→ Paket wird still verworfen
→ Absender bekommt KEINE Antwort
→ Absender wartet auf Timeout (kann Minuten dauern)
→ Kein Hinweis dass der Port existiert

REJECT:
→ Paket wird verworfen + ICMP-Fehler zurückgeschickt
→ Absender weiß sofort: Verbindung abgelehnt
→ Schnelle Fehlermeldung ("Connection refused")
→ Verrät dass ein Host unter dieser IP existiert

Wann welches Target?

Beispiele

# DROP – still verwerfen (Angreifer bemerkt nichts sofort)
iptables -P INPUT DROP
iptables -A INPUT -s 1.2.3.4 -j DROP

# REJECT – mit ICMP-Fehler (tcp-reset oder icmp-port-unreachable)
iptables -A INPUT -p tcp --dport 8080 -j REJECT
iptables -A INPUT -p tcp --dport 8080 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp --dport 161  -j REJECT --reject-with icmp-port-unreachable

# REJECT-Typen:
# icmp-net-unreachable
# icmp-host-unreachable
# icmp-port-unreachable  ← Standard für geschlossene Ports
# tcp-reset              ← für TCP, simuliert geschlossenen Port

Diagnose: Warum kommt keine Verbindung an?

# DROP: Verbindung hängt, kein Fehler → Timeout nach ~2 Min
# REJECT: sofort "Connection refused" oder "No route to host"

# Testen ob DROP oder REJECT:
time curl --connect-timeout 5 http://10.0.1.50:8080
# Bei DROP:   curl: (28) Connection timed out after 5000ms  → DROP
# Bei REJECT: curl: (7) Failed to connect ... Connection refused → REJECT

# Aktuelle Regeln prüfen:
iptables -L INPUT -n -v --line-numbers
iptables -L INPUT -n | grep -E "DROP|REJECT"

ufw deaktivieren auf Ubuntu

ufw (Uncomplicated Firewall) ist auf Ubuntu vorinstalliert.
Bei manuellem iptables-Einsatz müssen beide koexistieren oder ufw muss weg.
Mischbetrieb erzeugt doppelte und widersprüchliche Regeln!

Problem erkennen

# ufw aktiv?
ufw status verbose

# ufw-Chains in iptables?
iptables -L | grep ufw
# Wenn Ausgabe nicht leer → ufw mischt sich ein!

ufw sauber deaktivieren

# Schritt 1: ufw deaktivieren
ufw disable

# Schritt 2: ufw-Service stoppen und deaktivieren
systemctl stop ufw
systemctl disable ufw

# Schritt 3: ufw maskieren (verhindert versehentliches Starten)
systemctl mask ufw

# Schritt 4: prüfen ob ufw-Chains weg sind
iptables -L | grep ufw
# Ausgabe sollte jetzt leer sein!

# Schritt 5: eigene iptables-Regeln laden
bash /etc/iptables/rz-rules.sh

# Schritt 6: Regeln persistent machen
iptables-save > /etc/iptables/rules.v4

ufw und iptables gleichzeitig – was passiert

Problem-Szenario:
1. Admin aktiviert manuell: iptables -P INPUT DROP
2. ufw ist noch aktiv und hat eigene FORWARD/INPUT Chains
3. Pakete laufen durch BEIDE Regelwerke
4. Reihenfolge: ufw-before-* Chains laufen VOR eigenen Regeln
5. Ergebnis: unvorhergesagtes Verhalten, schwer debugbar

Lösung: immer eines von beiden – nie beides!
  → Entweder ufw (einfach, für Einzelserver)
  → Oder manuelles iptables/nftables (flexibel, für RZ)

Nach ufw-Deaktivierung: RHEL firewalld

# Auf RHEL/Rocky: firewalld ist das Äquivalent zu ufw
# Gleiches Problem – gleiches Vorgehen:

systemctl stop firewalld
systemctl disable firewalld
systemctl mask firewalld

# Eigene iptables laden:
systemctl enable iptables
systemctl start iptables
iptables-restore < /etc/sysconfig/iptables

Schnellreferenz

# DROP vs REJECT testen
time curl --connect-timeout 5 http://ZIEL:PORT   # timeout=DROP, refused=REJECT

# ufw Status
ufw status verbose
iptables -L | grep ufw              # ufw-Chains in iptables?

# ufw deaktivieren (Ubuntu)
ufw disable && systemctl mask ufw

# firewalld deaktivieren (RHEL)
systemctl disable --now firewalld && systemctl mask firewalld

# Konflikt prüfen
iptables -L -n | grep -E "ufw|fw-"  # ufw-Chains
iptables -L -n | grep "f2b"          # fail2ban-Chains (ok, kein Konflikt)