Netﬁlter/IP-Tables · Firewall: Paket-Filter statefulinspection Policy IP-Tables: Grundsätzliches Aufbau Regeln Handling Einbindung Suse Debian/Ubuntu Tool:FWBuilder Advanced

Netfilter / IP-TablesSicherheitstage SS 2007

Hergen [email protected]

20.06.2007 (mit Nachträgen 14.01.2010)

Regionales Rechenzentrum für Niedersachsen

Firewall:Paket-Filterstateful inspectionPolicy

IP-Tables:GrundsätzlichesAufbauRegelnHandling

EinbindungSuseDebian/Ubuntu

Tool: FWBuilderAdvanced:

SSH-BruteforcePortscan-AbwehrBenutzerdefinierte Chains

Regionales Rechenzentrum für NiedersachsenHergen Harnisch | IP-Tables 20.06.2007 (mit Nachträgen 14.01.2010) | Folie 2

Firewall:

� Abblocken ungewollten Datenverkehrs� möglichst frühzeitig:

� vor Erreichen des Rechners:Hardware-Firewall, vgl. Netzschutz

� im Netzwerk-Code des Kernels:Personal-Firewall ←− z.B. mit IP-Tables

� teilweise mehr:� Verbindungs-Logging� Analyse Datenverkehr� Datenweiterleitung

� auf verschiedenen Ebenen:� nur Header-Daten:

Verbindungsebene (OSI-Layer 2–4) ←− Paket-Filter� inhaltlich:

Application-Level (OSI-Layer 7)


Firewall: Paket-FilterHeader-Informationen

EthernetIdentifikation durch Hardware-Adressen (MAC)

TCP/IP

IP-Pakete haben:� Quell-IP-Adresse� Ziel-IP-Adresse

TCP & UDP zudem:� Quell-Port� Ziel-Port

130.75.5.110

130.75.2.55

2044

80

Quelle

Ziel


Firewall: Paket-FilterProtokolle

TCP — Transmission Control Protocol� verbindungsorientiert: Verbindungsauf- und abbau� Bsp.: http, ssh

UDP — User Datagram Protocol� verbindungslos

trotzdem evt. Zugehörigkeit, z.B. Antwort auf Anfrage� Bsp.: dns, syslog

ICMP — Internet Control Message Protocol� verbindungslos, nicht für Daten� Bsp.: ping (echo-request)


Firewall: stateful inspectionstateless

� jedes Paket wird einzeln betrachtet;ohne Vorwissen, Folgerung

� mögliche Antworten sind zu beachten� schnell, z.B. in Routern, „veraltet“

stateful� Pakete werden im Zusammenhang gesehen;

Folgepakete werden wie 1. Paket behandelt,zugehörige Verbindungen (z.B. ftp) auch

� Regeln nur für Verbindungsaufbau anzugeben� z.B. bei Netzschutz-FW, bei Personal-FWs, heute üblich

IP-Tables wird stateful durch spez. Regeln-m state --state RELATED,ESTABLISHED -j ACCEPT


Firewall: PolicyGrundsatzgut bewusst Gewolltes erlauben, Rest verbieten

theoretische „Diensteinventur“q&d Schlechtes verbieten, Rest zulassen

nachträgliches Aufsetzen, Analyse Datenverkehr

Erlaubtes� Außen nach Innnen (auf Rechner):

� Wartungszugang, z.B. ssh aus Institutsnetz� für Server: je nach Aufgabe, z.B. http & https

� Innen nach Außen (von Rechner):� dns an bestimmte DNS-Server� http/ftp für System-/Virensignatur-Updates� smtp für System-Meldungen� generell: diese Richtung eher unkritisch


IP-Tables: Grundsätzliches

Netfilter / IP-Tables

� im Linux-Kernel 2.4 & 2.6 der Standard,ersetzt altes ipchains bzw. ipfwadm

� im Kernel implementiert, z.T. Kernel-Module

Vortrag

Ziel Einsatz als Personal-Firewallnicht Natting/Masquerading, Port-Forwarding, Routing/Forwarding,

Accounting, Logging


IP-Tables: AufbauSchema

Aufbau IPTables

lokale Prozesse

Routing

INPUT OUTPUT

FORWARD

User−Space

Kernel

Computer IPTables−Chain Netzwerk−Device (z.B. lo, eth0)


IP-Tables: Aufbaufür Server / Clients

� kein Routing: FORWARD uninteressant� jedes reinkommende Paket geht durch INPUT� jedes rausgehende Paket geht durch OUTPUT� nach Eintrag der „Stateful-Regel“ in INPUT & OUTPUT:

nur noch „Verbindungs“-Aufbauten� nach Innen / zum Rechner in INPUT� nach Außen / vom Rechner in OUTPUT

INPU

T

OUT

PUT

Kernellok. Prozess


IP-Tables: RegelnFlankierendes

Über proc-Dateisystem (de-) aktivieren:

Forwarding� /proc/sys/net/ipv6/conf/all/forwarding� /proc/sys/net/ipv4/ip_forward

IP-Spoofing� /proc/sys/net/ipv4/conf/*/rp_filter

−→ beides bei Debian die Standard-Einstellung,meist mittels echo 0|1>. . . in /etc/init.d/networking

Nachtrag 2011: jetzt über sysctl, vgl. /etc/sysctl.conf


IP-Tables: RegelnGrund-Setup

Standard-Policyiptables -P INPUT DROP# erstmal raus alles, spaeter ggf. restriktiveriptables -P OUTPUT ACCEPTiptables -P FORWARD DROP# ggf. alle chains komplett leereniptables -F

Statefuliptables -A INPUT -m state \

--state RELATED,ESTABLISHED -j ACCEPT

−→ bereits gute Absicherung eines Clients, aber noch zulassen:iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT1

1Nachtrag 2011: lieber nur iptables -A INPUT -i lo -j ACCEPTRegionales Rechenzentrum für NiedersachsenHergen Harnisch | IP-Tables 20.06.2007 (mit Nachträgen 14.01.2010) | Folie 14

IP-Tables: RegelnPrinzip

EinzelregelJede Regel besteht aus einer Bedingung und einem Ziel:

-s 127.0.0.1 -i lo︸︷︷︸wenn lokale IP vom Loopback-Device

-j ACCEPT

-m tcp -p tcp --dport 22︸︷︷︸wenn TCP auf den SSH-Port

-j ACCEPT︸︷︷︸dann akzeptieren

Das Ziel bestimmt das weiter Schicksal eines passenden Paketes.


IP-Tables: RegelnPrinzip

AbfolgeJede chain besteht aus einer Abfolge von Regeln,Reihenfolge ist entscheidend: Abarbeitung bis first match,d.h. nach einem „Match“ wird Regelverarbeitung abgebrochen

Beispiel1 -p tcp -d 130.75.2.0/24 --dport 25 -j ACCEPT2 -p tcp --dport 25 -j DROP3 -j ACCEPT

akzeptiert Mail an Mailserver des RRZN,Zustellung an andere Mailserver nicht erlaubt;restlicher Verkehr wieder erlaubt−→ fast alles erlaubt, aber direktes Spamming unterdrückt


IP-Tables: RegelnAbfolge: Umsetzung

� Regeln können ans Listenende angefügt werden:iptables -A chain ...

� Regeln können vor bestimmten Eintrag eingefügt werden:iptables -I chain rulenum ...

� Bestimmte Regeln können gelöscht werden:iptables -D chain rulenum

� Bestimmte Regeln können ersetzt werden:iptables -R chain rulenum ...

Anzeige mit Zeilennummern:iptables --line-numbers -L [chain]


IP-Tables: RegelnZiele

ACCEPTDas Paket wird durchgelassen.DROPDas Paket wird ohne Benachrichtigung/Rückmeldung verworfen.

REJECTDas Paket wird verworfen, aber der Absender wird benachrichtigt:

� standardmäßig per ICMP port-unreachable� alternativ auch mit Beendigung einer TCP-Verbindung,

sinnvoll für Ident-Port (Vermeidung von Timeouts):-p tcp –dport 113 -j REJECT --reject-with tcp-reset

REJECT kann nicht Chain-Policy sein und benötigt Zusatzmodul.


IP-Tables: RegelnZiele: Drop (vs. Reject)

Bei DROP erhält Anfragender keine Rückmeldung, ähnlich wieUnterdrückung der Pingbarkeit einzustufen.2

� IP-Adresse scheint (derzeit) ungenutzt� erschwert das Abscannen des Rechners:

Timeouts sind abzuwarten� Anfragender probiert wie bei Paketverlust nochmal,

z.B. P2P bei Dial-Up-Zugängen ebbt nur langsam ab, wenn manselbst kein P2P macht aber IP von einem P2P-Teilnehmer erbt

� Angreifer lassen sich kaum noch abschrecken,häufiger wird sowieso gezielt ein Port abgescannt

� man selbst muss auch auf Timeouts warten−→ Zumindest ping im LAN / LUH-Netz zulassen

2Wird häufig als stealth-Funktionalität beworben.Regionales Rechenzentrum für NiedersachsenHergen Harnisch | IP-Tables 20.06.2007 (mit Nachträgen 14.01.2010) | Folie 19

IP-Tables: RegelnMatches

IP-AdresseQuelle: -s [!] address[/mask] Untersuchung derAbsender-IP-Adresse (! negiert)z.B. nicht aus LUH-Netz: -s ! 130.75.0.0/255.255.0.0

Ziel: -d [!] address[/mask]

TCP/UDP-PortsQuelle: -p tcp|udp --sport [!] port

Ziel: -p tcp|udp --dport [!] portz.B. alle TCP-Verbindungen außer ssh: -p tcp --dport ! 22


IP-Tables: RegelnMatches

ICMPTyp: -p icmp --icmp-type [!] typez.B. ping-Anfrage: -p icmp --icmp-type echo-request

state-ModulStatus: -m state --state statewobei state eine Kombination aus

� ESTABLISHED Teil einer existierenden Verbindung� RELATED zwar neue Verbindung, aber zu existierender

gehörend (z.B. FTP-Data zu FTP-Control)� NEW gehört zu nichts Bekanntem� INVALID ungültig (oder auch Speicher-Problem des Moduls)


IP-Tables: RegelnConnection-Tracking

Status RELATED hängt sehr vom Protokoll ab, daher sindprotokoll-spezifische Erweiterungen nötig.

� ip_conntrack_ftp:FTP-Datenport (active & passive) fällt unter RELATED

� ip_conntrack_netbios_ns:damit wird das „Browsen“ nach Samba-Shares möglich

meist nötig: Module mit modprobe explizit laden!


IP-Tables: RegelnBeispielregeln

01 iptables -P INPUT DROP02 iptables -P OUTPUT ACCEPT03 iptables -P FORWARD DROP; iptables -F04 iptables -A INPUT -m state --state RELATED,ESTABLISHED\

-j ACCEPT# rein: lokal, ping, ssh aus LUH05 iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT06 iptables -A INPUT -p icmp –icmp-type 8 -j ACCEPT07 iptables -A INPUT -s 130.75.0.0/255.255.0.0 -p tcp \

--dport 22 -j ACCEPT# raus: alles, aber Mail/DNS nur LUH08 iptables -A OUTPUT -d 127.0.0.1 -o lo -j ACCEPT09 iptables -A OUTPUT -d ! 130.75.0.0/16 -p tcp \

--dport 25,465 -j DROP10 iptables -A OUTPUT -d 130.75.1.32/32 -j ACCEPT11 iptables -A OUTPUT -d 130.75.1.40/32 -j ACCEPT12 iptables -A OUTPUT --dport 53 -j DROPRegionales Rechenzentrum für NiedersachsenHergen Harnisch | IP-Tables 20.06.2007 (mit Nachträgen 14.01.2010) | Folie 23

IP-Tables: Regeln„Design-Kriterien“

� DROP als Standard-Policy� lieber REJECT als DROP:

leichter zur Fehlersuche allgemein, DROP nur gegen DoS gut� komplizierte Regelpassagen in User-Chains abtrennen (s.u.)� Übersichtlichkeit, Verständlichkeit, Wartbarkeit

wichtiger als 100%-iger Schutz mit Raffinessen� Aufbewahrung eines kommentierten Erstellungsskriptes

� ersetzt nie die normale Dienste-Absicherung


IP-Tables: HandlingSpeicherung von Regelsätzen

Befehle� Abspeichern mit iptables-save >Datei� Wiederherstellen mit iptables-restore <Datei

Beispiel-Datei# Generated by iptables-save v1.3.3 on Tue Jun 6 19:21:25 2006*filter:INPUT DROP [1:60]:FORWARD DROP [0:0]:OUTPUT ACCEPT [72:6224]-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT-A INPUT -s 127.0.0.1 -i lo -j ACCEPTCOMMIT

# Completed on Tue Jun 6 19:21:25 2006


IP-Tables: HandlingRemote-Bearbeitung

Problem: falsche Regeln führen zur AussperrungLösung: automatische Wiederherstellung / Löschung

Skript# ggf. Abspeicherung# iptables-save >/root/iptables-fallback.conf# neue Regeln:...# Timeout und Wiederherstellung:if read -p “Annahme neuer Regeln mit Return“ -t 30;then echo neue Regeln gelten;elseiptables-restore </root/iptables-fallback.conf;echo Regeln zurueckgesetzt;

fi


EinbindungInit-Prozess

Init-SkriptInit-Skript /etc/init.d/iptables erstellen. Parameter:start aktiviert die Firewallstop deaktiviert die FirewallQuelle: http://www.rrzn.uni-hannover.de/fw_linux.htmlMeist wird mit iptables-save erzeugte Datei/etc/iptables.conf eingelesen.

AktivierungSetzen von Links in /etc/rc?.d,unbedingt distributionsspezifische Tools verwenden (s.u.)


http://www.rrzn.uni-hannover.de/fw_linux.html

EinbindungModule

Einige IP-Tables-Erweiterungen liegen in Modulen, z.B.� ipt_state (für established, related)� ip_conntrack_ftp (für Datenport-Freischaltung)� ipt_REJECT (für Reject statt Drop)

Diese Module sind ggf. beim Systemstart zu laden, durch� Auflisten in /etc/modules� modprobe-Aufruf im Init-Skript� Abhängigkeiten von Geräten in /etc/modules.conf meist

nicht möglich


Einbindung SuseYast: Aufruf Firewall


Einbindung SuseYast: Unterpunkt Firewall


Einbindung SuseYast

Vorgehen� SuseFirewall2 nach der Installation aktiv� dann über Yast Ports öffnen („erlaubte Dienste“)

Eigenschaften Yast/SuseFirewall� Zonen-Konzept

� nur 3 Zonen: intern, extern, DMZ� geht konzeptionell von sichererem LAN aus� Öffnen nur für gewisse Clients nur begrenzt möglich

� ermöglicht NAT, DMZ, Port-Redirect, VPN,dadurch nicht unbedingt einfacher als Skript


Einbindung SuseInit-Skript

Zur Verwendung des oben genannten Init-Skripts:1. in Yast die FW-Konfiguration & Start auf „manuell“ schalten,

vgl. http://www.rrzn.uni-hannover.de/fw_suse.html

ab Suse 9 beachten2. INIT INFO-Block ins Skript einfügen (vgl. man insserv)

Suse 8-103. statt Links manuell zu setzen:

� Yast Control Center → System → Run level editor & Runlevelproperties

� oder chkconfig iptables on aufrufen


http://www.rrzn.uni-hannover.de/fw_suse.html

Einbindung Debian/UbuntuInit-Skript

� altes Init-Skript bei Debian-Sarge (oldstable) noch gepackt in/usr/share/doc/iptables/example/oldinitdscript.gz,(oder http://www.rrzn.uni-hannover.de/fw_debian.html)verwendet zwei gespeicherte Regelsätze:start aktiviert /var/lib/iptables/active,

erzeugen durch Setzen der Regeln undAbspeichern mit /etc/init.d/iptables save active

stop aktiviert /var/lib/iptables/deactive,abspeichern mit /etc/init.d/iptables save inactive

� alternativ: generisches Init-Skript vonhttp://www.rrzn.uni-hannover.de/fw_linux.html

� Links setzen mit: update-rc.d iptables defaults


http://www.rrzn.uni-hannover.de/fw_debian.html


Einbindung Debian/Ubuntuifupdown

� ifup/ifdown (de)-aktivieren Netzwerkschnittstellen undzugehörige Konfigurationen,Einstellungen dazu in /etc/network/interfaces

� z.B. Flankierendes (Spoof-Protection, Forwarding) auch in/etc/network/options

� z.B. über Skripte in/etc/network/if-[pre-up|up|down|post-down].d/

� Vorteil gegenüber Init-Skript:� Umkonfigurationen werden berücksichtigt� Beachtung von DHCP, Namen von Interfaces leichter� dynamische Änderungen wie z.B. WLan abdeckbar

� Beispiel-Skript & Erklärung unterhttp://www.rrzn.uni-hannover.de/fw_debian.html


http://www.rrzn.uni-hannover.de/fw_debian.html

Tool: FWBuilder

� GUI zur Regeleingabe & -bearbeitung, viel Drag&Drop� System-Einstellungen (z.B. Forward, Spoofing-Protection)� Standard-Setups zur Auswahl� benannte Objekte, Kommentierung� interne Datenbank der Einstellungen (XML-Dateien)� Export, u.a. als IPTables-Skript (policy-compiler)� zentrale Verwaltung mehrere Firewalls,

Regelverteilung auf die Systeme� unterstützt Bridging, Routing, NAT� FWBuilder selbst Cross-Plattform (insb. Linux, Windows)� Quelle: http://www.fwbuilder.org/


http://www.fwbuilder.org/

Tool: FWBuilderScreenshot


Tool: FWBuilderDemo Host: GUI


Tool: FWBuilderDemo Host: Ergebnis

aus Datei pc0815.fw# Rule 1 (global)#echo "Rule 1 (global)"###$IPTABLES -N Cid466E5765.0$IPTABLES -A OUTPUT -d ! 130.75.0.0/21 -j Cid466E5765.0$IPTABLES -N RULE_1$IPTABLES -A Cid466E5765.0 -p tcp -m tcp -m multiport --dports 25,465 -j RULE_1$IPTABLES -N Cid466E5765.1$IPTABLES -A INPUT -d ! 130.75.0.0/21 -j Cid466E5765.1$IPTABLES -A Cid466E5765.1 -p tcp -m tcp -m multiport --dports 25,465 -j RULE_1$IPTABLES -N Cid466E5765.2$IPTABLES -A FORWARD -d ! 130.75.0.0/21 -j Cid466E5765.2$IPTABLES -A Cid466E5765.2 -p tcp -m tcp -m multiport --dports 25,465 -j RULE_1$IPTABLES -A RULE_1 -j LOG --log-level info --log-prefix "RULE 1 -- REJECT "$IPTABLES -A RULE_1 -j REJECT

#


Advanced:recent-Modul

� Modul laden mit modprobe ipt_recent� ermöglicht eine adaptive Firwall:

� Quell-IP kann in Liste protokolliert werden� mit Liste können bisherige Zugriffe in Bedingungen geprüft

werden, dabei auch die Anzahl und der Zeitraum prüfbar� Listen:

� mehrere Listen möglich� standardmäßig bis zu 100 Einträge� angelegte Listen in /proc/net/ipt_recent/� Liste manipulierbar durch Schreiben auf procfs-Datei:

„xx.xx.xx.xx“ fügt IP zu, „-xx.xx.xx.xx“ löscht IP, „clear“ leert


Advanced: SSH-Bruteforce1 modprobe ipt_recent2 # state NEW nicht noetig, da stateful-Regel davor3 iptables -A INPUT -p tcp --dport 22 \4 -m recent --update --seconds 300 --hitcount 2

--name SSH \5 -j DROP6 iptables -A INPUT -p tcp --dport 22 \7 -m recent --set --name SSH \8 -j ACCEPT

in 4: SSH-Verbindungsaufbauten werden analysiert:a) Kombination hitcount&seconds: wenn Zähler für die letzten

5 min ≥2, dann die Verbindung „droppen“b) update: unter Bed. b) Zugriff in Liste SSH protokollieren

in 7: wenn Limit noch nicht erreicht (d.h. 4 nicht erfüllt):c) wenn neue IP: IP wird der Liste SSH zugefügt (Zähler 0)d) wenn IP bereits in Liste SSH: Zugriff protokollieren & Zähler+1

erlaubt 2 neue SSH-Verbindungen je 5 min, egal ob erfolgreich oder nicht


Advanced: Portscan-Abwehr

1 iptables -A INPUT -m recent --update \2 --seconds 300 --hitcount 4 --name BANME -j DROP3 iptables -A INPUT -m tcp -p tcp ! --syn -j DROP4 iptables -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT5 iptables -A INPUT -m recent --set --name BANME -j REJECT

� Prinzip: häufig genug auf verbotene Ports, dann wohl ein Scangenauer: 4 verbotene Zugriffe in 5 min gelten als Scan

� nach 3 bleiben von TCP nur Verbindungsaufbauten� 4 ist die letzte Stelle für Unverdächtiges (Bsp. ssh)� in 5 Ankommendes ist verdächtig, also notieren & zählen� 1,2: ggf. verbieten (s.o.) und auch weiterzählen,

dann definiert auch 4 keine Ausnahme mehr


Advanced: Portscan-Abwehr

� obiges Abwehr-Verfahren sehr brutalProblem: Zugriffsversuch mit Retry könnte schon als Scan geltenEinsatzbereich: Workstations mit SSH-Zugang, nicht für Server

� allgemein ist Port-Scan-Abwehr schwierig, da mehrereScan-Verfahren möglich (vgl. man nmap)

� Ausführliche Konfiguration, die auch andere Scan-Typen abdeckt, imrc.firewall-Skript (URL s.u., unterhalb von „#portscan detector“).

� extra Modul psd für Port-Scan-Detection war verfügbar, abernicht mehr supported

EmpfehlungDa Port-Scans eher unkritisch sind, einfach hinnehmen. Port-Scans(meint auch: ein Port auf mehreren IPs) sind nur interessant, dahäufig der Urheber infiziert ist.


Advanced: Benutzerdefinierte ChainsMan kann selbst Chains erzeugen, die als Ziel dienen können:

� Übersichtlichkeit durch Kapselung von Regeln� Wiederverwendung von Regelsätzen (mehrfach als Sprungziel)� statt Transaktionen: Regelsatz als Ganzes zufügen,

gut auch für Tests

Beispiel# Chain erzeugen und Regeln einfügen1 iptables -N SSHIN2 iptables -A SSHIN -m recent --update --seconds 300 \

--hitcount 2 --name SSH -j DROP3 iptables -A SSHIN -m recent --set --name SSH -j ACCEPT# aus user-def. Chains wird normalerweise zurueckgekehrt# daher hier explizit Policy: restlichen Verkehr verwerfen4 iptables -A SSHIN -j DROP# SSH-Verkehr in SSHIN-Chain umlenken5 iptables -A INPUT -p tcp --dport 22 -j SSHIN


Schlussbemerkungen

IP-Tables� Konfiguration ohne Spezialitäten wie NAT ist überschaubar� Möglichkeiten mächtig, dann aber kompliziert� Spezialitäten evt. in extra Chains abtrennbar� dokumentiertes Erstellungsskript aufbewahren

−→ lieber eine überschaubare Grundabsicherung

SonstigesTrotz IP-Tables-Sicherung immer Applikation traditionell sichern:

� applikationsspezifisch (z.B. httpd.conf, sshd_config)� TCP-Wrapper (hosts.allow, hosts.deny)−→ Firewall ist Zusatz, nicht Ersatz


Literatur

� Linux 2.4 Packet Filtering HOWTOhttp://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.htmlknapp, aber auch NAT

� IPTables-Tutorialhttp://iptables-tutorial.frozentux.net/umfassend, auch TCP/IP-Grundzüge, Zusatzmodule etc.

� RRZN-Webseite zu IP-Tableshttp://www.rrzn.uni-hannover.de/fw_linux.htmlbezogen auf Host-Absicherung (nicht NAT), Skripte zum Download


http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html

http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html

http://iptables-tutorial.frozentux.net/


Documents

Netﬁlter/IP-Tables · Firewall: Paket-Filter statefulinspection Policy IP-Tables: Grundsätzliches Aufbau Regeln Handling Einbindung Suse Debian/Ubuntu Tool:FWBuilder Advanced