Teil 13: iptables-Firewallswi.f4.htw-berlin.de/.../Folien/WIS-13/WIS-13-Firewall2-1.pdfWIS – SS...

50
04.06.20 1 WIS – SS 2020 - Teil 13/Firewalls II Informationssicherheit Teil 13: iptables-Firewalls

Transcript of Teil 13: iptables-Firewallswi.f4.htw-berlin.de/.../Folien/WIS-13/WIS-13-Firewall2-1.pdfWIS – SS...

  • 04.06.20 1WIS – SS 2020 - Teil 13/Firewalls II

    Informationssicherheit

    Teil 13: iptables-Firewalls

  • 2WIS – SS 2020 - Teil 13/Firewalls II

    Literatur

    [13-1] Spenneberg, Ralf: Linux-Firewalls mit iptables & Co. Addison-Wesley, 2006

    [13-2] Purdy, Gregor: LINUX iptables. Pocket Reference, O'Reilly, 2004

    [13-3] Barth, Wolfgang: Das Firewall-Buch. millin, 3. Auflage, 2004

    [13-4] Ziegler, Robert: Linux-Firewalls. Markt+Technik, 2.Auflage, 2003

    [13-5] http://de.wikipedia.org/wiki/Iptables

    [13-6] https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html

    [13-7] http://www.selflinux.org/selflinux/html/iptables.html

    [13-8] http://de.wikibooks.org/wiki/Linux-Praxisbuch:_Linux-Firewall_mit_IP-Tables

    [13-9] https://help.ubuntu.com/community/IptablesHowTo

    [13-10] https://wiki.archlinux.org/index.php/simple_stateful_firewall

    [13-11] http://www.online-tutorials.net/internet-netzwerk/iptables-tutorial/tutorials-t-29-214.html

  • 3WIS – SS 2020 - Teil 13/Firewalls II

    Überblick

    � Das Konzept der iptables

    � Architektur/Bauform einer Personal Firewall

    � Regeln für einige Dienste

    � Starten der Firewall

  • 4WIS – SS 2020 - Teil 13/Firewalls II

    Regelketten (Chains) der Filter-Table

    � Chain = Kette = Tabelle mit Regeln, die sequentiell geprüft werden

    � Input-Chain = Filter für eingehende Pakete an Prozesse des eigenen Systems

    � Output-Chain = Filter für ausgehende Pakete von Prozessen

    � Forward-Chain = Filter für Pakete, die durchgeleitet werden (Router)

  • 5WIS – SS 2020 - Teil 13/Firewalls II

    Algorithmus

    • Eine Regelkette wird solange durchlaufen bis das Ende erreicht wird oder die erste Bedingung zutrifft (hierbei gibt es Ausnahmen).

    • Eine Ausnahme sind Logging-Aktionen, nach denen weiter gelaufen wird.

    • Bei einem Zutreffen der Bedingung wird eine Aktion durchgeführt.

    • Ist das Ende einer Tabelle erreicht, wird eine allgemeine Regel angewandt: die Policy.

    Hinweis:Regeln können ähnlich Prozeduren in benannten Gruppenzusammen gefasst werden. Dies dient der besseren Strukturierung.

    Aus diesen Gründen kommt es auf die Reihenfolge der Regeln an.Auch die Performanz wird durch die Reihenfolge bestimmt.

  • 6WIS – SS 2020 - Teil 13/Firewalls II

    Kommando iptables

    � Verarbeitung der Pakete erfolgt durch drei Tabellen bzw. Module innerhalb des Kernels:1)Filter-Table

    (mit den besprochenen Chains)

    2)Mangle-Table (Markieren, Verändern von Paketen)

    3)NAT-Table (Durchführung von NAT)

    � Die Einträge in den Tabellen werden durch das Kommando iptables gesetzt, geändert und gelöscht.

    � Die Aufrufe von iptables dazu stehen üblicherweise in einem Shell-File, das möglichst direkt nach dem Start der Netzwerkdienste ausgeführt wird.

    Im Folgenden wird nur die Filter-Tabelle besprochen.

  • 7WIS – SS 2020 - Teil 13/Firewalls II

    Parameter für Filter-Tabelle I

    Komplette Chains (INPUT, OUTPUT, FORWARD und eigene):

    -F Chain Löscht alle Regeln einer Kette

    -P Chain Policy Legt Policy (ACCEPT oder DROP) fest

    -L Chain Listet Regeln auf

    Regeln einer Chain:

    -A Chain Fügt hinten an

  • 8WIS – SS 2020 - Teil 13/Firewalls II

    Parameter für Filter-Tabelle II

    -i [!] Interface Netzwerkschnittstelle für INPUT/FORWARD

    -o [!] Interface Netzwerkschnittstelle für OUTPUT/FORWARD

    -p [!] Protokoll Protokollangabe: ip, tcp, udp, icmp

    -s [!] Source Herkunft-IP-Adresse

    -d [!] Destination Ziel-IP-Adresse

    -j Aktion Aktion, z. B. DROP, REJECT, ACCEPT, LOG

    Weitere Bedingungen:

  • 9WIS – SS 2020 - Teil 13/Firewalls II

    Die möglichen Aktionen

    ACCEPT Annehmen und Weiterleiten des Pakets Ende

    DROP Verwerfen Ende

    REJECT Verwerfen und mit ICMP-Fehlermeldung Ende

    LOG Logging in /var/log/messages Fortsetzung

    Aktion kann sein (Auszug):

    Wenn benannte Blöcke von Regeln verwendet werden, wirdnach dem -j (wie jump) der Name des Blocks angegeben.Mit RETURN wird wieder zurückgekehrt.

  • 10WIS – SS 2020 - Teil 13/Firewalls II

    Zustandsbehaftete Firewall I

    State Erläuterung

    NEW TCP-Aufbaupaket bzw. 1. UDP-Paket

    ESTABLISHED Paket einer TCP-Verbindung bzw. Folge-UDP-Paket

    RELATED Verwandt: Fehlerpaket zu einer bestehenden Verbindung oder weitere Verbindung (FTP-Modul)

    INVALID Paket kann nirgends zugeordnet werden

    Diese Verbindungszustände gelten nur dann, wenn genügendTabellenplatz vorhanden ist.Falls nicht, geht automatisch der Filter in den stateless-Zustand!

    -m state Zustand innerhalb des Protokolls

    "-m" oder "--match XYZ" steht für verschiedene Parameter

  • 11WIS – SS 2020 - Teil 13/Firewalls II

    Zustandsbehaftete Firewall II - Bemerkungen

    � Nur bei der Verwendung des m-Flags mit den aufgeführten Zuständen wird der zustandsbehaftete Modus betreten.

    � Der TCP-Verbindungsaufbau wird nachvollzogen und entsprechende Einträge in internen Tabellen vermerkt.

    � Im Falle von UDP wird so etwas wie eine Verbindung durch Assoziation der beiden IP-Adressen und Port-Kombinationen simuliert.

    � RELATED bedeutet, dass diese Bedingung wahr wird, wenn eine neue Verbindung aufgebaut wird, die im Zusammenhang mit einer bestehenden steht. Das erfolgt normalerweise nur mit FTP (Kontrollkanal und Datenkanäle).

  • 12WIS – SS 2020 - Teil 13/Firewalls II

    Zustandsbehaftete Firewall III - Varianten

    Es gibt zwei Varianten, die äquivalent sind:

    iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

    Hier wird die ältere, die (fast) immer funktioniert, vorgestellt.

  • 13WIS – SS 2020 - Teil 13/Firewalls II

    Beispiele

    Erlauben aller TCP-Pakete von Außen nach Innen:

    iptables -A INPUT -p tcp --dport 80 -j ACCEPT

    Begrenzen von Pings von Außen nach Innen:

    iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 10/min --limit-burst 8 -j ACCEPT

    Ablehnen aller UDP-Pakete von Außen nach Innen:

    iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable

    Möglichkeit einer Diagnoseinformation

  • 14WIS – SS 2020 - Teil 13/Firewalls II

    REJECT oder DROP?

    � DROP führt zu einem kommentarlosen Wegwerfen des untersuchten Pakets.

    � REJECT führt zu einem Wegwerfen und dem Absenden einer ICMP-Fehlermeldung.

    � DROP ist fast immer besser als REJECT, wenn es sich um Pakete von Draußen handelt.

    � REJECT ist fast immer besser als DROP, wenn es sich um Pakete vom LAN oder von Drinnen handelt.

  • 15WIS – SS 2020 - Teil 13/Firewalls II

    Weitere Kommandos I

    � iptables -L [Chain]listet die aktuelle Situation auf

    � iptables-savegibt die aktuelle Situation in einem (fast) iptables-konformen Format aus

    � iptables-restorebenutzt das iptables-save-Format und definiert damit die neuen Regeln.

    � Siehe– http://www.iptables.info/en/iptables-save-restore-rules.html

    – https://www.thomas-krenn.com/de/wiki/Iptables_Firewall_Regeln_dauerhaft_speichern

    – http://www.faqs.org/docs/iptables/iptables-save.html

    – http://www.faqs.org/docs/iptables/iptables-restore.html

  • 16WIS – SS 2020 - Teil 13/Firewalls II

    Weitere Kommandos II - iptables –L-Output I

    Chain INPUT (policy DROP)target prot opt source destination ACCEPT all -- anywhere anywhere LOG all -- loopback/8 anywhere LOG ... LOG all -- anywhere loopback/8 LOG ... DROP all -- loopback/8 anywhere DROP all -- anywhere loopback/8 LOG all -- anywhere anywhere LOG ... DROP all -- anywhere anywhere Chain FORWARD (policy DROP)target prot opt source destination TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS..

  • 17WIS – SS 2020 - Teil 13/Firewalls II

    Weitere Kommandos III - iptables -L-Output II

    Chain OUTPUT (policy ACCEPT)target prot opt source destination ACCEPT all -- anywhere anywhere LOG icmp -- anywhere anywhere icmp time-exceeded LOG .... ACCEPT icmp -- anywhere anywhere cmp time-exceeded ACCEPT icmp -- anywhere anywhere cmp port-unreachable ACCEPT icmp -- anywhere anywhere cmp fragmentation-needed ACCEPT icmp -- anywhere anywhere cmp network-prohibited ACCEPT icmp -- anywhere anywhere icmp host-prohibited ACCEPT icmp -- anywhere anywhere icmp communication-prohibited DROP icmp -- anywhere anywhere icmp destination-unreachable ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED LOG all -- anywhere anywhere LOG ....

    Chain reject_func (3 references)target prot opt source destination REJECT tcp -- anywhere anywhere reject-with tcp-reset REJECT udp -- anywhere anywhere reject-with icmp-port-unreachable REJECT all -- anywhere anywhere reject-with icmp-proto-unreachable

  • 18WIS – SS 2020 - Teil 13/Firewalls II

    Weitere Kommandos IV - iptables-save (Auszug)

    -A INPUT -i lo -j ACCEPT -A INPUT -s 127.0.0.0/255.0.0.0 -j LOG ...-A INPUT -d 127.0.0.0/255.0.0.0 -j LOG ...-A INPUT -s 127.0.0.0/255.0.0.0 -j DROP -A INPUT -d 127.0.0.0/255.0.0.0 -j DROP -A INPUT -j LOG .... -A INPUT -j DROP -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 11 -j LOG ... -A OUTPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 3/3 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 3/4 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 3/9 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 3/10 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 3/13 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 3 -j DROP -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -j LOG --log-prefix "SuSE-FW-OUTPUT-ERROR " --log-tcp-options --log-ip-options

  • 19WIS – SS 2020 - Teil 13/Firewalls II

    Script zur Firewall-Definition I

    � Aus Gründen der Vereinfachung wird angenommen, dass durch Ausführen dieses Scripts die gesamte Firewall definiert wird, d.h. bestimmte Phasen des Bootens werden nicht berücksichtigt.

    � Für diese Fälle muss das Script in einzelne Teile aufgeteilt, gesondert angepasst und schrittweise ausgeführt werden.

    Es wird Schritt für Schritt ein Shell-Skript zur eigenen Benutzung einer Personal Firewall aufgebaut und erklärt.

    Das Sicherheitsniveau ist hierbei höher als bei einer "normalen"Personal Firewall.

  • 20WIS – SS 2020 - Teil 13/Firewalls II

    Script zur Firewall-Definition II

    Annahmen für das Weitere:

    � eth0: Ethernet-Schnittstelle nach außenBei DSL und damit PPPoE muss es stattdessen ppp0 heißen

    � Die Prozesse lesen und schreiben auf eth0

    � LINUX Kernel ab 2.6

  • 21WIS – SS 2020 - Teil 13/Firewalls II

    Script zur Firewall-Definition III

    � Wenn die Adressen vertrauenswürdiger Server bekannt sind, so sollte der Zugriff nur auf diese beschränkt werden.Konkret auf folgende Server:– DHCP-Server

    – HTTP-Proxy-Server

    – DNS-Server

    – NTP-Server

    � Ein Problem besteht natürlich, wenn diese Server nicht laufen und deren Funktion durch andere ersetzt werden muss.Dann geht nichts mehr ("ausgesperrt").

  • 22WIS – SS 2020 - Teil 13/Firewalls II

    Script zur Firewall-Definition IV

    (A) Setzen der Kernel-Parameter

    (B) Löschen alter Regeln

    (C) Policies definieren

    (D) Behandeln schräger Scanns

    (E) Dynamische Regeln

    (F) Unsinniges von Draußen filtern

    (G) Behandlung einzelner Dienste

    (H) ICMP

    (I) Logging von unerwünschten Paketen

    Abschnitte des Scripts

    Im folgenden werden Auszüge aus einem Skript vorgestellt.Anhand dessen können die fehlenden Teile leicht ergänzt werden.

  • 23WIS – SS 2020 - Teil 13/Firewalls II

    Script zur Firewall-Definition V - Beispiele

    Damit das Skript universeller wird, werden verschiedene Parameterin Shell-Variablen gelegt, die nun erklärt werden:

    OUTER="eth0" Schnittstelle nach Außen

    OUTERNET="172.22.0.0"OUTERNET_BROADCAST="172.22.255.255"

    Netz über eth0

    LOOPBACK="127.0.0.0/8"LOCALHOST="lo"

    Lokale Schnittstelle bzw. Netz

    NAMESERVER="172.22.x.x"SMTPSERVER="172.22.x.x"POPSERVER="172.22.x.x"IMAPSERVER="172.22.x.x"TIMESERVER="172.22.x.x"

    Vom Provider gestellte oder lokaler Server

    CLASS_A="10.0.0.0/8"CLASS_B="172.16.0.0/12"CLASS_C="196.168.0.0/16"CLASS_D="224.0.0.0/4"CLASS_E="240.0.0.0/5"

    Lokale Adressräume und Sonderadressen für IPv4

  • 24WIS – SS 2020 - Teil 13/Firewalls II

    Konfigurieren der Kernelparameter I

    (1) # Alle eingehende Pings ignorieren# echo 1 >/proc/sys/net/ipv4/icmp_echo_ignore_all

    (2) # Pings an Broadcast-Adressen ignorierenecho 1 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

    ……(4) # TCP-SYN Cookies einschaltenecho 1 >/proc/sys/net/ipv4/tcp_syncookies

    Abschnitt (A)

    Hierbei ist die Entscheidung zu treffen, ob ein anderes Systemdas eigene "anpingen" können darf oder nicht.

  • 25WIS – SS 2020 - Teil 13/Firewalls II

    Konfigurieren der Kernelparameter II

    � Das Setzen von Kernelparametern erfolgt über das /proc-Dateisystem.

    � Das /proc-Dateisystem beruht auf einem ähnlichen Verfahren wie die Geräte-Dateien (/dev): Interne Tabellen werden über die Dateisystemschnittstelle (open, read, write, close) verfügbar gemacht.

    � Das bedeutet auch, dass das Aktivieren einer Firewall nur mit root-Rechten möglich ist.

    � Zu (1): einige Internet-Service-Provider benutzen Ping zu Diagnose-Zwecken

    � Zu (4): Dies soll gegen SYN-Flooding schützen

  • 26WIS – SS 2020 - Teil 13/Firewalls II

    Konfigurieren der Kernelparameter III

    � Lesen eines Wertes für IPv4 :cat /proc/sys/net/ipv4/Parameter

    � Setzen der Werteecho "X" > /proc/sys/net/ipv4/Parameter

    wobei X– für das Einschalten 1,

    – für das Ausschalten 0,

    – oder der gewünschte Wert ist.

    � Nach jedem Booten brauchen die Variablen nur einmal gesetzt zu werden, bei jedem Herunterfahren gehen die Werte verloren.

    � Andere Programme können die Werte verändern, z.B. durch ein Programm, das beim Booten später gestartet wird.Daher ist es anzuraten, dass die Firewall als letztes in der Boot-Sequenz gestartet wird.

  • 27WIS – SS 2020 - Teil 13/Firewalls II

    Konfigurieren der Kernelparameter IV

    � Sofortiges Setzen nach jedem Booten erfolgt je nach Distribution, z.B. per grub; dies erfolgt in /boot/grub/menue.lst bzw. in /boot/grub.conf.

    � Siehe dazu– https://www.linuxtopia.org/online_books/centos5/

    centos_5_xen_virtualization/centos5_sect-Virtualization-Tips_and_tricks-Modifying_etcgrub.conf.html

    – https://de.opensuse.org/GRUB

    – https://www.thegeekdiary.com/centos-rhel-7-how-to-modify-the-kernel-command-line/

    – http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/

  • 28WIS – SS 2020 - Teil 13/Firewalls II

    Konfigurieren der Kernelparameter V (Auszug)

    Name Bedeutung

    ip_forward Bei FORWARD-Regeln Einschalten (1)

    conf/*/rp_filter Anti-Spoof-Filter: Einschalten (1)

    tcp_syncookies SYN-Flooding-Test: Einschalten (1)

    icmp_echo_ignore_all Kein ping mehr: Einschalten (1)

    icmp_echo_ignore_broadcasts Ping-Räusche verhindern: Einschalten (1)

    icmp_ignore_bogus_error_responses Schmutzbeseitigung: Einschalten (1)

    accept_redirects Abschalten (0)

    accept_source_route Abschalten (0)

    boot_relay Abschalten (0)

    log_martians Bei unklaren Paketen: Einschalten (1)

    mc_forwarding Nur bei Multicast: Einschalten

    Alle Dateinamen relativ zu /proc/sys/net/ipv4:

  • 29WIS – SS 2020 - Teil 13/Firewalls II

    Löschen alter Regeln - Loopback erlauben

    # Alle bestehenden Chains loescheniptables --flush # Default-Chains iptables -t nat --flushiptables -t mangle --flush

    iptables --delete-chain # Benutzer-Chainsiptables -t nat --delete-chainiptables -t mangle --delete-chain

    # Loopback interface zulasseniptables -A INPUT -i $LOCALHOST -j ACCEPTiptables -A OUTPUT -o $LOCALHOST -j ACCEPT

    Hier werden für alle drei Tabellen alle Chains gelöscht.Dies ist wichtig, da vorher schon Regeln definiert sein könnten.

    -A bedeutet Anfügendieser Regel an allebestehenden

    Abschnitt (B)

  • 30WIS – SS 2020 - Teil 13/Firewalls II

    Policies definieren

    # Policies definiereniptables --policy INPUT DROPiptables --policy OUTPUT DROPiptables --policy FORWARD DROP

    iptables -t nat --policy PREROUTING ACCEPTiptables -t nat --policy OUTPUT ACCEPTiptables -t nat --policy POSTROUTING ACCEPT

    iptables -t mangle --policy PREROUTING ACCEPT iptables -t mangle --policy OUTPUT ACCEPT

    Hier werden für ersten drei Tabellen die Policies als DROP definiert, d.h. ohne explizite Erlaubnis wird alles ohne Reaktion weggeworfen.Die ACCEPTs sind für die hier nicht besprochenen Tabellen wichtig.

    Abschnitt (C)

  • 31WIS – SS 2020 - Teil 13/Firewalls II

    Behandeln von Portscanns

    # Alle Bits gelöschtiptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP# SYN und FINiptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP# SYN und RSTiptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP# FIN und RSTiptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP# FIN ohne ACK, Xmas-Scanniptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP# PSH ohne ACKiptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP# URG ohne ACKiptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP

    Abschnitt (D)

    Siehe: https://www.selflinux.org/selflinux/html/iptables11.html#d82e3289

  • 32WIS – SS 2020 - Teil 13/Firewalls II

    Bemerkungen

    � ".... -p tcp --tcp-flags SYN,FIN SYN,FIN..." bedeutet z.B., dass die TCP-Flags SYN,FIN (erster Eintrag) betrachtet werden und dass die Flags SYN,FIN (zweiter Eintrag) An sein sollen, damit die Regel zutrifft.

    � Hier werden die bekannten Portscanns gestört, da die beschränkende Bedingung von "-i $OUTER" fehlt, gilt dies für alle Schnittstellen.

  • 33WIS – SS 2020 - Teil 13/Firewalls II

    Dynamische Regeln I

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTiptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPTiptables -A INPUT -m state --state INVALID -j LOG --log-prefix "INVALID..."iptables -A INPUT -m state --state INVALID -j DROPiptables -A OUTPUT -m state --state INVALID -j LOG --log-prefix "INVALID..."iptables -A OUTPUT -m state --state INVALID -j DROP

    Es werden alle aufgebauten Verbin-dungen aller Protokolle an allen Schnitt-stellen ohne weitere Prüfung erlaubt

    Logging mitspeziellemPräfix

    Alles mit unklarenVerbindungsstatuswird verworfen

    Abschnitt (E)

    Das sind die "Durchzugsregeln" für den eigentlichen Datentransport.

  • 34WIS – SS 2020 - Teil 13/Firewalls II

    Dynamische Regeln II

    � Dies hier betrifft den Unterschied zwischen stateless und statefull Filtern.

    � Regeln mit "-m state --state" o.ä. setzen das Verfolgen von Verbindungen samt den Kontext voraus. Im Kernel wird für jede Verbindung der Zustand in einer Tabelle vermerkt.

    � Diese Überwachung benötigt dynamisch so viele Einträge, wie Verbindungen aufgebaut werden.– Dies führt zu einem Löschen bzw. Überschreiben alter Einträge,

    wenn die interne Tabelle voll ist.

    – Dies wiederum führt zu einem Vergessen des Zustands.

    – Daher können nach den dynamischen Regeln statische als "Fall back" folgen – jedenfalls, wenn dies gewünscht wird.

  • 35WIS – SS 2020 - Teil 13/Firewalls II

    Unsinniges von Draußen

    # Private Adressen von Draußen und Loopbackiptables -A INPUT -i $OUTER -s $CLASS_A -j DROPiptables -A INPUT -i $OUTER -s $CLASS_B -j DROPiptables -A INPUT -i $OUTER -s $CLASS_C -j DROP

    iptables -A INPUT -i $OUTER -s $LOOPBACK -j DROP

    # Broadcasts behandelniptables -A INPUT -i $OUTER -s $OUTERNET_BROADCAST -j LOG iptables -A INPUT -i $OUTER -s $OUTERNET_BROADCAST -j DROP# iptables -A INPUT -i $OUTER -d $OUTERNET_BROADCAST -j LOG # iptables -A INPUT -i $OUTER -d $OUTERNET_BROADCAST -j DROP

    Abschnitt (F)

    Aber (Achtung): Mit der letzten Zeile werden alle Broadcasts an die eigene Maschineverworfen, was vielleicht nicht immer gewollt ist.

    Das muss entsprechenddem benutzten Netzangepasst werden.

  • 36WIS – SS 2020 - Teil 13/Firewalls II

    Behandlung einzelner Dienste

    � Nun wird Dienst für Dienst behandelt.

    � Wer einen bestimmten Dienst nicht hat bzw. ihn nur lokal auf seiner Maschine benutzen will, lässt die Angabe von Regeln weg, was DROP bedeutet.Dies gilt für den Zugriff von außen, aber auch für den von innen.

    � Wem DROP für die eigene Benutzung von Diensten zu destruktiv erscheint, baut eine eigene Regel mit "-A OUTPUT -o $OUTER" und "-j REJECT" ein.Dann erhält ein Client, der einen nicht erlaubten Dienst benutzen will, ein ICMP-Fehlerpaket.

    Abschnitt (G)

  • 37WIS – SS 2020 - Teil 13/Firewalls II

    DNS – Tabelle (aus letzter Einheit)

    Nr Außen Richtung Innen Außen-Innen

    (1) *:UDP:53 *:TCP:53 Client-Server

    IP-AdresseAußen

    InitialeRichtungPort

    Port RollenIP-AdresseInnen

    Kürzel Erläuterung Kürzel Erläuterung

    Open 1024:65535 * Beliebige sinnvolle Adresse

    UDP Protokoll TCP Protokoll

  • 38WIS – SS 2020 - Teil 13/Firewalls II

    Umsetzung in iptables-Regeln I

    Nr Außen Richtung Innen Außen-Innen

    (1) *:UDP:53

  • 39WIS – SS 2020 - Teil 13/Firewalls II

    Umsetzung in iptables-Regeln II

    iptables -A OUTPUT -o $OUTER -p udp --sport $OPEN_PORT --dport 53 -m state --state NEW -j ACCEPT

    iptables -A OUTPUT -o $OUTER -p udp --sport $OPEN_PORT --dport 53 -j ACCEPT

    iptables -A INPUT -i $OUTER -p udp --sport 53 --dport $OPEN_PORT -j ACCEPT

    Zustandsbehaftet Zustandslos

    Interpretationsreihenfolge

    Fallback

  • 40WIS – SS 2020 - Teil 13/Firewalls II

    Hinweise zum Fallback (UDP-Version)

    iptables -A OUTPUT -o $OUTER -p udp --dport XYZ -m state --state NEW -j ACCEPT

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTiptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

    iptables -A OUTPUT -o $OUTER -p udp --dport XYZ -j ACCEPT

    iptables -A INPUT -i $OUTER -p udp --sport XYZ -j ACCEPT

    Zustandsloser Modus

    Zustandsbehafteter Modus

  • 41WIS – SS 2020 - Teil 13/Firewalls II

    Hinweise

  • 42WIS – SS 2020 - Teil 13/Firewalls II

    Umsetzung in iptables-Regeln III

    # Einfache Client-Anfragen Zeile (1)iptables -A OUTPUT -o $OUTER -p udp --sport $OPEN_PORT --dport 53 -m state --state NEW -j ACCEPT

    iptables -A OUTPUT -o $OUTER -p udp --sport $OPEN_PORT --dport 53 -j ACCEPTiptables -A INPUT -i $OUTER -p udp --sport 53 --dport $OPEN_PORT -j ACCEPT

    # Das Ganze noch einmal für TCP Zeile (2)iptables -A OUTPUT -o $OUTER -p tcp --sport $OPEN_PORT --dport 53 -m state --state NEW -j ACCEPT

    iptables -A OUTPUT -o $OUTER -p tcp --sport $OPEN_PORT --dport 53 -j ACCEPTiptables -A INPUT -i $OUTER -p tcp ! --syn --sport 53 --dport $OPEN_PORT -j ACCEPT

    Für TCP muss der Aufbau vonAußen verhindert werden, trotzdemmuss der Rückfluss erfolgen können

    Für UDP ist "! --syn"nicht erforderlich.

  • 43WIS – SS 2020 - Teil 13/Firewalls II

    Hinweise zum Fallback (TCP-Version)

    iptables -A OUTPUT -o $OUTER -p tcp --dport XYZ -m state --state NEW -j ACCEPT

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTiptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

    iptables -A OUTPUT -o $OUTER -p tcp --dport XYZ -j ACCEPT

    iptables -A INPUT -i $OUTER -p tcp ! --syn --sport XYZ -j ACCEPT

    Zustandsloser Modus

    Zustandsbehafteter Modus

  • 44WIS – SS 2020 - Teil 13/Firewalls II

    Umsetzung in iptables-Regeln IV

    Nr Außen Richtung Innen Außen-Innen

    (1) $NAMESERVER:UDP:53

  • 45WIS – SS 2020 - Teil 13/Firewalls II

    Umsetzung in iptables-Regeln V

    # Einfache Client-Anfragen

    iptables -A OUTPUT -o $OUTER -p udp --sport $OPEN_PORT-d $NAMESERVER --dport 53 -m state --state NEW -j ACCEPT

    iptables -A OUTPUT -o $OUTER -p udp --sport $OPEN_PORT-d $NAMESERVER --dport 53 -j ACCEPT

    iptables -A INPUT -i $OUTER -p udp -s $NAMESERVER --sport 53 --dport $OPEN_PORT -j ACCEPT

    # Das Ganze noch einmal für TCP

    iptables -A OUTPUT -o $OUTER -p tcp --sport $OPEN_PORT-d $NAMESERVER --dport 53 -m state --state NEW -j ACCEPT

    iptables -A OUTPUT -o $OUTER -p tcp --sport $OPEN_PORT-d $NAMESERVER --dport 53 -j ACCEPT

    iptables -A INPUT -i $OUTER -p tcp ! --syn -s $NAMESERVER --sport 53--dport $OPEN_PORT -j ACCEPT

    Fall Back

  • 46WIS – SS 2020 - Teil 13/Firewalls II

    ICMP

    � "Time exceeded", "Parameter Error" und "Destination unreachable" sollten von Außen immer erlaubt werden.

    � Wenn fremdes Traceroute erlaubt werden soll: "Time exceeded" und "Destination unreachable" von Innen nach Außen.

    � Je nach Entscheidung bezüglich pings: – Von Innen nach Außen: eigene pings

    – Von Außen nach Innen: fremde pings, Kernel-Parameter ändern

    � In jedem Fall:– "Parameter Error" von Innen nach Außen und

    – alle fragementierten ICMP-Pakete verwerfen.

    Abschnitt (H)

  • 47WIS – SS 2020 - Teil 13/Firewalls II

    ICMP II - Auszug

    #--Fragmentierte Pakete auf allen Schnittstelleniptables -A INPUT --fragment -p icmp -j LOG --log-prefix "Fragmented ICMP: "iptables -A INPUT --fragment -p icmp -j DROP

    #--Parameter-Problemiptables -A INPUT -i $OUTER -p icmp --icmp-type parameter-problem -j ACCEPTiptables -A OUTPUT -o $OUTER -p icmp --icmp-type parameter-problem -j ACCEPT

    #--destination unreachable samt den Untertypeniptables -A INPUT -i $OUTER -p icmp --icmp-type destination-unreachable -j ACCEPTiptables -A OUTPUT -o $OUTER -p icmp --icmp-type destination-unreachable -j DROP

    #--dieser Typ muss leider hinaus gehen, sonst gehen andere Sachen nichtiptables -A OUTPUT -o $OUTER -p icmp --icmp-type fragmentation-needed -j ACCEPT

  • 48WIS – SS 2020 - Teil 13/Firewalls II

    Logging I

    #--Logging der abgewiesenen empfangenen ICMP-Paketeiptables -A INPUT -i $OUTER -p icmp --icmp-type ! 8

    -j LOG --log-prefix "Dropped Received ICMP: "

    #--Logging der abgewiesenen UDP-Paketeiptables -A INPUT -i $OUTER -p udp

    -j LOG --log-prefix "Dropped Received UDP: "

    #--Logging der abgewiesenen TCP-Paketeiptables -A INPUT -i $OUTER -p tcp

    -j LOG --log-prefix "Dropped Received TCP: "

    #--Logging der abgewiesenen gesendeten Paketeiptables -A OUTPUT -o $OUTER -p tcp

    -j LOG --log-prefix "Dropped Send Packet: "

    Abschnitt (I)

  • 49WIS – SS 2020 - Teil 13/Firewalls II

    Logging II

    � Aber: Viel ist nicht unbedingt besser als wenig.Aber immer: Die Logfiles analysieren!

    � Ausprobieren, welchen Umfang das Logging haben soll.

    � Dazu kommt noch die Frage nach dem Einsatz von IDS, z. B. snort, die ja auch eine Menge Logging-Möglichkeiten haben.

    In jedem Falle: Ein einheitliches, einfach zu analysierendesLogfile-Format benutzen.

    Dieses Format muss auch zu den Auswertewerkzeugen passen,z.B. logsurfer.

  • 50WIS – SS 2020 - Teil 13/Firewalls II

    Nun wieder etwas entspannen...

    Einsam aufweiter Flur...