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.
Bei dem Zugriff auf Server hat man es mit vielen Clients <strong>und</strong> wenigen IP - Nummern sowie<br />
Ports zu tun. Es müssen die Ports 80 <strong>und</strong> 21 <strong>für</strong> Zugriffe aus dem Internet freigeschaltet<br />
werden. Nur in Ausnahmefällen sollten weitere Ports, z.B. <strong>für</strong> SQL zugelassen werden.<br />
Hier<strong>für</strong> reichen erstaunlich wenige Regeln völlig aus. Etwas problematisch ist die große<br />
Zahl von Zugriffen pro Sek<strong>und</strong>e, die auf die Server einstürmen. Die <strong>Firewall</strong> muß also<br />
Tausende von simultanen Zugriffen pro Sek<strong>und</strong>e im RAM verwalten können. Hierzu muß<br />
der <strong>LINUX</strong> Kernel speziell <strong>für</strong> eine große Zahl von halboffenen Verbindungen vorbereitet<br />
werden. Hierzu ist die Variable SOMAXCONN in der Datei<br />
/usr/src/linux/include/linux/socket.h von 128 auf eine höhere Zahl gesetzt werden. Bevor<br />
man aber den Maximalwert von 65535 einsetzt, sollte man sich überlegen, wieviel RAM<br />
jede halboffene Verbindung verbraucht. Reicht das RAM nicht aus, so fängt die <strong>Firewall</strong><br />
an, den SWAP Speicher zu bemühen, was zu einem völligem Performanceeinbruch<br />
führen kann. Jede TCP - Verbindung beansprucht im RAM einen Puffer, der bei <strong>LINUX</strong> je<br />
nach Kernel-Version <strong>und</strong> Prozessortyp schwankt. Der Standardwert liegt bei etwas über 1<br />
KByte. Die Werte schwanken jedoch auch von Betriebssystem zu Betriebssystem.<br />
Genaue Angaben von kommerziellen Herstellern bekommt man derzeit nur von SUN oder<br />
halt von OpenSource <strong>Firewall</strong>s, wie TIS FWTK (NAI), JUNIPER <strong>Firewall</strong> oder<br />
GENUAWALL.<br />
Unter NT sind solche Angaben nur schwierig zu bekommen.<br />
Problematisch ist der Zugriff von Browsern auf Server über die <strong>Firewall</strong> hinweg. in vielen<br />
Fällen öffnet der Browser viele simultane Verbindungen zum Server. Spricht der Server<br />
nur HTTP 1.0, dann wird die <strong>Firewall</strong> erheblich belastet. Im Falle dessen, daß die Server<br />
mit neueren IIS / APACHE Servern ausgerüstet sind, die HTTP 1.1 konform sind, werden<br />
alle Grafiken <strong>und</strong> HTML Seiten in einen einzigen Datenstrom (TCP Verbindung) verpackt.<br />
Wie man sieht, hängt die Leistung der <strong>Firewall</strong> auch von den WWW-Servern hinter der<br />
<strong>Firewall</strong> <strong>und</strong> den Clients ab. Man sollte auch bedenken, daß pro Client stets zwei TCP<br />
Verbindungen auf der <strong>Firewall</strong> initiiert werden, einmal zum Client <strong>und</strong> weiterhin zum<br />
WWW-Server. Bei 50.000 offenen Zugriffen auf eine Serverfarm müssen also mindestens<br />
100.000 simultane TCP Verbindungen offengehalten werden können. Hier ist eine RAM<br />
Ausstattung von 128 MByte das Minimum, sofern alle Server HTTP 1.1 konform sind.<br />
Hinzu kommt, daß z.B. <strong>für</strong> jede Initiierung einer Verbindung alle <strong>Firewall</strong>regeln durchlaufen<br />
werden müssen. Eine scheinbar langsame 2 MBit Anbindung kann aber eine <strong>Firewall</strong> in<br />
erhebliche Bedrängnis bringen, zumal es nur einiger h<strong>und</strong>ert Byte bedarf (abhängig von<br />
der MTU) um eine halboffene Verbindung zu initiieren. Diese scheinbar geringe<br />
Bandbreite von 2 MBit reicht bei einem DoS Angriff z.B. aus, um die <strong>Firewall</strong> mit einigen<br />
h<strong>und</strong>ert neuen Verbindungen pro Sek<strong>und</strong>e zu traktieren.<br />
Hierbei spielen die Timeout Einstellungen bei halboffenen Verbindungen eine große Rolle.<br />
Fast alle <strong>Firewall</strong>s sind auf einige Minuten bis St<strong>und</strong>en standardmäßig eingestellt. Diesen<br />
sollte man unbedingt auf wenige Sek<strong>und</strong>en heruntersetzen, auch wenn man in Gefahr<br />
läuft, daß Teilnehmer aus langsamen Netzwerken keine Verbindung mehr aufbauen<br />
können.<br />
Hier kommt es also entschieden auf die Intelligenz des TCP/IP Stacks an. FAST<br />
RETRANSMIT, SACK ....sind Begriffe die alle mit intelligentem Timing <strong>und</strong> Timeouts zu<br />
tun haben. Wer also sicher sein möchte, daß keine der o.a. Probleme entstehen sollten,<br />
der sollte BSD UNIX, SOLARIS 2.6/2.7, <strong>LINUX</strong> <strong>2.2</strong> Kernel, OS/2 oder die SF <strong>Firewall</strong><br />
unter <strong>LINUX</strong> einsetzen. <strong>LINUX</strong> <strong>2.0</strong> mit IPFWADM oder IPCHAINS ist hier<strong>für</strong> völlig<br />
ungeeignet, ebenso wie alle Windows NT basierten <strong>Firewall</strong>s, da NT nicht über intelligente<br />
Mechanismen, wie FAST RETRANSMIT, SACK ... verfügt. Für den Einsatz im Intranet<br />
oder als <strong>Firewall</strong>-Router zur Anbindung eines Unternehmens spielen diese Betrachtungen<br />
keine Rolle.<br />
Das größere Problem bei ISP´s ist die Speicherung von LOG-Dateien. Intelligente DoS<br />
Angriffe können bei einer 2 MBit Anbindung dazu führen, daß jede Sek<strong>und</strong>e die Daten von<br />
500 neuen Verbindungen gespeichert werden müssen. Das sind pro Tag ca. 2 GByte an<br />
Daten. Es reicht also, die <strong>Firewall</strong> mit 100 GByte Festplattenplatz auszurüsten. Billige AT-<br />
Erstellt von Doc Gonzo - http://kickme.to/plugins
Change language