entwickler.com

Wie in der letzten Woche angekündigt, geht es im Security- Feature dieser Woche um die Filterung von FTP-Verbindungen sowie um zustandsorientierte Paketfilter.

FTP-Verbindungen
Im Gegensatz zu z.B. HTTP und HTTPS verwendet FTP zwei TCP-Verbindungen, je eine zur Übertragung der Befehle und der Daten. Für den Verbindungsaufbau gibt es zwei Methoden: aktiv und passiv.

Aktive Methode

Beim Aufbau einer FTP-Verbindung wählt der Client zwei beliebige Portnummern ab 1024, der Server empfängt Befehle über den definierten TCP-Port 21 und sendet die Daten über den definierten TCP-Port 20. Der Client baut zur Befehlsübertragung eine Verbindung zum Port 21 des FTP-Servers auf und teilt dem Server mit, über welchem Port er die Daten empfangen möchte. Der Server baut daraufhin zur Datenübertragung eine Verbindung von seinem Port 20 zum angegebenen Port des Clients auf.

Passive Methode

Der Client baut die Verbindung für die Befehlsübertragung zu TCP-Port 21 des FTP-Servers auf und teilt dem FTP-Server mit, dass er die passive Methode verwenden möchte. Daraufhin teilt der FTP-Server dem Client den Port mit, über den er die Daten senden wird. Der Client baut dann eine Verbindung zu diesem Port auf.

Die aktive Methode hat für einen Paketfilter auf der Client-Seite den Nachteil, dass ein entfernter, nicht vertrauenswürdiger Rechner eine Verbindung zu einem nicht wohldefinierten Port auf dem Client aufbauen will. Ein zustandsloser Paketfilter müsste daher alle eingehenden Verbindungen von Port 20 an Ports ab 1024 akzeptieren, was ein riesiges Loch in die Firewall reißt. Aus Client-Sicht sollte deshalb die passive Methode bevorzugt werden.

Die Firewall auf der Server-Seite hat dafür bei der passiven Methode das Problem, dass ein entfernter, nicht vertrauenswürdiger Rechner eine Verbindung zu einem nicht wohldefinierten Port auf dem FTP-Server aufbauen will. Möchte man nur Verbindungen zu wohldefinierten Ports erlauben, kann der FTP-Server also nur die aktive Methode unterstützen.

Die Lösung dieses Problems sind zustandsorientierte Paketfilter: Wenn eine Verbindung für die Befehlsübertragung aufgebaut wird, erkennt der zustandsorientierte Paketfilter, dass nun der FTP-Client eine Verbindung zu dem vom FTP-Server bekannt gegebenen Port aufbauen wird. Eine temporär eingefügte Regel erlaubt dann den Aufbau der gewünschten Verbindung zum bekannt gegebenen Port für die Datenübertragung.

Zustandsorientierte Paketfilter
Zustandsorientierte Paketfilter (Stateful Inspection) berücksichtigen auch die Informationen der Anwendungsschicht. Die Status- und Kontextinformationen einer Kommunikationsbeziehung werden in Zustandsautomaten gespeichert. Während ein normaler Paketfilter von außen alle Pakete mit gesetztem ACK-Flag nach innen durchleitet, dürfen einen zustandsorientierten Paketfilter nur Pakete passieren, die zu einer bestehenden Verbindung gehören. D.h., es ist vorher ein zugehöriges Paket mit gesetztem SYN-Flag von innen nach außen durchgeleitet worden.

Dynamische Paketfilter
Bei verbindungslosen Protokollen wie UDP kann nicht festgestellt werden, welche Seite eine Verbindung aufgebaut hat. Dynamische Paketfilter sind eine Erweiterung normaler (statischer) Paketfilter: Sie protokollieren Senderadresse und -port sowie Zieladresse und -port ausgehender Pakete und können bei Bedarf ihre Filterregeln temporär ändern.

Anhand der gespeicherten Informationen über gesendete UDP-Pakete können sie erkennen, ob ein von außen kommendes UDP-Paket die Antwort auf eine zuvor gesendete Anfrage ist. Entsprechende temporäre Regeln lassen die erwarteten Pakete passieren, während nicht erwartete Pakete weiter durch die Standardregeln abgewiesen werden.

Reject oder Deny?
Für die Behandlung unerwünschter Pakete gibt es zwei Möglichkeiten: Reject und Deny. Reject ist eine aktive Ablehnung des Verbindungsaufbaus durch ein ICMP-Paket (Destination Unreachable). Deny ist das kommentarlose Verwerfen des Verbindungsaufbaus, sodass die Gegenseite erst durch ein Timeout erkennt, dass keine Verbindung aufgebaut werden konnte.

Während ein Angreifer problemlos eine Vielzahl von Portscans gleichzeitig starten und danach auf das Ergebnis warten kann, werden normale Benutzer durch das Warten auf ein Timeout behindert. Daher sollte Reject vorgezogen werden (s. z.B. [1]).

Nächste Woche wird das Thema Paketfilter abgeschlossen. Außerdem werden Application Level Gateways vorgestellt.

Carsten Eilers

• 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