05.02.2013 Aufrufe

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

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

Arbeitsplätzen im Netz erfolgen. Es existieren nun zwei Möglichkeiten, den Zugriff zu<br />

begrenzen. Die Änderung der <strong>Firewall</strong>regeln, oder die Anpassung des der Datei<br />

/etc/hosts.allow, /etc/hosts.deny <strong>und</strong> der /etc/inetd.conf Datei. Betrachten man nun die<br />

Datei /etc/hosts.allow:<br />

ALL: LOCAL<br />

in.ftpd sshd : ALL<br />

Es wird allen Arbeitsstationen im Netzwerk die Aktivierung der Dämonen in.ftpd <strong>und</strong><br />

sshd erlaubt. (FTP <strong>und</strong> SSH) Betrachten man nun die Datei /etc/hosts.deny:y<br />

ALL: PARANOID<br />

ALL EXCEPT in.ftpd sshd : ALL<br />

Man erreicht mit diesen Einstellungen, daß die <strong>Firewall</strong> ein "double reverse lookup" bei<br />

jedem Verbindungsaufbau durchführt, d.h. den DNS - Namen in eine IP - Nummer auflöst,<br />

mit reverse lookup diese IP - Nummer <strong>zurück</strong> in den DNS - Namen auflöst, <strong>und</strong> vergleicht.<br />

Ist die zugreifende Maschine dann nicht korrekt in die DNS - Server eingetragen, also<br />

nicht offiziell, dann wird die Verbindung abgelehnt. Ein Gr<strong>und</strong> hier<strong>für</strong> kann sein, daß ein<br />

Angreifer versucht, von einem Laptop o.ä. sich Zugang zur <strong>Firewall</strong> zu verschaffen. Im<br />

Internet führt diese Einstellung zu einer erheblichen Belastung der DNS Server, weil<br />

weltweit viele Konfigurationsfehler passieren. Allerdings verbessert diese Einstellung sehr<br />

den Schutz vor Angriffen mit gespooften Adressen. Hierzu muß jedoch der TCPD mit -<br />

DPARANOID neu kompiliert werden. Dies trifft im Übrigen auf die Dämonen zu: APACHE,<br />

SAMBA, BIND, SQUID, mountd...Diese müssen alle mit der eingeb<strong>und</strong>enen libwrap neu<br />

kompiliert werden, damit diese bei jedem Kontakt mit einem Client einen double reverse<br />

lookup durchführt. Der Befehl man tcpd gibt zusätzlich noch genügend Hinweise <strong>für</strong> die<br />

Konfiguration des TCP Wrappers.<br />

Hier noch einige Tips zur Konfiguration der <strong>Firewall</strong><br />

• Die <strong>Firewall</strong>regeln sollten immer nur von einem vollständigen Skript aus<br />

gesetzt werden.<br />

• Es sollte sichergestellt sein, daß alle vorherigen Regeln gelöscht werden.<br />

Dies kann mit: ipfwadm -F/I/O -f geschehen. Um sich davon zu überzeugen,<br />

daß alle Regeln wirklich gelöscht sind, reicht ipfwadm -I/O/F -l aus.<br />

• Man sollte nicht vergessen, vor dem Löschen der Regeln die <strong>Firewall</strong> von<br />

dem ISDN - Router zu trennen. Die default policy ist auch eine Regel. Im<br />

richtigen Moment könnte sonst ein Angreifer durch die <strong>Firewall</strong> tunneln. Dies<br />

ist abhängig davon, ob forwarding im Kernel aktiviert wurde.<br />

• Die <strong>Firewall</strong> sollte niemals ungeprüft an das Internet angeschlossen werden.<br />

Die Philosophie des Herumprobierens, bis es läuft, <strong>und</strong> dann zu testen,<br />

hat schon vielfach zu Einbrüchen geführt. Insbesondere interessieren<br />

sich Hacker <strong>für</strong> neu vergebene IP-Netze <strong>und</strong> Domainnamen (RIPE). Es<br />

dauert mitunter nur St<strong>und</strong>en, bis ein Hacker sein Glück versucht.<br />

• Das Mitloggen von Ereignissen schon zu Beginn kann sehr aufschlußreich<br />

sein, insbesondere auch der internen Pakete. Es sollten stets auch alle Flags<br />

(SYN, ACK) überprüft werden. Mit der Option -o am Anschluß einer jeden<br />

<strong>Firewall</strong>regel wird sichergestellt, daß bei einem Verstoß gegen diese Regel<br />

ein Eintrag im Logfile der <strong>Firewall</strong> erscheint.<br />

• Schon beim Aufbau der <strong>Firewall</strong> sollte die Security Policy aufgestellt sein.<br />

10. Überprüfung der <strong>Firewall</strong>regeln<br />

Es ist immer eine gute Idee, die <strong>Firewall</strong>regeln auch von einer zweiten Person überprüfen<br />

zu lassen, die viel weniger Ahnung hat. Die vielen Fragen, die dann aufkommen, zeigen<br />

dann, ob alles richtig verstanden <strong>und</strong> umgesetzt wurde. Die Befehle lauten:<br />

Erstellt von Doc Gonzo - http://kickme.to/plugins

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!