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.
liefert, jedoch korrekte Informationen über alle von außen sichtbaren <strong>und</strong> erreichbaren<br />
Hosts. Da<strong>für</strong> wird dann intern ein unabhängiger DNS-Server aufgesetzt, der die richtigen<br />
Informationen über interne <strong>und</strong> externe Adressen des Netzwerk besitzt. Beide DNS-<br />
Server, insbesondere der externe DNS-Server muß gut gegen Anfriffe abgesichert sein,<br />
da er die Einträge <strong>für</strong> Mail-Server (MX) des Unternehmens nach außen hin trägt. Werden<br />
diese verändert, so können von außerhalb keine e-Mails mehr empfangen werden, diese<br />
werden evtl. an einen beliebigen Server im Internet vom Angreifer umgeleitet. Damit kein<br />
Angreifer eine falsche IP - Nummer vortäuschen kann, sollte der bastion host <strong>und</strong> der<br />
interne DNS-Server stets ein double reverse lookup durchführen. Hierbei wird die IP-<br />
Adresse über reverse lookup in den Namen <strong>und</strong> der Name wieder in die IP - Nummer<br />
aufgelöst. Stimmen die Ergebnisse nicht überein, ist entweder der zugreifende Client ein<br />
Angreifer, oder falsch konfiguriert. Jedefalls kann er seine Identität nicht nachweisen, <strong>und</strong><br />
somit sollte er strikt abgelehnt werden. Hierzu müssen alle Dämonen des bastion hosts<br />
mit der Bibliothek des TCP Wrappers (TCPD) unter UNIX zusammen kompiliert werden.<br />
Der Wrapper prüft vor des Start eines Dienstes, ob der double reverse lookup korrekt war.<br />
War er das nicht, so wird der Client abgelehnt. Der TCP Wrapper <strong>und</strong> der INETD sind<br />
auch unter Windows NT verfügbar.<br />
20. <strong>Firewall</strong> mit Screened Host Architektur<br />
<strong>Firewall</strong> mit überwachtem Host:<br />
I N T E R N E T<br />
^<br />
|<br />
|<br />
<strong>Firewall</strong><br />
| lokales Netz<br />
+--------+--------+--------+-------><br />
| | | |<br />
Server1 Host A Host B Host C<br />
Beispiel 3<br />
Diese Architektur ist im Gegensatz zu einem <strong>Firewall</strong> - Aufbau mit nur einer <strong>Firewall</strong> <strong>und</strong><br />
einem im Intranet positionierten, von der <strong>Firewall</strong> überwachten Host (Server1)<br />
kostengünstiger, aber auch unsicherer. Der gesamte Datenverkehr mit dem Internet wird<br />
über diesen überwachten Host abgewickelt (screened host). Da kein Grenznetz existiert,<br />
gelten <strong>für</strong> den überwachten Host besondere Restriktionen. Er ist mit einer festen IP -<br />
Nummer über aus dem Internet erreichbar. Dieser stellt als das klassische Extranet dar,<br />
einen WWW-Server, der im Hause steht, aber von außerhalb jederzeit zu erreichen ist.<br />
Dieser Server sollte unbedingt wie ein bastion host abgesichert <strong>und</strong> darüber hinaus auch<br />
gegen buffer overflows abgesichert sein. Es muß sichergestellt werden, daß alle<br />
Arbeitsstationen im Intranet ausschließlich über den bastion host ihren Datenverkehr mit<br />
Hosts im Internet abwickeln. Die <strong>Firewall</strong> sollte also alle internen Arbeitsstationen <strong>für</strong><br />
direkten Zugriff auf Server im Internet sperren. Es werden aber auch besondere<br />
Anforderungen an die <strong>Firewall</strong> gestellt, das gilt besonders <strong>für</strong> die Auswahl relevanter<br />
Ereignisse, die an den Systemadministrator gemeldet werden müssen. Da bei dieser<br />
Konfiguration kein Abgleich zwischen Logfiles von innerer <strong>und</strong> äußerer <strong>Firewall</strong> erfolgen<br />
kann, ist also hier besondere Aufmerksamkeit erforderlich. Es ist von einer solchen<br />
Konfiguration abzuraten, da sie keinerlei Sicherheitsreserven bieten kann.<br />
Regel Richtung Quell-IP Ziel-IP Prot Quellport Zielport ACK? Aktion<br />
SPOOF ein intern bel. bel. bel. bel. bel. verbieten<br />
TEL1 aus intern bel. TCP >1023 23 bel. zulassen<br />
TEL2 ein bel. intern TCP 23 >1023 ja zulassen<br />
Erstellt von Doc Gonzo - http://kickme.to/plugins