Firewall Handbuch für LINUX 2.0 und 2.2 - zurück
Firewall Handbuch für LINUX 2.0 und 2.2 - zurück
Firewall Handbuch für LINUX 2.0 und 2.2 - zurück
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Diese Regel hatten wir eingeführt, damit die Pakete aus dem Intranet aus dem externen<br />
Interface in das Internet gelangen können. Angreifer aus dem Internet werden ja von der<br />
default policy abgelehnt, da ja keine der Regeln auf dieses Paket zutreffen würde.<br />
Allerdings gibt es eine Ausnahme: Pakete, die als Quelladresse eine IP - Nummer aus<br />
dem Intranet besitzen, werden von dem externen Interface akzeptiert <strong>und</strong> weitergeleitet.<br />
Diese Pakete sind gespoofte Pakete, die Cracker synthetisch erzeugen. Hierzu müssen<br />
Sie routingtechnisch näher an die <strong>Firewall</strong> heran, um ihren Angriff zu starten. Diese<br />
Möglichkeit, gespoofte Pakete in das Intranet senden zu können widerspricht völlig der<br />
default policy. Diese besagt, daß alles verboten ist, was nicht ausdrücklich erlaubt ist !<br />
Demnach darf das Netzwerkinterface EXTERNES_INTERFACE entsprechend der Regel<br />
9 keine Pakete annehmen, sondern nur aussenden. Also gibt es kein Problem ? Hier ist<br />
es:<br />
Regel 10 besagt, daß das externe Netzwerkinterface, EXTERNES_INTERFACE aber<br />
dann Pakete forwarden, also weiterleiten darf, wenn diese aus dem Intranet stammen,<br />
also auch wenn diese von INTRA1 stammen. Weiterleitung von EXTERNES_INTERFACE<br />
bedeutet, daß das Paket zwar nicht nach der Regel 9 , aber entsprechend der Regel 10<br />
Zugang zu der <strong>Firewall</strong> findet. Hat es Zugang gef<strong>und</strong>en, dann befindet sich dieses Paket<br />
innerhalb der <strong>Firewall</strong> <strong>und</strong> kann auch wieder entsprechend der Regel 9 die <strong>Firewall</strong><br />
verlassen. Nun hängt es davon ab, welche Zieladresse das Paket besitzt. Ist die<br />
Zieladrese die <strong>Firewall</strong> selber, so kann ein Angreifer auf Dämonen der <strong>Firewall</strong> zugreifen,<br />
da diese sich ja an alle Interfaces geb<strong>und</strong>en haben. Die letzen drei Regeln erlauben es<br />
einem Angreifer, mit Paketen, deren Quelladresse im Intranet liegt, <strong>und</strong> deren Zieladresse<br />
die <strong>Firewall</strong> selber ist, von außen auf die Dämonen der <strong>Firewall</strong> zuzugreifen. Dieses<br />
Vortäuschen nennt man address spoofing. Entsprechend der Regel 7 könnte der Angreifer<br />
direkt seine Pakete an einen Host in dem Intranet adressieren <strong>und</strong> somit auf einen Server<br />
hinter der <strong>Firewall</strong> zugreifen.<br />
Oops ! Das war so nun wirklich nicht beabsichtigt.<br />
Wie ist das Dilemma zu beseitigen ? ?<br />
Kein Problem - Es gibt anti spoofing Regeln, die genau aufpassen, ob es interne oder<br />
externe IP - Nummern sind, die an dem internen oder externen Interface ankommen:<br />
# anti spoofing<br />
ipfwadm -I -a deny -o -W $EXTERNES_INTERFACE -S $INTRANET<br />
ipfwadm -O -a deny -o -W $EXTERNES_INTERFACE -D $INTRANET<br />
Die fügen wir nun (fälschlicherweise) an das Regelwerk an ! Es werden nun alle Pakete<br />
abgelehnt, deren Quelladresse ein Host im INTRANET ist, <strong>und</strong> der über das externe<br />
Interface, EXTERNES_INTERFACE sich Zugriff verschaffen will. Ein - <strong>und</strong> ausgehender<br />
Verkehr mit falschen Absendern an das externe Interface wird geblockt. Zusätzlich ist eine<br />
Option -o eingefügt, die einfach nur besagt, daß Verstöße gegen die <strong>Firewall</strong>regel an den<br />
SYSLOGD gemeldet werden, der diese in die Datei /var/log/messages schreibt. Wer<br />
möchte, daß die Fehlermeldungen an einen weiteren LOGSERVER weitergeleitet werden,<br />
der möge sich mit Hilfe von man syslogd über die Syntax der Konfiguration des<br />
SYSLOGD informieren. Wer nämlich den SYSLOGD mit der Option -r aufruft, der muß<br />
damit rechnen, daß der SYSLOGD sich nicht nur an das LOOPBACK Interface bindet,<br />
sondern auch an die Netzwerkkarte, um von anderen Servern Logmeldungen<br />
entgegenzunehmen. Für eine <strong>Firewall</strong> tödlich ! Zur Auswertung mehrerer <strong>Firewall</strong>s sei der<br />
LOGSurfer von Wolfgang Ley, ehemals DFN-CERT, heute SecureNet, Hambung<br />
empfohlen. Ein sehr mächtiges, <strong>und</strong> zur Überwachung von Netzwerken auch völlig<br />
ausreichendes Werkzeug. Es wird hier<strong>für</strong> auch kommerzieller Support angeboten. Als<br />
Alternative verbleibt nur noch der NFR (Network Flight Recorder) von NAI.<br />
9.9 Die Reihenfolge der Regeln<br />
Erstellt von Doc Gonzo - http://kickme.to/plugins