Archiv

Linux als Firewall

Einordnung und Abgrenzung

  • Firewall-Systeme, Router
  • ausschliesslich Paketfilter-Techniken 
# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
#
  • Schutz eines privaten Netzes mit Maschinen unterschiedlicher Plattformen
    • eine von viele Schutzmaßnahmen
    • Wirksamkeit umstritten
    • filtern von ein- und ausgehenden Datenverkehr aller Rechner des privaten Netzes
    • Ziel: ungewollten/unbeabsichtigten Datenverkehr unterbinden
    • Voraussetzung: genaue und detaillierte Kenntnisse über Anwendungsprotokolle
  • hier: Basismechanismen und -werkzeuge
  • ausserdem: Selbstschutz des Firewall-Systems
  • nicht:
    • Application Level Gateway (Proxy)
    • grafische Frontends für Regel-Definitionen

Was ist netfilter/iptables?

  • Paket-Filter im Linux-Kernel (ab Version 2.4)
    • inspiziert IP-Pakete
    • entscheidet auf Grund von Regeln, wie mit einem IP-Paket zu verfahren ist
  • konfiguriert durch das Kommando iptables
  • realisiert als Kernel-Moduln 
# ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
arptable_filter.ko          ipt_addrtype.ko    ipt_NETMAP.ko
arp_tables.ko               ipt_ah.ko          ipt_NOTRACK.ko
arpt_mangle.ko              ipt_CLASSIFY.ko    ipt_owner.ko
ip_conntrack_amanda.ko      ipt_comment.ko     ipt_physdev.ko
ip_conntrack_ftp.ko         ipt_conntrack.ko   ipt_pkttype.ko
ip_conntrack_irc.ko         ipt_dscp.ko        ipt_realm.ko
ip_conntrack.ko             ipt_DSCP.ko        ipt_recent.ko
ip_conntrack_proto_sctp.ko  ipt_ecn.ko         ipt_REDIRECT.ko
ip_conntrack_tftp.ko        ipt_ECN.ko         ipt_REJECT.ko
ip_nat_amanda.ko            ipt_esp.ko         ipt_SAME.ko
ip_nat_ftp.ko               ipt_helper.ko      ipt_sctp.ko
ip_nat_irc.ko               ipt_iprange.ko     ipt_state.ko
ip_nat_snmp_basic.ko        ipt_length.ko      ipt_tcpmss.ko
ip_nat_tftp.ko              ipt_limit.ko       ipt_TCPMSS.ko
ip_queue.ko                 ipt_LOG.ko         ipt_tos.ko
iptable_filter.ko           ipt_mac.ko         ipt_TOS.ko
iptable_mangle.ko           ipt_mark.ko        ipt_ttl.ko
iptable_nat.ko              ipt_MARK.ko        ipt_ULOG.ko
iptable_raw.ko              ipt_MASQUERADE.ko
ip_tables.ko                ipt_multiport.ko
#

  • es werden nur die Moduln geladen, für die Regeln definiert sind (bzw. zugehörige Helper-Moduln) 

# lsmod|grep ip
ipv6                  240097  100
ipt_REJECT             10561  3
ipt_LOG                10049  1
ipt_multiport           5953  3
ipt_state               5825  4
ip_conntrack           45573  1 ipt_state
iptable_filter          6721  1
ip_tables              21441  5 ipt_REJECT,ipt_LOG,ipt_multiport,ipt_state,iptable_filter
#

Funktionsprinzipien von iptables

  • ein IP-Paket durchläuft mehrere chains / tables
  • chains enthalten Regeln
  • eine Regel definiert
    • ein Muster: Bedingungen, denen ein Paket entsprechen soll, z.B. bestimmte Ziel-Adresse, bestimmte Flags im TCP-Header, o.dgl.
    • ein Ziel: target
  • ein target ist eine weitere chain oder ein default-target (z.B. DROP, ACCEPT, ...)
  • ein Paket wird an das target weitergeleitet, wenn es dem in der Regel definierten Muster entspricht (match)
  • d.h.: sobald ein match erreicht ist, werden nachfolgende Regeln in dieser Tabelle nicht mehr angewendet
  • wird in einer chain kein match erreicht, dann
    • wird mit übergeordneter chain fortgesetzt, falls es eine gibt
    • sonst bestimmt die policy das Verhalten
  • policy definiert eines der default-targets

Paketverarbeitung: das ganze Bild

Bild: Netfilter Paket Traversal

Tabellen (tables)

  • regeln unterschiedliche Arten der Paketverarbeitung
  • grundlegende Gruppierung der Pakete
  • jede Tabelle enthält vordefinierte und ggf. nutzerdefinierte chains
  • conntrack
    • Connection Tracking
    • erkennen von zusammengehörigen Paketen (z.B. TCP-Session, UDP-Stream, Analyse von Anwendungsprotokollen)
    • realisiert sog. statefull packet filter
    • nicht veränderbar: es können keine Regeln angegeben werden
  • mangle
    • bestimmte Änderungen an Paketen, z.B. TTL (time-to-live), TOS (Type of Service)
    • Pakete markieren
    • chains: alle
  • nat
    • Network Address Translation
    • Änderung von IP-Adressen/Port-Nummern
    • SNAT (Soure-NAT):
      • Ändern der Quell-Adresse
      • chains: POSTROUTING
      • auch: Masquerading (Umgang mit dynamischen IP-Adressen, setzen der Quell-IP-Adresse auf IP-Adresse des outgoing Interfaces)
    • DNAT (Destination-NAT):
      • Ändern der Ziel-Adresse
      • chains: PREROUTING und OUTPUT
      • Redirection: Ändern des Ziel-Ports
  • filter
    • Paket-Filter
    • chains: INPUT, OUTPUT und FORWARD
    • oftmals benutzerdefinierte chains
  • ggf. weitere Tabellen, je nach Distribution, Kernel- und iptables-Version
  • wenn für eine Table keine Regeln definiert sind, entfällt die komplette Table (der Kernel-Modul wird nicht geladen)
  • Maschinen, die kein Routing vornehmen, benutzen i.d.R. nur die filter-Table

Regelketten (chains)

IP-Pakete passieren die einzelnen chains unter den folgenden Bedingungen (die einzelnen Tables enthalten ggf. nicht alle chains)

  • PREROUTING
    • unmittelbar nach dem Eintreffen an der Maschine
    • vor der routing-Entscheidung
  • INPUT
    • Ziel: lokaler Prozess
  • FORWARD
    • Ziel: nicht lokal, Paket hat externen Empfänger
  • OUTPUT
    • Quelle: lokaler Prozess
  • POSTROUTING
    • vor dem Verlassen der Maschine

Das Kommando iptables

  • Einrichten, Manipulieren und Anzeigen der iptables-Regeln im Kernel

Aufrufkonventionen, Syntax, etc.

Connection Tracking

Kernel-Modul

  • Kernel-Modul ip_conntrak führt eine Connection Tracking Database (/proc/net/ip_conntrak)
  • einzelne Einträge beschreiben zu einem konkreten Zeitpunkt den Zustand von IP-Verbindungen 

# cat /proc/net/ip_conntrack
...
tcp      6 429160 ESTABLISHED src=134.109.201.14 dst=134.109.132.20 \              #1
                  sport=1023 dport=22 packets=385 bytes=24044 \                    #2 
                  src=134.109.132.20 dst=134.109.201.14 sport=22 dport=1023 \      #3 
                  packets=231 bytes=33073 [ASSURED] use=1                          #4

...
tcp      6    115 SYN_SENT src=134.109.201.14 dst=134.109.148.50 \                 #5
                  sport=1022 dport=22 [UNREPLIED] \                                #6
                  src=134.109.148.50 dst=134.109.201.14 sport=22 dport=1022 \      #7
                  [ASSURED] use=2                                                  #8

  • erster Eintrag (#1...#4)
    • TCP-Verbindung (IP-Protokollnummer 6) zwischen 134.109.201.14:1023 und 134.109.132.20:22
    • Zustand (tcp state): ESTABLISHED (three-way handshake ist beendet)
    • Timeout: 429160 Sekunden
      • Startwert ist zustandsabhängig
      • Reset bei Zustandsänderung oder wenn die Verbindung benutzt wird
    • Zeilen #1 und #2: "request"-Richtung
    • Zeilen #3 und #4: "return"-Richtung
    • [ASSURED]: Eintrag wird nicht gelöscht, wenn max. Anzahl von Einträgen erreicht ist
  • zweiter Eintrag (#5...#8)
    • TCP-Verbindung (IP-Protokollnummer 6) zwischen 134.109.201.14:1022 und 134.109.148.50:22
      • Zustand (tcp state): SYN_SENT
      • es wurde bisher nur ein TCP-Segement mit gesetzem SYN-Flag gesendet
      • erster Schritt im three-way handshake
    • [UNREPLIED]: bisher keine Antwort
  • zahlreiche Zustände (protokollabhängig)

iptables

  • Modul ipt_state
  • vereinfachtes Zustandsmodell (iptables -m state --state)
    • NEW
      • erstes Paket einer Verbindung
      • typisch: SYN -Paket einer TCP-Verbindung
      • erstes UDP-Paket mit bestimmten Addressangaben (Source-IP, Source-Port, Dest-IP. Dest-Port)
      • ACK -Packet einer TCP-Verbindung, die nicht beendet wurde (close), aber den timeout-Wert überschritten hat
    • ESTABLISHED
      • Paket-Verkehr in beiden Richtungen hat stattgefunden
    • RELATED
      • zugehörig zu einer ESTABLISHED Verbindung
      • typisch: ftp-data / ftp-control
      • erfordert oftmals anwendungsprotokollspezifische helper modules
      • ICMP error messages
    • INVALID
      • Paket kann nicht identifiziert werden
      • ICMP error messages, die zu keiner bekannten Verbindung gehören
      • out of TCP window packets
      • falsche Kombination von TCP-Flags
    • UNTRACKED
      • Paket wurde nicht von conntrack behandelt
  • connection tracking in der chain
    • PREROUTING
      • alle ankommenden Pakete: Neueintrag (request) oder Zustandsänderung (reply)
      • vor Routing-Entscheidung
        • alle lokal addressierten Pakete
        • alle zu routende Pakete (richtungsunabhängig)
    • OUTPUT
      • alle lokal gesendeten Pakete: Neueintrag (request) oder Zustandsänderung (reply)
  • conntrack- und iptables-Zustände
    Beispiel: Aufbau einer TCP-Verbindung von Host A zu Host B
    Schritt Richtung TCP-Flags Sicht von Host A Sicht von Host B
    iptables chain tcp state iptables state iptables chain tcp state iptables state
    1 A -> B SYN OUTPUT SYN_SENT NEW PREROUTING SYN_RECV NEW
    2 B -> A SYN+ACK PREROUTING SYN_RECV ESTABLISHED OUTPUT ESTABLISHED ESTABLISHED
    3 A -> B ACK OUTPUT ESTABLISHED ESTABLISHED PREROUTING ESTABLISHED ESTABLISHED

  • Steuerung über Parameter in /proc/sys/net/ipv4/netfilter/*

Beispiel: Paketfilter für ein Server-Subnetz

Setup und Aufgabenstellung

Beispiel: Paketfilter für ein Server-Subnetz

  • Server-Subnetz 134.109.102.0/24 (routbare IP-Adressen) enthält einige Server
    • Web-Server
      • Linux-Server 134.109.102.1
    • Datenbank (proprietäres Produkt)
      • Linux-Server 134.109.102.2
    • Windows Terminal-Server
      • Client der Datenbank
      • Spezial-Anwendungen
      • 134.109.102.3
  • Ziele:
    • Server schützen
      • proprietäre Produkte/Protokolle
    • Windows-Terminal-Server
      • interaktive Nutzung einschränken
      • evtl. eingeschleppte Malware nicht weiter verbreiten
      • Besonderheit: einzelne Anwendungen greifen per HTTP/HTTPS auf externe (bekannte) Server zu
  • Zugänge
    • aus dem Internet
      • mit HTTP/HTTPS zu 134.109.102.1
      • mit RDP (Remote Desktop Protocol) zu 134.109.102.3
      • mit proprietärem Protokoll (1972/tcp) zu Datenbank-Server 134.109.102.2 (Updates) durch bekannte Partner
    • aus dem Intranet
      • mit HTTP/HTTPS zu 134.109.102.1
      • mit RDP (Remote Desktop Protocol) zu 134.109.102.3
      • mit SSH auf alle Linux-Systeme
  • Forderungen
    • geschützte Server sollen Dienste im Intranet nutzen können
      • DNS
      • NTP
      • DHCP
      • AFS
      • ...
    • geschützte Server sollen einzelne Server im Internet erreichen können
      • HTTP/HTTPS
    • Firewall-System soll sich selbst schützen

Lösungsansatz

  • IP-Adresse 134.109.100.100 muss als Gateway-Adresse für das Subnetz 134.109.102.0/24 im zentralen Router eingetragen sein
  • "klassischer" statefull packet filter
  • Policy: Verkehrsbeziehungen unterbinden, die nicht explizit erlaubt sind
  • erlaubte Pakete sollen möglichst wenige Regeln passieren müssen
  • Table: filter
  • Chains
    • FORWARD
      • Schutz des Server-Subnetzes
    • INPUT, OUTPUT
      • Selbstschutz
  • benutzerdefinierte Chains
    • COMMON
      • referenziert aus FORWARD, INPUT, OUTPUT
      • "statefull Regeln"
      • "Hygiene": was nicht sein kann, darf nicht sein
    • COMMONCLIENT
      • referenziert aus OUTPUT und FORWARD
      • Dienste, die vom Firewall-System selbst als auch von den Maschinen im Server-Subnetz genutzt werden
    • SERVERNET
      • referenziert aus FORWARD
      • Dienste, die Maschinen im Server-Subnetz anbieten
    • LOGREJECT
      • referenziert aus FORWARD, INPUT, OUTPUT und COMMON
      • Logging und zurückweisen von Paketen
  • zusätzliche Kernel-Konfiguration 


# cat /etc/sysconfig/iptables
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
###
# LOGREJECT
###
-N LOGREJECT
-A LOGREJECT -j LOG --log-level info  --log-prefix "iptables REJECT:"
-A LOGREJECT -p tcp -j REJECT --reject-with tcp-reset
-A LOGREJECT -j REJECT --reject-with icmp-host-prohibited
###
# COMMON
###
-N COMMON
-A COMMON -m state --state INVALID -j DROP
-A COMMON -m state --state ESTABLISHED,RELATED -j ACCEPT
-A COMMON -p tcp ! --syn -m state --state NEW -j LOGREJECT
-A COMMON -i eth0 -s 134.109.102.0/24 -j LOGREJECT
-A COMMON -o eth0 -d 134.109.102.0/24 -j LOGREJECT
# Monitoring
-A COMMON -s 134.109.aaa.bbb -d 134.109.102.0/24 -p icmp -m icmp --icmp-type ping -j ACCEPT
###
# COMMONCLIENT
###
-N COMMONCLIENT
# AFS
# udp_stream_timeout!
-A COMMONCLIENT -o eth0 -p udp -m multiport --dports 7000,7002,7003,7004 -j ACCEPT
# Kerberos
-A COMMONCLIENT -o eth0 -p udp -m multiport --dports 88,750,4444 -j ACCEPT
# DNS, NTP
-A COMMONCLIENT -o eth0 -p udp -m multiport --dports 53,123 -j ACCEPT
###
# SERVERNET
###
-N SERVERNET
# HTTP/HTTPS
-A SERVERNET -d 134.109.102.1 -p tcp -m multiport --dports 80,443 -j ACCEPT
# RDP
-A SERVERNET -d 134.109.102.3 -p tcp -m tcp --dport 3389 -j ACCEPT
# DB-Zugriff
-A SERVERNET -d 134.109.102.2 -s xxx.yyy.zzz.0/24 -p tcp -m tcp --dport 1972 -j ACCEPT
# SSH
-A SERVERNET -d 134.109.102.1 -s 134.109.0.0/16 -p tcp -m tcp --dport 22 -j ACCEPT
-A SERVERNET -d 134.109.102.2 -s 134.109.0.0/16 -p tcp -m tcp --dport 22 -j ACCEPT
# HTTP/HTTPS zu externen Servern
-A SERVERNET -d nnn.mmm.ooo.ppp -s 134.109.102.3 -p tcp -m multiport --dports 80,443 -j ACCEPT
# Path MTU discovery
-A SERVERNET -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT
###
# FORWARD
###
-A FORWARD -j COMMON
-A FORWARD -j COMMONCLIENT
-A FORWARD -j SERVERNET
-A FORWARD -j LOGREJECT
###
# INPUT
###
-A INPUT -j COMMON
-A INPUT -i lo -j ACCEPT
# DHCP
-A INPUT -i eth1 -p udp -m udp --dport 67 --sport 68 -j ACCEPT
-A INPUT -j LOGREJECT
###
# OUTPUT
###
-A OUTPUT -j COMMON
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -j COMMONCLIENT
-A OUTPUT -j LOGREJECT

Network Address Translation

  • ersetzen der IP-Adresse in einem Paket
  • Maschinen mit privaten, nicht routbaren IP-Adressen sollen im Internet kommunizieren können
  • private Adressbereiche
    Adressbereich CIDR-Schreibweise Anzahl der Adressen
    10.0.0.0-10.255.255.255 10.0.0.0/8 16.777.214
    172.16.0.0-172.31.255.255 172.16.0.0/12 1.048.574
    192.168.0.0-192.168.255.255 192.168.0.0/16 65.534
    169.254.0.0-169.254.255.255 (link local) 169.254.0.0/16 65.534
  • NAT-Gateway
    • setzt private Adressen in öffentliche Adresse(n) um
    • ggf. werden auch Port-Nummern umgeschrieben
  • NAT ist primär keine Sicherheitstechnik
    • Struktur des privaten Netzes wird verborgen
    • ausserhalb tritt nur NAT-Gateway in Erscheinung
    • maskierte Rechner haben vollständigen Internet-Zugang
  • Sicherheitseigenschaften durch zusätzliche filter-Einstellungen
  • Source Network Address Translation (SNAT)
    • auch: Masquerading
    • ändern der Quell-Adresse eines IP-Pakets
    • Client im privaten Netz
    • Quell-Adresse (nicht routbar) wird ersetzt durch Adresse des Gateways (routbar)
    • Illustration: http://www.kohnlehome.de/netz/Masquerading.swf
    • iptables chain: POSTROUTING
      • Änderung am Paket unmittelbar bevor das Paket die Maschine verlässt
  • Destination Network Address Translation (DNAT)
    • auch Port Forwarding
    • ändern der Ziel-Adresse eines IP-Pakets
    • Server im privaten Subnetz
    • Adresse des Gateways wird ersetzt durch (nicht routbare) Ziel-Adresse des Servers
    • Clients adressieren das Gateway (DNS-Einträge!)
    • Illustration: http://www.kohnlehome.de/netz/PortForwarding.swf
    • iptables chain: PREROUTING (OUTPUT)
      • Änderung am Paket unmittelbar nach Empfang des Pakets und vor Routing-Entscheidung
      • Änderung an lokal erzeugten Paketen
  • es wird nur das jeweils erste Paket einer Verbindung analysiert (match) und entsprechend der Regel behandelt
  • das Austauschen der Adressinformationen erfolgt dann für alle weiteren Pakete der Verbindung analog
  • deshalb in Table nat möglichst keine Filter-Regeln formulieren

Beispiel: NAT für ein privates Netz

Setup und Aufgabenstellung

Szenarium 2: NAT für ein privates Netz

  • IP-Adresse 134.109.100.100 wird im DNS abgebildet auf natgw.hrz.tu-chemnitz.de
  • private Maschinen als Client sollen erreichen
    • ohne Einschränkungen alle Maschinen in 134.109.0.0/16
    • ausserhalb von 134.109.0.0/16 nur
      • HTTP/HTTPS
      • SSH
      • FTP
  • private Maschinen als Server sollen erreichbar sein
    • per SSH: alle ausgehend von 134.109.100.0/24
    • per HTTP: ein Web-Server ausgehend von 134.109.0.0/16 auf 192.168.1.1
  • NAT-Gateway soll sich selbst schützen

Lösungsansatz

  • NAT-Gateway mit Packetfilter-Funktionen
  • Tables/Chains
    • nat/POSTROUTING
      • private Maschinen als Client
      • SNAT
      • Masquerading
    • nat/PREROUTING
      • private Maschinen als Server
      • DNAT
    • filter/FORWARD
      • Schutz des privaten Netzes
    • filter/INPUT, filter/OUTPUT
      • Selbstschutz
  • zusätzliche Kernel-Moduln und Kernel-Konfiguration 

# cat /etc/sysconfig/iptables
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
###
# SNAT: nat/POSTROUTING
###
-A POSTROUTING -o eth0 -j SNAT --to-source 134.109.100.100
###
# DNAT: nat/PREROUTING
###
# in das private Netz nicht direkt routen
-A PREROUTING -i eth0 -d 192.168.0.0/16 -j DROP
# HTTP
-A PREROUTING -d 134.109.100.100 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.1
# SSH
-A PREROUTING -d 134.109.100.100 -p tcp --dport 122 -j DNAT --to-destination 192.168.1.1:22
-A PREROUTING -d 134.109.100.100 -p tcp --dport 222 -j DNAT --to-destination 192.168.1.2:22
-A PREROUTING -d 134.109.100.100 -p tcp --dport 322 -j DNAT --to-destination 192.168.1.3:22
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
###
# filter/LOGREJECT
###
-N LOGREJECT
-A LOGREJECT -j LOG --log-level info  --log-prefix "iptables REJECT:"
-A LOGREJECT -p tcp -j REJECT --reject-with tcp-reset
-A LOGREJECT -j REJECT --reject-with icmp-host-prohibited
###
# filter/COMMON
###
-N COMMON
-A COMMON -m state --state INVALID -j DROP
-A COMMON -m state --state ESTABLISHED,RELATED -j ACCEPT
-A COMMON -p tcp ! --syn -m state --state NEW -j LOGREJECT
###
# filter/PRIVATENET
###
-N PRIVATENET
# Client mit Zielen im Intranet
-A PRIVATENET -d 134.109.0.0/16 -j ACCEPT
# Client mit Zielen FTP/SSH/HTTP/HTTPS im Internet
-A PRIVATENET -d ! 192.168.1.0/24 -p tcp -m multiport --dports 21,22,80,443 -j ACCEPT
# Server
# SSH für Clients aus 134.109.100.0/24
-A PRIVATENET -d 192.168.1.0/24 -s 134.109.100.0/24 -p tcp -m tcp --dport 22 -j ACCEPT
# HTTP für alle
-A PRIVATENET -d 192.168.1.1 -p tcp -m tcp --dport 80 -j ACCEPT
# Path MTU discovery
-A PRIVATENET -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT
###
# filter/FORWARD
###
-A FORWARD -j COMMON 
-A FORWARD -j PRIVATENET
-A FORWARD -j LOGREJECT
###
# filter/INPUT
###
-A INPUT -j COMMON
-A INPUT -i lo -j ACCEPT
# DHCP 
-A INPUT -i eth1 -p udp -m udp --dport 67 --sport 68 -j ACCEPT
-A INPUT -j LOGREJECT
###
# filter/OUTPUT
###
-A OUTPUT -j COMMON
-A OUTPUT -o lo -j ACCEPT
# AFS
-A OUTPUT -o eth0 -p udp -m multiport --dports 7000,7002,7003,7004 -j ACCEPT
# Kerberos
-A OUTPUT -o eth0 -p udp -m multiport --dports 88,750,4444 -j ACCEPT
# DNS, NTP
-A OUTPUT -o eth0 -p udp -m multiport --dports 53,123 -j ACCEPT
-A OUTPUT -o eth1 -d 192.168.1.0/24 -p tcp -m tcp --dport 22 -j ACCEPT
-A OUTPUT -o eth1 -d 192.168.1.1 -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -j LOGREJECT
COMMIT

  • Regeln in nat/PREROUTING und nat/POSTROUTING erfüllen o.g. Forderungen
    • Maschinen im privaten Netz erreichen definierte Ziele ausserhalb
    • Maschinen im privaten Netz sind erreichbar von ausserhalb
      private Adresse öffentliche Adresse Beispiel
      192.168.1.1:22 134.109.100.100:122 ssh -p 122 natgw.hrz.tu-chemnitz.de
      192.168.1.2:22 134.109.100.100:222 ssh -p 222 natgw.hrz.tu-chemnitz.de
      192.168.1.3:33 134.109.100.100:322 ssh -p 322 natgw.hrz.tu-chemnitz.de
      192.168.1.1:80 134.109.100.100:80 http://natgw.hrz.tu-chemnitz.de/

1. Problem

  • private Maschinen können Dienste auf privaten Maschinen nicht erreichen
  • Beispiel: Webbrowser auf 192.168.1.2 versucht URL http://natgw.hrz.tu-chemnitz.de/ zu erreichen
    1. Paket an 134.109.100.100:80 verlässt 192.168.1.2
    2. Paket erreicht natgw
    3. in nat/PREROUTING wird es über DNAT mit neuer Zieladresse 192.168.1.1:80 versehen
    4. Paket verlässt natgw und erreicht HTTP-Server
    5. HTTP sendet Antwort an 192.168.1.2 (direkt, weil im selben Subnetz)
    6. Paket mit Quelladresse 192.168.1.1:80 erreicht 192.168.1.2 und wird dort verworfen
      (kein reply auf ursprünglichen request an 134.109.100.100:80)
  • erforderlich: SNAT für alle Pakete, die natgw erreichen und für die es DNAT Einträge gibt 
-A POSTROUTING -d 192.168.1.0/16 -j SNAT --to-source 192.168.1.254
  • vor Schritt 4 wird Source-Adresse in private Adresse von natgw geändert
  • Server in 192.168.1.0/24 sehen immer 192.168.1.254 als Absender (Logging wird nutzlos)
  • wünschenswert: Angabe -i eth1
    • Änderung würde nur geschehen, wenn der Absender der Pakete aus dem privaten Netz stammt
    • chain POSTROUTING erlaubt Angabe -i ... jedoch nicht
  • weiteres Problem: filter/PRIVATENET verwirft Pakete mit Ziel-IP 192.168.1.0/24 und Ziel-Port 22, wenn diese eine Source-IP ausserhalb 134.109.100.0/24 besitzen
  • weitere Regel in filter/PRIVATENET erforderlich (als 4. Regel eintragen): 
-A PRIVATENET -d 192.168.1.0/24 -s 192.168.1.0/24 -p tcp -m tcp --dports 22 -j ACCEPT
  • Konsequenz: solche Konstruktionen möglichst vermeiden
    • z.B. Hostname natgw.hrz.tu-chemnitz.de in /etc/hosts auf Maschinen in privatem Netz direkt auf 192.168.1.1 abbilden

2. Problem

  • Clients auf natgw können Dienste auf privaten Maschinen nicht erreichen
  • Beispiel: Webbrowser auf natgw versucht URL http://natgw.hrz.tu-chemnitz.de/ zu erreichen
    1. Paket an 134.109.100.100:80 erreicht chain OUTPUT
    2. nat/OUTPUT enthält keine Regeln
    3. Paket wird über filter/OUTPUT in filter/LOGREJECT gelenkt und dort abgewiesen
  • erforderlich: Target DNAT in chain nat/OUTPUT für alle Ziele im privaten Netz 
# DNAT in nat/OUTPUT
-A OUTPUT -d 134.109.100.100 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.1
-A OUTPUT -d 134.109.100.100 -p tcp -m tcp --dport 122 -j DNAT --to-destination 192.168.1.1:22
-A OUTPUT -d 134.109.100.100 -p tcp -m tcp --dport 222 -j DNAT --to-destination 192.168.1.2:22
-A OUTPUT -d 134.109.100.100 -p tcp -m tcp --dport 222 -j DNAT --to-destination 192.168.1.3:22

Targets SNAT und MASQUERADE

  • in nat/POSTROUTING
  • Target SNAT
    • erfordert Angabe der Source-Adresse(n) (--to-source ...)
    • Problem: IP-Adresse der Internet-Verbindung wird dynamisch durch Provider vergeben
  • Target MASQUERADE
    • benutzt IP-Adresse des outgoing Interfaces
    • erleichtert iptables-Konfiguration bei dynamischer Vergabe der IP-Adresse der Internet-Anbindung
  • Source-Port-Nummer bleibt erhalten (bei TCP/UDP), es sei denn
    • sie ist bereits in Benutzung (durch NAT-Gateway selbst oder Verbindung einer anderen Maschine aus dem privaten Netz)
      • port < 512: anderer Port < 512
      • 512 <= 512 port < 1024: anderer Port < 1024
    • Port-Range wird vorgegeben
      • -j SNAT --to-source ipaddr1[-ipaddr2][:port1-port2]]
      • -j MASQUERADE --to-ports port1[-port2]]
      • jeweils nur in Verbindung mit -p tcp|udp

Targets DNAT und MASQUERADE

  • Target DNAT tauscht Ziel-IP in Paketen aus (in nat/PREROUTING oder nat/OUTPUT)
  • erforderlich ist die Qualifikation der Pakete (IP-Adresse, Port-Nummer)
    • nur solche Pakete, die als Ziel das Gateway-Interface der Paketfilter-Maschine haben
  • Target MASQUERADE anstelle von SNAT wird benutzt, wenn IP-Adresse des Gateway-Interfaces dynamisch vergeben wird - also nicht bekannt ist
  • Konsequenz: DNAT und MASQUERADE lassen sich nicht sinnvoll gemeinsam einsetzen
  • weiterhin: Server mit dynamisch wechselnder IP-Adresse benötigen ohnehin weitere Vorkehrungen (DDNS)

Zusammenfasung

  • netfilter/iptables ist mächtiges Werkzeug zum Aufbau von Paketfiltern
  • Erfahrung, Training und Detailkenntnisse erforderlich
  • hier nur einige Aspekte behandelt

Literatur und Verweise

Bücher

Spenneberg, Ralf
Linux Firewalls mit iptables & Co
ISBN 3-82732-136-0 Addison-Wesley Verlag, 2006

Barth, Wolfgang
Das Firewall-Buch
Grundlagen, Aufbau und Betrieb sicherer Netzwerke mit Linux
ISBN 3-89990-128-2
Nicolaus Millin Verlag GmbH, 2004

Cheswick, W.R.; Bellovin, S.M.; Rubin, A.D.
Firewalls und Sicherheit im Internet
Schutz vor cleveren Hackern
ISBN 3-8273-2117-4
Addison-Wesley Verlag, 2004

Links

http://de.wikipedia.org/wiki/Netfilter/iptables - gute deutsche Zusammenfassung bei Wikipedia

http://www.pro-linux.de/t_netzwerk/print/iptables.html - deutsches Tutorial

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

http://www.kalamazoolinux.org/presentations/20010417/conntrack.html - Connection Tracking

http://www.netfilter.org/ - Homepage von netfilter/iptables

http://de.wikipedia.org/wiki/Path_MTU_Discovery - Path MTU Discovery bei Wikipedia

TUCaktuell

  • Ki generiertes Bild

    Offen für Argumente geht in die zweite Runde

    Online-Debattenformat der Juniorprofessur Soziologie der TU Chemnitz thematisiert am 10. September 2025 die Rolle der Solarenergie im Zuge der Energiewende …

  • Gruppe vieler Menschen

    Let's run #TUCgether!

    Zum Jubiläum des Chemnitzer Firmenlaufs gingen 266 Laufbegeisterte für die TU Chemnitz an den Start …

  • Menschen stehen vor einer Leinwand

    Erfolgreiche Summer School an der TU Chemnitz

    Professur Medienpsychologie und die Hochschulallianz Across begrüßten zur Summer School „How much science is in science fiction?“ medienbegeisterte Nachwuchswissenschaftlerinnen und -wissenschaftler aus neun verschiedenen Ländern …

  • Menschen stehen vor einem Haus

    Als Azubi an die Uni? Ja, klar!

    Kanzler der TU Chemnitz begrüßte neue Auszubildende und gratulierte Absolventinnen und Absolventen zum erfolgreichen Berufsabschluss – TU Chemnitz bildet aktuell in zehn Berufen aus …