Firewall Handbuch für LINUX 2.0 und 2.2: Aufbau der LINUX Firewall mit ipfwadm: Regeln für die Netzwerkkarten

9.7 Regeln für die Netzwerkkarten

Nachdem dies schwierige Problem geklärt ist, kann man nun den Datenverkehr zu einer Netzwerkkarte zulassen:


# Erlaube ein- und ausgehenden Verkehr
ipfwadm -I -a accept -W $LOKALES_INTERFACE -S $INTRANET
ipfwadm -O -a accept -W $LOKALES_INTERFACE -D $INTRANET

Dies bedeutet, daß eingehende Pakete "-I" in LOKALES_INTERFACE mit einer beliebigen Quell IP - Nummer "-S" aus dem Bereich INTRANET akzeptiert werden sollen. Ebenso sollen ausgehende Pakete "-O" in das Netzwerk INTRANET zugelassen werden.

Mit LOKALES_INTERFACE ist diejenige Netzwerkkarte gemeint, an der sich die zu schützenden Arbeitsplatz - PCs befinden. Mit INTRANET ist die Netzwerknummer gemeint, die im Intranet vergeben wird. Netzwerknummern besitzen immer eine 0 (Null) als letzte Zahl, z.B. 194.245.123.0 Soweit so gut, betrachten wird nun noch einmal genauer die Dämonen. Wir haben festgestellt, daß sich die meisten Dämonen einfach an alle Interfaces binden, also auch an LOKALES_INTERFACE. Das bedeutet, daß nun alle Dämonen über das LOKALES_INTERFACE von außen erreichbar sind. LOKALES_INTERFACE soll, wie leicht zu erraten ist, diejenige Netzwerkkarte sein, die mit dem INTRANET verbunden ist.

Was nun hervorragend funktioniert, ist der Verkehr zwischen den Arbeitsplatz - PCs und der Firewall auf dem LOKALES_INTERFACE Netzwerk- Interface.

Darüber hinaus sollten Pakete von einem Host in dem Intranet auch an einen anderen Host in dem Intranet weitergeleitet werden können, quasi als Gateway.

Und schon wieder ein neuer Begriff, dem wahrscheinlich schon viele einmal begegnet sind, der jedoch keinem so genau etwas sagt.

Die Angabe eines Gateways auf einem Arbeitsplatz-PC besagt, daß alle ausgehende Pakete zuerst einmal an das Gateway gehen. Das Gateway kann dann entscheiden, ob die Pakete z.B. für das Internet bestimmt sind, oder ob die Zieladresse vielleicht ein Server im Intranet ist. Ist das Paket für das Internet bestimmt, so leitet es das Paket intern an die zweite Netzwerkkarte weiter, die es an den Router übergibt, der es an weitere Router übergibt, bis das Ziel erreicht ist. Damit das Gateway überhaupt entscheiden kann, muß es zuerst einmal gefragt werden. Ist der Verkehr für einen anderen Host im Intranet bestimmt, so läuft folgende Prozedur ab:

INTRA1 sendet ein Paket mit INTRA2 als Zieladresse an das Gateway....das Gateway sendet das Paket....

Ooops, wäre das nicht eine völlig Verschwendung von Bandbreite und CPU - Zeit in der Firewall ? Wenn der Verkehr von INTRA1 über das Gateway zu INTRA2 laufen würde, wäre die Aussage korrekt. Dem ist aber nicht so. Das Interface LOKALES_INTERFACE erkennt, daß Quell - und Zieladressen des Paketes von Intra1 innerhalb der Netzwerkadresse von LOKALES_INTERFACE, also im INTRANET liegen. Die Netzwerkkarte leitet diese Pakete erst gar nicht an den Kernel weiter. Die Netzmaske ist hierfür verantwortlich und schirmt den Kernel ab. Derjenige Host, der gemeint ist, also INTRA2, wird schon auf die Anfragen von INTRA1 antworten. Also akzeptiert das Gateway nur dann die Daten zur Weiterleitung, wenn die Zieladresse nicht im Intranet liegt.

Zusammenfassend kann man also sagen, daß ein Gateway darüber entscheidet, ob Pakete im Netzwerkstrang bleiben, oder ob diese in andere Netzwerke weitergeleitet werden.

Bisher wurde der Firewall aber nur mitgeteilt, daß sie Pakete, deren Quell Adresse im Intranet liegt, zu akzeptieren hat. Sie würde also das Paket von INTRA1 akzeptieren, sofern die Zieladresse nicht auch im Intranet liegt. Danach gibt es keine Regel mehr, die der Firewall sagen könnte, was mit dem Paket geschehen soll. Wir erinnern uns - Die Weiterleitung von Paketen, also das forwarding wurde mit ipfwadm -F -p deny, der default policy untersagt. Pakete aus dem Intranet sollen aber auch an das externe Interface der Firewall weitergeleitet werden. hierzu müssen wir eine weitere Regel hinzufügen.


# Erlaube Internet - Datenaustausch
ipfwadm -O -a accept -W $EXTERNES_INTERFACE -S $INTRA1

Etwas verwirrend mag die Reihenfolge der Regeln erscheinen. Zuerst werden alle Pakete abgelehnt, um diese dann durch eine nachfolgende Regel wieder zuzulassen. Hierzu muß man nur eines wissen. Firewalls arbeiten alle Regeln immer nur bis zu einem Match (zutreffende Regel) ab. Findet sich in der Reihe zuerst eine Regel, die die Weiterleitung zuläßt, so wird weitergeleitet. Wenn die Regel keine Weiterleitung zuläßt, dann wird das Paket verworfen und die folgenden Regeln nicht weiter abgearbeitet. Trifft keine der Regeln zu, dann wird es interessant. Der Kernel führt dann diejenige Regel aus, die der Policy entspricht. Steht die Policy auf allow, dann wird das Paket weitergeleitet, steht die Policy auf deny, dann wird das Paket verworfen. Also Achtung beim Hinzufügen oder Löschen von Regeln, wenn die default policy nicht auf deny steht. Das setzen der Policy auf deny sollte also unbedingt und unter allen Umständen zu allererst in den Firewallregeln erfolgen. Diese müssen sogar zu allererst gesetzt werden.

Nun erlauben wir den Zugriff eines Hosts mit der IP - Nummer INTRA1 aus dem INTRANET auf die äußere Netzwerkkarte, EXTERNES_INTERFACE. Was bedeutet nun dieses ? Ein Host aus dem Intranet mit INTRA1 bezeichnet darf Pakete an LOKALES_INTERFACE, also der inneren Netzwerkkarte senden. Soweit verständlich. Der Firewall wurde erlaubt, an dem Interface LOKALES_INTERFACE Pakete anzunehmen, die für das Internet bestimmt sind. Soweit auch verständlich. Nun wird zugelassen, daß die Firewall diese angenommenen Pakete aus dem Intranet an das äußere Interface EXTERNES_INTERFACE sendet. Die Syntax lautet:

Erlaube eingehende und ausgehende Pakete mit dem Ziel EXTERNES_INTERFACE, und das für Pakete, die aus dem Intranet kommen. Die Firewall durfte stets Pakete aus dem Intranet annehmen, nun ist es der Firewall erlaubt, diese Pakete an die äußere Netzwerkkarte zu senden.

Wie verhalten sich die Dämonen ? Diese hatten sich ja an alle Netzwerkkarten gebunden !? Sie sehen die Pakete vorbei huschen, fühlen sich aber nicht angesprochen, da die Zieladresse im Kopf des Paketes von dem Host aus dem Intranet ja für das Internet bestimmt ist, und nicht für den Dämon selber. Also kein echtes Problem.

Welche Auswirkungen hat dies auf das forwarding ?


#Forwarding von Paketen von LOKALES_INTERFACE an EXTERNES_INTERFACE
ipfwadm -F -a -W $EXTERNES_INTERFACE -S $INTRANET

Es wird der Firewall erlaubt, Pakete mit Quelladresse INTRANET "-S" an das Interface EXTERNES_INTERFACE, also dem äußeren Interface, weiterzuleiten. Oops, etwas verwirrend.....

Schauen wir uns die Regeln noch einmal in der Zusammenfassung an:


  # Default Policy
1 ipfwadm -I -p deny
2 ipfwadm -O -p deny
3 ipfwadm -F -p deny

  # Das loopback Interface
4 ipfwadm -I -a accept -W $LOOPBACK 
5 ipfwadm -O -a accept -W $LOOPBACK

  # Erlaube ein- und ausgehenden Verkehr
6 ipfwadm -I -a accept -W $LOKALES_INTERFACE -S $INTRANET
7 ipfwadm -O -a accept -W $LOKALES_INTERFACE -D $INTRANET

  # Erlaube Internet - Datenaustausch mit einem Host aus dem Intranet
8 ipfwadm -O -a accept -W $EXTERNES_INTERFACE -S $INTRANET
9 ipfwadm -I -a accept -W $EXTERNES_INTERFACE -S $INTRANET

  # Forwarding von Paketen von LOKALES_INTERFACE an EXTERNES_INTERFACE
10 ipfwadm -F -a -W $EXTERNES_INTERFACE -S $INTRANET

In Regel 6 und 7 finden sich weitere Parameter. Der Parameter -S in Regel 6 besagt, daß die Pakete mit Quelladresse (-S = Source) aus dem Intranet auf das LOOPBACK INTERFACE zugreifen dürfen. In Regel 7 ist der Parameter -D dafür da, um die Zieladresse (-D = Destination) zu bestimmen. Normalerweise müßte man immer genau angeben, von wo und nach wo. Wenn aber einer der Parameter -S oder -D weggelassen wird, dann ist in Gedanken immer ein -S 0/0 oder ein -D 0/0 hinzuzufügen. Alternativ kann man auch 0.0.0.0 statt 0/0 schreiben. Dies ist der Ersatz für: von überall oder nach überall. Die Regel 6 müßte also genau heißen:

6 ipfwadm -I -a accept -W $LOKALES_INTERFACE -S $INTRANET -D 0.0.0.0

oder

6 ipfwadm -I -a accept -W $LOKALES_INTERFACE -S $INTRANET -D 0/0

Alle drei Schreibweisen sind identisch.

Online Suche im Handbuch

LITTLE-IDIOT NETWORKING