iptables Hilfe gesucht - Script fast fertig?

[Raul]

Hallo,

ich habe eine Regelliste erstellt. Sie enthält Regeln zum Schutz und Freigaberegeln.

Gibt es Ergänzungen, ist die Reihenfolge so in Ordnung? Wo ??? sind, bin ich mir unsicher.

Code: Alles auswählen

#Variablen, das eth+ steht für eth0, eth1, etc
LAN_INTERFACE="eth+"

#Alle Regeln loeschen
iptables -F
iptables -X

#Alle Verbindungen verwerfen
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP


#Alles verwerfen was nicht in in den Regeln steht
???

#Alle neuen nichtdefinierten Verbindungen blocken
iptables -N block
???


#Regeln gegen falsche TCP Pakete - TCP Pakete muessen mit "SYN" anfangen
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
 
#Korrupte Pakete zurueckweisen
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP
 
#Regeln gegen gefaelschte weil unroutbare/ungueltige IP-Adressen
iptables -A INPUT -s 255.0.0.0/8 -j DROP
iptables -A INPUT -s 192.168.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 10.0.0.0/8 -j DROP

#Schutz vor Syn-Flooding Attacks
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

#Schutz vor Ping of Death
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

#Portscannerschutz
iptables -A FORWARD -p tcp --tcp-flags ALL NONE -m limit --limit 1/h -j ACCEPT
iptables -A FORWARD -p tcp --tcp-flags ALL ALL -m limit --limit 1/h -j ACCEPT

#Localhost (lo) freigeben
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#---- Freigaben für Anwendungen ----
#SSH-Port beachten >Aussperrgefahr<
iptables -A INPUT -p tcp -i $LAN_INTERFACE --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -o $LAN_INTERFACE --sport 22 -m state --state ESTABLISHED -j ACCEPT
#HTTP, HTTPS, DNS & Paketaktualisation, sowie Anwendung
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT
#FTP-wget Benutzung
iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
#FTP Zusatz, aktivesFTP
#iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
#iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT
#RSYNC-Backup-Restore
iptables -A INPUT -p tcp -i $LAN_INTERFACE -s BACKUPSERVER --sport 873 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -o $LAN_INTERFACE -d BACKUPSERVER --dport 873 -m state --state NEW,ESTABLISHED -j ACCEPT


???????????????????????????
sport und dport richtig
NEW, ESTABLISHED, RELATED was ist wie sinvoll
was wird wirklich gebraucht
-o -i $LAN_INTERFACE wird gebraucht oder nicht

Soweit der Stand. Es ist für einen Server.

Gruss, Raul

[MSfree]

Es ist für einen Server.

Was soll der Server denn alles servieren?

Ich kann zwar erkennen, daß du SSH (22), HTTP (80), HTTPS (443), FTP (20,21), rsync (873) und DNS (53) ein beide Richtungen zulassen willst, aber ist das wirklich, was du willst?

Warum SSH in beide Richtungen?
Warum DNS in beide Richtungen?
Warum FTP in beide Richtungen?
Warum rsync in beide Richtungen?

Ein Server ist auch keine Router, Forward-Regeln sind also gar nicht nötig, und das, was du als Portscanschutz bezeichnest, ist im Grunde keine.

Vor dem Ping of Death, gegen den inzwischen kein OS mehr anfällig ist (das war Windows 95 vor 20 Jahren), schützt man sich nicht, indem man die Pingrate auf eins pro Sekunde limitiert sondern indem man die maximale Paketgröße eines Pingpaketes auf einen sinnvollen Wert wie 1024 Bytes beschränkt (Ping of Death war ein 64KiB großes Ping-Paket).

[Dimejo]

Warum benutzt Du nicht einfach ein Programm wie firewalld? Das erspart Dir Arbeit und Fehler.

[Raul]

Warum benutzt Du nicht einfach ...

Gute Frage, weil ich es so einfach wie möglich halten möchte mit zusätzlichen Paketen.


@MSfree, Danke für die Winks mit den Zaunpfählen. Ich überarbeite es nochmal, wobei rsync und ssh nur mit einer Definition in beide Richtungen funktionierten.

[eggy]

Schau Dir mal an wie z.B. Anfragen an nen Webserver aussehen, ganz grob:
Client stellt Anfrage TCP Verbindung aufzumachen, also SYN (wenn Dir das nichts sagt, nachlesen: Stichwort 3-Wege-Handshake TCP) an TCP80, aber woher?
Server antwortet - aber von woaus? und wohin? und welche Flags sollten jetzt gesetzt sein?
Dazu am besten mal Wireshark anwerfen und sich das ganze in Ruhe ansehen.

Deine Regeln "unroutbare Adressen" solltest Du evtl auch nochmal überdenken, immerhin sprichst Du weiter oben von LAN-Interface - und im Lan dürfen solche Anfragen dann schon kommen - in der Anleitung aus dem das stammt gabs sicher ne Trennung nach eingehenden Interfaces die Du wegoptimiert hast (siehe weiter unten).

Ausserdem stellt sich noch die Frage ob die Kiste IPv6 spricht, dann das ganze Spiel mit ip6tables nochmal von vorn.

zu Deinen Fragen:
NEW, ESTABLISHED, RELATED wozu ist das? Das sind "Verbindungseigenschaften", iptables versucht zu wissen, ob das aktuelle Paket zu ner neuen Anfrage gehört, oder einer die bereits geöffnet wurde oder sonstwie mit etwas verwandt ist, was bereits durch durfte.

-o -i $LAN_INTERFACE wird gebraucht? jein, wenn Du willst, dass die Regeln auf egal welches Interface zutreffen, dann nicht. In der Regel will man aber für Loopback zb andere Regeln als für eth0, oder fürs WLAN was anderes als fürs Lankabel. Auch falls der Server auf der einen Karte am "Internet" hängt, hat er evtl ne zweite fürs Monitoring, die Wartung, oder einfach Direktverbindung zum Fileserver - damit kannst Du eingehend (-i) bzw ausgehendes (-o) Interface angeben.

[Raul]

Ok,

bei meinen Versuchen habe ich folgendes festgestellt:

#Variablen
LAN_INTERFACE="eth0"

iptables -A OUTPUT -p tcp -o $LAN_INTERFACE --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -i $LAN_INTERFACE --sport 80 -m state --state ESTABLISHED -j ACCEPT

Für eine ausgehende Verbindung zu einer Webseite benötige ich NEW und ESTABLISHED.
Damit ich eingehende Pakete für DIESE Verbindung erhalten kann, wird bei INPUT ESTABLISHED gesetzt.
So funktioniert es.

Gibt es daran noch was zu verfeinern, z.B. durch TCP-Flags?

[Raul]

So Fachmänner , nach viel Arbeit habe ich jetzt eine Endversion entworfen.
Die hauptsächliche Anwendung auf dem Server läuft als Client und baut eine Verbindung über http/https auf.

Mit bitte um eine Abnahme.

Code: Alles auswählen

#Variablen
LAN_INTERFACE="eth0"

#Alle Regeln loeschen
iptables -F
iptables -X

#Alle Verbindungen verwerfen für die es keine Regel gibt
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

#Regeln gegen falsche TCP Pakete - TCP Pakete muessen mit "SYN" anfangen
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

#Korrupte Pakete zurueckweisen
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP

#Mit iptables lassen sich Portscans leicht blockieren. Um die bekanntesten Portscans 
#auch zu protokollieren verwende ich normalerweise folgende Regeln. Als erstes brauchen wir 
#ein neues Ziel für die erkannten Pakete. Die Pakete die hier rein wandern werden protokolliert und danach verworfen.
iptables -N PORTSCAN
iptables -A PORTSCAN -j LOG --log-prefix "PORTSCAN detected -- "
iptables -A PORTSCAN -j DROP
#Danach können wir uns an die einzelnen Portscan Typen machen, die wir anhand von ungültigen Flagkombinationen aussortieren.
#FORWARD Regeln sind nur für den Routerbetrieb notwendig. 
#SYN + RST
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j PORTSCAN
#SYN + FIN
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j PORTSCAN
#FIN + URG + PSH
iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j PORTSCAN
#ALL
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j PORTSCAN
#nmap Null scan
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j PORTSCAN
#nmap FIN stealth scan
iptables -A INPUT -p tcp --tcp-flags ALL FIN -j PORTSCAN
#XMAS
iptables -A INPUT -p tcp --tcp-flags ALL URG,ACK,PSH,RST,SYN,FIN -j PORTSCAN

#ICMP 0 = Echo Reply, 3 = Destination Unreachable, 8 = Echo Request
iptables -A INPUT  -i $LAN_INTERFACE -p icmp --icmp-type 3 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $LAN_INTERFACE -p icmp --icmp-type 3 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT  -i $LAN_INTERFACE -p icmp --icmp-type 0/0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $LAN_INTERFACE -p icmp --icmp-type 0/0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $LAN_INTERFACE -p icmp --icmp-type 8/0 -m state --state NEW,ESTABLISHED -j ACCEPT

#Localhost (lo) freigeben
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT


#---- Freigaben für Anwendungen Begin ----

#SSH-Port beachten >Aussperrgefahr<
iptables -A INPUT -p tcp -i $LAN_INTERFACE --dport 2222 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -o $LAN_INTERFACE --sport 2222 -m state --state ESTABLISHED -j ACCEPT

#HTTP, HTTPS, DNS & Paketaktualisation, wget reicht http
iptables -A OUTPUT -p tcp -o $LAN_INTERFACE --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -i $LAN_INTERFACE --sport 80 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -o $LAN_INTERFACE --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -i $LAN_INTERFACE --sport 443 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -o $LAN_INTERFACE --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -i $LAN_INTERFACE --sport 53 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -o $LAN_INTERFACE --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -i $LAN_INTERFACE --sport 53 -m state --state ESTABLISHED -j ACCEPT

#---- Freigaben für Anwendungen Ende ----

echo "Firewall gestartet"

[mludwig]

So Fachmänner , nach viel Arbeit habe ich jetzt eine Endversion entworfen.
Die hauptsächliche Anwendung auf dem Server läuft als Client und baut eine Verbindung über http/https auf.

Mit bitte um eine Abnahme.

Code: Alles auswählen

#Variablen
LAN_INTERFACE="eth0"

#Alle Regeln loeschen
iptables -F
iptables -X

#Alle Verbindungen verwerfen für die es keine Regel gibt
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

gut, heißt, alles, was nicht explizit erlaubt wird, wird weggeworfen.

Code: Alles auswählen

#Regeln gegen falsche TCP Pakete - TCP Pakete muessen mit "SYN" anfangen
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Wirklich jedes Paket? Nur beim Verbindungsaufbau ist SYN gesetzt, was ist mit Anwortpaketen? Da die Regeln in Reihenfolge abgearbeitet werden, schmeißt deine Firewall jetzt jedes Paket, dass nicht dem Verbindungsaufbau dient (also NEW), weg? Weil mit DROP wird weggeworfen, wenn die Bedingung stimmt, die nachfolgend definierten Regeln interessieren nicht mehr. Damit sperrt man sich doch selbst aus?

Warum außerdem explizit wegwerfen? Wie oben geschrieben, wird eh alles weggeworfen, was nicht durch eine Regel explizit erlaubt wird.

Um das weitere zu vereinfachen:

Portscans explizit zu loggen und dann wegwerfen? Wozu? Weggeworfen werden die doch sowieso, und wen interessieren die Protokolle? Die Protokolle nutze ich, um bei fehlerhafter Konfiguration/Regeln rauszukriegen, wo mir mein Paket verlorengeht, aber auf die Portscans irgendwelcher Chinesen/NSA ... hat man sowieso keinen Einfluss.

Das ist vielleicht auch eine Frage der Methodik oder Philosophie, wie man seine Firewall aufbaut, also nicht prinizipiell falsch. Jedenfalls nehme ich nur notwendige Regeln auf, denn diese sind dann
a) übersichtlicher
b) leichter zu warten
c) weniger Fehleranfällig

Also, Policy auf Drop, und dann nur Regeln, die bestimmte Sachen erlauben, die ich halt brauche. Alles andere wird dann eh weggeworfen.

viele Grüße

mludwig

[dirk11]

Müssen die DROP-Regeln nicht am Ende der Kette stehen? Ich dachte bisher, das IPTABLES der Reihe nach abarbeitet, und wenn ich da als erstes alles DROPpe, wie sollen die anderen Regeln dann überhaupt noch etwas mitbekommen davon?

[Raul]

Hallo erstmal,

Wirklich jedes Paket? Nur beim Verbindungsaufbau ist SYN gesetzt, was ist mit Anwortpaketen? Da die Regeln in Reihenfolge abgearbeitet werden, schmeißt deine Firewall jetzt jedes Paket, dass nicht dem Verbindungsaufbau dient (also NEW), weg? Weil mit DROP wird weggeworfen, wenn die Bedingung stimmt, die nachfolgend definierten Regeln interessieren nicht mehr. Damit sperrt man sich doch selbst aus?

Nein, alle Verbindungen funktionieren, kein aussperren.
Ich verstehe die Regel so, wenn etwas ankommt und Neu ist und nicht SYN ist, fliegt es weg. Ist die Verbindung hergestellt, dann greift diese Regel nicht, genauso für die Antwort, OUTPUT, dafür gelten dann die normalen Regeln. Ist nur für den eingehenden Erstkontakt, im Falle hier SSH.

Code: Alles auswählen

#SYN + RST
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
#SYN + FIN
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
#FIN + URG + PSH
iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
#ALL
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
#nmap Null scan
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
#nmap FIN stealth scan
iptables -A INPUT -p tcp --tcp-flags ALL FIN -j DROP
#XMAS
iptables -A INPUT -p tcp --tcp-flags ALL URG,ACK,PSH,RST,SYN,FIN -j DROP

Du meinst den Portscannbereich kann ich schrumpfen auf diesen Code?

[mludwig]

Müssen die DROP-Regeln nicht am Ende der Kette stehen? Ich dachte bisher, das IPTABLES der Reihe nach abarbeitet, und wenn ich da als erstes alles DROPpe, wie sollen die anderen Regeln dann überhaupt noch etwas mitbekommen davon?

Eine Policy ist implizit die letzte Regel einer Kette, also

Code: Alles auswählen

iptables -P INPUT -j DROP

wird jedes Paket der Kette input verworfen, was nicht durch eine vorherige Regel erlaubt wurde.

Deswegen ist es eigentlich nicht notwendig, speziell nochmal einzelne Regeln aufzustellen die bestimmte Pakete wegwerfen, wie z. B. mit den Filterregeln für Portscans weiter oben. Wenn es nicht irgendwo explizit erlaubt wird, schmeißt die Policy es sowieso weg.

[dirk11]

Dein Text beantwortet meine Frage nicht. Antworte doch bitte so, das meine Frage beantwortet wird, damit es auch verständlich ist. Oder bist Du Politiker?

[eggy]

Dein Text beantwortet meine Frage nicht. Antworte doch bitte so, das meine Frage beantwortet wird, damit es auch verständlich ist. Oder bist Du Politiker?

Doch tut er. Du verstehst es nur nicht. (Wahrscheinlich weil Du die Dokumentation von iptables nie gelesen hast.)

[mludwig]

Vielleicht nochmal anders formuliert (mit Beispiel):

Eine ssh Verbindung zu deinem Server, bei dir Port 2222.

Sie kann aufgebaut werden, da Port 2222 erlaubt ist. Beim beenden sendet der Kommunikationspartner ein Paket mit FIN flag, was bei dir von den Portscan-Regeln verworfen wird. Die Verbindung kann also nicht ordnungsgemäß beendet werden, da die Erlaubnis Port 2222 in den Regeln später erfolgt.

Ein Paket mit FIN flag auf andere Ports, was von den Portscan-Regeln (berechtigt) verworfen wird, würde aber durch die Policy auch verworfen. D. h. diese Regeln sind in meinen Augen entweder unnötig oder sogar fehlerhaft.

[Raul]

Sie kann aufgebaut werden, da Port 2222 erlaubt ist. Beim beenden sendet der Kommunikationspartner ein Paket mit FIN flag, was bei dir von den Portscan-Regeln verworfen wird. Die Verbindung kann also nicht ordnungsgemäß beendet werden, da die Erlaubnis Port 2222 in den Regeln später erfolgt.
Ein Paket mit FIN flag auf andere Ports, was von den Portscan-Regeln (berechtigt) verworfen wird, würde aber durch die Policy auch verworfen. D. h. diese Regeln sind in meinen Augen entweder unnötig oder sogar fehlerhaft.

So wie ich das verstehe, müsste der Portscannschutz unten in der Liste stehen. Dann ist der Portscannschutz dieser Art unbrauchbar, weil ein Portscanner die offenen Ports findet.
Dann würde es nur Sinn machen einen Portscannschutz zu bauen, welcher bei Anfragen auf geschlossene Ports greift und für die anfragende IP-Adresse einen Block macht für eine bestimmte Zeit.

Mit bitte um Antworten, das Thema ist doch interessant.


Ein praktischer Versuch:
Einen Test habe ich gemacht, den Codeabschnitt einmal oben und einmal unten eingefügt:

Code: Alles auswählen

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Das Ergebniss war das gleiche.

[dirk11]

Eine ssh Verbindung zu deinem Server, bei dir Port 2222.

Sie kann aufgebaut werden, da Port 2222 erlaubt ist. Beim beenden sendet der Kommunikationspartner ein Paket mit FIN flag, was bei dir von den Portscan-Regeln verworfen wird. Die Verbindung kann also nicht ordnungsgemäß beendet werden, da die Erlaubnis Port 2222 in den Regeln später erfolgt.

Ein Paket mit FIN flag auf andere Ports, was von den Portscan-Regeln (berechtigt) verworfen wird, würde aber durch die Policy auch verworfen. D. h. diese Regeln sind in meinen Augen entweder unnötig oder sogar fehlerhaft.

Nicht bei mir, sondern beim TE, aber egal. Also stimmt, was ich schrieb, und die DROP-Regel gehört an das Ende des jeweiligen Regelwerk?

[mludwig]

Eine ssh Verbindung zu deinem Server, bei dir Port 2222.

Sie kann aufgebaut werden, da Port 2222 erlaubt ist. Beim beenden sendet der Kommunikationspartner ein Paket mit FIN flag, was bei dir von den Portscan-Regeln verworfen wird. Die Verbindung kann also nicht ordnungsgemäß beendet werden, da die Erlaubnis Port 2222 in den Regeln später erfolgt.

Ein Paket mit FIN flag auf andere Ports, was von den Portscan-Regeln (berechtigt) verworfen wird, würde aber durch die Policy auch verworfen. D. h. diese Regeln sind in meinen Augen entweder unnötig oder sogar fehlerhaft.

Nicht bei mir, sondern beim TE, aber egal. Also stimmt, was ich schrieb, und die DROP-Regel gehört an das Ende des jeweiligen Regelwerk?

bei den Befehlen, die die Policy setzen, ist es egal wo in dem Skripten sie stehen, da sie immer als letztes greifen. (also iptables -P xxxx)
Bei den übrigen Befehlen (iptables -I INPUT oder iptables -A INPUT) ist die Reihenfolge wichtig, weil es hier (gewollt oder ungewollt) das Verhalten der Firewall beeinflusst.

iptables -A xxxx setzt die Regel an das bisherige Ende der Kette (aber vor! die Policy), iptables -I xxxx (I wie Insert) setzt die Regel an den Anfang, man kann auch per Parameter eine bestimmt Postition angeben.

@raul die Kombination von den Portscan-Regeln mit z. B. fail2ban würde Sinn machen, dann macht es auch Sinn diese Pakete zu protokollieren, da fail2ban diese Protokolle auswertet und dann entsprechend die auffälligen IPs sperren kann.

[Raul]

Ok Herr mludwig

Vielen Dank, hier nochmal was ich zu dem "iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP" fand:

Die Statustabelle aus Sicht der Verbindungsverfolgung

Bei der Verbindungsverfolgung gibt es lediglich die Status: NEW, ESTABLISHED, RELATED und INVALID (explizite Erweiterungen).

Achtung! Dieser Status ist nicht äquivalent mit dem TCP-Status. Wenn beispielsweise ein ACK-Paket zu einem nicht-existierenden Rechner hinter der Firewall versendet wird, wird ein Verbindungseintrag in der Statustabelle erzeugt, weil es als erstes Paket einer noch nicht bestehenden Verbindung (und damit als NEW) gilt. Unter dem Gesichtspunkt, dass solche ACK-Pakete die Statustabelle überfluten können, ist die folgende Regel sehr sinnvoll:

root@linux # iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Diese Regel stellt sicher, dass der Aufbau von TCP-Verbindungen ausschließlich durch SYN-Pakete initiiert werden kann. Sie hat jedoch einen kleinen Nachteil:

Manchmal treten bei TCP-Verbindungen äußerst lange Wartezeiten auf, und die korrespondierenden Einträge verschwinden dann aus der Statustabelle. Wenn aber nun die Verbindung mit ACK-Paketen (Daten) von außen fortgesetzt wird, dann verhindert die Regel den Transport nach innen. Anders ausgedrückt: Die Firewall dachte, die Verbindung wurde abgebrochen, und entfernte deshalb den Eintrag in der Statustabelle. Das ankommende Datenpaket (ACK) kann keiner Verbindung zugeordnet werden und gilt deshalb als "NEW". Die obenstehende Regel blockiert aber TCP-Pakete ohne SYN-Flag, die zu keiner Verbindung zugeordnet werden können. [besser Workaround tcp-window-tracking]

Quelle: https://de.wikibooks.org/wiki/Linux-Pra ... _IP-Tables

[Raul]

Guten Abend,

sicherlich kann man an einem Freitag Abend etwas anderes machen, aber heute war es halt so.

Ich kann ICMP Typ 3 und 11 nicht überprüfen.

Ich habe gelesen, dass für diese Typen ESTABLISHED,RELATED gesetzt sein soll.

Code: Alles auswählen

iptables -A INPUT -p icmp --icmp-type 3 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 3 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 11 -m state --state ESTABLISHED,RELATED -j ACCEPT

Für alle, die Interesse daran haben, ich habe hier eine tolle Übersicht gefunden:
http://www.protecus.de/Firewall_Security/icmp.html

Wie könnte ich ein ICMP Paket vom Typ 3 oder 11 prüfen?

Zur Prüfung in verschiedenen Definitionen:
In iptables alle ICMP vorerst auf DROP, OUTPUT wie INPUT.

Mit nmap -sS ipadresse kann ich Typ 3 Rückmeldungen empfangen, zudem Ping/Pong.
ipadresse ist hier eine externe.

Mit wireshark und IPTraf erhalte ich trotz aller ICMP DROP, ICMP Rückmeldung Typ 3, was nicht sein sollte.

Nur wenn ich den UDP INPUT auf DROP setze, schweigen die Netmonitore bei Typ 3.

Was läuft hier schief?

User hat sich selbst geholfen, eine tiefergründige Untersuchung hat ergeben, dass es sich um die eingehenden Pakete handelt, welche im Netmonitor angezeigt werden. Sprich die Meldungen von nmap selbst. Zumindest finde ich jetzt keine andere Erklärung.

Thema gut nu, es sei denn es gibt noch was Intelligentes

[N3Cr0N]

Hi,
hätte dir noch sowas anzubieten aus meinem Iptables Script,
dass ich mir mal zusammen geschustert habe aus verschieden Code Schnipseln, da ich nicht so der Iptables Spezie bin.

Code: Alles auswählen

# 2. Prevent DoS attack
iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT

# 3. NMAP Scan verhindern
iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,URG,PSH -j LOG --log-prefix "NMAP-XMAS SCAN:" --log-tcp-options --log-ip-options 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "NMAP-NULL SCAN:" --log-tcp-options --log-ip-options 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j LOG --log-prefix "SYN/RST SCAN:" --log-tcp-options --log-ip-options 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG --log-prefix "SYN/FIN SCAN:" --log-tcp-options --log-ip-options 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP