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 root
oder alternativ sudo
den Befehl als root ausführen müssen. Ich werde versuchen, solche Befehle mit dem optionalen zu markieren [sudo]
.
Inhalt:
- Auftragsangelegenheiten oder der Unterschied zwischen
-I
und-A
- Zeigt die aktuelle Firewall-Konfiguration an
- Interpretation der Ausgabe von
iptables -L -v -n
- Kennen Sie Ihre Umgebung
- Die INPUT- und FORWARD-Ketten
- Kernel-Module
1. Ordnungsangelegenheiten oder der Unterschied zwischen -I
und-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 -A
Option 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 -I
der 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 -n
ist dein Freund (obwohl manche Leute es iptables-save
besser mögen ). Bei der Besprechung von Konfigurationen ist es oft nützlich, die --line-numbers
Option 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-save
Ausgabe enthalten, müssen jedoch separat aufgelistet werden, indem die -t nat
Option 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-save
ein 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 INPUT
Kette, 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-SSH
die 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-SSH
Kette 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- lo
Schnittstelle ( 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 iptables
den 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 -plnut
oder 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 123
oder openssl s_server -accept 1234 [options]
wenn Sie einen TLS / SSL-Listener benötigen (prüfen Sie, ob man s_server
Optionen verfügbar sind ).
- Stellen Sie sicher , dass Sie eine Verbindung vom Server selbst herstellen können, dh
telnet <IP of Server> 123
oder echo "Hello" | nc <IP of Server> 123
wenn 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/services
stimmen 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.
getenforce
wird 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 libwrap
und die /hosts.[allow|deny]
Steuerdateien.
5. INPUT
oder FORWARD
Ketten
Das Konzept der Ketten wird hier ausführlicher erklärt , aber die kurze davon ist:
In der INPUT
Kette ö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 FORWARD
Kette 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_ftp
denen 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.