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
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
33. <strong>Firewall</strong> Auditing<br />
:windows-color (green)<br />
)<br />
)<br />
:track (<br />
: Long<br />
)<br />
:install (<br />
: (Gateways<br />
:type (gateways)<br />
:color ("Navy Blue")<br />
:icon-name (icon-gateways)<br />
)<br />
)<br />
:time (<br />
: Any<br />
)<br />
)<br />
: (rule-2<br />
:src (<br />
: Any<br />
)<br />
:dst (<br />
: Any<br />
)<br />
:services (<br />
Die Überprüfung der <strong>Firewall</strong> ist eine ebenso komplexe wie zeitraubende Angelegenheit.<br />
Wie schwierig dies ist, <strong>und</strong> wieviele Fehler möglich sind, mag ein Beispiel zeigen. Seit<br />
Jahren lieferte CHECKPOINT <strong>Firewall</strong>s aus, viele dieser Installationen wurden von<br />
unabhängigen Experten überprüft, <strong>und</strong> <strong>für</strong> sicher bef<strong>und</strong>en. Niemand hatte über Jahre<br />
hinweg auch nur daran gedacht, neben den TCP/IP Ports auch das SMNP Protokoll zu<br />
überprüfen. Hacker konnten so über Jahre hinweg bei einigen Installationen sämtliche<br />
Statistiken z.B. der Mail-Übertragungen über die <strong>Firewall</strong> hinweg einsehen. Die Mail -<br />
Adressen sämtlicher K<strong>und</strong>en war dort aufgelistet. Auch die sogenannte<br />
Zertifizierungsstellen hatten diesen Test nicht durchgeführt. Bekannt wurde dieser Fehler<br />
erst über die BUGTRAQ Liste, woraufhin Checkpoint auch schnell reagierte, <strong>und</strong> die<br />
Standardeinstellung <strong>für</strong> SMNP des externen Interfaces auf "AUS" stellte. Andere <strong>Firewall</strong>-<br />
Installationen wurden <strong>für</strong> sicher bef<strong>und</strong>en, obwohl viele der Angriffe via E-Mail über die<br />
Arbeitsstationen <strong>und</strong> die Makrofunktionen ausgeführt wurden (Siehe MELISSA). Es dürfte<br />
jedem klar sein, daß eine <strong>Firewall</strong> niemals Schutz bietet, sondern nur ALARM -<br />
MELDUNGEN an den Systemadministrator weitergeben kann. Diese richten sich nach der<br />
Security Policy <strong>für</strong> das Netzwerk <strong>und</strong> die User. Damit dieser Mechanismus auch korrekt<br />
arbeiten kann, müssen zuerst alle Ports überprüft werden. Hierzu werden alle Zielports<br />
von 0-65535 der Reihe nach gescannt. Viele <strong>Firewall</strong>s haben jedoch einen Scanner<br />
Detektor <strong>und</strong> schießen die Verbindung vom Scanner-Host schon nach 2 durchgescannten<br />
Ports <strong>und</strong> Melden einen Scanner-Angriff an den Systemadministrator. Hierbei kann der<br />
Portscanner nicht mehr entdecken, daß z.B. Port 25 oder 23 weit offensteht, weil die<br />
<strong>Firewall</strong> jeden Kontakt unterbrochen hat. Ein andere Fall ist das jüngste Ereignis mit dem<br />
TCPWRAPPER von Wietse Venema, dessen Quellcode von einem Hacker manipuliert<br />
wurde. Dieser reagierte auf normale Portscans völlig korrekt, nur wenn der Portscann von<br />
einem 400er Port aus initiiert wurde, dann öffnete sich eine ROOT-Shell. Das bedeutet<br />
Erstellt von Doc Gonzo - http://kickme.to/plugins
Change language