Online Suche im Handbuch

LITTLE-IDIOT NETWORKING

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