In der mit diesem Beitrag beginnenden Reihe zum Thema "Firewall unter Linux" zeigen wir Ihnen von Grund auf, wie Sie eine dedizierte Firewall mit Linux aufbauen. Den Anfang macht die grundlegenden Konfiguration und Sicherung des Linux-Systems. Im zweiten Teil lesen Sie, wie Sie mit ipchains die Firewallaufsetzen. Weitere zwei Beiträge im Wochenrhythmus informieren Sie über spezielle Themen wie Masquerading oder Dial-On-Demand, die Ihrem System den letzten Schliff geben.
Die Beispiele beziehen sich auf den bewährten Kernel 2.2.x. Auf Kernel 2.4.x geht diese Reihe bewusst nur im Ausblick ein. Bedenken Sie, dass die 2.4er noch recht jung sind und noch so noch die eine oder andere Kinderkrankheit haben können. Viele der Netzwerkfunktionen wurden dort komplett neu implementiert. Gerade für eine Firewall sollten Sie jedoch bewährte Komponenten einsetzen. Da die 2.2-Reihe des Kernels noch weitergepflegt wird, sollten Sie hier für die Übergangszeit auch noch weitere Updates erhalten - wichtig für die Sicherheit Ihres Systems.
Anhand der im Kernel 2.2.x zur Verfügung stehenden Paketfilter zeigt diese Artikelreihe, wie Sie die Firewall selbst und die Server in einer DMZ bzw. Clients im Intranet schützen. Grundlagen zum Thema Firewall finden Sie in einem gesonderten Beitrag.
Hard- und Softwareauswahl
Die Auswahl der Hardware für eine Firewall ist relativ unkritisch. Allerdings hängt die Dimensionierung von CPU, Hauptspeicher und Festplattenplatz vom Einsatzzweck ab. Eine Firewall, die nur Port-Filterung durchführt, ist wesentlich anspruchsloser als eine, die zusätzlich einen Webproxy beinhaltet. Natürlich braucht eine Firewall mindestens zwei Schnittstellen, über die Netzwerkpakete ausgetauscht werden können. Hierfür ist die Auswahl groß, denn (fast) alles, das Linux als Netzwerkschnittstelle unterstützt, lässt sich verwenden. Also beispielsweise Ethernet- oder Token-Ring-Netzwerkkarten für das lokale Netzwerk und ISDN-Karten beziehungsweise Modems für WAN-Anbindungen.
Softwareseitig sollten Sie die Firewall möglichst dediziert aufbauen. Es sollen also nur die allernotwendigsten Dienste aktiv sein. Als Grundlage für diesen Artikel diente ein Red Hat Linux 6.2. Dieses System ist zwar nicht mehr das jüngste, dafür aber bekanntermaßen stabil. Das Installieren aller Updates ist hier allerdings obligatorisch. Sie stehen auf dem FTP-Server von Red Hat oder auf diversen Spiegelservern zur Verfügung. Das sollte aber nicht davor abschrecken, diese Version zu benutzen, denn vergleichbaren anderen Distributionen geht es diesbezüglich nicht besser. Red Hat bietet auch, falls Sicherheitslöcher ans Tageslicht kommen, relativ schnell neue Pakete zum Download an und veröffentlicht die entsprechenden Informationen auf einer speziellen Webseite.
Installation von Updates
Die Installation von Updates erfolgt in zwei Schritten. Zuerst speichern Sie die Pakete lokal, zum Beispiel mit Hilfe von rsync:
# Basisverzeichnis (Achtung, der Pfad auf dem RSYNC-Server kann sich unter Umständen ändern)
# Remote-Verzeichnis
BASEREMOTE="ftp.tuwien.ac.at::gds/linux/ RedHat.com/dist/linux"
# Lokales Verzeichnis
BASELOCAL="/home/install/ftp.redhat.com"
# 1. rsync-Befehl
rsync --delete -rv --size-only $BASEREMOTE/updates/6.2/en/os/i386/ $BASELOCAL/updates/6.2/i386/
# 2. rsync-Befehl
rsync --delete -rv --size-only $BASEREMOTE/updates/6.2/en/os/noarch/ $BASELOCAL/updates/6.2/noarch/
Anschließend führen Sie das Update der Pakete (ohne Kernel) durch:
find $BASELOCAL/updates/6.2/ ! -name 'kernel*.rpm' -name '*.i386.rpm' -o -name '*.noarch.rpm' | while read paket; do echo $paket; rpm -Fhv $paket; done
Wenn Sie den Kernel updaten wollen, installieren Sie zunächst das RPM. Bei SCSI-Systemen ist die initiale RAM-Disk unbedingt notwendig. Passen Sie den Eintrag in /etc/lilo.conf an und aktivieren die Änderungen mit /sbin/lilo. Weitere Informationen zum Kernel-Upgrade finden Sie in den How-tos.
Installation des Basis-Systems
Die Prämisse bei einer Firewall lautet immer: "Was nicht gebraucht wird, wird auch nicht installiert". Darunter fallen zum Beispiel das X-Window System und der C-Compiler. Hierauf muss natürlich schon zu Beginn geachtet werden. Das spätere Nachinstallieren von fehlenden Paketen ist einfacher als das Deinstallieren von überflüssigen. Bei Red Hat Linux 6.2 wird dazu entweder der Typ "Server" oder "benutzerdefiniert" ausgewählt. Der zweite Typ ist jedoch eher für Experten gedacht, da hier die einzelnen Pakete separat zu selektieren sind.
Ausgehend von diesem Minimalsystem sollten nach erfolgter Installation nur wenige lokale Dienste und überhaupt keine Netzwerkdienste aktiv sein.
Deaktivieren unnötiger Dienste
Sehr einfach lassen sich Dienste unter Red Hat durch das Kommando chkconfig dienst off deaktivieren. "dienst" ist hierbei der zu deaktivierende Service, wie zum Beispiel "httpd" für den Apache Webserver.
Zu den Diensten, die Sie unbedingt deaktivieren sollten, gehören insbesondere der unsichere Super-Daemon "inetd" (und damit alle Unterdienste, für die er zuständig ist, wie etwa "finger", "telnet", "ftp" etc.). Auch den "portmapper", der für RPC (etwa für NFS) zuständige ist, sollten Sie deaktivieren. Ein solches abgespecktes System ist trotzdem in der Lage, nach einer Netzwerkkonfiguration Pakete weiterzuleiten und damit auch zu filtern.
Falls Sie die Firewall nicht nur direkt an der Konsole administrieren wollen, ist die SSH (Secure Shell) nützlich. Fertige Binärpakete finden Sie hier. Weil telnet die Authentifizierungsdaten im Klartext überträgt, ist dieser Dienst absolut tabu! Vergessen Sie diesen Veteranen der Remote-Administration schnell wieder.
Wichtige Proxies
Zur Basisinstallation gehören gegebenenfalls noch Proxies. Hier eine Auswahl für die wichtigsten Internet-Dienste:
Dienst | Applikation |
|---|---|
| |
(Caching) Domain Name System | |
HTTP, HTTPS, FTP-over-HTTP | |
HTTP, inkl. Junk-Filter | |
FTP |
Weitere Proxies findet man am schnellstens durch eine Suche bei Freshmeat. Die Proxies und die eventuell zusätzlichen Pakete zur Auflösung der Abhängigkeiten sind natürlich separat zu installieren und konfigurieren.
Falls die Pakete nicht in der Distribution enthalten sind, empfiehlt sich die Neukompilierung. Beachten Sie hier allerdings, dass auf der Firewall aus Sicherheitsgründen kein Compiler installiert sein darf. Erledigen Sie deshalb diese Schritte auf einem ähnlichen Testsystem. Dann übertragen Sie nur die Binärdateien (vorzugsweise als RPM oder bei Debian als DEB) auf die Firewall mit Diskette, CD-ROM oder SCP (Secure Copy).
Generell sollten Sie versuchen, benötigte Proxy- und Netzwerkdienste auf der Firewall immer fest an IPv4-Adressen zu binden: Somit können Unberechtigte diese bei Fehlkonfiguration nicht nutzen. Wenn der Proxy nicht selbst als Serverdienst laufen kann, so ist unbedingt "xinetd" dem "inetd" vorzuziehen, da hier entsprechende Konfigurationsmöglichkeiten (Option "bind") bestehen.
Konfiguration und Verbindungen
Bevor Sie den ersten Firewall-Regelsatz erstellen können, muss die grundlegende Netzwerkfunktionalität gewährleistet sein. Dazu gibt es verschiedene einfache Werkzeuge, die in der Linux-Distribution enthalten jedoch eventuell noch nicht installiert sind.
Mit ifconfig überprüfen Sie die Konfiguration der Netzwerkadressen und mit route -n die Routingtabelle. Die Option n deaktiviert dabei die Zuordnung von IPv4-Adressen oder -Netzwerken zu Namen. Dies vermeidet Verzögerungen bei der Anzeige der Einträge, falls DNS noch nicht eingerichtet oder voll funktionsfähig ist.
Mit dem Tool netstat lassen sich die verschiedensten Informationen über die IPv4-Schnittstelle anzeigen. Der Befehl netstat -n --ip gibt aktuell bestehende Verbindungen aus. Netzwerkdienste, die auf eingehende Verbindungen warten und deshalb sich im sogenannten LISTEN-Status befinden, zeigt netstat -nlptu an. Dabei stehen die Option "-l" für Ports im LISTEN-Zustand, "-p" zeigt (meist) die zugehörigen Dienste mit Prozess-ID. "-t" und "-u" spezifizieren jeweils TCP und UDP für die Anzeige.
Weitere Tools zur Netzwerkkontrolle
Um offene oder aktuell benutzte Ports einem Prozess zuzuordnen, nutzen Sie das Werkzeug lsof (list open files). Mit dem Befehl lsof -i :53 sehen Sie beispielsweise alle Prozesse, die Port 53 benutzen.
Weitere Information liefert auch die Liste aller sogenannter "well-known" Ports: STD2 beziehungsweise RFC 1700. Zudem gibt es eine Suchmaschine für Ports.
Hilfreich für die Fehlersuche ist auch tcpdump. Das Tool zeigt alle Pakete an, die an den Schnittstellen eintreffen. Die Paketbeschreibungssprache ist zwar nicht sehr komfortabel, dafür aber ist das Programm über die Kommandozeile und damit auch von der Ferne über SSH oder eine serielle Leitung zu bedienen. Wichtige Schalter sind "-n" zum Deaktivieren der Namensauflösung und "-i interface" zur Auswahl einer speziellen Netzwerkschnittstelle. Das Tool gibt es übrigens auch für Windows, um etwa festzustellen, ob Pakete auch an diesen Clients ankommen. Wer lieber graphische Werkzeuge benutzen will, für den ist ethereal das Mittel der Wahl. Ethereal ist für Windows und Linux verfügbar.
Grundschutz durch den Linux-Kernel
Neben der im folgenden beschriebenen Paketfilterung sind im Linux-Kernel Möglichkeiten zum Grundschutz schon eingebaut und sollten auch aktiviert werden. Zu finden sind diese im proc-Dateisystem. Sie lassen sich normalerweise mit dem Befehl sysctl kontrollieren. Eine Beschreibung der wichtigsten Parameter von sysctl finden Sie auf der nächsten Seite. Vollständige Beschreibungen aller vorhandenen Schalter stehen in den Kernel-Quellen unter documentation/proc.txt und documentation/networking/ip-sysctl.txt zur Verfügung.
Ein Beispiel für das Lesen einer Variable ist der Befehl
sysctl net.ipv4.icmp_destunreach_rate
Gesetzt wird ein Wert mit dem Befehl
sysctl -w net.ipv4.icmp_destunreach_rate=100
Besonders hervorzuheben ist der Eintrag /proc/sys/net/ipv4/ip_local_port_range. Dieser gibt an, aus welchem Bereich lokale Ports für Verbindungen stammen dürfen. Der Bereich ist im Kernel (net/ipv4/tcp_ipv4.c) standardmäßig auf 1024-4999 festgelegt, lässt sich aber während des Betriebs verändern. Aus Sicherheitsgründen sollten Sie den Bereich unbedingt auf 32768-60999 setzten. Denn dieser Portbereich wird sehr selten von einem Dienst statisch benutzt. Zudem stehen damit auch mehr Ports für gleichzeitige Verbindungen zur Verfügung, was für einen lokalen installierten Webcache von Vorteil sein kann. Der Befehl für die Änderung lautet
sysctl -w net.ipv4.ip_local_port_range="32768 60999"
Zusammen mit dem für IP-Maskierung festgelegten Portbereich von 61000-65095 lässt sich der Portbereich für eingehende Antwortpakete später in den Paketfilterregeln genau festlegen. Die Ports zur IP-Maskierung sind nur durch Patchen des Quellcodes (include/net/ip_masq) und Neukompilieren des Kernels änderbar.
Ausnahmen sind allerdings die Clients der r-Dienste (rlogin, rcmd, rexec) und ssh, falls das SUID-Bit gesetzt ist oder diese von "root" benutzt werden. Denn in diesem Fall werden Ports zwischen 512 und 1023 für abgehende Verbindungen benutzt. Grund dafür ist die Authentifizierungsmethode der r-Dienste auf Vertrauensbasis mit der Annahme, dass Ports zwischen 1 und 1023 nur von "root" benutzt werden können. Diese Methode sollte jedoch nur in abgeschotteten Netzwerken zum Einsatz kommen, deren teilnehmende Server ganz sicher unter der Kontrolle des Administrators sind.
Grundschutz im Detail I
In dieser Tabelle finden Sie die wichtigsten Parameter für das Kommando sysctl. Die Tabelle führt Parameter auf, die alle Schnittstellen betreffen.
Eintrag in "/proc/sys/" | Wofür | Hilft gegen |
|---|---|---|
| ||
net/ipv4/icmp_destunreach_rate net/ipv4/icmp_echoreply_rate net/ipv4/icmp_paramprob_rate net/ipv4/icmp_timeexceed_rate | Limitieren der Rate an auszusendenden speziellen ICMP-Paketen, je höher der Wert, desto niedriger die Rate | DoS-Attacken |
net/ipv4/tcp_syncookies | Aktivieren der TCP-Syncookie-Unterstützung | SYN-Flooding |
net/ipv4/icmp_echo_ignore_ broadcasts | Abschalten von ICMP echo-reply auf Broadcast-Adressen | Scanning |
net/ipv4/icmp_echo_ignore_all | Abschalten von ICMP echo-reply generell | Scanning |
net/ipv4/icmp_ignore_bogus_ error_responses | Protokollieren von fehlerhaften ICMP-Paketen | Attacken |
net/ipv4/ip_always_defrag | Defragmentieren von allen eingehenden IPv4-Paketen | Attacken |
net/ipv4/ip_forward | Globales Deaktivieren der Weiterleitung (routing) von IPv4-Paketen | unerwünschtes Routing |
net/ipv4/ip_local_port_range | Festlegen des Quellportbereichs bei ausgehenden Verbindungen | Filterprobleme beim statischen Portfilter |
Grundschutz im Detail II
In dieser Tabelle finden Sie die wichtigsten Parameter für das Kommando sysctl, die für jede Schnittstelle dediziert angegeben werden müssen.
Eintrag in "/proc/sys/" | Wofür | Hilft gegen |
|---|---|---|
Der * ist jeweils durch den Namen der Schnttstelle zu ersetzen, also beispielsweise eth0.ö | ||
net/ipv4/conf/*/accept_source_ route | Verwerfen von IPv4-Paketen mit Source-Route-Option | Attacken |
net/ipv4/conf/*/secure_redirects | Erlauben von ICMP-redirect, die vom Standard-Gateway eintreffen | Attacken |
net/ipv4/conf/*/accept_redirects | Verwerfen von ICMP-redirect Paketen | Attacken |
net/ipv4/conf/*/log_martians | Protokollieren von Paketen mit unmöglichen IP-Adressen | Scanning |
net/ipv4/conf/*/forwarding | Deaktivieren von IP-forwarding per Interface (Entscheidung wird beim Paketeingang getroffen!) | unerwünschtes Routing |
net/ipv4/conf/*/rp_filter | Überprüfen des Absenders anhand der Routing-Tabelle | IP-Spoofing |
Quellport für ausgehende Verbindungen
Die folgende Tabelle zeigt zusammenfassend die lokal benutzten Ports bei ausgehenden Verbindungen. Eingehende Pakete an der externen Schnittstelle, die andere lokale Zielports ansprechen, sollten verworfen werden. Damit erledigt sich das Problem, diverse Ports ab 1024 dediziert zu sperren. Beispiele hierfür wären Webcache (3128, 8080 oder 8000), X11 (6000-6063) und ISDN-Kontrolldienste (6105, 6106).
Art der Verbindung | Quellportbereich |
|---|---|
| |
vom Firewall ausgehende Verbindungen mit r-Clients oder ssh mit gesetztem SUID-Bit bzw. von "root" aufgerufen | 512-1023 |
vom Firewall ausgehend (Standard) | 1024-4999 |
vom Firewall ausgehend (empfohlen, modifiziert via sysctl) | 32768-60999 |
vom Firewall maskiert ausgehend | 61000-65095 |
Kontrolle der Paketweiterleitung
Auch die Schalter für das Routing (/proc/sys/net/ipv4/*Schnittstelle*/forwarding) sind bei der Konfiguration einer Firewall zu berücksichtigen. Linux benutzt diese Schalter, um beim Eingang des Pakets zu entscheiden, ob es an eine andere Schnittstelle gehen darf. Dies gilt auch für Pakete, die demaskiert werden müssen. Steht der Wert für eine Schnittstelle auf 0, so bleibt das Paket in der Firewall. Damit lässt sich erreichen, dass Pakete von intern nicht nach außen geroutet werden, auch wenn die Firewall das Standard-Gateway ist.
Der aus Kompatibilitätsgründen zu Kernel 2.0.x noch vorhandene globale Schalter /proc/sys/net/ipv4/ip_forward ist mit Vorsicht zu genießen. Dieser Schalter verändert automatisch alle schnittstellenspezifischen Schalter für das Forwarding. Dies kann eine vorhandene Feinkonfiguration zunichte machen. Allerdings benutzen die meisten Netzwerkkonfigurationsskripts nur diesen globalen Schalter, so dass Sie unter Umständen diese Skripts bearbeiten müssen.
Zum Schluss sollten Sie noch den für das Defragmentieren von IPv4-Paketen zuständigen Schalter aktivieren:
sysctl -w net.ipv4.ip_always_defrag=1
Sonst können eventuell die Filterlisten der Firewall nicht immer greifen. Außerdem verhindert diese Einstellung Angriffe mit fragmentierten Paketen. Für die IP-Maskierung ist dies zudem obligatorisch, denn sonst funktioniert der Mechanismus nicht zuverlässig.
Fazit
Mit den in diesem Teil vorgestellten Schritten haben Sie das grundsätzliche System aufgebaut und soweit abgesichert, dass der Einsatz als Firewall Sinn macht. In den folgenden drei Teilen der Serie stellen wir Ihnen unter anderem vor wie Sie
mittels ipchains Filterregeln aufstellen.
interne DNS-Auflösung aktivieren.
gezielt Dienste für den Zugriff von innen und außen freischalten.
Dienste wie FTP oder HTTP in der DMZ einrichten.
das Netz über IP-Masquerading abschotten.
Angriffe auf Ihr Netzwerk erkennen.
Für die folgenden Beiträge stellen wir Ihnen in Zusammenarbeit mit dem Autor Dr. Peter Bieringer auch seine detaillierten und gut kommentierten Scripte zur Verfügung. Diese müssen Sie nur noch an die lokalen Gegebenheiten in Ihrem Netz anpassen. mha)