Firewalling unter GNU/Linux
Administration :
Firewalling : Übersicht
25-Jan-2003/09-Jan-07
Übersicht
Mit der Kommerzialisierung des Internet ab Mitte der 90er Jahre nahm
auch die Menge der Mißbrauchsversuche zu; zu den Folgen dieser
Entwicklung gehört beispielsweise neben der »Erfindung« von Spam
(Sanford »Spamford« Wallace, Firma Cyber Promotion, um 1994) die
zunehmende Bedrohung von Subnetzen durch Viren, Würmer, Trojaner und
Cracker. Etwa ab Mitte der 90er Jahre werden daher zunehmend
Firewalls eingesetzt, die den Zugang zu Subnetzen aus dem Internet
und umgekehrt einschränken. Spätestens seit Ende der 90er Jahre gehört
eine Firewall schließlich zwingend zu jedem mit dem Internet verbundenen
Netzwerk.
Seit Jahren liefern sich Blackhats und Skript-Kiddies
einen Wettlauf mit Sicherheitsspezialisten und Netzwerkadministratoren;
ein beiderseitiges Hochrüsten ist zu beobachten, das zunehmend
unproduktiv Ressourcen verschlingt, aber mittlerweile leider
unumgänglich geworden ist. Ein verantwortungsbewusster
Netzwerkadministrator muss heute sein Netzwerk durch Schutzmaßnahmen
absichern!
Zur Netzwerkabsicherung gibt es verschiedene Ansätze; neben
dezentralisierten lokalen Firewalls (sog. Personal Firewalls)
auf den Netzwerk-Hosts selbst sind zentrale Firewalls in der Nähe
des Gateways zwischen LAN und Internet am weitesten verbreitet; letztere
regeln entsprechend den Sicherheitsrichtlinien des
Netzwerkbetreibers (Security Policy) mehr oder minder strikt,
welche Datenströme zwischen Internet und LAN in welcher Form fließen
dürfen. Im Rahmen der Sicherheitsrichtlinien bildet die Firewall
dabei allerdings immer nur eine Komponente eines ebenfalls mehr oder
minder umfangreichen Maßnahmenkatalogs, die zu einer sicheren
Netztopologie führen sollen.
Die grundlegendste und einfachste Form der Firewall ist ein
Paketfilter; dieser kann IP-Pakete nach bestimmten Regeln
annehmen (ACCEPT), verarbeiten (z.B. FORWARD) oder verwerfen (DROP,
REJECT, DENY).
Zum Betreiben einer paketfilternden Firewall unter GNU/Linux gibt es
verschiedene Ansätze, die von dem eingesetzten
Linux-Kernel abhängen:
- Iptables [Netfilter] (ab Linux-Kernel
2.4.x)
- Ipchains (ab Linux-Kernel 2.2.x)
- Ipfwadm (ab Linux-Kernel 2.0.x)
Die Kernel haben eine gewisse Abwärtskompatibilität gewahrt, so dass
bei einem Wechsel des Kernels keine sofortige Migration zwingend
notwendig ist, für das Aufsetzen neuer Firewalls gibt es jedoch keinen
Grund, noch Ipfwadm oder Ipchains einzusetzen.
Topologien
Für den Aufbau komplexer Firewalls sind eine Reihe von Topologien zu
unterscheiden, die sich erheblich im zu betreibenden Aufwand, aber auch
im Grad der gebotenen Sicherheit unterscheiden.
Die wohl einfachste Variante ist eine paketfilternde Firewall, die
direkt auf dem Gateway läuft und ein dahinter liegendes LAN
schützen soll; meist wird man auf diesem Host zusätzlich Network
Adress Translation (NAT) oder
Masquerading einrichten. Entsprechende Funktionalitäten bieten
heutzutage nahezu alle Breitband-Router, natürlich lässt sich eine
solche Firewall auch in wenigen Stunden unter GNU/Linux aufsetzen. Eine
solche Konfiguration ist zwar einfach aufzubauen und vergleichsweise
unproblematisch zu warten, der Schutz ist jedoch minimal: Ist das
Gateway kompromittiert, werden die Rechner des LANs bestenfalls noch
durch persönliche Firewalls geschützt. Für kleinste private Netzwerke
mag eine solche Konfiguration heute noch vertretbar sein, für größere
Unternehmensnetzerke ist diese »Topologie« jedoch schleichtweg
inakzeptabel.
Etwas mehr Schutz bieten Single Homed Bastion Hosts, die
den Aufbau einer demilitarisierten Zone (engl. Demilitarized
Zone, DMZ; gelegentlich auch als Grenznetz bezeichnet) ermöglichen; in dieser DMZ können exponierte Hosts – i.d.R.
externer DNS- sowie Proxy-, Mail- und Webserver –
aufgestellt werden; in der Werbung für Netzwerkprodukte werden DMZs und
Exposed Hosts häufig gleichgesetzt, was jedoch falsch ist: Die
DMZ bietet einen Gewinn an Sicherheit, während der Exposed Host
ein Sicherheitsrisiko darstellt.
Die Single Homed Bastion Hosts setzen zwei Firewalls voraus,
eine vor und eine hinter der DMZ, die jeweils mit einer Netzwerkkarte
versehen sind. Grundsätzlich ist jeder direkte Datenverkehr vom Internet
in das LAN und umgekehrt ebenso verboten wie der direkte Datenaustausch
zwischen den beiden Firewalls. Wird die äußere Firewall kompromittiert,
muss der Angreifer noch die hinter der DMZ liegende zweite Firewall
»knacken«.
Um die Dienste der in der DMZ lokalisierten Rechner nutzen zu können,
muss auf der Firewall Port Mapping eingerichtet werden; dabei
werden bestimmte auf der Firewall eingehenden Anfragen auf einen
bestimmten Port an einen bestimmten Rechner im LAN weitergereicht (Port
Forwarding). So können beispielsweise alle auf der äußeren Firewall
eingehenden Pakete auf dem Port 80 an den Webserver in der DMZ
weitergeleitet werden.
Deutlich mehr Schutzleistung bieten Double Homed Bastion Hosts;
die beiden Bastion Hosts vor und hinter der DMZ sind jeweils mit
zwei Netzwerkkarten ausgestattet, was die Unterbrechung jeder
physikalischen Verbindung zwischen den beiden Firewalls ermöglicht. Ein
Datenverkehr ist nun nur noch über logische Routen möglich, also
entsprechend relayende Server oder Proxies. Beispielsweise operiert ein
in der DMZ lokalisierter Mail-Server nur noch als SMTP-Relay, der alle
E-Mails an einen internen Mailserver weiterreicht; auf dem Rechner in
der DMZ sind weder Postfächer lokalisiert, noch werden Passwörter in die
DMZ transportiert.
Hat man schließlich eine möglichst sichere Firewall-Topologie am
Laufen, sollte man sich Gedanken über ein Intrusion Detection System
(IDS) sowie ein Intrusion Response System (IRS) machen; geeignete
Tools sind beispielsweise
Snort oder
Portsentry.
Abschließend sei noch auf ein prinzipielles Problem sicherer
Netzwerktopologien hingewiesen: Die Internet-Anbindung dürfte in den
meisten Netzwerken nicht den einzigen Zugang zum lokalen Netz
darstellen. Rechner im LAN mögen mit ISDN-Karten ausgestattet sein, über
Modems verfügen, Netzwerkbuchen ermöglichen das Einstöpseln von
Notebooks und lokale Rechner verfügen über Disketten- und CD-Laufwerke
sowie zahllose Schnittstellen für USB-Sticks oder serielle Geräte. Die
sicherste Internet-Firewall ist eingeschränkt nützlich, wenn Nutzer im
LAN die gebotene Sicherheit durch Modemverbindungen oder Notebooks
jederzeit unterlaufen können. Darum sei hier noch einmal darauf
hingewiesen: Jede Firewall bildet nur eine Teilkomponente im Rahmen
zahlreicher Sicherheitsmaßnahmen, die in den Sicherheitsrichtlinien der
jeweiligen Organisation schriftlich fixiert sein sollten.
Frontends
Wer eine Firewall unter GNU/Linux einrichten möchte, muss sich
entscheiden, ob er von Anfang an Ipchains- oder Iptables-Regeln lernen möchte, oder
– zumindest für den Einsteig – lieber ein Frontend einsetzen
möchte. Einige dieser Frontends unterstützen den Benutzer beim
Formulieren sinnvoller und syntaktisch korrekter Firewall-Regeln, was
den Einstieg natürlich erleichtern kann.
Mittelfristig bewahrt jedoch
keins dieser Tools davor, sich mit Ipchains oder Iptables
auseinanderzusetzen, weil man sonst weder die Firewall den individuellen
Bedürfnissen anpassen kann, noch sinnvoll die
Logfiles
auswerten kann.
Frontends zur Administration und Konfiguration von
GNU/Linux-basierten Firewalls:
(a) Kommandozeilen-Tools:
(b) GUI-Tools:
- Knetfilter (KDE)
- Lokkit und Gnome-Lokkit
- Firestarter
- Guarddog
- Guidedog
- ...
Die GUI-basierten Tools setzen einen installierten X-Server mit KDE
oder GNOME voraus; nichts davon wird man auf seiner Firewall haben
wollen, daher kann man diese Tools m.E. nur sinnvoll einsetzen, wenn man
zur Konfiguration und zum Testen einen identisch konfigurierten Rechner
einsetzt. Die GUI-Tools simulieren leider keine Test-Umgebung, sondern
werden im Live-Betrieb aktiv, d.h. sie laden benötige Kernel-Module und
verändern das Routing etc. So schön Tools wie Guidedog oder Knetfilter
auch zum Herumspielen sein mögen, so wenig erschließt sich mir ihr
Nutzen in der Praxis. Ich lasse mich aber gerne über sinnvolle
Einsatzszenaiern aufklären...
Sinnvoll erscheinen mir allenfalls die Ansätze von Lokkit, Jay's
Iptables Firewall und der Shoreline
Firewall (Shorewall); die benötigen kein GUI und können auf
einer echten Firewall genutzt werden, ohne sich zahllose potenzielle
Sicherheitslücken das X-Window-Systems oder von KDE ins Haus zu holen.
Lokkit eignet sich nur für einfachste Anforderungen, Jay's Iptables
Firewall ist leider derzeit bis zur völligen Unbrauchbarkeit verbuggt
(Stand: November 2004), einzig
Shorewall funktioniert so wie erwartet: zuverlässig und
kalkulierbar.
Wer seinen lokalen Desktop-Rechner in einem bereits gesichterten LAN
noch etwas besser absichern will, mag in Tools wie Knetfilter ein
einfach zu bedienendes Hilfsmittel finden, auf einer Firewall im
produktiven Einsatz hat KDE oder GNOME jedoch m.E. nichts zu suchen.
Tools zum Testen
Welche Ports sind geöffnet?
- lsof -i
- netstat -tupan
- rpcinfo -p
Merke: Ob eine Firewall funktioniert, kann man nicht vom lokalen Netz
aus testen!
Einige Anbieter stellen im Netz einfache Portscanner zur Verfügung;
ein populäres Beispiel ist Shields up! von grc.com, das zumindest
einen groben Eindruck der Firewall von »außen« vermittelt. Ein
ähnliches, aber etwas ausführlicheres Tool stellt der Alexander Khine
EDV-Service zur Verfügung:
Dieser externe Port Scanner sucht nach offenen Ports aus einer
Datenbank von khine.de, die derzeit 3.154 TCP-Ports umfasst (Stand:
Dezember 2004). Es ist naheliegend, dass auch dieser kostenlose Dienst
nur einen ersten Eindruck von der Funktionalität der Firewall vermitteln
kann.
Für detailliertere Analysen müssen von außerhalb Tools eingesetzt werden wie
Wer eine Firewall wirklich sorgfältig testen will, wird sich die Fähigkeiten
eines Crackers aneignen – oder eben auf die Hilfe eines kommerziellen
Dienstleisters zurückgreifen müssen.
Einzelne Dienste
Quelle:
www.little-idiot.de/firewall/zusammen-119.html.
NTP (Uhrzeit)
NTP ist ein Dienst auf Basis von UDP. NTP-Server benutzen Port 123, um
untereinander und mit NTP-Clients zu kommunizieren. NTP-Clients benutzen
beliebige Portnummern über 1023.
Regel Richtung Protokoll Quellport Zielport
1 ein UDP >1023 123
2 aus UDP 123 >1023
3 aus UDP >1023 123
4 ein UDP 123 >1023
5 ein UDP 123 123
6 aus UDP 123 123
Anmerkungen zu den Regeln:
1: Eingehende Anfrage, Client an Server
2: Antwort auf eingehende UDP-Anfrage, Server an Client
3: Ausgehende Anfrage, Client an Server
4: Antwort auf ausgehende UDP-Anfrage, Server an Client
5: Anfrage oder Antwort zwischen zwei Servern
6: Anfrage oder Antwort zwischen zwei Servern
FINGER (Information)
FINGER ist ein Dienst auf Basis von TCP. Server verwenden Port 79,
Clients verwenden Portnummern über 1023.
Regel Richtung Protokoll Quellport Zielport Ergänzungen
1 ein TCP >1023 79 SYN/ACK
2 aus TCP 79 >1023 ---/ACK
3 aus TCP >1023 79 SYN/ACK
4 ein TCP 79 >1023 ---/ACK
Anmerkungen zu den Regeln:
1: Eingehende Anfrage, Client an Server. ACK gesetzt, außer im ersten
Paket
2: Ausgehende Antwort, Server an Client. ACK gesetzt
3: Ausgehende Anfrage, Client an Server. ACK gesetzt, außer im ersten
Paket
4: Eingehende Antwort, Server an Client. ACK gesetzt
WHOIS (Information)
WHOIS basiert auf TCP. Server benutzen Port 43 Clients benutzen beliebige
Portnummern über 1023.
Regel Richtung Protokoll Quellport Zielport Kommentar
1 aus TCP >1023 43 SYN/ACK
2 ein TCP 43 >1023 ---/ACK
Anmerkungen zu den Regeln:
1: Ausgehende Anfrage, Client an Server. ACK gesetzt, außer im ersten
Paket
2: Eingehende Antwort, Server an Client. ACK gesetzt
X11 (X-Windows)
X11 arbeitet mit TCP und benutzt Port 6000 für den ersten Server auf
einer Maschine.
Regel Richtung Protokoll Quellport Zielport Ergänzungen
1 ein TCP >1023 6000n SYN/ACK
2 aus TCP 6000n >1023 ---/ACK
3 aus TCP >1023 6000n SYN/ACK
4 ein TCP 6000n >1023 ---/ACK
Anmerkungen zu den Regeln:
1: Eingehende X11-Verbindung zum n-ten Server, Client an Server. ACK
gesetzt, außer im ersten Paket
2: Eingehende X11-Verbindung zum n-ten Server, Server an Client. ACK
gesetzt
3: Ausgehende X11-Verbindung zum n-ten Server, Client an Server. ACK
gesetzt, außer im ersten Paket
4: Ausgehende X11-Verbindung zum n-ten Server, Server an Client. ACK
gesetzt
LPR (Printer)
LPR basiert auf TCP. Server benutzen Port 515 Clients benutzen
Portnummern unter 1023.
Regel Richtung Protokoll Quellport Zielport Ergänzungen
1 ein TCP <1023 515 SYN/ACK
2 aus TCP 515 <1023 ---/ACK
3 aus TCP <1023 515 SYN/ACK
4 ein TCP 515 <1023 ---/ACK
Anmerkungen zu den Regeln:
1: Eingehendes LPR, Client an Server. ACK gesetzt, außer im ersten Paket
2: Eingehendes LPR, Server an Client. ACK gesetzt
3: Ausgehendes LPR, Client an Server. ACK gesetzt, außer im ersten Paket
4: Ausgehendes LPR, Server an Client. ACK gesetzt
Netmeeting
Microsoft Netmeeting ist ein komplexes
Protokoll, welches sich vielerlei Ports und Protokolle bedient:
PORT TCP/UDP STATIC/DYNAMIC PROTOCOL NETMEETING
389 TCP statisch LDAP Internet Locator Server (ILS)
522 TCP statisch ULP User Location Service
1503 TCP statisch imtc-mcs T.120
1720 TCP statisch h323hostcall H.323 Anruf
1731 TCP statisch msiccp Audio Anruf
1024+ TCP dynamisch H.245 H.323 Anrufkontrolle
1024+ UDP dynamisch RTP/RTCP H.323 streaming (RTP)
Die Probleme mit Netmmeting sind ungeheuer groß. Im Kapitel
Was Hersteller kommerzieller
Firewalls verschweigen werden die Probleme genauer beleuchtet.
SQL
Aufgrund der Komplexität und der Wichtigkeit des Schutzes der Inhalte von
Datenbanken habe ich diesen nun ein eigenes Kapitel
Sicherung von SQL-Datenbanken gewidmet.
Für ORACLE im "dedicated" Modus reicht es, Port 1521 freizuschalten. Für
ORACLE im "multi threaded" Modus müssen darüber hinaus auch alle Ports >
1024 freigeschaltet werden. Für MySQL muß der Port 3333 freigegeben
werden, ältere Versionen von MySQL (< 3.20) benutzen Port 3306. Da
MySQL keinen "dedicated" Modus besitzt, ist es hier immer notwendig,
alle Ports > 1024 freizuschalten.
Regel Richtung Protokoll Quellport Zielport Ergänzungen
1 ein TCP >1023 1521 SYN/ACK
2 aus TCP 1521 >1023 ---/ACK
3 aus TCP >1023 1521 SYN/ACK
4 ein TCP 1521 >1023 ---/ACK
Anmerkungen zu den Regeln:
1: Eingehende Verbindung, Client an Server. ACK gesetzt, außer im ersten
Paket
2: Eingehende Verbindung, Server an Client. ACK gesetzt
3: Ausgehende Verbindung, Client an Server. ACK gesetzt, außer im ersten
Paket
4: Ausgehende Verbindung, Server an Client. ACK gesetzt
Shorewall
Date: Wed, 16 Jul 2003 09:26:50 -0600
To: shorewall-users@lists.shorewall.net
From: "Rodolfo J. Paiz"
Subject: [Shorewall-users] HOWTO: Temporary dynamic blocking with Shorewall
and Portsentry
www.shorewall.net/pub/shorewall/contrib/PortsentryHOWTO.txt.
Literatur
Linux Security Box. Firewalls und Intrusion-Detection-Systeme für
Linux-Server
von Ralf Spenneberg und Robert Ziegler
Broschiert - Markt+Technik
Erscheinungsdatum: 15. Dezember 2002
ISBN: 3827264987
(nicht mehr lieferbar bei Amazon.de)
Kurzbeschreibung: Die Sicherheit eines vernetzten Einzelsystems oder
Netzwerks zu gewährleisten ist ein kontinuierlicher Lernprozess zwischen
der Abwehr erfolgloser und der Erkennung erfolgreicher Angriffe. Nur
wenn es Ihnen gelingt, Einbrüche in Ihr System rechtzeitig zu entdecken,
zu analysieren und aus den Ergebnissen zu lernen, werden Sie Ihre
Abwehrmaßnahmen entsprechend optimieren können. Firewalls zur Prävention
und Intrusion Detection-Systeme (IDS) zur Erkennung und Analyse von
Angriffen sind die tragenden Konzepte, auf denen Ihre individuelle
Sicherheitsstrategie in der Praxis beruhen wird. Die Linux Security Box
zeigt Ihnen, wie Sie Firewalls und IDS einsetzen, um Ihrem System und
seinen Daten und Nutzern dauerhaft ein höchstmögliches Maß an Sicherheit
zu bieten. Die beiden Bücher widmen sich jeweils einem der Konzepte: Mit
der zweiten Auflage des Bestsellers "Linux Firewalls" von Robert Ziegler
lernen Sie, wie Sie mit iptables eine Paketfilter-Firewall aufbauen und
einsetzen. In "Intrusion Detection für Linux-Server" zeigt Ihnen Ralf
Spenneberg, wie Sie mit Open Source-Tools ein hoch effektives IDS
erstellen und zur Optimierung Ihrer Sicherheitsstrategie einsetzen.
Beide Bücher arbeiten weitestgehend mit den seit Kernel 2.4 in jeder
Linux-Distribution verfügbaren Bordmitteln. Zusätzlich benötigte Tools
liegen auf CD bei.
Netmarks
Debianforum.de: Firewallscripts,
www.debianforum.de/forum/viewtopic.php?t=3419.
Anmerkungen
| 
Kefk Network :
GNU/Linux |
About |
Wiki.
Firewalling:
EUR
49,90
