Walter Selos
Zusätzlich zu den in der letzten ZIDline behandelten Sicherheitsmechanismen (z. B. inetd und TCP-Wrapper) gibt es für Linux noch eine generellere Methode, um den IP-Netzwerkverkehr und vor allem den wichtigen TCP-Netzwerkverkehr zu kontrollieren und bei Bedarf einzuschränken. Diese Methode heißt "Packet Filtering" und ist ein Grundbestandteil jeder Firewall. Die meisten Firewalls verfügen darüber hinaus auch über Mechanismen zur Adressübersetzung (Network Address Translation), über Proxy-Funktionalität und einiges mehr.
Jeder Verkehr über ein Netzwerk wird in Form von Paketen gesendet. Jedes dieser Pakete beinhaltet Verwaltungsinformation, den so genannten Header, und die Nutzdaten, den body.
Im Header befinden sich Informationen über Herkunft (Source Address) und Ziel (Destination Address) des Pakets, über das verwendete IP-Protokoll (z. B. TCP, UDP, ICMP, ...) und einiges mehr (siehe IANA, Internet Assigned Numbers Authority, www.iana.org). Neben der reinen Datenübertragung gibt es bei verbindungsorientierten IP-Protokollen (z. B. Transmission Control Protocol (TCP)) spezielle Pakete für den Verbindungsaufbau bzw. -abbau. Auf dem TCP-Protokoll basieren die bekanntesten Services im Internet, wie z. B. HTTP (Web Traffic), SMTP (Mail-Transfer), SSH (Secure Shell) und Datentransfer (z. B. FTP).
Um auf Paketebene effektiv Zugriffsbeschränkungen und Kontrollmechanismen zu realisieren, muss man im besten Fall alle Informationen über die involvierten Protokolle haben, besonders wichtig sind aber die von den Services verwendeten Portadressen. Ebenso ist es wichtig zu wissen, welche weiteren Services zur einwandfreien Funktion eines gewünschten Services im Hintergrund noch von Bedeutung sind. Zum Surfen im Internet reicht es nicht aus, nur HTTP (Port 80) zuzulassen, man benötigt zumindest noch das Domain Name Service (DNS) mit Port 53 des UDP-Protokolls, sonst werden keine Zielknoten über deren Namen erkannt. Für ein derartiges Zusammenspiel mehrerer Protokolle gibt es zahlreiche Beispiele. Eine Liste der häufig verwendeten Protokolle (UDP und TCP) mit den zugehörigen Portadressen sind in der Datei "/etc/services" aufgelistet und können dadurch auch über den Servicenamen und nicht nur über die Portnummer spezifiziert werden.
Zur Verwendung eines Packet Filters sind also gewisse Grundkenntnisse über den Netzwerkverkehr notwendig, und ich möchte dringend von der Verwendung dieser Mechanismen abraten, solange man nicht wirklich weiß, was man will bzw. welche Services auf dem Rechner benötigt werden. Befolgt man diesen Rat nicht, läuft man Gefahr, sich in falscher Sicherheit zu wiegen, weil man ja ohnehin die "Firewall" aktiviert hat, ohne zu wissen, was da noch alles an den Filterregeln vorbei läuft, oder erwünschte Services funktionieren aufgrund falscher Konfiguration nicht mehr.
Unter Linux werden zwei Packet Filter eingesetzt: ipchains für Kernels 2.2.x bzw. netfilter/iptables für Kernels 2.4.x.
Die Grundidee ist für beide die gleiche:
(Namen und Syntax werden hier
von ipchains verwendet, für iptables sind sie leicht unterschiedlich.)
Man kann ein Muster bekannt geben und eine dafür anzuwendende Methode, hier Target genannt. Stimmt ein Packetheader mit diesem Muster überein, wird die Target-Methode darauf angewandt. Targets können vordefinierte Aktionen sein, wie z. B.
ACCEPT
Paket wird weitergeleitet
DENY
Paket wird nicht weitergeleitet und einfach vergessen
REJECT
wie DENY, nur dass freundlicherweise eine ICMP-Nachricht an den Sender
zurück geschickt wird, damit der Sender nicht auf ein Timeout warten muss.
Über die Funktionalität eines Packet Filters hinaus führen folgende Targets:
MASQ
kann ein privates Subnetz so verstecken, dass es als eine IP-Adresse
nach außen erscheint (dies geschieht durch Austausch der Portnummern).
Da es aber nicht möglich ist, von außen eine Verbindung zu einem der dahinter
versteckten Computer aufzunehmen, können solche Konfigurationen die Sicherheit
wesentlich erhöhen.
REDIRECT
Pakete können aus der Input-Chain (oder einer selbst definierten)
an ein lokales Socket umgeleitet werden.
NAT
(nur bei iptables verfügbar) die Source-Adresse bzw. die Destinations-Adresse
eines Pakets kann gegen eine andere ausgetauscht werden.
Schließlich kann als Target eine selbstdefinierte komplexe "Chain" angegeben werden, in die man eine Menge von Regeln einbauen kann. Diese Technik kann man verwenden um vorzufiltern, wenn man z. B. für verschiedene Subnetze unterschiedliche Regeln (Rulesets) anwenden möchte. Es gibt bereits fix vorgegebene "Chains", z. B. input, output und forward.
Mit Hilfe von "Policies" kann man das Standard-Verhalten einer "Chain" festlegen, wenn keine der definierten Regeln zutrifft, also generell ablehnen (DENY) oder zulassen (ACCEPT).
Der Sicherheitsbewusste wird wohl demnach eine Deny-Policy wählen. Dabei muss man natürlich wissen, was man explizit alles erlauben muss, um einen Betrieb zu gewährleisten (siehe das oben angeführte Beispiel mit DNS, ebenso wäre z. B. zu bedenken, wenn man alles, also auch ICMP, für die Output-Chain sperrt, das Target REJECT sich genau so verhalten würde wie DENY - also wieder einmal: Vorsicht ist geboten ! ).
ipchains -A input -s 128.131.xxx.0/24 -d 128.131.xxx.123 www -p tcp -j ACCEPT
ipchains -A input -s 0/0 -d 128.131.xxx.123 www -p tcp -y -j REJECT -l
-A append (Anhängen am Ende der Kette)
-s Source Address (Absender)
-d
Destination Address (Empfänger)
-p Protokoll
-j Target
-l wenn das
Muster zutrifft, wird ein Eintrag ins Logfile geschrieben
-y heißt, nur
SYN-Pakete (dienen zum Verbindungsaufbau für TCP) werden behandelt
Bei den oben angeführten Regeln geht es darum, den Zugriff auf den Webserver des Rechners 128.131. xxx.123 zu kontrollieren. Es soll der Zugriff nur vom eigenen Subnetz aus erlaubt sein. Die zweite Zeile ist nötig, wenn die Policy für die Input-Chain nicht auf REJECT gesetzt ist, z. B.: ipchains -P input REJECT
Genauere Interpretation:
1. Zeile: Alles, was vom Subnetz 128.131.xxx.0
mit der Netzmaske 255.255.255.0 (= 24 Bits) kommt und an die Maschine 128.131.xxx.123
geht, ein TCP-Paket ist und fürs WWW-Port (80, siehe /etc/services) bestimmt
ist, wird erlaubt.
Wenn der Verkehr mit dem Muster nicht übereinstimmt, wird die nächste Zeile abgearbeitet. TCP-Verkehr mit beliebiger Absenderadresse und dem Ziel 128.131.xxx.123 auf dem HTTP-Port (80) wird schon beim Verbindungsaufbau (-y) abgeblockt und der Versuch ins Logfile geschrieben. So kann man dokumentieren, wenn jemand mit dem Web-Server von 128.131. xxx.123 Verbindung aufnehmen will, dem der Zugriff verwehrt ist.
Will man jenen Netzwerkverkehr, der einem bestimmten Muster entspricht, nur mitloggen, wird die Regel ohne Target (also ohne -j XXXX) aber mit der -l Option definiert. Das kann auch zur Verifikation und Fehlersuche sehr nützlich sein.
Dieses Beispiel soll den grundlegenden Mechanismus der Paketfilterung erläutern. Durch die Definition eigener "Chains" können sehr leistungsfähige und komplexe Filtermechanismen geschaffen werden.
Hinweise auf die Dokumentation, die Sie für einen Echtbetrieb unbedingt benötigen, finden Sie unten. Um mit den Paketfiltern sinnvoll arbeiten zu können, muss man sich doch ziemlich tief in die Materie einarbeiten, da würden "Kochrezepte" wohl nicht sehr hilfreich sein.
Zu erwähnen ist noch, dass einige Linuxdistributionen vorgefertigte Firewall-Scripts mit z. T. sehr komplexen Regeln beinhalten. Meist sind sie sehr unübersichtlich, sodass man nicht leicht Modifikationen darin vornehmen kann.
Sowohl was diese fertigen Scripts betrifft als auch nach der Erstellung seiner eigenen Filterregeln, finde ich es empfehlenswert, das Filterverhalten ausführlich zu testen, um sicher zu sein, dass das, was erlaubt ist, auch wirklich funktioniert, und - wichtig für die Sicherheit - dass auch die Restriktionen voll funktionsfähig sind.
1. ehen Sie die mitgelieferten Manualpages durch: z. B.: man ipchains oder man iptables.
2. Sehr informativ sind die dazugehörigen HOWTOs, welche im Zuge des LDP (Linux Documentation Project) verfügbar gemacht wurden.
Die Links für die TU:
für ipchains in den HOWTOs: http://gd.tuwien.ac.at/opsys/linux/LDP/HOWTO/IPCHAINS-HOWTO.html
für netfilter/iptables in Network-Administrators-Guide: http://gd.tuwien.ac.at/opsys/linux/LDP/LDP/nag2/x-087-2-firewall.future.html
Allgemeine Information zu TCP/IP:
"The Linux Networking Overview HOWTO": http://gd.tuwien.ac.at/opsys/linux/LDP/HOWTO/Networking-Overview-HOWTO.html
"A TCP/IP Tutorial": http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1180.html
Seitenanfang | ZIDline 6 - Dezember 2001 | ZID | TU Wien