Firewalling unter Linux

Inhalt:

1.1 Was ist eigentlich eine Firewall ?
1.2 Warum wird eine Firewall benötigt ;
1.3 Aufgaben einer Firewall

2.1 Mögliche Angriffe aus einem anderen Netz
2.1.1 "Source-routed-traffic" - Angriff
2.1.2 "ICMP redirects" und "redirect bombs"
2.1.3 "denial of service" - Angriffe mit ICMP-Paketen
2.1.4 Normale "denial of service" - Angriffe
2.2 Bekannte und häufig praktizierte Angriffe
2.2.1 SMURF-Attacken
2.2.2 SMTP Session Hijacking
2.2.3 Exploiting Bugs in Applications
2.2.4 Spoofing
2.3 Meldung von Angriffen

3.1 Die Firewall im Linux-Kern - Der Paketfilter
3.2 Application-Level Gateways

4.1 ipchains
4.2 Die Befehle und Optionen des Programms ipchains
4.3 Die Formulierung der Regeln
4.4 Was passiert im Kernel ?
4.5 Praktische Beispiele
4.5.1 Erste Konfiguration
4.5.2 Eine "Dial-Up-Firewall"
4.5.3 Konfiguration für Web-Zugriffe
4.6 Was beim Masquerading beachtet werden muss
4.7 Benutzerdefinierte Regellisten
4.7.1 Eine andere "Dial-Up-Firewall"
4.8 Aktives FTP und Masquerading
4.9 Transparenter Proxy
4.10 Die log Regel
4.11 Das ToS-Feld
4.12 Mit Port Forwarding Arbeit verteilen
4.13 Abwehr bestimmter Angriffe
4.13.1 ICMP
4.13.2 Verbindungspakete
4.14 Das Testen der Firewall

5. Quellen

6. GNU General Public License



Dieses Dokument darf nur gemäß der "GNU General Public License" (GPL Software-Lizenz, siehe 6.) verbreitet werden !
Copyright (C) 2000 Samuel Stähle (Autor)

This document is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License.
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License (chapter 6.) for more details. You should have received a copy of the GNU General Public License along with this document; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

document version: 1.4

 

1.1 Was ist eigentlich eine Firewall ?

Das Wort "Firewall" stammt aus der englischen Sprache und bedeutet "Feuerwand". Diese "Feuerwand" hat eigentlich die Aufgabe ein bestimmtes Gebiet vor dem Übergreifen von Feuer zu schützen.

In der Informatik wird Firewall als Bezeichnung für einen Computer benutzt, der die Schnittstelle zwischen Computernetzen darstellt, und gleichzeitig bestimmte Bereiche der Computernetze vor Angriffen und/oder unerwünschten Zugriffen schützt.

Es kann sich bei einer Firewall auch um eine ganze Gruppe von Computern handeln, von denen jeder einen bestimmten Bereich des Netzes bearbeitet.

 

 

1.2 Warum wird eine Firewall benötigt ?

Die Zeiten, in denen die einzige Bedrohung für Computer von Viren ausging, welche mit herkömmlichen Datenträgern wie Disketten oder CD-ROMs übertragen wurden, sind vorbei.

Durch die zunehmende Vernetzung von Firmen, Privathaushalten, Schulen, anderen öffentlichen Einrichtungen, und deren Anbindung an das globale Internet, müssen diese "lokalen und kleinen" Netze (sogenannte LANs, Local Area Networks) vor Angriffen und Viren, zum Beispiel aus dem Internet, geschützt werden. Doch auch Angriffe die aus "kleinen und lokalen" Netzen, wie zum Beispiel einer anderen Abteilung eines Unternehmens (oder eines anderen Netzes einer Schule, einer Universität), sind keine Seltenheit. Der Angreifer sitzt nicht immer im Internet !

Ohne eine Firewall bemerken die Besitzer dieser LANs die Einbrüche durch Angreifer aus anderen kleinen Netzen oder dem Internet oftmals nicht.

Eine Firewall kann jedoch nur vor Angriffen schützen die auch durch die Firewall gehen müssten. Es muss deshalb sicher gestellt werden, dass die Firewall die einzige Schnittstelle zwischen den angrenzenden Netzen ist. Ist es für den Angreifer möglich die Firewall zu umgehen, so kann sie diese nicht ausreichend schützen.

Auch die gesamte Sicherheitsphilosophie des Netzwerk-Betreibers muss beachtet werden. So macht macht es zum Beispiel keinen Sinn eine Tür aus 8 Zoll dickem V4A-Stahl in einem Holzhaus zu installieren.

Beachten sie also die Sicherheitsstufen des gesamten Sicherheitssystems, bevor sie eine sehr mächtige Firewall installieren, und am Ende die eigentlich geschützten Daten über Disketten gestohlen werden können.

 

 

1.3 Aufgaben einer Firewall

Eine Firewall sollte:

 

Da bei Firewalls die Ausfallsicherheit eines der wichtigsten Kriterien ist, entscheiden sich die meisten Systemadministratoren für UNIX oder ein UNIX Derivat als Betriebssystem.

Ich selbst würde LINUX empfehlen, da es eine sehr gute Leistung und ein ebenso gutes Preis-Leistungsverhältnis bietet.

Da die Linux-Firewall auch gleichzeitig Router ist, läßt sich diese Kombination aus Firewall und Router feiner einstellen, als bei getrennten Geräten. Es empfiehlt sich generell, an einer Linux-Firewall die vielen Netzwerksegmente eines LANs zusammenzuführen. Bei anderen "fertigen" Firewalls ist die Anzahl der Netzwerkschnittstellen auf zwei, manchmal drei begrenzt, weshalb man bei diesen Lösungen nicht die gleichen Freiheiten hat, wie mit einer Linux-Firewall.

 

 

2.1 Mögliche Angriffe aus einem anderen Netz

Es gibt verschiedene Möglichkeiten und Ziele von Angriffen auf Firewalls oder einzelne Rechner in Netzen.

Hier ein Überblick:

2.1.1 "Source-routed-traffic" - Angriff

Normalerweise wird der Weg (die Route) den ein IP-Paket zurücklegt um von seinem Ausgangspunkt zu seinem Ziel zu gelangen nur durch die Router zwischen Ausgangspunkt und Zielpunkt festgelegt. Das Paket selbst sagt nur, wohin es will. Nicht welchen Weg es dorthin zurücklegen möchte.

Es gibt aber die Möglichkeit in einem IP-Paket Informationen zu speichern, welche genau festlegen welchen Weg ein Paket gehen will. Diese Information wird von den Routern verarbeitet und das Paket dementsprechend geleitet.

Nun kann jemand IP-Pakete generieren, die die Information enthalten, dass sie von dem Netz innerhalb der Firewall (also aus dem geschützten Bereich) zu kommen. Ist das Ziel dieser Pakete innerhalb des geschützten Bereiches, so wird die Firewall das Paket dorthin senden. Der Angreifer hätte es in diesem Fall also geschafft, IP-Pakete in den eigentlich geschützten Bereich zu senden. Deshalb sollte man "source-routed-traffic" nicht durch die Firewall leiten, sondern immer abblocken.

2.1.2 "ICMP redirects" und "redirect bombs"

Ein "ICMP redirect" (ein spezielles Datenpaket) weist das Empfänger-System an, seine Routing-Tabelle zu verändern. Normalerweise werden ICMP-Pakete von Routern an Hosts versendet, um diesen mitzuteilen dass die vom Host vorgeschlagene Route zu langsam oder funktionsunfähig ist, zum Beispiel wenn der Host das Paket an den falschen Router gesendet hat. Der "falsche Router" sendet dann ein ICMP-Paket an den Host, in dem er diesem eine bessere Route vorschlägt. Diese neue Route wird vom Host über die vorherige Route in seiner Routing-Tabelle geschrieben. (Die alte Route ist somit gelöscht.)

Wenn man es nun schafft ICMP-Pakete künstlich zu generieren und an einen Host zu senden, der auf diese Pakete sogar reagiert, so kann man dessen Routingtabelle verändern. Man kann sie so verändern, dass man unter Umständen das Sicherheitskonzept des Administrators unterwandert, indem man die Firewall anweist die Pakete in einen Netzwerk-Bereich zu routen, der eigentlich für die Firewall gesperrt ist. (Da der Administrator der Firewall bewusst keine Route in diesen Bereich zugewiesen hat, um den Bereich zu schützen.) Auf dieser neuen Route können dann IP-Pakete in einen Netzwerkbereich transportiert werden, in den es eigentlich über die Firewall keinen Zugang gibt.

2.1.3 "denial of service" - Angriffe mit ICMP-Paketen

Hierbei handelt es sich um Angriffe bei denen der angegriffene Host funktionsunfähig wird, indem man ihm suggeriert dass es verschiedene Probleme mit seiner Netzwerkverbindung gibt.

Man kann einem Host ein ICMP-Paket senden welches ihm mitteilt, dass er eine neue Route verwenden soll, die überhaupt nicht funktioniert. Der Host wird also seine Pakete in die falsche Richtung senden, und sein Ziel nicht erreichen.

Oder man sendet ihm ein "ICMP Network Unreachable"-Paket welches dem Host mitteilt, dass er Pakete in dieses Netzwerk nicht mehr senden kann, da es unerreichbar ist. Der Host geht dann davon aus, dass er wirklich keinen Zugang mehr in die von dem Angriff betroffenen Netze hat, und verweigert das Senden von weiteren IP-Paketen in diese Netze.

2.1.4 Normale "denial of service" (DoS) - Angriffe

Mit diesen Angriffen versucht der Angreifer ein Netzwerk oder eine Firewall unbrauchbar zu machen, indem er es/sie mit Paketen flutet oder mit bestimmten Paketen zu crashen versucht, oder es/sie vom Rest des Netzes irgendwie trennt.

Das Problem dabei ist, dass sich niemand davor wirklich schützen kann. Selbst wenn es der Angreifer nicht schafft, das lokale und geschützte Netzwerk zu fluten, so kann er doch alle Zugänge des geschützten Netzwerkes zum Internet zu fluten versuchen oder stillegen (sofern diese nicht genug geschützt sind).

Ein Praxisbericht:

Am 2000-02-07 wurde einer der am häufigsten besuchten Server im Internet, www.yahoo.com, mit einem von mehreren Angreifern gleichzeitig ausgeführten "verteilten DoS-Angriff" lahmgelegt. Zum Höhepunkt des Angriffs wurde Yahoo mit Abfragen in einem Ausmass von bis zu 1 Gigabit pro Sekunde überflutet. Erst nach mehreren Stunden gelang es Yahoos Systemadministatoren, die böswilligen Zugriffe zu filtern.

Die virtuellen Angriffsnetze, so genannte "floodnets", sollen teilweise aus mehr als 1000 Computern bestehen, welche mit "Trojanischen Pferden" infiziert sind und zentral gesteuert werden können. Die Bandbreite derart grosser floodnets könnten ein Vielfaches von der Bandbreite haben, wie sie yahoo arbeitsunfähig machte.

 

 

2.2 Bekannte und häufig praktizierte Angriffe:

2.2.1 SMURF-Attacken

Eine Smurf-Attacke läßt sich durch erhöhten ICMP-Verkehr sowie Ping-Pakete an Broadcast-Adressen leicht identifizieren. Sie ist eine Art "denial of service" Angriff.

2.2.2 SMTP Session Hijacking

Hierbei wird der Angreifer wahnsinnig viele emails an einen Host oder ein ganzes Netz von Hosts senden, so dass dessen email-Server überlastet ist und funktionsunfähig wird.

2.2.3 Exploiting Bugs in Applications

Hierbei werden Programmier-Fehlern in Anwendungen die auf einem Host laufen ausgenutzt. Die möglichen Folgen reichen von "nicht bemerkbar", bis "Rechner danach unbrauchbar". Das Risiko das ein solcher Angriff mit sich bringt kann nur verringert werden, indem auf dem betroffenen Host so wenig Anwendungen wie nur möglich laufen. Man kann oftmals auch auf "reifere" Programme zurückgreifen, deren Fehler bereits erkannt und beseitigt wurden.

Dazu zählen zum Beispiel Angriffe auf Web-Server wie der altbekannte `phf-Fehler´ (ein Bug der das Ausführen beliebiger Kommandos auf dem Web-Server ermöglicht). Diese verraten sich durch den Inhalt der Pakete.

Ein TCP/IP-Paket mit Ziel-Port 80 (http) und einem Inhalt der Form:

GET /cgi-bin/phf?irgendetwas%0a<Befehl> HTTP/1.0

ist eindeutig als Einbruchsversuch und Angriff zu werten.

2.2.4 Spoofing

Hierbei handelt es sich um das Vortäuschen eines falschen Absenders von IP-Paketen (IP-Spoofing), eines anderen Internet-Namens (DNS-Spoofing) oder des gesamten WWW durch Umleitung von Anfragen über einen Zwischenrechner (Web-Spoofing).

Bei speziellen Formen des DNS-Spoofings wird die DNS Auflösung verhindert, und der betroffene Host dadurch Netzwerk-Arbeitsunfähig gemacht. (Denn schließlich muss er die DNS Adressen in IP-Adressen umsetzen können, um seine Ziele zu adressieren.) Dabei wird entweder der Name-Service-Cache des betroffenen Hosts beschädigt, oder dem Domain-Name-Server suggeriert, dass die betreffende Domain nicht mehr existiert oder funktionsunfähig ist.

 

 

2.3 Meldung von Angriffen

Eine Firewall muss überwacht werden um Angriffsversuche oder eventuell sogar geglückte Angriffe melden. Dafür gibt es sogenannte Intrusion-Detection-Systeme (IDS), welche versuchen Attacken zu erkennen und möglichst viele Informationen über den Angreifer zu sammeln. Wird ein Angriffsversuch erkannt, so wird der Administrator der Firewall z.B. per email benachrichtigt. Ich werde ihnen zeigen, wie man mit Hilfe der Log-Regel schon viele Angriffe erkennen kann. Sollten sie jedoch starke IDS installieren wollen, so empfehle ich ihnen die Dokumentation http://www.enteract.com/~lspitz/pubs.html

 

 

3.1 Die Firewall im Linux-Kern - Der Paketfilter

Die Entwickler der Firewall für Linux haben diese als einen Teil des Betriebsystemkerns programmiert. Schon vor der Compilierung des Linux-Kerns (des "Kernels") wird der Benutzer aufgefordert, sich für oder gegen die Installation der Firewall im Kernel auszusprechen.

Die Linux-Firewall ist hauptsächlich ein leistungsfähiger Paketfilter, der IP-Pakete filtern kann.

Anhand der Quell- und Zieladresse, der Portnummern, des Pakettyps, des ACK- und SYN-Bits, des Netzwerkinterfaces und der Richtung wird entschieden, ob ein Paket die Firewall passieren darf, oder nicht.

Haben die Rechner des eigenen Netzes (des LANs) reservierte (nicht registrierte, also nicht offizielle) IP-Adressen, dann sind direkte TCP/IP-Verbindungen in das andere an der Firewall angeschlossene Netz (z.B. das Internet) nicht möglich. Bei Verbindung mit dem Internet muss das äußere Netzwerk-Interface der Firewall (welches am Internet angeschlossen ist) auf jeden Fall eine internetweit gültige (offizielle) IP-Adresse erhalten. Da Pakete mit reservierten IP-Adressen (welche extra für LANs reserviert wurden) im Internet nicht transportiert werden, ersetzt die Firewall bei Paketen die in das Internet gehen die Quelladresse durch ihre eigene offizielle IP-Adresse. Bei aus dem Internet kommenden Paketen übersetzt sie die Zieladresse durch die IP-Adresse des Hosts im eigenen Netz, der die Verbindung aufgebaut hat. Diese allgemein als IP-Proxying bezeichnete Funktion wird unter Linux als Masquerading bezeichnet. Sie ermöglicht die Internetanbindung vieler Rechner mit nur einer einzigen echten und offiziellen IP-Adresse, welche die Firewall besitzt. (Sie ist eine Sonderform der NAT (Network Address Translation), bei der im Allgemeinen eine m:n Zuordnung gemacht wird. Beim Masquerading findet eine m:1 Zuordnung statt.)

Masquerading bietet auch zusätzlichen Schutz. Für Hosts im Internet sieht es so aus, als ob sie direkt mit der Firewall, und nur mit der Firewall, kommunizieren. Die Rechner im eigenen Netz bleiben für andere Rechner im Internet unsichtbar.

"Port Forwarding" ist eine elegante Möglichkeit, um hinter einer IP-Adresse verschiedene Netzdienste über verschiedene Rechner anzubieten: Die Linux-Firewall leitet einfach alle Anfragen an einen bestimmten Port auf einen anderen Rechner um, der sich im LAN hinter der Firewall befindet und so gegenüber dem Internet abgeschottet ist. Die Rechner im Internet bemerken dabei nicht, wie deren IP-Pakete hinter der Firewall behandelt werden.

Man kann ein "lokales Port Forwarding" benutzen, um die Internetzugriffe der Anwender im geschützten LAN über einen Proxy zu bearbeiten, ohne dass die Anwender das speziell in ihrem Browser konfigurieren müssen, oder bemerken. Das nennt man dann einen transparenten Proxy. Läuft beispielsweise auf der Firewall auf dem Port 3128 ein WWW-Proxy (z.B. squid), so kann die Firewall alle IP-Pakete die an ihren Port 80 gerichtet sind an diesen Proxy-Port weiterleiten (forwarden), ohne das der Endanwender etwas davon bemerkt.

 

Paketfilter, wie die Firewall im Linux-Kern, haben oft dann potentielle Sicherheitsprobleme, wenn eine Sitzung mehrere Verbindungen benötigt, oft auch über das UD-Protokoll (UDP). Bekannt sind solche Probleme z.B. bei FTP, IRC und pcAnywhere. Um statisch bei Bedarf diese Verbindungen zuzulassen, müssen die Regeln weiter gefaßt werden als eigentlich beabsichtigt. Man müsste also vor jedem solchen Verbindungsaufbau den Paketfilter umkonfigurieren. Das ist per Hand relativ aufwendig und zeitraubend. Nur ein sogenannter Proxy-Prozeß kann Regeln dynamisch einfügen und entfernen, indem er das zugrunde liegende Protokoll (z.B. FTP) interpretiert und die nötigen Aktionen vornimmt.

Es gibt jedoch auch eine andere Lösung: spezielle Kernel-Module.

 

 

3.2 Application-Level Gateways

Grundsätzlich muß man sich entscheiden, ob ein Internet-Dienst über Paketfilterung oder über ein Application-Level Gateway genutzt bzw. angeboten werden soll. Letzteres ermöglicht eine höhere Sicherheit, da alle Daten eines Internet-Dienstes von einer auf der Firewall laufenden Applikation weitergeleitet werden. Somit ist es möglich, für Dienste wie email und ftp alle Daten auf Viren zu prüfen und andere dienstspezifische Tests durchzuführen. Befindet sich hinter der Firewall ein Mailserver, dann bietet einfache Paketfilterung nicht genügend Schutz vor Angriffen.

Ältere Versionen von sendmail erlaubten es zum Beispiel, mit Hilfe von sendmail-spezifischen Befehlen, Shell-Kommandos als root auszuführen, was man durch einfache Paketfilterung nicht verhindern kann.

Das Kernproblem bei allen Internet-Servern ist, daß der jeweilige Dienst von einem sehr umfangreichen Programm angeboten wird. Sicherheitsrelevante Programmfehler sind bei einer solchen Größe wahrscheinlich. Application-Level-Gateways sind hier die einzige Möglichkeit, Internet-Server vor Angriffen wirksam zu schützen.

Sie haben allerdings auch einen Nachteil. Die Geschwindigkeit der Datenübertragung durch die Firewall ist wesentlich langsamer als bei einem Paketfilter. Es bietet sich jedoch an, beide Möglichkeiten zu nutzen und Internet-Dienste mit hohen Anforderungen an die Geschwindigkeit auf IP-Ebene (durch einen Paketfilter) und Dienste mit hohen Sicherheitsanforderungen auf Anwendungsebene (durch ein Application Level Gateway) zu transportieren.

 

 

4.1 ipchains

Das Programm ipchains ist die Benutzerschnittstelle zum Paketfilter der Firewall. Es ist in jeder guten Linux-Distribution enthalten. Falls es ihrer Distribution nicht beiliegt, können sie es aus dem Internet kopieren. (http://www.rustcorp.com/linux/ipchains/)

Pro Aufruf des Programms wird eine Regel für IP-Pakete angegeben. Eine solche Regel gibt die Eigenschaften eines IP-Pakets an, und definiert eine Aktion die auszuführen ist, wenn das Paket allen angegebenen Eigenschaften entspricht.

 

Mögliche Eigenschaften der IP-Pakete:

Diese Eigenschaften können auch negiert werden indem ihnen ein ! voran gestellt wird.

 

Aktionen des Paketfilters:

 

Durch die Verknüpfung von Eigenschaften und Aktionen lassen sich Regeln aufstellen, die in Regellisten zusammengefasst werden und die Filterfunktionen des Paketfilters steuern.

Standardmässig gibt es drei Regellisten:

Die Regeln einer Regelliste werden der Reihe nach abgearbeitet. Die erste, für das Paket passende Regel wird ausgeführt. Spezielle Regeln müssen also unbedingt vor (!) allgemeinen Regeln stehen !

 

 

 

 

4.2 Die Befehle und Optionen des Programms ipchains:

Befehle und Optionen übergeben sie in folgender Reihenfolge an ipchains:

ipchains <Befehl> <Option1> <Option2> <Option3> u.s.w.

 

 

 

Eine Liste der Befehle von ipchains:

Befehl

Kurzbezeichnung

Parameter

Beschreibung

--add

-A

<name_der_regelliste>

Hängt die nachfolgende Regel an die Regelliste an

--delete

-D

<n_d_rl> <Position/Regel>

Löscht die Regel aus der Regelliste. Es muss entweder die Position der Regel (1-n), oder die Regel selbst angegeben werden.

--insert

-I

<n_d_rl> <Position> <Regel>

Fügt die Regel an der angegebenen Position in die Regelliste ein. (Wählt man als Position 1, so wird die Regel an den Anfang der Regelliste geschrieben.)

--replace

-R

<n_d_rl> <Position> <Regel>

Ersetzt die Regel an der angegebenen Position in der Regelliste, durch die neue Regel.

--list

-L

[ <n_d_rl> ]

Zeigt alle Regellisten oder die Regelliste und all ihre Regeln an.

--flush

-F

[ <n_d_rl> ]

Löscht alle Regellisten oder alle Regeln in der angegebenen Regelliste.

--zero

-Z

[ <n_d_rl> ]

Setzt Null-Zähler in allen Regellisten oder nur in der angegebenen Regelliste

--check

-C

<n_d_rl>

Testet die Reaktion der Regelliste auf dieses Paket

--new

-N

<n_d_rl>

Legt eine neue (nicht-standard) Regelliste an

--delete

-X

<n_d_rl>

Löscht eine leere (!) nicht-standard Regelliste

--policy

-P

<n_d_rl> <ACCEPT / REJECT / DENY>

Legt die standard Aktion für die Regelliste fest. Diese wird nur ausgeführt, wenn keine der vorhandenen Regeln auf das Paket zutreffen.

--masquerade

-M

-L

Gibt eine Liste der aktuellen masqerading-Verbindungen aus

--masquerade

-M

-S <tcp-Zeit> <tcpfin-Zeit> <udp-Zeit>

Setzt die "masquerading timeout"-Zeiten (in Sekunden)

 

 

 

Eine Liste der Optionen von ipchains:

Option

Kurzbezeichnung

Parameter

Beschreibung

--bidirectional

-b

 

Erstellt automatisch auch eine Regel, für die entgegengesetzte Richtung, bei der die Quell- und Ziel-Adresse vertauscht sind, um den Pakettransfer in beide Richtungen zu erlauben.

--proto

-p

[!] <Protokoll>

Protokoll der Pakete (Protokollnummer oder Kurzbezeichnung, wie tcp, udp, icmp, u.s.w.)

--source

-s

[!] <address>[/<mask>] [!] [<port>[:<port>]]

Spezifiziert die Quell-Adresse und (optional) das Quell-Port

--source-port

 

[!] [<port>[:<port>]]

Spezifiziert den Quell-Port der Pakete, wenn die Angabe -s in der Regel fehlen sollte

--destination

-d

[!] <address>[/<mask>] [!] [<port>[:<port>]]

Spezifiziert die Ziel-Adresse und (optional) das Ziel-Port

--destination-port

 

[!] [<port>[:<port>]]

Spezifiziert den Ziel-Port der Pakete, wenn die Angabe -d in der Regel fehlen sollte

--icmp-type

 

[!] <typ>

Legt den ICMP-Paket-Typ der Pakete fest (Nummer oder Bezeichnung des Typs angeben)

--interface

-i

[!]<Netzwerkschnittstelle> [+]

Legt die Netzwerkschnittstelle fest (z.B. eth0, ppp0)

Ein + repräsentiert alle Schnittstellen diesen Typs.

Beachte: in der forward-Regelliste das Interface, an welches das Paket weitergeleitet werden soll ! (Also das Ziel des forwardens.)

--jump

-j

<n_d_rl / ACCEPT / REJECT / DENY / MASQ / [<port>] REDIRECT>

Aktion die mit den Paketen ausgeführt wird, auf die die Regel passt. Diese Pakete können auch an eine nicht-standard Regelliste weiter gegeben werden. Trifft in einer solchen nicht-standard Regelliste keine Regel auf das Peket zu, so wird es wieder an die Ursprungsliste zurück gegeben und diese weiter abgearbeitet.

--numeric

-n

 

Gibt die Nummern von IP-Adressen und Ports aus

--log

-l

 

Dieses Paket wird in einer log-Datei (/var/log/messages) durch syslogd vermerkt ("mit gelogt")

--output

-o

[<maximale_Groesse>]

Gib passende Pakete auf dem "netlink device" aus

--TOS

-t

<neue_ Besetzung_ des_ ToS-Feldes>

Ändert das ToS-Feld im Paket

--verbose

-v

 

Erzeugt eine ausführliche Ausgabe

--exact

-x

 

Zeigt die Paket und Byte-Zähler an

[!] --fragment

[!] -f

 

Beachte nur das zweite oder alle weiteren Paketfragmente

[!] --syn

[!] -y

 

Bezeichnet TCP-Pakete, bei denen das SYN-Bit gesetzt, und die ACK und FIN Bits nicht gesetzt sind. Also nur die Pakete, die eine TCP-Verbindung aufbauen wollen.

[!] --version

[!] -V

 

Gib die Paketversion aus

 

Hinweise zu den Befehlen und Optionen:

Das Zeichen "!" negiert die jeweilige Option (Eigenschaft des Pakets). So steht z.B. "! -p www" für alle Protokolle außer www, "! -y" steht für alle Pakete deren SYN-Bit nicht gesetzt ist, u.s.w.

IP-Adressen und Subnetze lassen sich als Adresse/Netzmaske entweder in der Form z.B. 192.168.0.0/255.255.255.0, oder in der Form z.B. 192.168.0.0/24 angeben, wobei ich die erste empfehlen würde.

Anstatt eines einzelnen Ports kann man mit Hilfe eines ":" auch einen ganzen Bereich von Ports angeben.

Bsp: 1000:2000 repräsentiert alle Ports mit einer Nummer von 1000 bis 2000.

1024: bedeutet alle Ports mit einer Nummer >= 1024

:1024 bedeutet alle Ports mit einer Nummer <= 1024

Die Port-Nummern können auch durch die Namen der entsprechenden Dienste ersetzt werden, sofern in der Datei /etc/services eine eindeutige Zuordnung der Namen zu den Port-Nummern stattfindet.

Falls sie das Protokoll hinter -p angeben wollen, so können sie eine Liste der möglichen Protokolle in der Datei /etc/protocols einsehen.

Bei der Angabe der Netzwerk-Schnittstelle hinter -i repräsentiert ein "+" anstelle der Interfacenummer alle Netzwerk-Schnittstellen, dieses Typs. (Also repräsentiert z.B. ppp+ alle Modems, eth+ alle Ethernet Netzwerkkarten, u.s.w.)

 

 

4.3 Die Formulierung der Regeln

Für eine normale TCP-Verbindung durch die Firewall sind 6 Regeln notwendig. 3 für den Hin- und 3 für den Rückweg. Eine typische Paketfilterschicht einer großen Firewall besteht aus Hunderten von Regeln. Die erste passende Regel wird ausgeführt. Eine einzige Regel, die falsch angegeben ist, kann ein fatales Sicherheitsloch sein. Es ist deshalb immer anzuraten, die Regeln so eng wie möglich anzugeben, und erst bei Bedarf zu erweitern.

Als letzte Regel für die drei standard-Regellisten wird deshalb oft eine "Log-Regel" (Option -l) angegeben. Diese gilt für alle Pakete, die bis zum Ende der Regelliste gelangt sind, und auf die bislang keine Regel zugetroffen hat. Sie werden abgelehnt und gleichzeitig von syslogd in einer log-Datei (/var/log/messages) vermerkt. Dadurch ist es möglich, solche Sicherheitslöcher zu finden und mit passenden Regeln "zu stopfen".

 

 

4.4 Was passiert im Kernel ?

Auf dem Weg durch den Kernel muss jedes einzelne Paket eine Reihe von Überprüfungen über sich ergehen lassen. Zunächst verwirft der Kernel alle die Pakete, deren Prüfsumme nicht stimmt. Anschließend erfolgt der Test, ob es sich um korrekte IP-Pakete handelt. Da beschädigte Pakete die Firewall irritieren könnten, werden diese abgelehnt. Diese "Sanity-Checks" stehen vor allen Regellisten.

Danach trifft das Paket auf die input-Regelliste, in der alle Regeln nacheinander abgearbeitet werden. Sobald eine Regel zutrifft, gelangt das Paket zum Sprungziel der Regel. DENY und REJECT verwerfen das Paket, wobei der Absender des Paketes bei REJECT per ICMP-Paket die Mitteilung bekommt, dass das Ziel nicht erreichbar ist. ACCEPT lässt das Paket passieren.

Das Sprungziel kann aber auch eine benutzerdefinierte Regelliste sein. Eine solche Liste könnte beispielsweise alle Regeln zur Behandlung von ICMP-Paketen enthalten. Eine einzige Regel in der input-Liste leitet dann die ICMP-Pakete an die ICMP-Liste weiter. So lässt sich der Aufbau der Filter übersichtlicher strukturieren, und die Unterstützung zum Beispiel eines kompletten Protokolls oder eines Netzwerk-Interfaces durch nur eine Regel ab- und wieder anschalten.

Die input-Liste bietet außerdem die Möglichkeit, mit dem Sprungziel REDIRECT Pakete auf einen lokalen Port umzuleiten. So lässt sich z.B. ein transparenter Proxy realisieren. Trifft keine Regel der input-Liste auf das Paket zu, so wird das Paket nach der Standardregel (der "default policy") behandelt.

Verlässt ein akzeptiertes Paket die input-Liste, so entscheidet der Kernel ob das Paket für einen lokalen Port bestimmt ist. In diesem Fall kann der Prozess der diesen Port belegt, das Paket direkt entgegennehmen. Pakete die ein lokaler Prozess versendet gelangen direkt zur output-Liste.

Ist weder Herkunft noch Ziel des Paketes ein lokaler Prozess, so überprüft der Kernel ob es sich um die Antwort auf ein maskiertes Paket handelt, welches ursprünglich von einem Computer im "geschützten" Netz hinter der Firewall (vom LAN) stammt, welches von der Firewall mit ihrer eigenen Adresse versendet wurde. Ist das der Fall, so wird das Paket jetzt wieder demaskiert (also die ursprüngliche Adresse des Clients eingetragen), und es wird direkt an die output-Liste weitergeleitet, um zum Client gesendet zu werden.

Ist das nicht der Fall, so wird es an die forward-Liste weitergeleitet. (In der Forward Regelliste landen alle Pakete, die den Rechner von einem Netzwerk-Inteface zu einem anderen durchqueren wollen, und keine Antwort auf maskierte Pakete sind.)

Auch hier werden wieder alle Regeln abgearbeitet, und falls keine zutrifft, wird das Paket nach der standard-Regel (standard-policy) behandelt. Wird hier ein Paket akzeptiert, so gelangt es danach in die output-Regelliste.

In die output-Regelliste kommen nur die Pakete, die von lokalen Prozessen versendet wurden, oder erfolgreich die forward-Regelliste durchquerten. Auch hier werden wieder alle Regeln abgearbeitet, und falls keine zutrifft, wird das Paket nach der standard-Regel (standard-policy) behandelt.

 

 

4.5 Praktische Beispiele:

Da die Firewall ihre letzte Konfiguration nicht automatisch speichert, und nach einem Neustart des Rechners diese auch nicht automatisch neu lädt, empfehle ich die im Folgenden aufgeführten Einzelaufrufe von ipchains in ein Script zu schreiben, welches nach jedem Neustart ausgeführt wird, und somit die Firewall konfiguriert. Schreiben sie dazu das jeweilige Script zur Konfiguration der Firewall, und machen sie einen entsprechenden Eintrag zum Aufruf des Scripts im init-Script ihres Rechners.

Hinweis: Man kann mit dem Befehl "ipchains-save > regeln" die aktuellen Regellisten in die Datei "regeln" schreiben, und sie von dort bei jedem Neustart des Rechners mit "ipchains-restore < regeln" in die Firewall laden. Somit reicht es anstatt des Firewall-Konfigurationsscripts nach jedem Neustart "ipchains-restore" aufzurufen.

Hinweis: Die folgenden Beispiele gehen davon aus, dass die Firewall eine interne Netzwerkkarte $DEV_LAN mit der IP-Adresse (der LAN Adresse der Firewall) $IP_LAN, der LAN-Adresse und Maske $LAN hat.

Ausserdem hat die Firewall ein externes Netzwerkinterface (ins Internet) $DEV_INET mit der IP-Adresse $IP_INET, und der Inter-Netz-Adresse und Maske $INET.

Es sollten also folgende Zeilen am Anfang JEDES Firewall-Initialisierungs-Scripts stehen:

(Wobei sie natürlich die Adressen durch die in ihrer Konfiguration benutzten Adressen austauschen können.)


DEV_LAN = eth0
IP_LAN = 192.168.0.1
LAN = 192.168.0.0/255.255.255.0
DEV_INET = ppp0
IP_INET = 141.35.1.16
INET = 0.0.0.0/0.0.0.0

 

 

4.5.1 Erste Konfiguration

Als ersten Schritt bei der Konfiguration der Firewall löschen wir alle alten Regeln und alle benutzerdefinierten Regellisten mit folgendem Befehl:

ipchains -F

Um jeglichen Netzwerkverkehr zu verbieten, der nicht explizit erlaubt wurde, wählen wir die default-policy DENY oder REJECT für alle drei standard Regellisten.

ipchains -P input DENY

ipchains -P forward DENY

ipchains -P output DENY

Nun müssen wir ledeglich die von uns gewünschten Dienste freischalten. (Würden wir prinzipiell alles erlauben, und nur die "gefährlichen" Dienste verbieten, so würden wie Gefahr laufen einen gefährlichen Dienst zu übersehen.)

Als erstes erlauben wir die lokale Netzwerkkommunikation auf der Firewall über das "local loopback device":

ipchains -A input -i lo -j ACCEPT

ipchains -A output -i lo -j ACCEPT

 

Für eine normale TCP-Verbindung durch die Firewall sind sechs Regeln notwendig. Drei für den Hinweg, und drei für den Rückweg der Pakete.

 

Wollen wir nun z.B. allen Rechnern im an der Firewell angeschlossenen LAN den Zugriff auf einen Internet-Proxy gewähren, der auf der Firewall installiert ist, so gehen wir wie folgt vor:


# Wir sorgen dafür, dass der Proxy auf der Firewall von Clients im LAN angesprochen werden kann,
# indem TCP-Pakete von einem Port > 1024 kommend, an den Port 3128 gehend (da ist der Proxy),
# akzeptiert werden.
ipchains -A input -s $LAN 1024: -d $IP_LAN 3128 -p tcp -i $DEV_LAN -j ACCEPT


# Erlaubt die Antwortpakete vom Proxy ins LAN. ! -y sorgt dafür, dass nur Pakete ohne SYN-Bit
# passieren dürfen. Der Proxy darf also nicht versuchen, mit dem SYN-Bit neue Verbindungen zu
# den Clients im LAN zu initialisieren. Das ist nur für den Fall, dass sich jemand in der Firewall
# befindet und von dort aus Angriffe auf einen der Clients versucht.
ipchains -A output -s $IP_LAN 3128 -d $LAN 1024: -p tcp -i $DEV_LAN -j ACCEPT ! -y

Damit haben aber die Clients im LAN keinen direkten Internetzugang. Es werden ledeglich all ihre Anfragen an den Proxy und von diesem in das Internet gesendet. Die Antworten aus dem Internet werden vom Proxy entgegengenommen, und an die Clients gesendet.

 

 

4.5.2 Eine "Dial-Up-Firewall"

(Firewall die nur kurzzeitigen Internetzugang via Modem hat)

Nehmen wir nun einmal an, wir wollen ein LAN über eine Modem-Verbindung mit dem Internet verbinden. Dann wird das LAN "maskiert", d.h. auf der Firewall werden die Netzwerkverbindungen umgesetzt. Ein Beobachter im Internet sieht einen einzigen Computer, der viele Verbindungen zu verschiedenen Zielen zur gleichen Zeit hat (er sieht also nur die Firewall). Ein Beobachter im LAN sieht direkte Verbindungen zu den Ziel-Computern im Internet (er hingegen sieht nicht die Firewall).

In der Firewall (also im Linux-Kernel) wird eine Tabelle geführt, mit der die Zuordnung von vermeintlichen Verbindungen zwischen Client und Server verwaltet wird. Hier werden auch die Verbindungen zwischen Client und Firewall sowie maskierte Verbindungen zwischen Firewall und Server gespeichert.

(Beachten sie hierbei den ipchains-Befehl "-M -S <tcp-Zeit> <tcpfin-Zeit> <udp-Zeit>", mit dem sie die Dauer des Speicherns dieser Zuordnungen festlegen können. )

Bei dynamischer IP-Adressenzuweisung, die man bei Einwählverbindungen normalerweise hat, kann man diese Regeln nicht statisch angeben. Im Skript (z.B. ppp-up) muss deshalb DEV_INET mit der vom Internetprovider dynamisch zugewiesenen IP-Adresse belegt werden. Es ist auch ratsam, gleich nach dem Booten des Rechners den Befehl "echo "1" > /proc/sys/net/ipv4/ip_dynaddr" und "echo "1" > /proc/sys/net/ipv4/ip_forward" auszuführen, damit der Linux-Kernel das dynamisch nach der Einwahl beim Internetprovider zugewiesene Internetgateway ansprechen, und IP-Pakete aus dem LAN dorthin senden kann.

Die Einfachste Möglichkeit den Benutzern des LAN direkten Zugang zum Internet zu verschaffen ist folgende:


# Jedes Paket das ankommt annehmen
# (Uns kann also eventuell ein Cracker angreifen, da wir auch seine Pakete empfangen.)
ipchains -P input ACCEPT


# Jedes Paket das gesendet werden will, senden
# (Wenn die Firewall von einem Cracker geknackt wird, so kann er von ihr aus in den geschützten Bereich, in das
# LAN, senden.)
ipchains -P output ACCEPT


# Nicht jedes Paket das weitergeleitet (ge-routet) werden will auch weiterleiten
ipchains -P forward DENY


# Nur die Pakete weiterleiten und automatisch maskieren, die aus dem LAN kommen
# (In der Gegenrichtung erkennt der Kernel automatisch das es sich um eine Antwort auf ein maskiertes Paket
# handelt, und forwarded das Antwortpaket, auch ohne explizit angegebene Regel.)
ipchains -A forward -s $LAN -j MASQ

 

Bessere, weil sicherere Regeln, sind folgende:


# als Standard alle Pakete ablehnen
ipchains -P input DENY
ipchains -P forward DENY
ipchains -P output DENY


# Nur die Pakete annehmen, die an der Netzwerkschnittstelle die am LAN ist ankommen, TCP-Pakete
# sind, als Quell-Adresse eine LAN-Adresse haben und als Ziel-Adresse eine Internetadresse mit dem
# Port 80 (http) haben.
ipchains -A input -i $DEV_LAN -p tcp -s $LAN -d $INET 80 -j ACCEPT


# Nur die Pakete weiterleiten und automatisch maskieren, die zur Netzwerkschnittstelle wollen die am
# Internet ist, die TCP-Pakete sind, die als Quell-Adresse eine LAN-Adresse haben und als Ziel-Adresse
# eine Internetadresse mit dem Port 80 (http) haben.
ipchains -A forward -i $DEV_INET -p tcp -s $LAN -d $INET 80 -j MASQ


# Nur die Pakete senden, die über die Netzwerkschnittstelle gesendet werden wollen die am Internet ist,
# die TCP-Pakete sind, die als Quell-Adresse die der Firewall haben (also bereits maskiert sind), und als
# Ziel-Adresse eine Internetadresse mit dem Port 80 haben.
ipchains -A output -i $DEV_INET -p tcp -s $IP_INET -d $INET 80 -j ACCEPT


# Nur Pakete annehmen, die an der Netzwerkschnittstelle die am Internet ist ankommen, TCP-Pakete
# sind, als Quell-Adresse eine Internetadresse mit dem Port 80 (http) und als Zieladresse die Adresse
# der Firewall haben. (Die also Antwortpakete aus dem Internet an die Clients im LAN sind.)
ipchains -A input -i $DEV_INET -p tcp -s $INET 80 -d $IP_INET -j ACCEPT


# Nur die Pakete weiterleiten und automatisch de-maskieren, die zur Netzwerkschnittstelle wollen die am
# LAN ist, die TCP-Pakete sind, die als Quell-Adresse eine Internetadresse mit dem Port 80 (http) und
# als Ziel-Adresse eine LAN-Adresse haben.
# (Diese Regel kann theoretisch entfallen, da der Kernel das automatisch tut.
# Siehe 4.5.2 Eine "Dial-Up-Firewall")
ipchains -A forward -i $DEV_LAN -p tcp -s $INET 80 -d $LAN -j MASQ


# Nur die Pakete senden, die über die Netzwerkschnittstelle gesendet werden wollen die am LAN ist,
# TCP-Pakete sind, als Quell-Adresse eine Internetadresse mit dem Port 80, und als Ziel-Adresse eine
# LAN-Adresse haben.
ipchains -A output -i $DEV_LAN -p tcp -s $INET 80 -d $LAN -j ACCEPT

 

 

4.5.3 Konfiguration für Web-Zugriffe

Wenn wir z.B. Web-Zugriffe aus dem lokalen Netz ins Internet zulassen wollen, so lauten diese Regeln:


# als Standard alle Pakete ablehnen
ipchains -P input DENY
ipchains -P forward DENY
ipchains -P output DENY


# Nur die Pakete annehmen, die an der Netzwerkschnittstelle die am LAN ist ankommen, TCP-Pakete sind, als
# Quell-Adresse eine Adresse im LAN und als Ziel-Adresse eine Adresse im Internet mit dem Port 80 haben.
ipchains -A input -i $DEV_LAN -p tcp -s $LAN -d $INET 80 -j ACCEPT


# Nur die Pakete weiterleiten und automatisch maskieren, die an die Netzwerkschnittstelle die am Internet ist
# weitergeleitet werden wollen, TCP-Pakete sind, als Quell-Adresse eine Adresse im LAN und als Ziel-Adresse
# eine Adresse im Internet mit dem Port 80 haben.
ipchains -A forward -i $DEV_INET -p tcp -s $LAN -d $INET 80 -j MASQ


# Nur die Pakete senden, die über die Netzwerkschnittstelle gesendet werden wollen die am Internet ist,
# TCP-Pakete sind, als Quell-Adresse eine Adresse im LAN und als Ziel-Adresse eine Adresse im Internet mit dem
# Port 80 haben.
ipchains -A output -i $DEV_INET -p tcp -s $LAN -d $INET 80 -j ACCEPT


# Nur die Pakete annehmen, die an der Netzwerkschnittstelle die am Internet ist ankommen, TCP-Pakete sind, als
# Quell-Adresse eine Adresse im Internet mit dem Port 80, und als Ziel-Adresse eine Adresse im LAN haben.
ipchains -A input -i $DEV_INET -p tcp -s $INET 80 -d $LAN -j ACCEPT


# Nur die Pakete weiterleiten und de-maskieren, die an die Netzwerkschnittstelle die am LAN ist weitergeleitet
# werden wollen, TCP-Pakete sind, als Quell-Adresse eine Adresse im Internet mit dem Port 80, und als Ziel-
# Adresse eine Adresse im LAN haben.
# (Diese Regel kann theoretisch entfallen, da der Kernel das automatisch tut.
# Siehe 4.5.2 Eine "Dial-Up-Firewall")
ipchains -A forward -i $DEV_LAN -p tcp -s $INET 80 -d $LAN -j MASQ


# Nur die Pakete senden, die über die Netzwerkschnittstelle gesendet werden wollen die am LAN ist, TCP-
# Pakete sind, als Quell-Adresse eine Adresse im Internet mit dem Port 80, und als Ziel-Adresse eine Adresse im
# LAN haben.
ipchains -A output -i $DEV_LAN -p tcp -s $INET 80 -d $LAN -j ACCEPT

 

 

4.6 Was beim Masquerading beachtet werden muss

Sie können alle oben beschriebenen Beispiele auch auf normalen Routern anwenden, bei denen die Clients offizielle Internetadressen haben. In diesem Fall können sie auf die Maskierung der Pakete verzichten, und überall wo im Moment die Option -MASQ verwendet wird, ein -ACCEPT verwenden.

Doch was muss denn nun beim Masquerading beachtet werden ?

Pakete vom LAN ins Internet:

In der input und forward Regelliste ist die Herkunftsadresse des Paketes die des Clients im LAN. In der output Regelliste ist die Herkunftsadresse die der Firewall selbst ! (Da diese beim forward-Vorgang an die Stelle geschrieben wurde, an der zuvor die Adresse des original Absenders stand.)

Pakete vom Internet ins LAN:

Für die input Regelliste ist die Zieladresse gleich der offiziellen IP-Adresse der Firewall. Für die output Regelliste ist die Zieladresse die des Client im LAN, da das Paket bereits vom Kernel vollautomatisch demaskiert wurde, bevor es in die output-Liste kam. (Deshalb ist in dieser Richtung eigentlich keine explizite Demaskierung notwendig.)

4.7 Benutzerdefinierte Regellisten

Die ipchains-Option -N ermöglicht das Erstellen benutzerdefinierter Regellisten. Will man beispielsweise den Datendurchsatz durch die Firewall erhöhen, so kann es sinnvoll sein den Pakettypen der am häufigsten durch die Firewall gesendet wird, in einer extra Liste zu behandeln die gleich am Anfang jeder standard-Regelliste angesprungen wird.

Beispiel:


# Lege eine Neue Regelliste mit dem Namen "icmp_liste" an
ipchains -N icmp_liste


# Füge an die erste Position in der forward-Regelliste eine Weiterleitung von icmp-Paketen an die
# "icmp_liste"-Regelliste ein
ipchains -I forward 1 -p icmp -j icmp_liste

 

In solchen Regellisten kann man auch gut häufig wiederkehrende Behandlungsroutinen zusammenstellen, genauso wie es bei Funktionen von z.B. C-Programmen genutzt wird.

Man kann zum Beispiel eine neue Regelliste für icmp-Pakete anlegen, die immer dann angesprungen wird, wenn ein icmp-Paket behandelt werden muss. Damit schnell erkannt wird, ob es sich um ein icmp-Paket handelt oder nicht, fügen wir diesen Test an den Anfang jeder standard-Regelliste.

Beispiel:


ipchains -N icmp_liste
ipchains -A icmp_liste -p icmp -icmp-type destination-unreachable -j DENY
ipchains -A icmp_liste -p icmp -icmp-type source-quench -j ACCEPT
ipchains -A icmp_liste -p icmp -icmp-type time-exceeded -j ACCEPT
ipchains -A icmp_liste -p icmp -icmp-type parameter-problem -j DENY
ipchains -I input 1 -p icmp -j icmp_liste
ipchains -I forward 1 -p icmp -j icmp_liste
ipchains -I output 1 -p icmp -j icmp_liste

 

Da für eine benutzerdefinierte Regelliste keine standard Regel (standard policy) festgelegt werden kann, gibt diese jedes Paket das sie nicht selbst behandelt an die Liste zurück, aus der es kam.

 

 

4.7.1 Eine andere "Dial-Up-Firewall"

Folgende Regeln sollen gelten:

Niemand aus dem Internet darf eine Verbindung zu unserer Firewall aufbauen. (Wir müssen also alle Pakete die an unserem Internet-Interface (ppp0) ankommen, und ein gesetztes SYN-Bit haben, ablehnen.) Wir werden auch nicht auf ping-Pakete antworten, also für ping unsichtbar bleiben. Versucht jemand unsere Regeln zu umgehen, so wird dieser Versuch protokolliert. Versucht jemand eine LAN-Adresse zu emulieren, und uns somit vorzutäuschen dass er ein Rechner aus unserem lokalen Netz ist (sollte also jemand ip-spoofing betreiben), so wird auch das mitgelogt. Der Zugang aus unserem LAN ins Internet soll uneingeschränkt möglich sein.

Und hier nun das dazugehörige Firewall-Initialisierungs-Script:


ipchains -F
ipchains -P input DENY
ipchains -P output ACCEPT
ipchains -P forward ACCEPT


# Niemand aus dem Internet darf eine Verbindung zu uns aufbauen
ipchains -A input -i ppp0 -p tcp -y -j DENY -l


# Aus dem LAN dürfen Verbindungen zu uns aufgebaut werden
ipchains -A input -i eth0 -s $LAN -j ACCEPT


# Maskiere alle Pakete die in das Internet gehen
ipchains -A forward -i ppp0 -p tcp -s $LAN -j MASQ


# De-Maskiere alle Pakete die aus dem Internet kommen
ipchains -A forward -i eth0 -p tcp -d $LAN -j MASQ


# Neue Regelliste für Pakete aus dem Internet
ipchains -N inet_in


# ping ignorieren
ipchains -A inet_in -p icmp --icmp-type echo-request -j DENY -l


# ip-spoofing verhindern
ipchains -A inet_in -p tcp -s $LAN -j DENY -l


# unnötige Protokolle abblocken und mit-logen
ipchains -A inet_in -p idp -j DENY -l
ipchains -A inet_in -p udp -j DENY -l


# alles was bisher nicht abgelehnt wurde, akzeptieren
ipchains -A inet_in -j ACCEPT


# alles was am Modem ankommt, in die neue Regelliste senden
ipchains -A input -i ppp+ -j inet_in

 

 

4.8 Aktives FTP und Masquerading

Schwierig wird es beim aktiven FTP, wie es die meisten Kommandozeilen FTP-Clients benutzen. Im Gegensatz zum passiven FTP der gängigen Browser, baut beim aktiven FTP der Server von Port 20 aus eine Verbindung zum Client im LAN auf, um darüber die Daten zu übertragen, nachdem ihn der Client auf Port 21 dazu aufgefordert hat. Bei maskierten IP-Adressen funktioniert das nicht, da der Server die tatsächliche IP-Adresse des Client nicht kennt. Ausserdem darf die Firewall in diesem Fall keine Pakete aus dem Internet mit gesetzten SYN-Bit ablehnen, was sie aus Sicherheitsgründen häufig tut.

Um trotz dem aktives FTP zu ermöglichen, müssen sie mit dem Befehl "insmod ip_masq_ftp" das Kernel-Modul ip_masq_ftp laden, dass im Grunde ein kleines Application Leven Gateway darstellt. Dieses Modul erwartet den Aufbau einer FTP-Datenverbindung vom Port 20 eines FTP-Servers und setzt die Empfängeradresse korrekt um, so das es den Client der die Verbindung auf Port 21 etabliert hat bestimmen kann. Dazu analysiert das Modul den Datenstrom der Kontrollverbindung (vom Client zum FTP-Server) und filtert daraus den Port, den der FTP-Client dem FTP-Server als Ziel-Port für die aufzubauende Datenverbindung mitteilt. Pakete die vom Port 20 des FTP-Servers an diesen Port gerichtet sind, werden dann entsprechend umgesetzt.

Hier sind die Notwendigen ipchains-Regeln, die die Kontroll und Datenverbindung zulassen:


# zuerst erlaubt man den Clients im LAN den Zugang zu FTP-Servern im Internet:
ipchains -A input -s $LAN 1024: --destination-port 21 -p tcp -i $DEV_LAN -j ACCEPT
ipchains -A forward -s $LAN 1024: --destination-port 21 -p tcp -i $DEV_INET -j MASQ
ipchains -A output -s $IP_INET 1024: --destination-port 21 -p tcp -i $DEV_INET -j ACCEPT


# dann lässt man die Antwortpakete durch, die nicht zum Verbindungsaufbau dienen dürfen
ipchains -A input --source-port 21 -d $IP_INET 1024: -p tcp -i $DEV_INET -j ACCEPT ! -y
ipchains -A output --source-port 21 -d $LAN 1024: -p tcp -i $DEV_LNET -j ACCEPT ! -y


# und danach sorgt man noch für die Datenübertragung (und erlaubt den Verbindungsaufbau,
# da dieser zwingend notwendig ist)
ipchains -A input --source-port 20 -d $IP_INET 1024: -p tcp -i $DEV_INET -j ACCEPT
ipchains -A output --source-port 20 -d $LAN 1024: -p tcp -i $DEV_LAN -j ACCEPT
ipchains -A input -s $LAN 1024: --destination-port 20 -p tcp -i $DEV_LAN -j ACCEPT ! -y
ipchains -A forward -s $LAN 1024: --destination-port 20 -p tcp -i $DEV_INET -j ACCEPT ! -y
ipchains -A output -s $IP_INET 1024: --destination-port 20 -p tcp -i $DEV_INET -j ACCEPT ! -y

 

 

4.9 Transparenter Proxy

Um einen transparenten Proxy zu implementieren, empfehle ich folgendes Initialisierungs-Script:


ipchains -A input -s $LAN 1024: --destination-port 80 -p tcp -i $DEV_LAN -j REDIRECT 3128
ipchains -A output --source-port 80 -d $LAN 1024: -p tcp -i $DEV_LAN -j ACCEPT ! -y

Beschreibung: Das Sprungziel "-j REDIRECT 3128" weist den Kernel an, alle an den WWW-Port 80 eines beliebigen Rechners gerichteten Pakete an den lokalen Port 3128 zu senden, auf dem squid Anfragen entgegen nimmt.

Zuvor sollten sie allerdings den www-Proxy squid auf der Firewall installieren, und folgende Konfiguration an ihm in der Datei squid.conf vornehmen:


http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on

Und auch im Kernel sollten sie "transparent proxying" aktiviert haben.

 

 

4.10 Die log Regel

An das Ende jeder standard Regelliste sollte man die "mit-logen" Regel setzen.


ipchains -A input -l
ipchains -A forward -l
ipchains -A output -l

Nur so kann gewährleistet werden, dass die Pakete, die aus unbekannten Gründen durch die Regellisten durchgefallen sind ohne bearbeitet worden zu sein, vom Administrator erkannt werden, da sie in die Datei /var/log/messages von syslogd eingetragen werden. Der Administrator wird dann entsprechende Regeln hinzufügen, die in Zukunft auch diese Pakete behandeln.

Folgender Eintrag könnte zum Beispiel in /var/log/messages auftauchen:

packet log: input DENY eth0 PROTO=17 192.168.0.15:53 192.168.0.1:1025 L=34 S=0x00 I=18 F=0x0000 T=254

Dieser Eintrag würde vom Administrator wie folgt interpretiert werden:

Ein UDP-Paket (Protokoll 17), das über die Netzwerkkarte eth0 vom Rechner 192.168.0.15 Port 53 (DNS) auf die Firewall (192.168.0.1 Port 1025) gelang wurde dort von der input Regelliste abgelehnt. Die Anderen Angaben beschreiben die Größe des Pakets (L), den ToS (S), die IP-ID (I), den Status bezüglich der Fragmentierung (F) und die Lebensdauer des Pakets (T).

 

 

 

4.11 Das ToS-Feld

Mit der Option -t kann ipchains das ToS-Feld (Type of Service) von IP-Paketen manipulieren. Dieses ToS-Feld beeinflusst die Art wie diese Pakete durch das Netz transportiert werden.

Die vier möglichen besetzungen des ToS-Feldes:

Besetzung

Auswirkung

0x01 0x10

Geringste Verzögerung (z.B. telnet, WWW)

0x01 0x08

Maximaler Datendurchsatz (z.B. FTP)

0x01 0x04

Maximale Zuverlässigkeit (z.B. SNMP)

0x01 0x02

Minimale Kosten (z.B. News)

 

Wollen sie z.B. das ToS-Feld aller Pakete, die an den WWW-Port 80 gerichtet sind, auf Maximalen Datensurchsatz stellen, so benutzen sie folgenden Befehl:

ipchains -A output -p tcp --destination-port 80 -t 0x01 0x08

 

 

4.12 Mit Port Forwarding Arbeit verteilen

Soll sich ein anderer Server im LAN mit der IP-LAN-Adresse WORKER_IP_LAN um die Bearbeitung von WWW-Anfragen (Port 80) kümmern, so können sie mit folgendem Befehl die Anfragen die an die Firewall gerichtet waren von der Firewall auf diesen Rechner leiten:

ipmasqadm portfw -a -P -tcp -L $IP_LAN 80 -R $WORKER_IP_LAN 80

 

Nun benötigt die Firewall aber noch die ipchains-Regeln, die Anfragen am Port 80 akzeptieren, und die Pakete an den anderen Server abgeben:


ipchains -A input -d $IP_INET 80 -p tcp -i $DEV_INET -j ACCEPT
ipchains -A output -d $WORKER_IP_LAN 80 -p tcp -i $DEV_LAN -j ACCEPT

 

Natürlich müssen auch die Antworten des Servers wieder ins Internet gelangen:


ipchains -A input -s $WORKER_IP_LAN 80 -p tcp -i $DEV_LAN -j ACCEPT ! -y
ipchains -A forward -s $WORKER_IP_LAN 80 -p tcp -i $DEV_INET -j MASQ ! -y
ipchains -A output -s $IP_INET 80 -p tcp -i $DEV_INET -j ACCEPT ! -y

 

 

4.13 Abwehr bestimmter Angriffe

Damit sie überhaupt merken dass sie angegriffen wurden, sollten sie hinter jedes DENY ein -l schreiben, um das erfolgreich abgewehrte Paket in der Log-Datei zu vermerken.

Nicht jedes dadurch mit-gelogte Paket ist auch ein Angriff gewesen. Manchmal benutzt nur einer der Anwender der Clients im LAN ein seltenes Protokoll, welches ähnlich dem FTP-Protokoll eine Verbindung von aussen zum Client aufbauen muss. Bei der Regel die dieses Paket mit-gelogt hat können sie das -l beruhigt entfernen und den Paketen keine weitere Beachtung schenken.

Vergessen sie bitte auch nicht, dass sie damit nur die Angriffe mitlogen, die erfolgreich abgewehrt wurden. Falls wirklich eine Sicherheitslücke in der Konfiguration ihrer Firewall existiert, so wird diese ihnen damit nicht auffallen.

 

 

 

4.13.1 ICMP

Das ICMP Protokoll dient der Übermittlung von Statusmeldungen zu Routern oder Rechnern.

Hier ist eine Liste der möglichen ICMP-Flags, die sie mit ipchains und der Option

-icmp-type <Name des Typs/Nummer des Typs> einzeln aktivieren oder deaktivieren können. Somit ist es ihnen relativ einfach möglich, die Firewall zum Beispiel vor einem ping zu verstecken. Ein möglicher Angreifer im Internet wird es als schwer haben zu bemerken, dass ihre Firewall am Internet angeschlossen ist.

 

Paket-Typ

Name

Funktion

0

echo-reply

ping-Signal beantworten

3

destination unreachable

Keine Route gefunden

5

redirect

Router sendet neue Zieladresse

8

echo request

Ping-Signal senden

11

time exceed

Route zu lang, zu viele Hops

(Eine ausführlichere Liste erhalten sie durch Eingabe von: ipchains -h icmp)

 

4.13.2 Verbindungspakete

Damit ein Rechner eine Verbindung zu einem anderen Rechner aufbauen kann, muss er den Wunsch zum Verbindungsaufbau durch in IP-Paket mit gesetzten SYN-Bit äußern. Nur wenn der Server, zu dem eine Verbindung aufgebaut werden soll, dieses Paket akzeptiert, kann eine Verbindung aufgebaut werden. Der Server kann aber auch alle Pakete mit gesetzten SYN-Bit ignorieren, und somit verhindern, dass anderen Rechner zu ihm eine IP-Verbindung aufbauen.

Wenn die Firewall also alle IP Pakete die aus dem Internet an sie gesendet werden ignoriert, die ein gesetes SYN-Bit haben, dann kann sie so verhindern dass ein möglicher Angreifer aus dem Internet eine Verbindung zu ihr aufbaut.

 

 

4.14 Das Testen der Firewall

Nach einer Veränderung an der Konfiguration der Firewall ist es oft notwendig, diese zu testen. Damit sie nicht zu allen Clients im LAN laufen müssen, und bei jedem einzeln überprüfen ob seine Pakete auch wirklich durch durch die Firewall gelangen, können sie den Paketdurchlauf mit ipchains simulieren.

Beispiel:

ipchains -C input -i eth0 -p tcp -y -s 192.168.0.5 80 -d 192.168.0.1 1044

P>Diese Befehlszeile überprüft, ob die input Regelliste ein TCP-Paket von Port 80 des Rechners 192.168.0.5, das eine Verbindung aufbauen möchte und über die erste Ethernetkarte mit dem Ziel 192.168.0.1 Port 1044 ankommt, akzeptieren würde.

Um eine noch ausführlichere Ausgabe zu erhalten können sie zusätzlich -v verwenden. Also:

ipchains -v -C <Name der Liste> <Paketbeschreibung> ...

 

5. Quellen:


Henning Emmerich, "Netzwerk in Ketten", c´t 17/1999, S. 194
David Ranch, Ambrose Au, "Linux IP Masquerade mini HOWTO"
Frank Bernhard, "Brandschutz-2.2", Linux-Magazin 6/99, S.86

 

6. GNU GENERAL PUBLIC LICENSE

Version 2, June 1991 

Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Preamble

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. 

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. 

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. 

For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. 

We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. 

Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. 

Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. 

The precise terms and conditions for copying, distribution and modification follow. 

TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". 

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 

1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. 

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: 
 
 

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. 

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. 

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. 

If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 

4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 

5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. 

If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. 

It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. 

This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 

8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 

9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. 

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 

10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. 

NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
 

END OF TERMS AND CONDITIONS



Feedback ist wichtig für die Verbesserung des Service
Autor: Samuel Stähle
Datum: 17. April 2000 - Pro-Linux