Firewall Handbuch für LINUX 2.0 und 2.2 - zurück

Regel Richtung Protokoll Quellport Zielport Ergänzungen
1 ein TCP >1023 1521 SYN/ACK
2 aus TCP 1521 >1023 ---/ACK
3 aus TCP >1023 1521 SYN/ACK
4 ein TCP 1521 >1023 ---/ACK
Anmerkungen zu den Regeln:
1: Eingehende Verbindung, Client an Server. ACK gesetzt, außer im ersten Paket
2: Eingehende Verbindung, Server an Client. ACK gesetzt
3: Ausgehende Verbindung, Client an Server. ACK gesetzt, außer im ersten Paket
4: Ausgehende Verbindung, Server an Client. ACK gesetzt
18.13 Generelle Gefahren bei UDP - Protokollen
Viele der hier aufgezählten Protokolle basieren unter anderem auf UDP. Hierzu gehören
Windows NT PDC, NFS, RPC allgemein, REALVIDEO, REALAUDIO, Videokonferencing
wie Netmeeting, u.s.w. UDP hat generell, wie schon beschrieben, den Nachteil, daß es
kein SYN/ACK Mechanismus besitzt, d.h. daß die Firewall nicht feststellen kann, ob die
Verbindung von innerhalb heraus geöffnet worden ist, oder ob evtl. jemand von außen
Pakete zusätzlich einschleust, z.B. mit gespooften Paketen. Für NFS findet man hier
zahlreiche Beispiele auf http://www.rootshell.com, die aufzeigen, wie man bei NFS
Verbindungen File-Handels erraten kann, um somit eigene Programme über die Firewall
hinweg auf die Festplatte einzuschleusen. Dasselbe ist prinzipiell auch möglich bei allen
anderen Protokollen, die UDP einsetzen. Bei DNS Servern ist dieses ebenfalls möglich, da
kurze DNS Anfragen über UDP abgewickelt werden, längere jedoch über TCP, aus
Gründen der Übertragungssicherheit. Es sollte also jedem klar sein, daß ein Angreifer von
außerhalb die DNS Server eines Unternehmens auf diese Art und Weise mit gespooften
Paketen bezüglich den DNS Informationen ausgelieferter Mail (MX-Einträge) manipulieren
kann. Er kann ohne Probleme alle ausgehenden Mails eines Unternehmens auf seinen
Server lenken. IBM hat sich daher für die generelle Abwicklung des DNS Verkehrs über
TCP entschieden. In vielen Fällen können, je nach Implementierung von DNS auf der
Firewall, von außerhalb Informationen über das interne Netzwerk eingeschleust werden.
Dieser Trick funktioniert über "additional informations", also der Einschleusung weiterer
Informationen, obwohl nicht danach gefragt wurde. Er funktioniert aber auch über die
Manipulation von Clients mit trojanischen Pferden, z.B. über Makroprogramme unter
WINWORD und EXCEL.
Generell müssen die PROXY´s, die solche TCP/UDP gemischten Protokolle absichern,
genaue Kenntnisse über die Protokollmechanismen und die Art und Zulässigkeit der
übertragenen Daten besitzen. Diese Proxy´s sind hoch komplex, überaus teuer und in
vielen Fällen, z.B. bei REAL AUDIO / REAL VIDEO nach kurzer Zeit schon völlig veraltet.
Noch etwas schlechter sieht das bei MS Netmeeting und PDC´s aus. Da Microsoft die
genauen Protokolldetails in den RFC´s nicht offenlegt, kann also kein sicherer PROXY für
diese Protokolle existieren. Wer also Microsoft Windows NT in großen Netzwerken
einsetzt, und mit Microsofts Primary / Secondary Domain Controller (PDC) arbeitet, der
hat ein großes Problem. Es bringt in diesem Falle nichts, einzelne Abteilungen mit
Firewalls gegen Übergriffe eventueller Angreifer abzusichern. Es gibt momentan keine
Firewalls, die eine korrekte Implementierung dieses Protokolls im Proxy besitzen. In
diesem Fall (ich denke, daß hiervon auch alle Banken, Versicherungen und großen
Industrieunternehmen betroffen sind) sollte man dringenst auf bewährte Software aus der
UNIX Welt zurückgreifen, sprich NIS+, Kerberos....u.s.w. Microsoft hat zwar angekündigt,
diese Protokolle mit NT 5.0 unterstützen zu wollen, nun ja...
Streaming Protokolle, wie REAL AUDIO/VIDEO haben ein großes Problem. Erstens
öffnen Sie unnötig viele UDP Ports beim Aufbau einer Verbindung (alle >1024),
andererseits sind in vielen Fällen bei Manipulation im Datenstrom möglich, die zu buffer
Erstellt von Doc Gonzo - http://kickme.to/plugins