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.
Sie werden sehen, daß plötzlich der SQUID PROXY gegenüber allen mir bisher<br />
bekannten Distributionen (S.u.S.E. -6.2 <strong>und</strong> RedHat -6.1) erheblich beschleunigt wird. Die<br />
Performanceverbesserungen sind so dramatisch, daß Sie durchaus ca. 150 Arbeitsplätze<br />
über eine ISDN Leitung an das Internet anbinden können, ohne daß jemand einschläft.<br />
Ein Problem sollten Sie jedoch berücksichtigen. Mit Hilfe der TOS Flags sollten Sie den<br />
FTP Traffic über den <strong>LINUX</strong> ISDN <strong>Firewall</strong>proxy gegenüber HTTP mit einer niedrigeren<br />
Priorität ausstatten, damit bei längeren FTP-Downloads alle User ohne merkliche<br />
Performance-Einbußen surfen können. Für 2 MBit Anbindungen mit vielen h<strong>und</strong>ert DIAL-<br />
IN´s sollten diese Einstellungen ebenfalls ausreichen, allerdings sollte man dem PROXY<br />
CACHE ein RAID System auf SCSI Basis <strong>und</strong> viel mehr RAM spendieren.<br />
Die Variable SOMAXCONN ist da<strong>für</strong> zuständig, die maximale Zahl der halboffenen<br />
Verbindungen (Siehe SYN-ACK Mechanismus bei der SINUS <strong>Firewall</strong>) begrenzt wird. Für<br />
jede angeforderte Verbindung einer Arbeitsstation über die <strong>Firewall</strong> oder über den PROXY<br />
müssen 2 Handels angefordert werden, einen nach innen, <strong>und</strong> einen nach außen. <strong>LINUX</strong><br />
<strong>2.0</strong> <strong>und</strong> <strong>2.2</strong> hat jedoch eine Beschränkung auf maximal 1024 Prozesse, bzw. maximal<br />
1024 Threads. Damit noch etwas Raum <strong>für</strong> interne Prozesse <strong>und</strong> Dämomen übrig bleibt,<br />
solle man nicht erlauben, daß ein Angreifer mehr als 400-500 Handels verbrauchen kann.<br />
Wichtig ist auch, daß ausreichend RAM zur Verfügung steht. Mehr als 64 MByte ist jedoch<br />
nicht notwendig, egal wie viele Clients auf den PROXY zugreifen.<br />
Sie sehen, daß man, wenn man einen <strong>LINUX</strong> PROXY oder <strong>LINUX</strong> ISDN-Router aufbaut,<br />
fast alle Software (Kernel <strong>und</strong> Dämonen/Dienste) neu kompilieren muß.<br />
21.5 ATM Netzwerke mit <strong>LINUX</strong> <strong>Firewall</strong>s<br />
ATM Netzwerke besitzen völlig eigene Protokolle, die mit <strong>LINUX</strong> (noch) nicht zu handeln<br />
sind. Auch wenn es bereits ATM Karten (FORE) unter <strong>LINUX</strong> gibt, so bedeutet dies nur,<br />
daß hierüber eine physikalische Verbindung zwischen zwei <strong>LINUX</strong> Servern hergestellt<br />
werden kann, auf welcher TCP/IP übertragen wird. Aufgr<strong>und</strong> der hohen Nettotransferrate<br />
bei ATM (155 MBit) scheitert der Einsatz einer <strong>LINUX</strong> <strong>Firewall</strong> an dem Durchsatz des PCI-<br />
BUS. Dennoch sind in zahlreichen Firmen bereits SINUS <strong>Firewall</strong>-1 Cluster im Einsatz, die<br />
jeweils an den 100 MBit Ausgängen der ATM Router/Switches aufgebaut sind. Hiermit läßt<br />
sich der gesamte Verkehr von Switches überwachen. Eine vergleichbare Lösung wird<br />
bisher nur von BAY NETWORKS <strong>und</strong> CHECKPOINT angeboten. Über deren Performance<br />
bei Vollast läßt sich noch keine Aussage machen. Die Performance der SINUS <strong>Firewall</strong>-1<br />
auf DEC ALPHA oder Pentium 400 mit je 2x 100 MBit Karten reicht jedoch völlig aus,<br />
sodaß auch bei komplexen <strong>Firewall</strong>regeln die Switches nicht gebremst werden. Es liegen<br />
Performance Analysen vor, jedoch können hieraus leider keine Schlußfolgerungen auf<br />
bereits installierte Netzwerke gezogen werden, da die Unterschiedlichkeit der Protokolle<br />
<strong>und</strong> Pakete stark schwankt. In jedem Falle sollte man pro 100 MBit Port des Switch eine<br />
<strong>Firewall</strong> mit 3 x 100 MBit Karten (+1x 100 MBit <strong>für</strong> Kommunikationsbackbone) einplanen.<br />
Die Kosten pro Port liegen bei ca. 1000 DM. Auf diese Weise lassen sich auch sehr<br />
schnelle Netzwerke mit Geschwindigkeiten jenseits der GIGABIT Grenze kontrollieren.<br />
<strong>LINUX</strong> besitzt allerdings einen Fehler im Kernel, der die sogenannten large frames (MTU<br />
> 9000) nicht filtert, also Vorsicht. Genauere Hinweise finden sich im Kapitel über<br />
Fallstricke bei Kerneloptionen<br />
21.6 Verbrauch an CPU Zyklen pro Paket<br />
Für Hispeed Netzwerke im Bereich GIGABIT ist es unerläßlich, genaue Informationen<br />
über die Transferrate pro Paket im Kernel zu erfahren. Es liegen genaue Meßwerte <strong>für</strong><br />
sämtliche BSD Betriebssysteme vor, darunter SUN OS, FreeBSD, NetBSD <strong>und</strong><br />
OpenBSD. Für die <strong>LINUX</strong> <strong>2.2</strong>.x Kernel können die Werte übernommen werden, da<br />
inzwischen große Teile des TCP/IP Stacks aus BSD implementiert worden sind. <strong>LINUX</strong><br />
<strong>2.0</strong> ist hier um Faktoren 2-15 langsamer. Von Interesse ist hier oft die Zahl der CPU<br />
Zyklen, die von dem Berkley Paket Filter <strong>für</strong> die Weiterleitung von Paketen verbraucht<br />
Erstellt von Doc Gonzo - http://kickme.to/plugins
Change language