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

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

Fertig ist die neue masquerading Regel !<br />

Während die ersten 3 Zeilen die Regeln <strong>für</strong> Input, Output <strong>und</strong> Forwarding listen (-l), ist die<br />

letzte Zeile <strong>für</strong> das Accounting zuständig, also dem Zählen von Paketen, um z.B.<br />

festzustellen, welcher Host viel surft. Wer DHCP im Einsatz hat, der sollte da<strong>für</strong> sorgen,<br />

daß MAC Adressen festen IP - Nummern zugewiesen werden...<br />

9.11 Dienste mit UDP Protokollen<br />

Ein Problem gibt es, wenn außergewöhnliche Protokolle die <strong>Firewall</strong> passieren müssen,<br />

z.B. FTP, RPC, oder REALVIDEO/AUDIO. Hier zu mehr später.<br />

Die <strong>Firewall</strong>, so wie oben konfiguriert, ist momentan, mit allen aktivierten <strong>Firewall</strong>regeln,<br />

von außerhalb nicht angreifbar. Es existiert kein einziger offener Port, der angreifbar wäre.<br />

Ganz anders sieht dies von innen aus. Hier ist jeder Port der <strong>Firewall</strong> von einem Host aus<br />

dem Intranet aus erreichbar. Es bieten sich verschiedene Dienste an, wie z.B. Mail, POP3,<br />

WWW, DNS, SMB- Fileservices, NOVELL - Server, PROXY Cache, u.s.w.<br />

Auch an dieser Stelle möchte ich noch einmal betonen, daß auf der <strong>Firewall</strong> selber absolut<br />

kein Dienst etwas zu suchen hat. Eine <strong>Firewall</strong> ist eine <strong>Firewall</strong>, jede weitere Software ist<br />

ein Risiko. Leider halten einige Systemadministratoren das Risiko eines Angriffes auf die<br />

<strong>Firewall</strong> über eine Arbeitsstation <strong>für</strong> gering. Dem kann ich im Prinzip zustimmen, wenn ich<br />

selber nicht das Angriffswerkzeug in meiner Schublade hätte....<br />

Betracht man einmal die Installation eines DNS - Servers auf der <strong>Firewall</strong>. Das DNS<br />

Protokoll basiert auf TCP <strong>und</strong> auf UDP. UDP ist ein Protokoll, welches kein ACK Bit<br />

benötigt. Dieses ACK Bit ist <strong>für</strong> die <strong>Firewall</strong> aber ein Zeichen, daß die Pakete passieren<br />

dürfen, sofern vorher ein Paket mit SYN Bit aus dem Intranet in das Internet versandt<br />

worden ist. Die <strong>Firewall</strong> speichert intern dann in einer HASH Tabelle, deren HASH - Werte<br />

sich aus Port - <strong>und</strong> IP - Nummer errechnen. Auch hier ergeben sich bei billigen <strong>Firewall</strong>s<br />

neue Angriffsmöglichkeiten, siehe auch die Ausführungen bei der SINUS-<strong>Firewall</strong>.<br />

Genaugenommen ist das SYN Bit ein Zeichen <strong>für</strong> die <strong>Firewall</strong>, sich genau zu merken, von<br />

welchem Host aus eine Verbindung aus dem Intranet zu einem Host ins Internet<br />

aufgebaut werden soll, also <strong>für</strong> welchen Host aus dem Internet Antwortpakete <strong>zurück</strong><br />

erwartet werden. Die Pakete, die aus dem Intranet <strong>zurück</strong> in das Intranet gesendet<br />

werden, ist durch das SYN Bit dann autorisiert. Die <strong>Firewall</strong> muß nur noch schauen, ob<br />

diese ein ACK Bit besitzen, ob die Port - Adresse korrekt ist, <strong>und</strong> die IP - Nummer stimmt.<br />

TCP Verbindungen benutzen nach dem 3-Wege Handshake, also dem<br />

Verbindungsaufbau, höhere Ports über 1024, auch unpriviligierte Ports genannt. Leider<br />

wurde diese Konvention, die aus Zeiten der BSD - Stacks noch stammt, von vielen<br />

Herstellern aufgeweicht. UDP hingegen hat einen wesentlich kleineren Overhead <strong>und</strong> ist<br />

somit viel schneller, insbesondere bei kleineren Datenmengen. Da<strong>für</strong> besitzt es keinerlei<br />

Möglichkeit, verlorene Pakete zu erkennen, <strong>und</strong> diese wie bei TCP evtl. nochmals neu<br />

anzufordern. UDP Pakete benutzen die Ports, die <strong>für</strong> den Verbindungsaufbau verwendet<br />

wurden, auch weiterhin, außer die Programme selber haben diesen Mechanismus<br />

implementiert. Für die Erstellung von Prüfsummen ist ebenfalls das Programm selber<br />

verantwortlich. Da UDP Pakete ein SYN/ACK Mechanismus besitzen, kann eine <strong>Firewall</strong><br />

bei diesen Paketen nicht feststellen, ob diese von einem Host im Intranet auch angefordert<br />

worden sind. Entweder die UDP Ports auf der <strong>Firewall</strong> sind frei geschaltet, oder die<br />

Antwortpakete aus dem Internet prallen an der <strong>Firewall</strong> ab. Für DNS muß als ein<br />

intelligenter Mechanismus gef<strong>und</strong>en werden, der TCP <strong>und</strong> UDP Pakete miteinander<br />

kombiniert, damit nicht alle UDP Ports auf der <strong>Firewall</strong> geöffnet werden müssen. IBM hat<br />

diese Problem dadurch gelöst, daß generell der DNS Server mit TCP arbeitet. Andere<br />

Hersteller haben komplexe Proxy´s eingeführt, die die Datenpakete zur Sicherheit filtern,<br />

das generelle Problem mit UDP bleibt aber bestehen. Noch einfacher ist es, in der Datei<br />

/etc/services die Zeile:<br />

domain 53/udp nameserver<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!