Wie letzte Woche angekündigt, wird heute das Thema Paketfilter abgeschlossen und das Application Level Gateway vorgestellt.
Bei den Regeln für Paketfilter gibt es zwei Ansätze: Entweder es wird alles erlaubt und nur potenziell gefährliche Pakete werden ausgefiltert (Default allow), oder es wird alles verboten und nur die gewünschten Pakete werden durchgeleitet (Default deny). Wie meistens ist der Default-deny-Ansatz die bessere Wahl. Nur so kann garantiert werden, das keine Filterregel für unerwünschte Pakete vergessen wurde. Außerdem ist es weitaus einfacher, eine relativ kurze Liste erwünschter Pakete zu verwalten als eine lange Liste potenziell gefährlicher. Im einfachsten Fall (ein Webserver, davor ein Paketfilter, keine weiteren Server oder Clients im lokalen Netz) kommt man mit den drei Regeln aus dem ersten Beispiel (About Security #29) aus: HTTP-Verbindungen sind erlaubt, alles andere ist verboten.
die Themen bisher:
- Einführung (#1, 2, 3, 4)
- Eine typische Schwachstelle: Der Pufferüberlauf (#5, 6, 7, 8, 9, 10)
- Schwachstellen in Webanwendungen: - SQL-Injection (#11, 12, 13)
- Webserversicherheit (#27, 28)
- Firewall (#29, 30, 31 )
- Cross-Site Scripting (#14, 15)
- Skriptcode einschleusen (#16)
- HTTP Request Smuggling (#17, 18, 19, 20)
- HTTP Response Splitting (#21, 22, 23, 24, 25)
- Gefahren für Webanwendungen (#26)
Reihenfolge der Regeln
Die Regeln werden in der Reihenfolge angewendet, in der sie angegeben
wurden. Sobald eine Regel auf das aktuelle Paket zutrifft, wird sie
angewendet und eventuell vorhandene weitere passende Regeln kommen nicht mehr
zum Zuge. Daher muss beim Aufstellen der Regeln besonders auf die richtige
Reihenfolge geachtet werden: Steht eine allgemeine Regel vor einer
speziellen, wird die spezielle Regel nie angewendet.
Ein Beispiel
| Regel 5 | "Verwerfe alle Pakete von den IP-Adressen
a.b.*.*" |
| Regel 8 | "Akzeptiere IMAP-Verbindungen von der IP-Adresse
a.b.c.d" |
Der Rechner mit der IP-Adresse a.b.c.d hat das Nachsehen: Auf seine Pakete wird die erste passende Regel angewendet und die Pakete werden verworfen.
Vor- und Nachteile von Paketfiltern
Vorteile und Besonderheiten von Paketfiltern
- Paketfilter arbeiten transparent, d.h. sie sind für Benutzer und beteiligte Rechner unsichtbar und arbeiten ohne deren aktive Mitarbeit.
- Sie sind leicht für neue Protokolle und Dienste erweiterbar.
- Sie sind nicht an bestimmte Protokollfamilien gebunden, sondern flexibel verwendbar.
- Durch den relativ einfachen Aufbau bieten sie eine hohe Performance und sind leicht realisierbar.
Nachteile und Grenzen von Paketfiltern
- Daten oberhalb der Transportschicht werden nicht analysiert.
- Paketfilter bieten keine Sicherheit auf der Anwendungsschicht: Angriffe auf einen freigegebenen Port sind möglich.
- Sie bieten keinen Schutz vor Schadprogrammen, die aus dem lokalen Netz eine Verbindung nach außen aufbauen.
- Die Struktur des internen Netzes wird nicht verborgen.
- Logfiles (dazu in einem späteren Feature mehr) enthalten nur Informationen bis zur Transportschicht.
Zustandsorientierte Paketfilter analysieren auch die Daten der Anwendungsschicht, daher treffen die obigen Punkte für sie nur teilweise zu.
Vorteile und Besonderheiten zustandsorientierter Paketfilter
- Auch zustandsorientierte Paketfilter arbeiten transparent.
- Sie sind leicht für neue Protokolle und Dienste erweiterbar.
- Sie sind nicht an bestimmte Protokollfamilien gebunden.
Nachteile und Grenzen zustandsorientierter Paketfilter
- Aufgrund der zusätzlichen Analysen sind sie deutlich komplexer als zustandslose Paketfilter. Ihre Performance ist dadurch geringer und sie sind schwieriger zu realisieren.
- Sie bieten keinen Schutz vor Schadprogrammen, die aus dem lokalen Netz eine Verbindung nach außen aufbauen.
- Die Struktur des internen Netzes wird nicht verborgen.
Damit wird das Thema "Paketfilter" vorerst abgeschlossen. Bei Bedarf wird später noch einmal auf Details eingegangen.
Application Level Gateway
Wie der Name schon sagt, arbeiten Application Level Gateways auf der
Anwendungsschicht des TCP/IP-Schichtenmodells. So genannte Dual-homed
Gateways mit zwei Netzwerkanschlüssen entkoppeln die angeschlossenen
Netze sowohl logisch als auch physikalisch. Ein Application Level Gateway
kann auch als Single-homed Gateway mit nur einem Netzwerkanschluss
realisiert werden. Dann besteht jedoch die Gefahr, dass ein Angreifer die
Schutzfunktion umgeht.
|
|||||||||||||||||||||||||||||||||||
Das Application Level Gateway empfängt über einen seiner TCP/IP-Stacks Pakete, die bis zur Anwendungsschicht normal verarbeitet werden. Auf der Anwendungsschicht sorgt eine spezielle Software für die Übertragung zum zweiten TCP/IP-Stack. Diese Software wird als Proxy (Stellvertreter) bezeichnet, da es aus Sicht der jeweiligen Kommunikationspartner so aussieht, als würden sie mit dem Proxy kommunizieren. Für jedes Protokoll der Anwendungsschicht, dass das Application Level Gateway verarbeitet, ist ein eigener Proxy zuständig. Protokolle, für die kein Proxy vorhanden ist, können das Gateway nicht passieren.
Das Application Level Gateway hat die vollständige Kontrolle über alle zwischen dem zu schützenden und dem unsicheren Netzwerk übertragenen Pakete.
Nächste Woche wird das Thema Application Level Gateways vertieft.
- About Security (#1): IT-Sicherheit – Was ist das eigentlich?
- About Security (#2): Angriffsszenarien
- About Security (#3): Eindringlinge abwehren
- About Security (#4): Gefährdung aus der Peripherie
- About Security (#5): Der Pufferüberlauf
- About Security (#6): Ausnutzung von Pufferüberlauf-Schwachstellen
- About Security (#7): Gegenwehr – Pufferüberläufe verhindern
- About Security (#8): Vorbeugung – Pufferüberläufe verhindern
- About Security (#9): Sourcecode Audit – Pufferüberläufe finden
- About Security (#10): Software-Audit – Schwachstellensuche in Binaries
- About Security (#11): SQL-Injection
- About Security (#12): SQL-Injection verhindern
- About Security (#13): Mit Stored Procedures gegen SQL-Injection
- About Security (#14): Cross-Site Scripting
- About Security (#15): Cross-Site Scripting verhindern
- About Security (#16): Skriptcode einschleusen
- About Security (#17): HTTP Request Smuggling
- About Security (#18): Spielarten des HTTP Request Smuggling, 1
- About Security (#19): Spielarten des HTTP Request Smuggling, 2
- About Security (#20): HTTP Request Smuggling erkennen und verhindern
- About Security (#21): HTTP Response Splitting, 1
- About Security (#22): HTTP Response Splitting, 2
- About Security (#23): Caches vergiften
- About Security (#24): Caches indirekt vergiften
- About Security (#25): Entführen von Webseiten
- About Security (#26): Gefahren für Webanwendungen
- About Security (#27): Gefahren für Webserver
- About Security (#28): Standorte für Webserver
- About Security (#29): Die Firewall, 1
- About Security (#30): Die Firewall, 2
- About Security (#31): Die Firewall, 3















