Nyxus wrote:Dann sind -grob geschätzt- 95% der Firewalls am Markt Mist?
Das kommt auf Deine Situation und Deinen Schutzbedarf an.
Security Management ist in erster Linie Risikomanagement. Für die Beurteilung der Firewall kommt es erst einmal darauf an, festzustellen, was zu schützen ist und was für Fähigkeiten der angenommene Angreifer hat.
Zu Firewalls:
Wenn Du ein System annimmt, das http-Verbindungen annimmt, und das innerhalb des http-Systems nachweisbar so sauber aufgesetzt ist, daß nur die Anwendung installiert ist und keine Reste von Default-Programmen im System verblieben sind, dann genügt eine portbasierende Firewall, eventuell sogar ohne Connection-Tracking, die einfach alle Ports außer 80 zuknallt und man ist mit einem Restproblem "Serversecurity" und "Anwendungssicherheit" konfrontiert.
Das ist ein sehr klassisches und einfaches Setup, das in vielen Umfeldern bevorzugt wird, weil es leicht zu konstruieren und zu validieren ist. Dein Freemail-Provider sichert den Großteil Deiner Dienste mit Sicherheit so ab.
Wenn Du stattdessen ein System annimmst, das innerhalb der Verbindungen noch Struktur hat, die mit analysiert werden muß, dann ist so etwas bei weiten nicht ausreichend. Wenn Du zum Beispiel einen WSDL Connection Endpoint hast, dann hast Du auch eine Port 80/443-Connection, aber darin werden Remote Procedure Calls übertragen, und Du willst bestimmt eine Entity haben, die erzwingt, daß bestimmte Kommunikationspartner nur bestimmte Calls mit bestimmten Parametern machen. Wenn Du das nicht im System machen kannst oder willst, dann mußt Du das externalisieren und das erfordert eine Firewall, die Verbindungsanalyse machen kann und dann Deine Policy durchsetzen kann.
Dasselbe für ONC/SUN RPC, für DCE/Microsoft RPC (etwa ein Exchange, das seine Ports zum Internet hin exponiert, damit externe Outlook da andocken können) ist eine recht häufige Fragestellung, und darum kann man zum Beispiel in einigen Firewalls innerhalb eines Protokolls einzelne RPC-Calls freischalten oder sperren (Checkpoint hat das einst stolz wie Oskar beworben, daß die das können. Linux iptables kann das nur "im Prinzip", macht es aber für die weitaus meisten Dienste nicht. Checkpoint hat dann auch Prompt Buffer Overflows in diesem Code gehabt... :) ).
Zur Security Staffelung:
Der Punkt ist, daß ein IDS Dir da nicht weiterhilft, weil ein IDS da die falsche Art Schutz bietet. In der Security (und nicht nur in der IT-Security) gibt es eine Staffel, die man mit den Worten "Abschrecken - Verhindern - Erkennen - Verlangsamen - Markieren" um die Tat selbst herum aufbauen kann.
Vor der Tat wirksame Maßnahmen Schrecken den Angreifer ab, sodaß er sich gar nicht traut, dieses Ziel anzugreifen. Bei Gebäuden sind zum Beispiel gut sichtbare Sicherheitsmaßnahmen diesem Komplex zuzuordnen. Bei Firewalls ist eine ICMP 3:10 Response auf Portscans diesem Komplex zuzuordnen.
Von den verbleibenden Angreifern wird wiederum ein guter Teil durch eine andere Sorte Sicherheitsmaßnahmen ausgeschaltet, weil die Maßnahme den Angriff verhindert.Ein Schloß, das sich nicht aufhakeln läßt oder eine Firewall, an der Dein Angriff einfach zerschellt ist dieser Staffel zuzuordnen.
Die mittlere Staffel von Sicherheitsmaßnahmen dienst der Erkennung von Angriffen, wenn sie stattfinden. Es handelt sich also um Maßnahmen, die nicht mehr vor, sondern während der Tat wirksam sind. Das sind dann also Alarmanlagen gegen Einbrüche oder Systemintegritätsprüfungen wie tripwire auf Systemen. Wie bei allen Erkennungseinrichtungen ist es einmal wichtig, daß keine false positives produziert werden, zum anderen aber auch, daß die Erkennung möglichst out-of-band analysiert und meldet, damit sie nicht denselben Fehlern unterliegt, die die vorderen Staffeln der Schutzsysteme haben.
Die nächsten Schritte, während und nach der Tat, dienen dann dazu den Angreifer zu verlangsamen, sodaß den Verteidigern mehr Zeit zur Reaktion zur Verfügung steht, um den Täter in flagranti zu erwischen und der Markierung, sodaß eine eindeutige Erkennung des Angreifers nach der Tat seine Ã?berführung vereinfacht. Bei Einbruch gibt es da verschiedene Maßnahmen, die üblich sind (Vereinzelungsschleusen sind zum Beispiel nicht aus Spaß so lahm, und so Farbampullen als Diebststahlssicherung an Kleidungsstücken hat bestimmt auch schon einmal jeder gesehen), bei Computersystemen sind unsere Maßnahmen da jedoch im Repertoire jedoch etwas eingeschränkt.
Wenn man IDSe da versucht einzusortieren, dann stellt man fest, daß sie nur im Bereich "Erkennung" wirksam sein können, und daß sie da in den meisten Fällen keinen Mehrwert bieten können, da sie bei Patternbasierenden IDSen in der Methodik der Diagnose auf denselben Maßnahmen und Mechanismen (oder sogar ganz genau denselben Tabellen!) basieren wie die vorgeordnete Verhinderungsmaßnahme, die Firewall. Damit liegt das IDS dann aber vollkommen im Schatten der Firewall und bringt verteidigungstechnisch genau gar nichts mehr.
Aber andere Frage: Welche FWs sind Deiner Meinung nach nicht Mist (ganz allgemein ohne spezielle Anforderungen)?
Das ist ohne Risikoanalyse eine sinnlose Frage. Für einen Laden wie web.de oder Hotmail reicht zum Beispiel für 80% der Maschinen ein einfacher Portfilter ohne Connection Tracking als vorderes Ende der Netzwerksicherheit aus, für die restlichen 20% der Maschinen braucht es aber ein wesentlich komplizierteres Setup.
Für keine einzelne dieser Maschinen bringt ein patternbasierendes IDS jedoch einen Mehrwert, weil das IDS in jedem Fall bei allen Anforderungen 100% im Windschaffen der Firewall läge.[/url]
