Firewall Handbuch f�r LINUX 2.0 und 2.2: Seri�sit�t von Security Consultants

31. Seri�sit�t von Security Consultants

Ich selber habe einer ganzen Reihe von Security Consultants bei verschiedenen Gelegenheiten einmal auf den Zahn gef�hlt. Zugegeben, f�r Spezialisten waren diese gut �ber neue Sicherheitsl�cken in Betriebssystemen informiert, sofern diese auch ver�ffentlicht waren. Als es allerdings um Erfahrungen als Programmierer ging, da wurde die Luft schon d�nner. Eigenst�ndig Sicherheitsprobleme auffinden und einen Exploit schreiben, dazu war kaum jemand in der Lage. Wer einem Security Consultant auf den Zahn f�hlen m�chte, der sollte sich davon �berzeugen, da� dieser einen standardm��ig installierten NT 4.0 Server mit SP5 am Netz zumindest zu einem "bluescreen" von einer Arbeitsstation aus bewegen kann, nat�rlich ohne die im Internet verbreiteten, fertigen "exploits" zu benutzen. Als Hilfmittel sollte C, C++, PERL v�llig ausreichen. Auf Schulungen zu Firewalls werden h�ufig vorbereitete "exploits" demonstriert, die dann Server zum Absturz bringen, oder unter UNIX eine ROOTSHELL �ffnen. Diese DEMO�s sind nichts weiter als einfache Schau. Die Werkzeuge daf�r finden sich z.B. auf der Domain http://www.rootshell.com.

Ganz problematisch wird es beim Auditing. Die Aufgabenstellung ist oft dieselbe: �berpr�fung der Sicherheit einer bestehenden Firewall-Installation. Es ist mit etwas Hintergrundwissen recht einfach, die typischen Schwachstellen einer Anbindung ausfindig zu machen. Diese auch auszunutzen, dazu geh�rt etwas Programmiererfahrung mit Microsoft Visual C++ oder Visual Basic. Der Rest ist Routine. Ich pers�nlich halte jede Art von Auditing f�r v�llig unseri�s, da in der Vergangenheit immer wieder neue Sicherheitsl�cken aufgedeckt wurden, die Systemadministratoren w�hrend ihrer t�glichen Arbeit garnicht alle schnell genug stopfen k�nnen. Auch eine Firma, die einen Wartungsauftrag f�r eine Internet-Anbindung erf�llt, kann nicht so schnell die Patches aufspielen, wie ein Cracker die neu entdeckten Sicherheitsl�cken ausnutzen kann. Allein schon ein Vorsprung von 10 Minuten nach einer Ver�ffentlichung im BUGTRAQ Archiv w�rde schon ausreichen, um in ein Netzwerk vorzudringen.

Auditing kann sich also nur auf eines konzentrieren: Die Analyse und Auswertung der Logfiles, damit ein Einbruch und ein Datendiebstahl auch bemerkt werden kann. Hierzu mu� undbedingt ein Einbruch durchgef�hrt, und dann analysiert werden, warum der Systemadministrator mal wieder nichts bemerkt hat, oder bemerken konnte. So ist es jedenfalls den Sicherheitsexperten einiger Banken und Forschungslabors einiger Chemiekonzernen gegangen, deren Anbindung ich (im Auftrag) �berpr�fen mu�te. Alle Anbindungen waren professionell installiert und von einer unabh�ngigen Firma/Institut zuvor �berpr�ft worden. Siehe hierzu auch Kapitel Stories. In fast allen F�llen ist das von diesen Firmen verwendete Werkzeug der ISS Security Scanner, der typische Fehler aufdecken kann. Ein seri�ser Cracker w�rde niemals auch nur auf die Idee kommen, eine bekannte Sicherheitsl�cke f�r seinen Angriff zu benutzen. (Das ist der Unterschied zwischen Crackern und Lamern). Die sogenannten Security Scanner oder Exploits werden immer nur von sogenannten "lamern" (Trittbrettfahern) , niemals aber von Profi�s mit einem gezielten Auftrag verwendet.

Wer also in den Logfiles seiner Firewall mal wieder einen Angriff verzeichnet sieht, der kann absolut sicher sein, da� hier keine Profis am Werk waren. Aus diesem Grunde sind die so gerne in seri�sen IT Zeischriften angef�hrten Statistiken und Umfragen zu registrierten Angriffen v�lliger Bl�dsinn.

Nach meinen Erfahrungen werden 95% aller Angriffe auf WWW-Server und eine etwas h�here Zahl von Angriffen auf Server �ber Arbeitsstationen nicht bemerkt. Die Zahlen bei WWW-Servern begr�nden sich LINUX Server mit SPARC und ARM Prozessor im Internet, die von mir speziell konfiguriert wurden, um bekannte und unbekannte buffer overflows zu registrieren. Da von fast allen Angreifern buffer overflows verwendet wurden, die auf INTEL Prozessoren zugeschnitten wurden, war es m�glich, diese Angriffe zu registrieren und auszuwerten.

Zur Sch�tzung der Angriffe und Angriffsm�glichkeiten auf Intranets habe ich in kleinem Rahmen an mir pers�nlich bekannte Mitarbeiter bei gr��eren und kleineren Unternehmen Mails mit Attachment versendet. Alle Mitarbeiter haben die Attachements ge�ffnet und die darin enthaltenen (harmlosen Programme) gestartet. Die Erfolgsquote liegt nahe den 100%. Es ist f�r jeden von Microsoft zertifizierten MCSD m�glich, Angriffswerkzeuge zu schreiben, und per E-Mail an Mitarbeiter von Unternehmen zu versenden. Dieses von mir verwendete .EXE Programm hat einen Portscan �ber alle IP-Nummern des Netzwerkesbereiches der Arbeitsstation und einige Broadcast Pakete in das Intranet versendet. Keine der Firmen hat diese bemerkt und Nachforschungen angestellt. Einige Systemadministratoren haben bei einer anschlie�enden Besprechung diese zwar Scans bemerkt, konnten jedoch die Ursache und Herkunft nicht ergr�nden.

Abschlie�end m�chte ich behaupten, da� man jede Person die eine Zertifizierung als MCSD besitzt und die die M�glichkeiten kennt (nach der Lekt�re diese Handbuches sp�testens hat sie diese), wie man Angriffswerkzeuge schreibt, schon als potentiellen Cracker betrachten mu�, der �ber das Wissen verf�gt, in beliebige Unternehmen vorzudringen, und Informationen aus diesen in das Internet zu entf�hren.

Online Suche im Handbuch

LITTLE-IDIOT NETWORKING