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

Laufzeit bzw. beim Start des Dienstes geöffnet werden. Falls hierbei Programme auf
wichtige Konfigurationsdateien zugreifen, ist zu prüfen, ob eine race condition vorliegt.
Das ist immer dann der Fall, wenn die Datei beim Lesezugriff durch den Dämon nicht
durch schnelle Schreibversuche eines anderen Programms beschädigt werden kann. Ein
Angreifer würde dann mit einem Debugger die Ursache im Binärcode suchen und einen
exploit programmieren. Unter http://www.l0pht.com ist die Vorgehensweise für beliebige
Betriebssysteme ausführlich beschrieben. Hierzu sind allerdings umgangreiche
Kenntnisse in der Speicherarchitektur und in der Maschinensprache des Prozessors
erforderlich.
Korrektur des Quellcodes
Es muß dann, falls Probleme existieren, im Quellcode an geeigneter Stelle eine Abfrage
auf Überlänge einprogrammiert werden. Falls dies nicht möglich ist, weil entweder keine
Quellcodes verfügbar sind, sollte man sich nach Alternativen umsehen. Dieses könnte die
Portierung von Software auf das System, für die der Quellcode verfügbar ist, bedeuten,
oder auch die Programmierung eines externen Filters, der speziell für diesen Befehl
programmiert wurde. Der Reihe nach können so weitere Dämonen, deren Befehle,
Parameter und Syntax überprüft werden. Hierbei sind besonders auf mögliche Probleme
bei der Übergabe von überlangen Parametern oder besonderen Befehlen an andere
Dämonen zu achten. bei jedem weiter in Betrieb genommenen Dienst ist stets auch der
bereits geprüfte Dienst erneut zu testen, damit Sicherheitslücken bei den
Parameterübergabe- Routinen entdeckt werden können.
Externe Filter
Man sollte meinen, daß Security Scanner erkennen können, ob ein Dienst verletzbar ist,
oder nicht. Das können sie eindeutig nicht. Sogar renomierte Produkte, wie ISS -
Securityscanner fragt nur die Versionsnumm ern der Dienstprogramme ab und schaut in
einer Datenbank nach, ob evtl. ein Fehler bekannt ist. Er kann weder neue Lücken
entdecken, noch erahnen. Da aber ein Dämon mehr als ein Problem haben kann, die
bekanntesten sind. sendmail, ftp, DNS - Server, Exchange-Server, Proxy´s, SSH, SSL-
Server, HTTP-Server..., ist ein Security Scanner gut, Hacker abzuwehren. Explizite
Angriffe führen diese höchstens bei der Überprüfung von möglichen DoS Angriffen auf
TCP/IP-Stacks durch. Professionelle Cracker verlassen sich nicht darauf, daß sie mal eine
in BUGTRAQ veröffentlichte Sicherheitslücke mit dem oft gleichzeitig veröffentlichten
exploit ausnutzen können, sondern sie spüren diese Sicherheitsprobleme selber auf.
Welche Arbeiten können dann entfallen, welche nicht ?
Man kann auf fast alle Korrekturen und Eingriffe im Betriebssystem verzichten. Wichtig ist
aber eine äußerst detailierte Filterung alle Befehle, deren Syntax und deren
Kombinationen, deren maximale Länge, Filterung der zurück erwarteten Datenpakete
unter Berücksichtigung der Länge der Datensätze (z.B. bei SQL). Nicht entfallen kann die
vollständige Analyse der Protokolle, der benötigten Befehle und die strenge Auswahl der
nicht benötigten Dienste, da man für jeden Dienst einen eigenen (positiv) Filter
programmieren muß.
Können Firewalls diese Aufgabe übernehmen ?
Wenn z.B. beim Firewall-1 von PROXY die Rede ist, so kann der Systemadministrator die
Unterstützung diese Dienstes (z.B. SQL) in der Firewall aktivieren, filtern kann die Firewall
diesen dann aber noch lange nicht. Hierzu müßte man Zugriff auf die wohlgehüteten
Geheimnisse der Datenbank für Checkpoint- Vertragshändler haben, die sich diese
Abfrage aber mit einigen hundert Mark pro Stunde bezahlen lassen. Eine Garantie für die
Unverletzbarkeit des zu schützenden Servers wird aber nur in Bezug auf die
Auswertungsprotokolle des ISS Securityscanners gegeben. Sicher ist das System dann
lange noch nicht.
Erstellt von Doc Gonzo - http://kickme.to/plugins