Debuggen von Iptables und häufigen Firewall-Tücken?


18

Dies ist eine vorgeschlagene kanonische Frage zum Verständnis und Debuggen der Software-Firewall auf Linux-Systemen.

Als Antwort auf die Antwort der EEAA und auf die Bemerkung von @ Shog, dass wir eine geeignete kanonische Frage und Antwort benötigen, um gängige, relativ einfache Fragen zu iptables zu beantworten.

Was ist eine strukturierte Methode zum Debuggen von Problemen mit der Linux-Software-Firewall, dem Netfilter- Paketfilter-Framework, auf das in der Benutzeroberfläche iptables häufig Bezug genommen wird ?

Was sind häufige Fallstricke, wiederkehrende Fragen und einfache oder etwas undeutlichere Dinge, die ein gelegentlicher Firewall-Administrator übersehen oder auf andere Weise davon profitieren könnte?

Selbst wenn Sie Tools wie UFW , FirewallD (aka firewall-cmd), Shorewall oder ähnliches verwenden, können Sie davon profitieren, wenn Sie ohne die Abstraktionsschicht, die diese Tools bieten, unter die Haube schauen.

Diese Frage ist nicht als How-To soll Firewalls für den Bau: die Überprüfen der Produktdokumentation für die und zum Beispiel dazu beitragen , Rezepte zu iptables Reise & Tricks oder suchen Sie die markierten Fragen für bestehende häufiges und gut angesehen High-Scoring Fragen und Antworten.


1
Was ist mit NAT- und Stateful-Regeln, die früher in die Kette aufgenommen werden können, um die Leistung zu verbessern und die Sicherheit zu erhöhen?
Matt

1
@Matt: Die Optimierung von Firewall-Regeln ist eine vollständige Frage und Antwort. In dieser
Frage und

1
Wenn Sie die Regel, die Sie in IPtables haben sollten, nicht erreichen, fügen Sie eine ähnliche LOG-Regel hinzu und folgen Sie der Kette, bis Sie die LOG-Nachrichten erhalten. Dann wird eine der Regeln darunter die Regel sein, die auf Ihrem Paket falsch übereinstimmt.
Matthew Ife

1
Oh, und die Einstellung net.netfilter.nf_conntrack_log_invalidauf 255 erfasst ziemlich gut ungültige Pakete, was helfen kann, wenn der zustandsbehaftete Teil von netfilter das schlechte Verhalten erzeugt.
Matthew Ife

Antworten:


14

Im Allgemeinen:

Das Anzeigen und Ändern der Firewall-Konfiguration erfordert Administratorrechte ( root) sowie das Öffnen von Diensten im eingeschränkten Portnummernbereich. Das bedeutet, dass Sie entweder angemeldet sein rootoder alternativ sudoden Befehl als root ausführen müssen. Ich werde versuchen, solche Befehle mit dem optionalen zu markieren [sudo].

Inhalt:

  1. Auftragsangelegenheiten oder der Unterschied zwischen -Iund-A
  2. Zeigt die aktuelle Firewall-Konfiguration an
  3. Interpretation der Ausgabe von iptables -L -v -n
  4. Kennen Sie Ihre Umgebung
  5. Die INPUT- und FORWARD-Ketten
  6. Kernel-Module

1. Ordnungsangelegenheiten oder der Unterschied zwischen -Iund-A

Beachten Sie, dass die Firewall-Regeln in der angegebenen Reihenfolge überprüft werden. Der Kernel beendet die Verarbeitung der Kette, wenn eine Regel ausgelöst wird, die ein Paket oder eine Verbindung entweder zulässt oder sperrt.

Ich denke, der häufigste Fehler für unerfahrene Firewall-Administratoren ist, dass sie die richtigen Anweisungen befolgen, um einen neuen Port zu öffnen, wie den folgenden:

[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT

und dann feststellen, dass es nicht wirksam wird.

Der Grund dafür ist, dass die -AOption diese neue Regel nach allen vorhandenen Regeln hinzufügt und da sehr oft die letzte Regel in der vorhandenen Firewall eine ist, die den gesamten Verkehr blockiert, der nicht explizit zulässig ist, was dazu führt

...
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
8        0  0    ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080

Oder gleichwertig in iptables-save:

...
iptables -A INPUT  -j REJECT
iptables -A INPUT  -p tcp --dport 8080 -j ACCEPT

und die neue Regel, die den TCP-Port 8080 öffnet, wird niemals erreicht. (Dies zeigt sich daran, dass die Zähler hartnäckig bei 0 Paketen und 0 Bytes bleiben).

Das Einfügen der Regel mit -Ider neuen Regel wäre die erste in der Kette gewesen und würde funktionieren.

2. Zeigen Sie die aktuelle Firewall-Konfiguration an

Ich empfehle dem Firewall-Administrator, sich die tatsächliche Konfiguration des Linux-Kernels anzusehen, anstatt zu versuchen, Firewall-Probleme mithilfe benutzerfreundlicher Tools zu diagnostizieren. Wenn Sie die zugrunde liegenden Probleme verstanden haben, können Sie sie häufig problemlos in einer von diesen Tools unterstützten Angelegenheit lösen.

Der Befehl [sudo] iptables -L -v -nist dein Freund (obwohl manche Leute es iptables-savebesser mögen ). Bei der Besprechung von Konfigurationen ist es oft nützlich, die --line-numbersOption auch zum Nummerieren von Zeilen zu verwenden. Wenn Sie sich auf Regel #X beziehen, wird das Erörtern dieser Regeln etwas einfacher.
Hinweis: NAT-Regeln sind in der iptables-saveAusgabe enthalten, müssen jedoch separat aufgelistet werden, indem die -t natOption dh [sudo] iptables -L -v -n -t nat --line-numbers.

Wenn Sie den Befehl mehrmals ausführen und nach inkrementierenden Zählern suchen, kann dies hilfreich sein, um festzustellen, ob tatsächlich eine neue Regel ausgelöst wird.

[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     784K   65M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
2    2789K  866M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3       15  1384 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       117.239.37.150       0.0.0.0/0           reject-with icmp-port-unreachable
2        4   412 REJECT     all  --  *      *       117.253.208.237      0.0.0.0/0           reject-with icmp-port-unreachable

Alternativ gibt die Ausgabe von iptables-saveein Skript aus, das die obige Firewall-Konfiguration neu generieren kann:

[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT

Es ist eine Frage der Präferenz, was für Sie verständlicher ist.

3. Interpretation der Ausgabe von iptables -L -v -n

Die Richtlinie legt die Standardaktion fest, die die Kette verwendet, wenn keine explizite Regel zutrifft. In der INPUTKette, die auf ACCEPT all traffic gesetzt ist.

Die erste Regel in der INPUT-Kette ist sofort eine interessante Regel. Sie sendet den gesamten Verkehr (Quelle 0.0.0.0/0 und Ziel 0.0.0.0/0), der für TCP-Port 22 ( tcp dpt:22) bestimmt ist, an ein benutzerdefiniertes Ziel ( fail2ban-SSH). . Wie der Name schon sagt, wird diese Regel von fail2ban (einem Sicherheitsprodukt, das unter anderem Systemprotokolldateien auf möglichen Missbrauch überprüft und die IP-Adresse des Missbrauchers blockiert) verwaltet.

Diese Regel wurde von einer iptables-Befehlszeile erstellt, iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHdie der Ausgabe von iptables-save as ähnelt oder in dieser enthalten ist -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH. Oft finden Sie eine dieser Notationen in der Dokumentation.

Die Zähler zeigen an, dass diese Regel 784'000 Paketen und 65 Megabyte Daten entspricht.

Datenverkehr, der mit dieser ersten Regel übereinstimmt, wird dann von der fail2ban-SSHKette verarbeitet , die als nicht standardmäßige Kette unterhalb der OUTPUT-Kette aufgelistet wird.

Diese Kette besteht aus zwei Regeln, eine für jeden Missbraucher (Quell-IP-Adresse 117.253.221.166 oder 58.218.211.166), der blockiert ist (mit einem reject-with icm-port-unreachable).

 -A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
 -A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable

SSH-Pakete, die nicht von diesen blockierten Hosts stammen, sind noch nicht zulässig oder nicht zulässig. Sobald die benutzerdefinierte Kette abgeschlossen ist, wird sie anhand der zweiten Regel in der INPUT-Kette überprüft.

Alle Pakete, die nicht für Port 22 bestimmt waren, haben die erste Regel in der INPUT-Kette bestanden und werden auch in der INPUT-Regel # 2 ausgewertet.

Die INPUT-Regel Nummer 2 macht dies zu einer Statefull-Firewall , die Verbindungen nachverfolgt . Dies hat einige Vorteile, da nur die Pakete für neue Verbindungen gegen den vollständigen Regelsatz geprüft werden müssen, aber sobald dies zulässig ist, werden zusätzliche Pakete, die zu einer eingerichteten oder verwandten Verbindung gehören, ohne weitere Prüfung akzeptiert.

Die Eingaberegel 2 stimmt mit allen offenen und verwandten Verbindungen überein, und Pakete, die mit dieser Regel übereinstimmen, müssen nicht weiter ausgewertet werden.

Hinweis: Regeländerungen in der Konfiguration einer Stateful Firewall wirken sich nur auf neue Verbindungen aus, nicht auf hergestellte Verbindungen.

Im Gegensatz dazu testet ein einfacher Paketfilter jedes Paket anhand des vollständigen Regelsatzes, ohne den Verbindungsstatus zu verfolgen. In einem solchen Firewall keine staatlichen Schlüsselwörter verwendet werden würde.

Die INPUT-Regel Nr. 3 ist ziemlich langweilig. Der gesamte Datenverkehr, der mit der Loopback- loSchnittstelle ( oder 127.0.0.1) verbunden ist, ist zulässig.

Mit den INPUT-Regeln 4, 5 und 6 werden die TCP-Ports 22, 80 und 443 (die Standardports für SSH, HTTP und HTTPS) geöffnet, indem der Zugriff auf NEUE Verbindungen gewährt wird (bestehende Verbindungen sind bereits nach INPUT-Regel 2 zulässig).

In einer zustandslosen Firewall werden diese Regeln ohne die Statusattribute angezeigt:

4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

oder

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Die letzte INPUT-Regel, # 7, blockiert den gesamten Datenverkehr, für den in den INPUT-Regeln 1-7 KEIN Zugriff gewährt wurde. Eine ziemlich verbreitete Konvention: Alles, was nicht erlaubt ist, wird abgelehnt. Theoretisch hätte diese Regel entfallen können, wenn die Standard-POLICY auf REJECT gesetzt worden wäre.

Untersuchen Sie immer die gesamte Kette.

4. Kennen Sie Ihre Umgebung

4.1. Die Einstellungen in einer Software-Firewall wirken sich nicht auf Sicherheitseinstellungen aus, die an anderer Stelle im Netzwerk gespeichert werden. Das heißt, trotz des Öffnens eines Netzwerkdienstes mit iptablesden unveränderten Zugriffssteuerungslisten auf Routern oder anderen Firewalls in Ihrem Netzwerk wird der Datenverkehr möglicherweise weiterhin blockiert.

4.2. Wenn kein Dienst empfangsbereit ist, können Sie unabhängig von den Firewall-Einstellungen keine Verbindung herstellen und erhalten den Fehler "Verbindung abgelehnt" . Deshalb:

  • Vergewissern Sie sich, dass ein Dienst empfangsbereit ist (auf der richtigen Netzwerkschnittstelle / IP-Adresse) und die von Ihnen erwarteten Portnummern verwendet [sudo] netstat -plnutoder diese alternativ verwendet ss -tnlp.
  • Wenn Ihre Dienste noch nicht ausgeführt werden sollen, emulieren Sie einen einfachen Listener mit beispielsweise netcat: [sudo] nc -l -p 123oder openssl s_server -accept 1234 [options] wenn Sie einen TLS / SSL-Listener benötigen (prüfen Sie, ob man s_serverOptionen verfügbar sind ).
  • Stellen Sie sicher , dass Sie eine Verbindung vom Server selbst herstellen können, dh telnet <IP of Server> 123oder echo "Hello" | nc <IP of Server> 123wenn Sie den TLS / SSL-gesicherten Dienst testen openssl s_client -connect <IP of Server>:1234, bevor Sie ihn von einem Remotehost aus versuchen.

4.3. Verstehen Sie die von Ihren Diensten verwendeten Protokolle. Sie können Dienste, die Sie nicht ausreichend verstehen, nicht ordnungsgemäß aktivieren / deaktivieren. Zum Beispiel:

  • wird TCP oder UDP verwendet oder beides (wie bei DNS)?
  • Verwendet der Dienst einen festen Standardport (z. B. TCP-Port 80 für einen Webserver)?
  • Alternativ kann eine dynamische Portnummer gewählt werden, die variieren kann (dh RPC-Dienste wie klassisches NFS, die sich bei Portmap registrieren).
  • infamous FTP verwendet sogar zwei Ports , eine feste und eine dynamische Portnummer, wenn es für den passiven Modus konfiguriert ist ...
  • Die Dienst-, Port- und Protokollbeschreibungen in /etc/servicesstimmen nicht unbedingt mit dem tatsächlichen Dienst überein, der einen Port verwendet.

4.4. Der Kernel-Paketfilter ist nicht das einzige, was die Netzwerkkonnektivität einschränken kann:

  • SELinux schränkt möglicherweise auch die Netzwerkdienste ein. getenforcewird bestätigen, ob SELinux läuft.
  • Obwohl TCP-Wrapper etwas undeutlich werden, sind sie immer noch ein leistungsfähiges Werkzeug zur Durchsetzung der Netzwerksicherheit. Überprüfen Sie mit ldd /path/to/service |grep libwrapund die /hosts.[allow|deny]Steuerdateien.

5. INPUToder FORWARDKetten

Das Konzept der Ketten wird hier ausführlicher erklärt , aber die kurze davon ist:

In der INPUTKette öffnen und / oder schließen Sie Netzwerkports für lokal ausgeführte Dienste auf dem Host, auf dem Sie die iptables-Befehle absetzen.

In dieser FORWARDKette wenden Sie Regeln an, um den Datenverkehr zu filtern, der vom Kernel an andere Systeme, tatsächliche Systeme, aber auch Docker-Container und virtuelle Gastserver weitergeleitet wird, wenn Ihr Linux-Computer als Bridge, Router, Hypervisor und / oder Netzwerkadresse fungiert Übersetzung und Portweiterleitung.

Da ein Docker-Container oder ein KVM-Gast lokal ausgeführt wird, sollte die anzuwendende Filterregel in der INPUT-Kette enthalten sein. Dies ist jedoch normalerweise nicht der Fall.

6. Kernel-Module

Da der Paketfilter im Linux-Kernel ausgeführt wird, kann er auch als dynamisches Modul kompiliert werden, dh als mehrere Module. Die meisten Distributionen enthalten Netfilter als Module, und die erforderlichen Netfilter-Module werden nach Bedarf in den Kernel geladen. Bei einigen Modulen muss ein Firewall-Administrator jedoch manuell sicherstellen, dass sie geladen werden. Dies betrifft in erster Linie die Verbindungsverfolgungsmodule, mit nf_conntrack_ftpdenen beispielsweise geladen werden kann insmod.

Mit können die aktuell in den laufenden Kernel geladenen Module angezeigt werden lsmod.

Die Methode, mit der sichergestellt wird, dass Module über Neustarts hinweg dauerhaft geladen werden, hängt von der Linux-Distribution ab.


1
Bei der Suche nach Inkrement-Paket / Byte-Zählern. Ein nützliches Werkzeug ist die Verwendung von watch im differentiellen Modus. So etwas wie folgt aus : watch --difference -n 1 iptables -L FORWARD -v -n. Wenn das Tool den Befehl regelmäßig ausführt und die Änderungen hervorhebt, ist dies viel einfacher.
Zoredache

1
Ich habe gerade Ihren schleppenden Kommentar gesehen. Dies ist eine gute Antwort, nicht sicher, ob ich viel hinzufügen kann. Möglicherweise möchten Sie die Verwendung der TRACE- Funktion erwähnen .
Zoredache

Ich werde die iptables-saveAusgabe (vorzugsweise mit -c) jedes Mal über diese gefürchtete iptables -L(mit verschiedenen Argumenten) Ausgabe nehmen.
0xC0000022L

7

Häufige Probleme mit verschiedenen Protokollen

DNS: DNS verwendet standardmäßig UDP-Port 53, aber Nachrichten, die nicht in ein einzelnes UDP-Datagramm passen, werden stattdessen über TCP übertragen (in der Regel Zonenübertragungen usw.), wobei auch TCP-Port 53 geöffnet sein muss, wenn Sie einen Nameserver ausführen .

E-Mail: Viele Internetdienstanbieter blockieren den SMTP-Verkehr (oder zumindest den Standardport TCP 25), sodass E-Mails nicht direkt empfangen oder gesendet werden können und ihre Kunden gezwungen sind, das SMTP-Relay des Internetdienstanbieters für alle ausgehenden E-Mails und manchmal auch für eingehende E-Mails zu verwenden . Bezieht sich auf §1.1.

FTP: FTP ist ein ungewöhnliches Protokoll, wenn zwei Verbindungen verwendet werden. Die erste ist die Steuerverbindung. Standardmäßig überwacht ein FTP-Server den TCP-Port 21 darauf. Die Steuerverbindung wird zur Authentifizierung und zur Ausgabe von Befehlen verwendet. Die eigentlichen Dateiübertragungen und Dinge wie die Ausgabe einer Verzeichnisliste gehen über eine zweite TCP-Verbindung, die DATA-Verbindung. Bei aktivem FTP würde diese DATA-Verbindung vom FTP-Server über TCP-Port 20 initiiert und eine Verbindung zum FTP-Client hergestellt. Active FTP funktioniert bei Benutzern hinter Firewalls und NAT-Gateways nicht besonders gut, weshalb es größtenteils nicht mehr genutzt wird. Die meisten FTP-Server unterstützen stattdessen Passives FTP. Mit Passives FTP öffnet der FTP-Server einen Listener für die DATA-Verbindung an einem zweiten Port, mit dem sich der FTP-Client verbinden kann. Das Problem für eine Firewall besteht darin, dass der DATA-Port ein beliebiger verfügbarer unprivilegierter Port zwischen 1024 und 65536 sein kann.

In einer zustandslosen Firewall wird dies normalerweise behoben, indem die Anzahl der vom FTP-Server zugewiesenen passiven Ports beschränkt und diese Ports dann explizit geöffnet werden. dh

iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT

In einer Stateful-Firewall muss der DATA-Port nicht explizit geöffnet werden. Das Netfilter-Hilfsmodul erkennt den zugewiesenen dynamischen Port und öffnet diesen Port dynamisch für den richtigen Client, indem die DATA-Verbindung als RELATEDmit der generischen Regel übereinstimmend markiert wird :

  iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT

Dies setzt voraus , dass das richtige Kernel-Modul geladen ist, im FTP-Fall beispielsweise durch manuelles Ausführen insmod nf_conntrack_ftp, sodass die Dauerhaftigkeit beim Neustart von der Distribution abhängt.

Hinweis: Das FTP-Verbindungsverfolgungsmodul schlägt fehl, wenn FTP mit SSL verwendet wird, da die Steuerverbindung verschlüsselt wird und der nf_conntrack_ftp die PASV-Antwort nicht mehr lesen kann.

NFS und ähnliche RPC-Dienste: Das Problem bei RPC-Diensten besteht darin, dass sie standardmäßig keinen bestimmten festen Port verwenden. Sie können jeden verfügbaren Port nach dem Zufallsprinzip auswählen, der dann beim RPC-Portmap-Dämon registriert wird. Ein Client, der versucht, eine Verbindung herzustellen, fragt den Portmap-Dämon ab und stellt dann eine direkte Verbindung zum richtigen Port her. Damit wurde das Problem gelöst, dass nicht mehr genügend reservierte Ports zur Verfügung stehen ...

Aus Firewall-Sicht muss der TCP / UDP-Port 111 und der tatsächliche Port, den der RPC-Dienst derzeit verwendet, geöffnet sein. Das Problem des Öffnens eines solchen zufälligen Ports in einer Firewall wird normalerweise dadurch gelöst, dass der RPC-Dienst, z. B. der NFS-Server, auf die Verwendung eines vordefinierten festen Ports beschränkt wird.


7

Iptables / Firewall "Einführung"

Eine Firewall ist im Grunde ein richtlinienbasierter Netzwerkfilter. Linux-Firewalls basieren auf Netfilter. Das Netzwerk-Paketverarbeitungs-Framework des Kernels, das aus mehreren Kernel-Modulen besteht, die bestimmte Aufgaben ausführen:

  1. Das FILTER-Modul (standardmäßig immer geladen) ermöglicht es uns hauptsächlich, IP-Pakete basierend auf bestimmten Übereinstimmungskriterien zu akzeptieren oder zu verwerfen.
  2. Mit dem NAT-Modulsatz können wir Netzwerkadressübersetzungen (SNAT, DNAT, MASQUERADE) durchführen.
  3. Mit dem MANGLE-Modul können wir bestimmte IP-Paketfelder (TOS, TTL) ändern.

Benutzer konfigurieren das Netfilter-Framework mithilfe von iptables über die Befehlszeile so, dass es ihren Firewall-Anforderungen entspricht. Mit iptables definieren wir Regeln, die den Kernel anweisen, was mit IP-Paketen zu tun ist, wenn sie in unserer Linux-Box ankommen, diese passieren oder diese verlassen. Jeder Netfilter-Hauptprozess wird durch eine TABELLE (FILTER, NAT, MANGLE) auf iptables-Jargon dargestellt. Sie haben mehrere spezifische Hook-Punkte in der Netzwerkpaketflusskarte, an denen sie vom Kernel aufgerufen werden, um ihre Aufgaben auszuführen. Bestimmte speziell lokalisierte Sequenzen von TABLE-Aufrufen werden allgemein als integrierte Ketten bezeichnet, die die Namen PREROUTING, INPUT, FORWARD, OUTPUT und POSTROUTING empfangen. Es ist leicht zu merken, ob wir eine TABELLE einem "Prozesstyp" und eine KETTE dem "Ort" auf der Netzwerkpaketflusskarte zuordnen, an dem Instanzen dieser Prozesse aufgerufen werden.

Bildbeschreibung hier eingeben

Da ein IP-Paket auf einer Netzwerkschnittstelle empfangen oder von einem lokalen Prozess erstellt wird, bis es endgültig zugestellt oder verworfen wird, testet die Netfilter-Engine nacheinander die in der Netzwerkpaketflusskarte enthaltenen Regeln und wendet sie an. Bei jedem Block, der durch ein TABLE @ CHAIN-Paar identifiziert wird, kann der Benutzer eine oder mehrere dieser aufeinanderfolgenden Regeln hinzufügen, die ein IP-Paket-Übereinstimmungskriterium und eine entsprechende Vorgehensweise enthalten. Es gibt Aktionen (dh ACCEPT, DROP usw.), die von mehr als einer TABLE ausgeführt werden können, und andere Aktionen (dh SNAT, DNAT usw.), die TABLE-spezifisch sind.

Das heißt, wenn ein IP-Paket von einer Netzwerkschnittstelle ankommt, wird es zuerst von der PREROUTING-Kette verarbeitet, wobei gegebenenfalls die benutzerdefinierten Regeln der MANGLE-Tabelle aufgerufen werden. Wenn es keine Regeln gibt, die mit dem aktuellen Paket übereinstimmen, gilt die entsprechende MANGLE @ PREROUTING-Standardaktion oder "Richtlinie". An diesem Punkt, wenn das Paket nicht verworfen wurde, wird der Prozess fortgesetzt und die Regeln der NAT-Tabelle in der PREROUTING-Kette (siehe Karte) und so weiter aufgerufen. Um das Layout der Regeln zu vereinfachen, können Benutzer auch ihre eigenen benutzerdefinierten Ketten erstellen und von verschiedenen Punkten der Karte aus darauf "springen".

Bildbeschreibung hier eingeben

Während integrierte Ketten benutzerdefinierte Richtlinien für ACCEPT- oder DROP-Pakete haben können, haben benutzerdefinierte Ketten immer eine unveränderbare Standardrichtlinie von RETURN für den Aufrufer, um den Prozess fortzusetzen.

Iptables-Befehle

Die iptables-Hauptbefehle füllen die Netzwerkpaketflusskarte mit den erforderlichen Verarbeitungsregeln.

Die generische iptables-Regel kann wie folgt geschrieben werden:

# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>

Es könnte gelesen werden wie:

Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed

<table>
  -t filter       (the filter table is assumed when omitted)
  -t nat
  -t mangle 

<Add/Insert/Delete>
  -A              (append rule at the end of the chain list)
  -I              (insert rule at the begining of the chain list)
  -D              (Delete rule)

<CHAIN>
  PREROUTING
  INPUT
  FORWARD
  OUTPUT
  POSTROUTING
  USER_DEFINED_CHAIN

<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
  -i [!] <if_name>    or --in-interface [!] <if_name>
          (OUTPUT and POSTROUTING chains cannot match on input  interfaces)
  -o [!] <if_name>    or --out-interface [!] <if_name>
          (INPUT  and PREROUTING  chains cannot match on output interfaces) 
    -mac-source [!] <xx-xx-xx-xx-xx-xx>
            (OUTPUT and POSTROUTING chains cannot match on input  interfaces)

ISO Level-3 matching:
  -s [!] <src_ip>     or --src [!] <src_ip>   or --source [!] <src_ip>
  -d [!] <dst_ip>     or --src [!] <dst_ip>   or --destination [!] <dst_ip>

ISO Level-4 matching:
  -p [!] <prot_name>    or --protocol [!] <prot_name>  (udp|tcp|icmp)

  Also available when ICMP protocol is defined
  --icmp-type [!] <icmp_type>

  Also available when UDP protocol is defined
  --source-port [!] <udp_src_port>      or --sport [!] <udp_src_port>
  --destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>

  Also available when TCP protocol is defined
  --source-port [!] <tcp_src_port>      or --sport [!] <tcp_src_port>
  --destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
  --tcp-flags [!] <tcp_flags>   (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
    --syn
  --tcp-option [!] <tcp_option#>

  --state [!] <state>
  -m <match> [options]

    note: [!] = negation operator

<ACTION>                (also called TARGET)
  -j ACCEPT             (process continues with rules of the next table in map)
  -j DROP               (discard current packet)
  -j REJECT             (discard current packet with ICMP notification)
      option:
      --reject-with <reject_type>
  -j USER_DEFINED_CHAIN   (start traversing USER_DEFINED_CHAIN rules)
  -j RETURN               (return from USER_DEFINED_CHAIN)
  -j LOG                  (log to syslog, then process next rule in table)
      options:
      --log-level <level>
      --log-prefix <prefix>
      --log-tcp-sequence
      --log-tcp-options
      --log-ip-options
      --log-uid

nat table specific
  -j SNAT             (rewrite the source IP address of the packet)
      option:
      --to <ip_address>
  -j SAME             (idem SNAT; used when more than one source address)
      options:
      --nodst 
      --to <a1-a2>
  -j MASQUERADE       (idem SNAT; used when the replace IP is dynamic)
  -j DNAT             (rewrite the destination IP address of the packet)
      option:
      --to <ip_address>
  -j REDIRECT         (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
      option:
      –-to-port <port#>

mangle table specific
  -j ROUTE            (explicitly route packets, valid at PREROUTING)
      options:
      --iface <iface_name>
      --ifindex <iface_idx>
  -j MARK             (set Netfilter mark values)
      options:
      --set-mark <value>
      --and-mark <value>
      --or-mark <value> 
  -j TOS              (set the IP header Type of Service field) 
      option:
      --set-tos <value>
  -j DSCP             (set the IP header Differentiated Services Field)
      options:
      --set-dscp <value>
      --set-dscp-class <class>
  -j TTL              (set the IP header Time To Live field)
      options:
      --ttl-set <value>
      --ttl-dec <value>
      --ttl-inc <value>

Die Hilfsbefehle von iptables vervollständigen das Szenario, indem Standardbedingungen festgelegt, Regeln aufgelistet, Regeln gelöscht usw. werden.

#iptables -t <table> -L             
       (Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>     
       (Lists the <table> rules in <CHAIN>)

#iptables -t <table> -N <CHAIN>     
       (Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>  
       (Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)

#iptables -t <table> -X   
       (Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
       (Deletes user-defined <CHAIN> created for holding <table> rules)

#iptables -t <table> -P <CHAIN> <ACTION>     where <ACTION> = ACCEPT|DROP
       (Sets the default policy of <table> rules at <CHAIN> to <ACTION>)

#iptables -t <table> -F             
       (Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
       (Flushes (deletes) all <table> rules in <CHAIN>)

#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
       (Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>

Iptables lädt unsere Befehle zur Laufzeit in die Netfilter-Engine. Netfilter erzwingt sofort die geladenen Regeln und Einstellungen, sie sind jedoch nicht dauerhaft. Nach einem Neustart gehen alle zuvor geladenen Netfilter-Regeln und -Einstellungen verloren. Aus diesem Grund gibt es iptables-Dienstprogramme, mit denen Sie den derzeit aktiven Regelsatz in einer Datei speichern und später erneut laden können.

#iptables-save > fileName
      (Save the currently active Netfilter ruleset to fileName)

#iptables-restore < fileName
      (Restore Netfilter ruleset to the one saved in fileName)

Iptables Zusammenfassung

Netfilter ist ein extrem flexibles und leistungsstarkes Framework, für das jedoch ein Preis zu zahlen ist. Iptables ist komplex. Aus Anwendersicht stimmen bestimmte Begriffe wie TABLE, CHAIN, TARGET nicht wirklich mit dem Konzept überein, das sie darstellen, und ergeben zunächst keinen Sinn. Das Thema ist lang, Befehle scheinen eine endlose Liste von Parametern zu haben. Erschwerend kommt hinzu, dass es kein einziges Buch gibt, das Iptables wirklich beherrscht. Sie fallen meist in zwei Kategorien: "Rezeptbuch" oder "Handbuch". Ich denke, diese Einführung gibt Ihnen einen Überblick über die Netfilter / Iptables-Landschaft sowie die notwendige Dosis vorverdauten Manpage-Materials. Wenn Sie neu bei iptables sind, können Sie nach mehrmaligem Lesen dieser Absätze Beispiele für iptables lesen. Mit etwas Übung werden Sie bald feststellen, dass Sie Ihre eigenen Regeln schreiben.

Firewalls

Eine Firewall dient hauptsächlich dazu, den Netzwerkverkehr basierend auf einer Reihe von Regeln dynamisch zuzulassen oder abzulehnen. An dieser Stelle ist es leicht zu verstehen, warum das Linux Netfilter / Iptables-Framework perfekt für die Firewall-Erstellung geeignet ist. In der Netzwerk-Paketflusskarte finden wir zwei besonders interessante Stellen in der FILTER-Tabelle in den Ketten INPUT und FORWARD. Wir können dort über die IP-Quelladresse, das IP-Protokoll (UDP / TCP), den Zielport (80, 21, 443 usw.) usw. entscheiden, ob wir ein bestimmtes IP-Paket akzeptieren, ablehnen oder einfach fallen lassen. Dies ist, was eine Firewall 80% der Zeit tut, wenn zB ein Webserver vor nicht autorisierten Netzwerkanforderungen geschützt wird. Die anderen 20% der Zeit manipulieren (NAT, MANGLE) Netzwerkpakete.

Firewalls-Szenarien

Es gibt Hunderte verschiedener Firewall-Layouts, die unterschiedliche Anforderungen erfüllen, aber drei davon können als die typischsten Firewall-Szenarien angesehen werden.

  1. Einfacher Webserver mit einer oder mehreren mit dem Internet verbundenen Schnittstellen. Die Richtlinie enthält grundlegende Regeln, um eingeschränkten eingehenden Zugriff, uneingeschränkten ausgehenden Zugriff und Antispoofing-Regeln zuzulassen. Die IP-Weiterleitung ist deaktiviert.
  2. Diese Firewall stellt eine Verbindung zum Internet und zu einem geschützten internen Bereich her. Die Richtlinie enthält grundlegende Regeln, um eingeschränkten eingehenden Zugriff, uneingeschränkten ausgehenden Zugriff und Antispoofing-Regeln zuzulassen. Da der geschützte Bereich private IP-Adressen verwendet, wird Quell-NAT benötigt. IP-Weiterleitung ist aktiviert.
  3. Diese Firewall verbindet sich mit dem Internet, dem internen geschützten und demilitarisierten Bereich. Die Richtlinie enthält grundlegende Regeln, um eingeschränkten eingehenden Zugriff, uneingeschränkten ausgehenden Zugriff und Antispoofing-Regeln zuzulassen. Da geschützte Bereiche und DMZ-Bereiche private IP-Adressen verwenden, benötigen sie Quell- und Ziel-NAT. IP-Weiterleitung ist aktiviert. Bildbeschreibung hier eingeben

Ich habe dies geschrieben für: http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.