![[Inhalt]](../../Grundlagen/Firewall/images/toc.gif){kind=small}
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
Um einen Server nachweislich gegen äußere Angriffe bekannter und unbekannter Art abzusichern, ist es notwendig, den Server mit denjenigen Mitteln zu testen, wie auch ein professioneller Angreifer einen exakten Nachbau eines Systems mit aller dazugehörigen Hard- und Software unter der exakten Einhaltung der Versions - und Patchlevel testen würde. Es ist davon auszugehen, daß Angreifer stets in der Lage sind, sich diese Daten und Informationen zu beschaffen. Erst nach dieser Prozedur kann der Systembetreiber sicher sein, daß der Server nicht mehr angreifbar ist, weder durch die Firewall auf application level hindurch, noch auf andere Art von außerhalb. Wer eine SQL-Datenbank sichern möchte, der muß über diese Tips hinaus noch einige weitere Sicherheitslücken bedenken. Hinweise finden sich im Kapitel Sicherung von SQL Datenbanken. Zur Sicherung von Servern gehört ebenso die Installation und die Aktivierung des Auditing von Fileservices. Da SAMBA zu den schnellsten Serverdämonen überhaupt gehört, und SAMBA eine wunderhübsche Benutzeroberfläche besitzt, bleibt nur noch der Wunsch, die Zugriffe der Clients auf Dateien mitloggen zu können. Hierin werden alle Zugriffe von Clients auf alle Dateien des Servers mitgeloggt. So kann man herausfinden, wer sich eventuell für andere Dinge in einem Unternehmen interessiert. Verstöße gegen die Security Policy können so festgestellt werden, ohne daß man durch strikte Filterung die Mitarbeiter an der Arbeit hindert. Einen Patch für die aktuellen SAMBA Dämonen findet man auf http://www.reac.com/samba/samba-audit.html. Geschrieben hat diesen Andy Bakun. LINUX erfüllt mit diesem Patch einige Punkte der C2 Zertifizierung (Auditing). In der Praxis bedeutet dies, daß man ebenso wie unter NOVELL und NT, mit LINUX alle File-Zugriffe auf den Server mit protokollieren kann. Hier ein Beispiel:
Sep 21 18:47:42 jupiter: uranus rollout jwall(514) sysadmin(233) jwall(192.168.1.50) SHAREOPEN
Sep 21 18:48:01 jupiter: jupiter home jwall(514) jwall(514) jwall(192.168.1.50) FILEDELETE file="jwall/New Text Document.txt"
Sep 21 18:49:08 jupiter: uranus rollout abakun(500) sysadmin(233) abakun(192.168.1.20) SHAREOPEN
Sep 21 18:49:52 jupiter: jupiter - - - jwall(192.168.1.50) LOGON interactive logon attempt for kdart
Sep 21 18:49:52 jupiter: jupiter - - - jwall(192.168.1.50) LOGONFAIL wrong password for kdart
Sep 21 18:49:55 jupiter: jupiter - - - jwall(192.168.1.50) LOGON interactive logon attempt for kdart
Sep 21 18:49:55 jupiter: jupiter - - - jwall(192.168.1.50) LOGON successful logon for kdart
Sep 21 18:49:59 jupiter: jupiter - - - jwall(192.168.1.50) LOGOFF user 100(100)
Sep 21 18:51:44 jupiter: uranus rollout jwall(514) sysadmin(233) jwall(192.168.1.50) SHARECLOSE
Sep 21 18:59:18 jupiter: uranus rollout abakun(500) sysadmin(233) abakun(192.168.1.20) SHARECLOSE
Sep 21 20:38:55 jupiter: jupiter home abakun(500) abakun(500) abakun(192.168.1.20) FILEDELETE file="abakun/NTprofile/Recent/Jungle Maximize.WAV.lnk"
In obigem Beispiel ist aufgeführt, wie man LINUX dazu bringt, Events aufzuzeichnen. Wichtig ist es immer, daß man sich auf Logdateien verlassen kann. Sie sind die einzigen Hinweise auf mögliche Verletzungen der Security Policy. Leider können Angreifer, die z.B. über einen Buffer overflow in ein System eindringen, die Logdateien verändern. Hierzu verwenden diese den I-Node-echten VI. Hierzu sollten mit Hilfe der Kernel Security Mechanismen dafür gesorgt werden, daß einzelne Log-Dateien mit dem Flag "append only" versehen werden, damit auch ein User mit Administrator-Rechten diese nicht mehr verändern kann (ROOT hingegen sehr wohl noch). Diese Mechanismen werden von einigen LINUX Derivaten (Abhandlung folgt) bereitgestellt und sind auch im Kernel 2.2 zu großen Teilen enthalten.
Bevor man sich an die Arbeit begibt, sollte man sich gut überlegen, welche Daten es zu schützen gilt, und welche Dienste / Dämonen dementsprechend notwendig sind. Alle anderen Dienste sollten unbedingt auf weitere Server ausgelagert werden.
Notwendige Aufgabe ist die Entfernung dieser Programme aus dem System / Netzwerk. Es muß sichergestellt sein, daß ein Angreifer diese keinesfalls reaktivieren kann (durch buffer overflows, z.B.). Es muß mit Bedienungs oder Konfigurationsfehler seitens des Systemadministrator s oder Setup-Programmes stets gerechnet werden. Das beinhaltet die physikalische Entfernung aller nicht benötigten Dienstprogramme aus dem System. Anschließend müssen sämtliche nachladbaren Treiber, Kernelmodule oder Dämonen gelöscht werden. Programme, die Dämonen eigenständig starten können (inetd) sind so zu konfigurieren, daß diese ohne Fehlermeldungen arbeiten. Darüber hinaus ist es sinnvoll, nicht benötigte Funktionen aus dem Kernel zu entfernen. Es schränkt zwar die Auswahl des Betriebssystems ein, ist aber unumgänglich.
Um Interaktionen vorzubeugen, werden erst alle benötigten Dienste vorübergehend deaktiviert. Der Grund liegt in den möglichen Interaktionen zwischen den Diensten, die zu Fehlern und neuen Problemen führen können. Es ist oft auch nicht klar, welcher Dienst auf welche Datei des Filesystems zugreift.
Nun wird ein Dienst nach dem anderen aktiviert und untersucht. Von Interesse sind folgende Informationen:
Um herauszufinden, welche Befehle ein Dienst einem Client zur Verfügung stellt und mit welchen Parametern diese aufgerufen werden können, ist es notwendig, sich zuerst die Dokumentation en in den RFC´s zu besorgen. Hier sind üblicherweise alle Kommunikationsprotokolle dokumentiert. Da es in der Praxis immer Unterschiede im Befehlssatz gibt, sollte man sich auch stets die originalen Dokumente des Herstellers durchlesen. Der Befehl HELP in einigen Dämonen (MAIL, FTP...) ist nicht als Referenz zu betrachten. Da es oft vom Hersteller nicht dokumentierte Befehle gibt, die nicht in den Referenzhandbüchern stehen, ist unbedingt auch der Quellcode mit heranzuziehen. Mit viel Aufwand lassen sich auch mit Hilfe eines einfachen HEX-Editors versteckte Befehle in Binaries entdecken.
Nun muß überprüft werden, welche Befehle dieses Dienstes /Dämons wirklich gebraucht werden, und welche nicht. Es sind unbedingt alle nicht benutzten oder entbehrlichen Befehle zu entfernen, da mit jedem weiteren Befehl die Zahl der zu überprüfenden Kombinationsmöglichkeiten quadratisch ansteigt.
Nun können aus dem Quellcode Befehle und Routinen entfernt werden. Es ist eine Neukompilierung erforderlich. Liegt der Quellcode nicht vor, so lassen sich mit Hilfe des HEX- Editors diejenigen Befehle mit Zufallszahlen überschreiben. Dies ist aber bestenfalls nur als Notlösung zu betrachten.
Nun müssen die verbleibenden Befehle auf mögliche buffer overflows überprüft werden. Hierzu reicht z.B. netcat oder socket unter UNIX, um einen Befehl mit überlangen Parametern an den Dämon oder das Dienstprogramm zu übergeben. Man sollte dann das Verhalten des Dämons bzw. des Systems beobachten. Gewöhnlich findet dann eine Verletzung des Speicherschutzes statt, oder es gibt Ausfälle bei Funktionen in Kernel oder anderen Diensten. Tritt auch bei einer massiven Bombardierung keine besonderen Fehlermeldungen (außer Syntax Error) oder anderen Effekte auf, so ist dieser Befehl ohne Gefahr einsetzbar. Bei Speicherschutzverletzungen oder coredump ist das Dienstprogramm verletzbar und somit nicht sicher. Während dieses Angriffs ist mit einem Debugger stets zu überprüfen, welche Betriebssystem - Routinen benutzt werden, und ob sich der Fehler nicht eventuell im Kernel oder in den Bibliotheken (libraries, DLL´s) befindet. Sollte dies der Fall sein, so ist der Quellcode des Betriebssystems bzw. der Bibliotheken betroffen. Da meist auch weitere getestete oder zu testende Dienste betroffen sind, lohnt es sich, diese Probleme sofort zu korrigieren. Mitprotokolliert werden muß auch, auf welche Files oder weitere Programme /Dienste /Dämonen der getestete Dämon zugreift bzw. zugegriffen hat. Hierzu gehören auch die shared libraries, die zur 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.
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.
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.
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ß.
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.
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.
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().
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |