Kostenlose PDF Bücher Downloads

[chris76]

Hi,

auf der Seite Open Source Training von Ralf Spenneberg gibt´s die Bücher "Intrusion Detection und Prevention mit Snort & Co." und "VPN mit Linux" ganz oder Kapitelweise zum Download.

http://www.os-t.de/buecher_new.php

[nyxus]

Hi,

auf der Seite Open Source Training von Ralf Spenneberg gibt´s die Bücher "Intrusion Detection und Prevention mit Snort & Co." und "VPN mit Linux" ganz oder Kapitelweise zum Download.

http://www.os-t.de/buecher_new.php

Hey, das ist ja sogar das aktuelle IDS-Buch von RS dabei. Bis vor kurzem war m.W. nur das ältere "Intrusion Detection für Linux-Server" verfügbar.

BTW: Hat einer von euch schonmal ein IDS-Training von Ralf Spenneberg besucht?

[tommbutu]

wow!

für das detection buch alleine verlangen die 59euro im laden. da lade ich doch direkt mal los, wobei (papier)bücher natürlich immer ne klasse für sich sind

[isotopp]

BTW: Hat einer von euch schonmal ein IDS-Training von Ralf Spenneberg besucht?

Nein. Ich habe bei einem früheren Arbeitgeber aber einmal ein Snort-basierendes, mit Signaturenerkennung arbeitendes, kommerzielles IDS eingesetzt, weil Verträge mit externen Dienstleistern dies erforderlich gemacht haben. Die Dinger sind prinzipbedingt sinnlos, eignen sich aber hervorragend als Rechtfertigungsgrund.

[nyxus]

[...]Snort-basierendes, mit Signaturenerkennung arbeitendes, kommerzielles IDS [...] Die Dinger sind prinzipbedingt sinnlos

Harte Worte. Hältst Du Snort für prinzipbedingt sinnlos oder IDS/IPS allgemein?

[isotopp]

[...]Snort-basierendes, mit Signaturenerkennung arbeitendes, kommerzielles IDS [...] Die Dinger sind prinzipbedingt sinnlos

Harte Worte. Hältst Du Snort für prinzipbedingt sinnlos oder IDS/IPS allgemein?

Szenario a: Du installierst ein signaturbasierendes IDS vor der Firewall. Warum? Du bekommst Informationen über Angriffe, die sowieso an Deiner Firewall zerschellen werden. Wieso willst Du das wissen?

Szenario b: Du installierst ein signaturbasierendes IDS hinter Deiner Firewall. Du bekommst Informationen über Angriffe, die an Deiner Firewall zerschellen hätten sollen. Wieso hast Du nicht gleich passende Rulesets als Verbot statt als Detect erzeugt?

Szenario c: Du setzt das IDS im Intranet ein, um damit etwa die Signaturen von unerwünschten Desktop-Programmen (eDonkey et al) zu erkennen, und die Mac-Adressen von nicht gemeldeten Laptops zu erkennen (weil die Switch-Infratstruktur oder die politische Struktur in der Firma derzeit kein 802.1x hergibt). Du kannst auf Verletzer der Security Policy losgehen und sagen "Mach das aus, Du bringst an unserem IDS sämliche Lampen zum rot leuchten" statt argumentieren zu müssen "Du verletzt unsere Security-Policy" und dann dieselbe und deren Sinn verteidigen zu müssen.

Szenarien a und b sind nutzlos. Szenario c lenkt sozialen Druck von Dir als CSO ab und Du kannst Dich auf "Der Computer hat gesagt" zurück ziehen und so viel Zeit und Streß sparen.

Ein IDS als Sicherheitsinstrument ist meiner persönlichen Erfahrung als CSO nach relativ zweckbefreit (aber ich habe das nur zwei Jahre lang gemacht) und produziert nur false positives. Dabei muss man bedenken, daß ich allerdings auch in einem Ausnahmeenvironment gearbeitet habe - auf unseren Servern damals hat der normale Traffic die Syncookies des Kernels ausgelöst, weil der Kernel dachte, das sei ein DDoS, dabei war es nur normaler Montagmorgen-Traffic.

Als sozialdynamische Argumentationshilfe ist es unbezahlbar. Ein 6er BMW-fahrendes Senior Management Mitglied wird extrem pissig, wenn man droht, ihm seinen Privatlap wegen "nicht gemeldet" aus dem Firmennetz auszusperren, weil dies eine Security Policy Violation ist. Wenn man ihm aber mit dem IDS Protokoll in der Hand an den Tisch kommt und damit ein wenig rumwedelt, diskutiert der nicht mal, sondern stellt sich brav am UHD in die Schlange und läßt sich den ohne weitere Rückfragen abnehmen.

Und wenn man durch den Credit Card Processing Audit will, muss man sowieso eins haben (aber der Audit verlangt nicht, dass die Logs von dem Ding tatsächlich von einem Menschen gelesen werden).

[Roger Wilco]

Als sozialdynamische Argumentationshilfe ist es unbezahlbar. [Amoklaufender 6er BMW-Fahrer]

Also als LART hatte ich ein IDS noch nicht gesehen. Nette Idee. ;)

[nyxus]

[...]Snort-basierendes, mit Signaturenerkennung arbeitendes, kommerzielles IDS [...] Die Dinger sind prinzipbedingt sinnlos

Harte Worte. Hältst Du Snort für prinzipbedingt sinnlos oder IDS/IPS allgemein?

Szenario a: Du installierst ein signaturbasierendes IDS vor der Firewall. Warum? Du bekommst Informationen über Angriffe, die sowieso an Deiner Firewall zerschellen werden. Wieso willst Du das wissen?

In Listen wie Security-Basic von Security-Focus wird diese Platzierung zwar häufig als wichtig dargestellt, von mir aber dort noch nie positioniert. Ok, manchmal wäre es geeignet den Chef zu einem größeren Budget zu überzeugen ala "Chef, schau mal wie böse das Internet ist ...".

Szenario b: Du installierst ein signaturbasierendes IDS hinter Deiner Firewall. Du bekommst Informationen über Angriffe, die an Deiner Firewall zerschellen hätten sollen. Wieso hast Du nicht gleich passende Rulesets als Verbot statt als Detect erzeugt?

Das sehe ich dann doch anders. Manche Firewalls gehen bei der Erkennung in den oberen Schichten dann halt doch nicht so weit was ein IDS kann. Und dort kann es zu einer Abrundung der Gesamtsecurity halt doch gut beitragen. Und nein, "Application Intelligence" und wie der ganze Runpel heißt reißt auch das nicht raus (noch nicht).

Szenario c: Du setzt das IDS im Intranet ein, um damit etwa die Signaturen von unerwünschten Desktop-Programmen (eDonkey et al) zu erkennen, und die Mac-Adressen von nicht gemeldeten Laptops zu erkennen (weil die Switch-Infratstruktur oder die politische Struktur in der Firma derzeit kein 802.1x hergibt).

Nicht .1x-fähige Switche sind leider noch recht weit verbreitet (mit noch mehr Grauen denke ich an die VMPS-Zeit zurück). Das Erkennen "falsch" konfigurierter PCs ist aber IMHO ein eine gute Möglichkeit für IDS, wenn ich da aber auch eher auf NetFlow setze.

Du kannst auf Verletzer der Security Policy losgehen und sagen "Mach das aus, Du bringst an unserem IDS sämliche Lampen zum rot leuchten" statt argumentieren zu müssen "Du verletzt unsere Security-Policy" und dann dieselbe und deren Sinn verteidigen zu müssen.

Die Argumentation muß ich zum Glück nur selten übernehmen. :-) Aber eine gewisse Sensibilisierung hat ja zum Glück dank Computer-Bild und manchmal Tagesschau schon stattgefunden.

Ein IDS als Sicherheitsinstrument ist meiner persönlichen Erfahrung als CSO nach relativ zweckbefreit (aber ich habe das nur zwei Jahre lang gemacht) und produziert nur false positives.

Kunden mit der Erwartung "das ist so teuer, das muß auch out of the box laufen" habe ich auch kennengelernt ... (nein, ich denke nicht daß Du sowas auch denkst ;-) ) Naja, das waren dann aber auch die, die die Logs nie richtig ausgewertet haben.

Dabei muss man bedenken, daß ich allerdings auch in einem Ausnahmeenvironment gearbeitet habe - auf unseren Servern damals hat der normale Traffic die Syncookies des Kernels ausgelöst, weil der Kernel dachte, das sei ein DDoS, dabei war es nur normaler Montagmorgen-Traffic.

gut, solche Kunden habe ich dann eher selten. Und bei den "normalen" ist das Eindämmen der False Positives dann meist doch recht gut möglich.

Als sozialdynamische Argumentationshilfe ist es unbezahlbar. Ein 6er BMW-fahrendes Senior Management Mitglied wird extrem pissig, wenn man droht, ihm seinen Privatlap wegen "nicht gemeldet" aus dem Firmennetz auszusperren,

und hinterher lehnt man sich zurück und sagt "ja! Dieser Job macht doch Spaß" :-)

(aber der Audit verlangt nicht, dass die Logs von dem Ding tatsächlich von einem Menschen gelesen werden).

Dafür gibt es ja jetzt die SIMS, reicht wenn die das lesen ... ;-)

[isotopp]

Szenario b: Du installierst ein signaturbasierendes IDS hinter Deiner Firewall. Du bekommst Informationen über Angriffe, die an Deiner Firewall zerschellen hätten sollen. Wieso hast Du nicht gleich passende Rulesets als Verbot statt als Detect erzeugt?

Das sehe ich dann doch anders. Manche Firewalls gehen bei der Erkennung in den oberen Schichten dann halt doch nicht so weit was ein IDS kann.

Dann ist Deine Firewall Mist und tut nicht das, was sie soll. Sie arbeitet etwa rein portbasiert, anstatt den Traffic in Deiner Kommunikation zu überwachen, so dies notwendig ist. Du willst schließlich keine Mail bekommen, wenn Dich jemand angreift, sondern der Angriff soll nicht möglich sein und blockiert werden.

[nyxus]

Das sehe ich dann doch anders. Manche Firewalls gehen bei der Erkennung in den oberen Schichten dann halt doch nicht so weit was ein IDS kann.

Dann ist Deine Firewall Mist und tut nicht das, was sie soll. Sie arbeitet etwa rein portbasiert, anstatt den Traffic in Deiner Kommunikation zu überwachen, so dies notwendig ist. Du willst schließlich keine Mail bekommen, wenn Dich jemand angreift, sondern der Angriff soll nicht möglich sein und blockiert werden.

Dann sind -grob geschätzt- 95% der Firewalls am Markt Mist? Gut, ich kenne beileibe nicht alle (bei der Vielfalt eher die wenigsten), aber die Welt ist doch nicht nur schwarz oder weiß. Es gibt halt noch andere Business-Vorgaben an die man sich halten muß und die auch die Auswahl der FW einschränken.
Aber andere Frage: Welche FWs sind Deiner Meinung nach nicht Mist (ganz allgemein ohne spezielle Anforderungen)?

[isotopp]

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]

[nyxus]

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.

Auch da könnte ein IDS/IPS doch behilflich sein. Ich denke nur an Sachen wie "der Exchange-Patch wird erst eingespielt wenn er ausgiebig getestet ist". Im Prinzip ja gut, aber die neuen IDS-Regeln sind schneller da als die Aussage der MSX-Truppe daß der Patch problemlos arbeiten wird.

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.

Auch meine "Leib-und-Magen-FW" macht genau das. Aber eben auch nur das. Was unter Programm-Nummer 123xyz transportiert wird sieht sie nicht, ein IDS/IPS schon.

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.

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.

Irgendwie hast Du doch in dem Part genau den IDS-Einsatz beschrieben. Wobei Tripwire (die aktuellen Versionen kenne ich allerdings praktisch nicht mehr) ja eher *nach* der Tat zum Einsatz kommt.

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 Computersystemen sind unsere Maßnahmen da jedoch im Repertoire jedoch etwas eingeschränkt.

Auch wenn es eingeschränkt ist, hast Du dazu ein paar mehr Informationen/Links?

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.

Und da ist dann wohl der Unterschied in unseren Umgebungen. Ich arbeite viel in Bereichen wo die Firewalls eben *nicht* diese beschriebenen Möglichkeiten haben, aber aus anderen Gründen trotzdem eine gute Wahl sein können.

[isotopp]

Auch da könnte ein IDS/IPS doch behilflich sein. Ich denke nur an Sachen wie "der Exchange-Patch wird erst eingespielt wenn er ausgiebig getestet ist".

Wie kann ein IDS da helfen? Willst Du zusehen, während Dein Exchange da exploitet wird? Du brauchst da eine Firewall, die in die Verbindung reinsieht und illegale Operationen unterdrücken kann. Ob Du die dann Firewall nennst oder "IPS" ist ja auch egal.

[lord_pinhead]

Auch da könnte ein IDS/IPS doch behilflich sein. Ich denke nur an Sachen wie "der Exchange-Patch wird erst eingespielt wenn er ausgiebig getestet ist". Im Prinzip ja gut, aber die neuen IDS-Regeln sind schneller da als die Aussage der MSX-Truppe daß der Patch problemlos arbeiten wird.

Was willst du mit einer solche Regel den bewerkstelligen? Sobald ich den Exploit codiere und dann nur einen Decoder mitliefere, sieht dein IDS nicht einmal das ein Exchange unter einer Attacke ist, selbiges gilt für eine SSL Verbindung, egal welches Super IDS du verwendest, es kann nicht den Datenstrom decodieren. IDS, egal ob Snort, Prelude oder alles andere, ist eigentlich nur zur neugierde, sicherheit bringt es nur bedingt oder wie Isotop schon gesagt hat um Leute unter Druck zu setzen (hab ich zwar bisher auch noch nicht gehört, klingt aber plausibel *G*). Lieber stecke ich mehr arbeit in den Rest des Systems, als mich nochmal auf ein IDS zu verlassen, die dinger lassen sich echt zu einfach an der Nase herumführen, manchmal ist es sogar dumm ein IDS zu nutzen. Beispiel Snort: Vor ewigkeiten hatte Snort ein Problem mit bestimmten Packeten, wenn ich als Kiddie sehen wollte ob Snort läuft muss ich einfach nur ein solches Packet zum Server schicken. Stürtzt er ab, war Snort drauf. Aktuell gibt es ja eine neue Variante für den Linux Kernel mit ICMP Packeten, kann man auch versuchen die Kiste zum abschmieren zu bringen ohne das mir ein IDS hilft.

Aber ok, wo würde ein IDS vielleicht doch helfen. Im Internen Netzwerk zwischen dem LAN, der DMZ und dem Router wäre ein IDS gut platziert. Damit es nicht jeder gleich merkt Bridgen wir das ganze und setzen das IDS an die Schnittstellen die es überwachen soll, damit würde ein Virus relativ schnell erkennt und das IDS das kann, wird die Mail gelöscht, bevor sie das Postfach erreicht (Mail nur als beispiel). Das wäre eine Sinnvolle anwendung wenn ich den Mailvirenscanner nicht zu arg belasten möchte. Aber das funktioniert halt nur bedingt, und ich brauch eine Regel für solche sowas.
Alternativ: Keine ausführbaren anhänge zulassen (MIME-Filter). Erledigt sich schon wieder der Aufwand für ein IDS. Spyware kann ich durch ein internen DNS austricksen (in der Hosts einfach die aktuelle Blacklist mit der IP 127.0.0.1 verknüpfen).

Szenario c: Du setzt das IDS im Intranet ein, um damit etwa die Signaturen von unerwünschten Desktop-Programmen (eDonkey et al) zu erkennen, und die Mac-Adressen von nicht gemeldeten Laptops zu erkennen (weil die Switch-Infratstruktur oder die politische Struktur in der Firma derzeit kein 802.1x hergibt).

Möglichkeit 1: Proxy statt NAT
Möglichkeit 2: Layer 7 Firewall
Und für Mac-Adressen brauch ich nicht zwingend ein aufgeblähtes IDS ;) Da die meisten ja sowisso DHCP eingestellt haben, würde ich ganz einfach eine Liste von Mac´s mit IP´s verknüpfen und dann im DHCP reinsetzen (dnsmasq leistet gute Dienste damit). Wenn sich jetzt Cheffe mit sein Lappi anmelden möchte, sitzt er in einen anderen Subnetz fest, punkt. Wenn ich allerdings einige Hundert Adresse habe, wird das zu aufwendig und ich würde mir überlegen ob meine Interne Struktur nicht doch durch ein paar besser Switches aufgebesser werden könnte. So ein Schlippsträger würde schon verstehen wenn ich etwas von schlechter Wirtschaftlichkeit aufgrund zu hoher Arbeitsstunden daherlaber, dann wird schon überlegt ob es sich nicht rechnet wenn man den Herrn der IT Abteilung mit ein paar Switches entlastet damit er anderweitig seine Arbeit machen kann.

Anyway, ich denke das ganze wird langsam extrem Offtopic. Wer gerne Ebooks hat, der sollte sich mal bei Galileo die Openbooks ansehen, sind recht nette Sachen dabei.

MFG

[nyxus]

Was willst du mit einer solche Regel den bewerkstelligen? Sobald ich den Exploit codiere und dann nur einen Decoder mitliefere, sieht dein IDS nicht einmal das ein Exchange unter einer Attacke ist,

Sofern Dein Exploit eine bekannte Werwundbarkeit anspricht ist die Wahrscheinlichkeit recht hoch daß das IDS anspricht. Sofern Du eine neue bisher unbekannte Verwundbarkeit meinst, ok, da muß man halt warten bis neue Signaturen kommen oder sich selbst eine Signatur basteln. Hier liegt natürlich wirklich eine Schwäche der signaturbasierten IDS/IPS. In der aktuellen Geschwindigkeit, in der die Exploits auf das Bekanntwerden der Verwundwarkeit folgen ist das schon schwieriger geworden.

selbiges gilt für eine SSL Verbindung, egal welches Super IDS du verwendest, es kann nicht den Datenstrom decodieren.

ach ... Btw, dafür hat man dann hoffentlich eine weitere Schicht in der Abwehr, z.B. das Host IPS (um beim Thema IDS/IPS zu bleiben)

manchmal ist es sogar dumm ein IDS zu nutzen. Beispiel Snort: Vor ewigkeiten hatte Snort ein Problem mit bestimmten Packeten, wenn ich als Kiddie sehen wollte ob Snort läuft muss ich einfach nur ein solches Packet zum Server schicken.

Software wird halt (zum Glück noch) von Menschen gemacht.

Stürtzt er ab, war Snort drauf.

Vielleicht war es auch einfach nur ein Windows-Server ... ;-)

Aktuell gibt es ja eine neue Variante für den Linux Kernel mit ICMP Packeten, kann man auch versuchen die Kiste zum abschmieren zu bringen ohne das mir ein IDS hilft.

Das hängt natürlich auch mal wieder von den Paketen ab, ein IPS könnte es verhindern, ein IDS zumindest die Ursache aufzeigen.

Damit es nicht jeder gleich merkt Bridgen wir das ganze

Hast Du schonmal ein IDS gesehen, das auf dem Sniffing-Interface eine IP hat bzw. ein IPS, das *nicht* als "Bump in the wire" betrieben wird?

und setzen das IDS an die Schnittstellen die es überwachen soll, damit würde ein Virus relativ schnell erkennt und das IDS das kann, wird die Mail gelöscht, bevor sie das Postfach erreicht (Mail nur als beispiel).

Das muß aber ein ziemlich pfifiges IPS sein, das inline die Mail entfernt ohne, daß der einliefernde Client bzw. Server das merkt.

Virus-Erkennung allgemein lasse ich mir ja noch gefallen. Das wird ja immer moderner obwohl ich gerade *das* eher als Host/Server-Aufgabe sehe. Und den Host-Scanner kann ein Virenscanner im IPS auch nicht ablösen.

Das wäre eine Sinnvolle anwendung wenn ich den Mailvirenscanner nicht zu arg belasten möchte.

Damit hättest Du die Last aber nur an eine teurere Stelle verlagert. Mehrere Mail-Relays einzusetzen würde wohl sinnvoller sein.

Szenario c: Du setzt das IDS im Intranet ein, um damit etwa die Signaturen von unerwünschten Desktop-Programmen (eDonkey et al) zu erkennen, und die Mac-Adressen von nicht gemeldeten Laptops zu erkennen (weil die Switch-Infratstruktur oder die politische Struktur in der Firma derzeit kein 802.1x hergibt).

Möglichkeit 1: Proxy statt NAT
Möglichkeit 2: Layer 7 Firewall

NAT im internen Netz? Bist Du masochistisch veranlagt oder arbeitest Du einfach nur für eine Firma die sich nach dem Merge mit einem Mitbewerber kein IP-Redesign leisten kann?
Und auch eine Application-Layer-Firewall wird schwierig bei der Vielzahl von Applikationen und Geschwindigkeiten im Multi-Gigabit-Bereich.

Willst Du zusehen, während Dein Exchange da exploitet wird? Du brauchst da eine Firewall, die in die Verbindung reinsieht und illegale Operationen unterdrücken kann.

ja, will ich zusehen! Und zwar dann wenn meine FW (z.B. weil sie halt Mist ist) es eben *nicht* verhindern kann. Dann empfinde ich es schon als Vorteil es frühzeitig zu bemerken, als nur die späteren Auswirkungen mitzukriegen.

Anyway, ich denke das ganze wird langsam extrem Offtopic.

Sind ja zum Glück im "Smalltalk". Aber hast schon recht, und alles nur weil ich wissen wollte wie die Trainings bei Ralf Spenneberg sind ...