Firewalls
Siehe auch
netfilter vs iptables vs nftables vs firewalld
Netfilter (https://netfilter.org) wird das (erste echte) Packet-Control-Framework des Linux-Kernels genannt. Es stellt Funktionen zur Paket-Filterung, NATting und Port Translation zur Verfügung. Die Netfilter-Entwicklung begann 1998 und findet sich seit Version 2.4 im Linux-Kernel. Der Vorgänger hiess ipchains, der Vor-Vorgänger ipfwadm (BSD-inspiriert).
Netfilter erlaubt einzelnen Kernel-Modulen jedes eingehende, ausgehende oder weitergeleitete Pakete zu inspizieren. Es erreicht dies durch eine Sammlung von Hooks im Linux-Kernel, die Kernel-Modulen das Registrieren von Callback-Funktionen im Networking Stack erlaubt. Die Hooks haben Prioritäten:
conntrack = -200
conntrack_confirm = int_max
conntrack_defrag = -400
conntrack_helper = 300
filter = 0
first = int_min
last = int_max
mangle = -150
nat_dst = -100
nat_src = 100
raw = -300
raw_before_defrag = -450
security = 50
selinux_first = -225
selinux_last = 225
Sobald ein Paket einen Hook im Network-Stack passiert, werden die registrierten Callback-Funktionen getriggert, die meist eine Filterung oder Modifikation des Paketes implementieren. Prominente Kernel-Module, die dieses Prinzip nutzen, sind iptables und nftables.
iptables: Die ab CentOS 7 als „legacy“ ausgewiesenen Kernel-Module ip_tables
, ip6_tables
, arp_tables
und ebtables
sind die ältesten Paketfilter für Netfilter und stellen ein tabellenbasiertes System zur Paketfilterung und -modifikation zur Verfügung, beispielsweise, ob Pakete gefiltert („filter“-Tabelle) oder übersetzt („NAT“) werden müssen (daher der Name).
iptables organisiert Regeln in sogenannten „Chains“. Regeln ermöglichen das Matching von Paketen; eine Chain ist eine Sammlung von Regeln in fixer Reihenfolge. Die vordefinierten Chain-Namen wie PREROUTING
, INPUT
und andere helfen, den Ursprung des Paketes im Netfilter-Stack auszumachen. Am Ende wird ein Paket ACCEPTed oder DROPped.
nftables: Der Nachfolger von Netfilter. Das passende Kernel-Modul hier heisst nf_tables
und ist ab CentOS 8 das Standard-Kernel-Modul für die Paketfilterung. nftables fügt dem Linux-Kernel eine einfache virtuelle Maschine hinzu, die rudimentäre Bytecode-Operationen auf Pakete ausführt, um zu entscheiden, wie das Paket zu handhaben ist: die VM kann Daten aus dem Paket extrahieren, Metadaten untersuchen und Connection Tracking Data verwalten. Zur Entscheidungsfindung lassen sich arithmetische, Bit- und Vergleichs-Operatoren einsetzen. Die VM kann darüber hinaus Paketdaten ändern (meist IP-Adressen). nftables bietet einen Kompatibilitätslayer zu iptables.
Der Entscheid für nftables fiel, da netfilter & Co. aus heutiger Sicht nicht allgmein genug und zu protokollspezifisch implementiert wurden, und die Logiken daher viermal repliziert werden mussten (für IPv4, IPv6, ARP und Ethernet Bridging). Zudem ist nftables wesentlich simpler konzipiert und performanter als netfilter/iptables.
- Userspace Utility Programs
Es existiert eine Reihe an Userland-Werkzeugen (also Frontends), die mit eigener Syntax Regeln für die Kernel-Module Netfilter oder nftables erzeugen.
Für die Pflege der Tabellen der Netfilter-Kernelmodule:
iptables
ip6tables
arptables
ebtables
firewalld (bis CentOS 7)
ufw („Uncomplicated Firewall“, Ubuntu)
Für die nftables-Kernelmodule:
nft (direkt für nftables; ersetzt iptables, ip6tables, arptables und ebtables)
firewalld (ab CentOS 8, direkt für nftables)
iptables (ab CentOS 8, nutzt den iptables-Kompatibilitätsmodus von nftables)
- GUI-Tools
Firewall Builder (fwbuilder)
GUFW für UFW
Shorewall
- Links
REJECT vs. DROP
Schlechte Praxis (und nicht TCP/IP-Standardkonform) bei der Konfiguration einer Firewall ist das Verwerfen (DROP) der Pakete bei einem ungewünschten Verbindungsaufbau, statt ein REJECT zurückzusenden.
Bei dem Versuch eine Verbindung herzustellen, bekommt der Client bei DROP überhaupt keine Antwort auf seine Anfrage und wartet ab, bis eine Zeitüberschreitung eintrifft. Dies kann bei Programmen zu lästigen Wartezeiten für die Benutzer oder zu weiteren unerwünschten Nebeneffekten führen. Zudem kann ein Angreifer so meist zurecht annehmen, dass hinter dem Port ein interessantes Ziel steckt.
Kernel Log-Meldungen verstehen
Hat man Logging für einzelne Regeln eingeschaltet, lässt sich das Verhalten der Firewall zum Beispiel auf CentOS 7 live mit tail -f /var/log/messages
mitverfolgen. Was bedeuten die Meldungen aber im Detail?
Drei Beispiele für Log-Meldungen (der Lesbarkeit halber umgebrochen):
UDP:
IN=eth2 OUT= MAC=00:...:00
SRC=1.2.3.4 DST=10.26.6.74 LEN=229
TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=138 DPT=138 LEN=209
TCP:
IN=eth0 OUT= MAC=00:...:00
SRC=1.2.3.4 DST=10.26.6.74 LEN=52
TOS=0x00 PREC=0x00 TTL=110 ID=22987 DF
PROTO=TCP SPT=50534 DPT=6444
WINDOW=258 RES=0x00 ACK URGP=0
ICMP:
IN=eth0 OUT= MAC=00:...:00
SRC=1.2.3.4 DST=10.26.6.74 LEN=86
TOS=0x08 PREC=0x40 TTL=228 ID=19015
PROTO=ICMP TYPE=3 CODE=3``
Die Felder bedeuten:
ACK
: TCP-Flag; bezeichnet die Art des Paketes („Acknowledgement“).CE
: Fragmentierungs-Flag „congestion“ (bei TCP, UDP).CODE=
: Der numerische Code des ICMP-Paketes; es interpretiert das TYPE-Feld genauer. Beispiele: bei „TYPE=0 CODE=0“ handelt es sich um ein „Echo Reply“, bei „TYPE=3 CODE=0“ um ein „Destination Unreachable“, genauer „Network Unreachable“ (nur bei ICMP).CWR
: TCP-Flag; bezeichnet die Art des Paketes („Congestion Window Reduced“).DF
: Fragmentierungs-Flag „don’t fragment“ (bei TCP, UDP).DPT=
: Destination-Port, angefragter Ziel-Port (bei TCP, UDP).DST=
: Angefragte IP-Adresse (bei TCP, UDP, ICMP).ECE
: TCP-Flag; bezeichnet die Art des Paketes („Explicit Congestion Notification Echo“).FIN
: TCP-Flag; bezeichnet die Art des Paketes („Finished“; es werden keine Daten mehr vom Sender kommen).ID=
: ID des IP-Paketes (bei TCP, UDP, ICMP).IN=
: Incoming Interface (bei TCP, UDP, ICMP).LEN=
: Länge des IP-Paketes (bei TCP, UDP, ICMP).LEN=
: Länge des IP-Paketes (nur bei IP).MAC=
: MAC-Adresse des angefragten Interfaces, eventuell ergänzt um die MAC-Adresse des Routers.MF
: Fragmentierungs-Flag „more fragments are coming“ (bei TCP, UDP).OUT=
: Outgoing Interface (bei TCP, UDP, ICMP).PREC=
: Precedence, Priorität (bei TCP, UDP, ICMP)PROTO=
: Protokoll. „TCP“, „UDP“, „ICMP“ oder eine Nummer aus/etc/protocols
(bei TCP, UDP, ICMP).PSH
: TCP-Flag; bezeichnet die Art des Paketes („Push“).RES=
: Reserved Bits (nur bei TCP).RST
: TCP-Flag; bezeichnet die Art des Paketes („Reset“).SPT=
: Von der anfragenden IP-Adresse verwendeter Port (bei TCP, UDP).SRC=
: Anfragende IP-Adresse (bei TCP, UDP, ICMP).SYN
: TCP-Flag; bezeichnet die Art des Paketes („Synchronize“).TOS=
: Type of Service. Normal-Service = 0x00, Minimize-Cost = 0x02, Maximize-Reliability = 0x04, Maximize-Throughput = 0x08, Minimize-Delay = 0x10 (bei TCP, UDP, ICMP).TTL=
: Time to live eines IP-Paketes. Wird durch jeden Router heruntergezählt. Bei TTL=0 wird das Paket verworfen (bei TCP, UDP, ICMP).TYPE=
: Der numerische Typ des ICMP-Paketes, die Nachrichtenart.0 = Echo Reply,
3 = Destination Unreachable,
4 = Source Quench,
5 = Redirect,
8 = Echo Request,
9 = Router Advertisement,
10 = Router Solicitation,
11 = Time Exceeded,
12 = Parameter Problem,
13 = Timestamp (erleichtert die Zeitsynchronisation),
14 = Timestamp Reply,
15 = Information Request,
16 = Information Reply,
17 = Address Mask Request,
18 = Address Mask Reply,
30 = Traceroute,
31 = Datagram Conversion Error,
32 = Mobile Host Redirect,
33 = Ursprünglich IPv6 Where-Are-You (ersetzt durch ICMPv6),
34 = Ursprünglich IPv6 I-Am-Here (ersetzt durch ICMPv6),
35 = Mobile Registration Request,
36 = Mobile Registration Reply,
37 = Domain Name Request,
38 = Domain Name Reply,
39 = SKIP,
40 = Photuris,
41 = ICMP messages utilized by experimental mobility protocols such as Seamoby (nur bei ICMP).
URG
: TCP-Flag; bezeichnet die Art des Paketes („Urgent“).URGP=
: Der Urgent Pointer (nur bei TCP).WINDOW=
: Länge des TCP-Window (nur bei TCP).
Was bedeutet „ACK PSH FIN“?
FIN: ich schliesse die Verbindung
PSH: Paket senden, nicht im Puffer des Netzwerkstacks behalten
ACK: wird immer gesetzt
Und warum sieht man manchesmal im Log:
DENY IN=eth0 OUT= MAC=...
SRC=10.26.6.16 DST=10.26.6.14 LEN=52
TOS=0x00 PREC=0x00 TTL=64 ID=55571 DF
PROTO=TCP SPT=8091 DPT=46588 WINDOW=239 RES=0x00 ACK FIN URGP=0
Der Grund:
TCP-Handshake
Alice sendet Daten und schliesst mit FIN/ACK ab
Alices Kernel-Firewall setzt Status auf „ESTABLISHED“ oder „RELATED“ und den dazu gehörenden Timeout auf n Sekunden
Bob sendet Antwort
mehr als n Sekunden verstreichen
Alices Kernel-Firewall entfernt den Status „ESTABLISHED“ oder „RELATED“
Bob versucht, den Datentransfer mit FIN/ACK zum Abschluss zu bringen
Alices Kernel-Firewall verwirft FIN/ACK, da das Paket nicht mehr zu einer bestehenden Verbindung gehört
Built on 2024-11-18