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