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

Test von verschlüsselten Systemen
Nun, für SSH z.B. ist bereits ein Exploit in bugtraq zu finden. Damit können Cracker
bereits in einen Server einbrechen, bevor der Dämon überhaupt nach einem Paßwort
fragt. Für SSL-Server gestaltet sich der Test nicht so einfach, man muß zudem zwischen
den verwendeten SSL - Versionen unterscheiden. Für SSL V2 gibt es im Quellcode
Software für einen PROXY. Diese Verschlüsselungsroutinen kann man benutzen, um
netcat sockets lynx o.ä. Software um diese Routinen zu erweitern. Zum Test von SSL V3
muß man diese Mechanismen dort einbauen, da hier ein PROXY (MITM) nicht toleriert
wird. Zum testen von SSL V2 kann man obiges Verfahren anwenden, um die Daten über
einen geringfügig modifizierten SSL- Proxy zu senden, der dann seinerseits einen
verschlüsselten Tunnel zum System aufbaut. Da kann z.B. mit der SSL-Version von
netcat oder socket erfolgen. Der Zugang zum Tunnel kann dann unverschlüsselt
stattfinden. Da dieser Angriff etwas komplexer ist, ist zu vermuten, daß auch die Hersteller
keine Ahnung haben, ob und welche Gefahren drohen. Es ist aber stark zu vermuten, daß
sich hinter der Barriere der Verschlüsselung wieder ein normaler WWW-Server mit allen
bekannten Sicherheitsproblemen verbirgt. Der Revisionsstand dürfte hinter seinen
unverschlüsselten Kollegen etwas hinterher hinken, daher sind diese Systeme die
Nummer 1 auf der Liste von professsionellen Angreifern. Der Support für SSL -V3 Proxies
in Firewalls beschränkt sich stets auf die Freigabe des Ports 663, ein Schutz besteht auch
hier nicht. Ich habe persönlich einmal einige SSL HTTP Server unter Laborbedingungen
untersucht, und Angriffe mit den typischen exploits durch einen SSL Tunnel durchgeführt.
Dabei haben sich einige erfolgversprechende Angriffsmöglichkeiten mit buffer overflows
ergeben.
chroot() Umgebung für Dienste/Dämomen
Die noch verbleibenden Dämonen sollten mit minimalen Userrechten in einer chroot()
Umgebung gestartet werden. Der chroot() Umgebung ist ein eigener Abschnitt gewidmet.
Siehe chroot().
29. Security Auditing
Ein Security Audit insbesondere nach der Installation einer Firewall wird von vielen Firmen
als besonders wichtige Aufgabe betrachtet. Hierzu wurden Portscanner, Security Scanner,
DoS Simulatoren, wie z.B. Ballista, u.s.w. herangezogen. Eine beliebte Aufgabe für Tiger
Teams war es bisher, aus dem Internet eine bestimmte Datei von einem Server im
Unternehmen zu stehlen. Nach einigen simulierten Angriffen auf von professionellen
Firmen und von einigen CERT Organisationen als "sicher" eingestuften Internet
Anbindungen, halte ich Security Audits generell für unseriös. Diese teilweise 5 - stelligen
Summen, die dafür ausgegeben werden, um gegenüber Melissa & Co unwesentliche
Sicherheitsprobleme zu erkennen und zu beseitigen sind (IMHO) völlig fehlinvestiert.
Seriöses Security Auditing kann sich aufgrund der Komplexität der Software (oft mehrere
hundert Mannjahre) nur auf ganz wenige, sehr spezielle Installationen beziehen.
Beispielsweise könnten dies Datenschnittstellen zu Banking Systemen oder zu
Warenwirtschaftssystemen sein. Hierbei werden Filter für genau definierte Protokolle und
Daten programmiert. Nur in einem solche genau definierten und begrenztem Umfeld ist es
möglich, mit hoher Sicherheit behaupten zu können, diese Anbindung sei sicher und auch
nicht duch DoS Angriffe zu stören.
30. PERL Sicherheit bei WWW-Servern
Die Absicherung von WWW-Servern, auf denen CGI-Skripte laufen, ist allein mit einer
Firewall nicht möglich. Angenommen, man würde vor einem WWW-Server eine Firewall
Erstellt von Doc Gonzo - http://kickme.to/plugins