RootForum Community

Hallo!

Ich suche ein paar Leute für folgendes Projekt:

iptables-Firewall - bis Layer 7 (mit ev. netfilter)
IDS (Intrusion Detection System) und
IRS (Intrusion Response Systems)

Also das die Firewall intelligent wird, Angriffe erkennt und Gegenmaßnahmen einleitet.

Die Iptables-Firewall ist ja kein Problem, Snort um Angriffe zu erkennen auch nicht, doch ein funktonierendes, aktuelles IDS und IRS zu bauen - ist eine Herausforderung.
Diese Firewall soll als erstes für Server gedacht sein, ist aber dann für Workstations natürlich auch anwendbar.

Erklärung: Die Layer 7 Firewall soll zB dafür sorgen das am Port 80 auch nur http drüber geht und nichts anderes.

Ich habe schon einige Ansätze gefunden (snort2iptables zB).

Falls jemand Literatur dazu kennt, bitte posten. Ich bräuchte noch einige Leute, die sich mit dieser Thematik schon auseinandergesetzt haben und ev. Mitarbeiten wollen - soll ein GNU-Projet werden.

Resourcen kann ich zur Verfügung stellen.

Interessantes Projekt. Für mich wäre es aber erst dann richtig interessant wenn das auch als Appliance lauffähig wäre. Und spätestens dann kommt die Frage nach Redundanz. Auch in der Hinsicht solltet ihr von vornherein darauf achten keine Sackgassen einzuplanen.

Genau das sind so Ansätze, wo mehr Leute mehr Wissen einbringen können. Redundanz ist so eine Sache, wenns auf dem Server dens betrifft installiert ist, kann ich mir nur vorstellen etwas zu bauen das überprüft ob das Teil läuft, wenn nicht mehr, dann...

Wenn ich einen extrigen Rechner als Firewall habe, gut, dann lässt sich was machen.

Netfilter läuft nur bis Layer 3 bzw. Pseudo 4. Der Patch für Layer 7 ist noch stark überholungsbedürtig, das ding würde ich auf keinen Fall für eine Produktive Umgebung verwenden. IDS/IRS/IPS oder wie du das immer taufen möchtest wird schwierig zu überwachen, vor allem die Pflege der Regeln ist schwierig. Wenn dann noch ein Angriff über ein verschlüsseltes Protokoll kommt, zb.: https, sind die IDS Systeme allesamt blind. Genauso blind sind sie, wenn der Angreifer einmal die Phrack gelesen hat und den Shellcode Codiert, das geht durch dein IDS durch wie nichts.

Diskutiert hatten wir das mal in der Ausbildung wie man sowas machen könnte, allerdings sind wir nie auf ein brauchbares ergebniss gekommen. Sofern die Mittel zur verfügen stehen würde, wäre sowas vielleicht denkbar:

Internet ---> Gateway mit Packetfilter (Bridge) --->Proxy der verschlüsselte Verbindungen übernimmt und klartext ins Lan schickt ---> IDS/IPS (Bridge) ---> Applicationserver

Der Proxy übernimmt in dem Fall die Entschlüsselung und der Traffic ab dem Proxy ins interne LAN ist wieder Klartext, danach kann erst ein IDS/IPS greifen. Problem bei dieser Methode: Wird der Proxy geknackt, ist das Chaos vorprogrammiert. Ausserdem muss man dem Intranet 100% vertrauen können, und das geht nur wenn die Rechner in Reihe verkabelt sind, im Schrank stehen und nur du und ein anderer Admin den Schlüssel dafür habt.

Egal, ich will das Projekt nicht als nutzlos taufen, sowas ist immer gern gesehen und je nach Anwendungsgebiet erfüllt es sicherlich auch seinen Zweck ;) Viele sachen kannst du auf http://www.samag.com nachlesen, finde die Seite recht interessant. Da stand auch irgendwo wie ich Squid als Reverse Proxy konfiguriere und damit das "Problem" mit SSL behebe. Musst einfach mal suchen.

MFG
Lord

Lord_Pinhead wrote:IDS/IRS/IPS oder wie du das immer taufen möchtest wird schwierig zu überwachen, vor allem die Pflege der Regeln ist schwierig. Wenn dann noch ein Angriff über ein verschlüsseltes Protokoll kommt, zb.: https, sind die IDS Systeme allesamt blind.

Er will es ja auf dem Server selbst laufen lassen. Und da kann man die Daten erst entschlüsseln und dann überprüfen.

Entschlüsselt wird auf Layer 7 von der Application, da kommt kein IDS mehr hin weil es schon die Filter durchschritten hat, daher der nötige zwischenschritt über den Proxy oder ähnliches. Vielleicht mal hier kurz nachlesen was gemeint ist, dort sind einige taktiken beschrieben. Bei einem VPN wird es richtig schwierig mit dem Sichern. Da würde mir direkt Virtualisierung einfallen vom VPN Gateway und den dann abgesichert, ein neuinitialisieren wenn die Kiste geknackt wurde wäre da einfacher.

Lord_Pinhead wrote:Entschlüsselt wird auf Layer 7 von der Application, da kommt kein IDS mehr hin weil es schon die Filter durchschritten hat, daher der nötige zwischenschritt über den Proxy oder ähnliches.

Wo ist das Problem? Natürlich geht das, andere HIPS oder Sachen wie mod-security bekommen das auch hin. Man muß halt seine IPS-Funktionalität an der richtigen Stelle ansetzen. Wo steht, daß ein IPS immer auf dem Netzwerklayer arbeiten muß? Und wenn Du unbedingt einen Proxy haben willst kann der aber natürlich auch auf der selben Maschine laufen.

Vielleicht mal hier kurz nachlesen was gemeint ist, dort sind einige taktiken beschrieben.

Da gab es auf SF aber schon aktuellere Sachen zum Thema. Und wo Du diesen Artikel ansprichst, inzwischen hat wohl jedes IDS anti-evasive-Techniken eingebaut, die sich von Whisker (bzw. seinen Nachfolgern) nicht sonderlich beeindrucken lassen.

Bei einem VPN wird es richtig schwierig mit dem Sichern. Da würde mir direkt Virtualisierung einfallen vom VPN Gateway und den dann abgesichert, ein neuinitialisieren wenn die Kiste geknackt wurde wäre da einfacher.

Alles was mit Virtualisierung läuft (wobei mir jetzt nicht klar ist welche Verbindung Du da zu VPNs hast, wofür ein "richtiges" VPN wenn man auf dem selben Rechner bleibt?) wäre für ein Projekt wie das vom OP sicher eher nicht geeignet.

Nyxus wrote:Wo ist das Problem? Natürlich geht das, andere HIPS oder Sachen wie mod-security bekommen das auch hin. Man muß halt seine IPS-Funktionalität an der richtigen Stelle ansetzen. Wo steht, daß ein IPS immer auf dem Netzwerklayer arbeiten muß? Und wenn Du unbedingt einen Proxy haben willst kann der aber natürlich auch auf der selben Maschine laufen.

Host IDS/IPS bzw. Hybrid IDS/IPS wie Prelude setzen da aus wo die Application anfängt, und wenn ich nur den Apachen sichere (als Beispiel), was mache ich mit dem Mailserver, ggfl. dem Proxy fürs Intranet oder andere Sachen? Zugegeben, ich hab nie in mein Leben ein funktionierenden Exploit für Postfix gesehen auf den Mailinglists (jedenfalls kann ich mich nicht erinnern), allerdings heißt das nicht das es in der Zukunft nicht geht. IDS/IPS Systeme sind für mich immer eigenständige Systeme die den Verkehr überwachen und jemanden unterstützen, richtig absichern kann man nur das Zielsystem bzw. deren Applicationen.

Nyxus wrote: Da gab es auf SF aber schon aktuellere Sachen zum Thema. Und wo Du diesen Artikel ansprichst, inzwischen hat wohl jedes IDS anti-evasive-Techniken eingebaut, die sich von Whisker (bzw. seinen Nachfolgern) nicht sonderlich beeindrucken lassen.
/quote]

Jain, das mit anti-evasive ist wieder etwas wo ich nicht 100% trauen würde. Neuste Exploits die verschlüsselt sind gehen immernoch durch denke ich. Sowas wäre mal interessant zu testen. Whisker, Nessus oder Nikto sind für mich an sich nur wenig aussagekräftig, sowas muss man mit funktionierenden Exploits selbst testen. Metasploit wäre vielleicht zur unterstützung ganz gut, allerdings nicht mit den Standard Modulen.

Nyxus wrote: Alles was mit Virtualisierung läuft (wobei mir jetzt nicht klar ist welche Verbindung Du da zu VPNs hast, wofür ein "richtiges" VPN wenn man auf dem selben Rechner bleibt?) wäre für ein Projekt wie das vom OP sicher eher nicht geeignet.

VPN´s ist ein großer Begriff, ich versteife mich nicht auf FreeSWAN oder Openssl. Eine https Verbindung ist schon ein VPN. Tunnel für ganze Netze sind sowisso viel kritischer zur schwieriger zu überwachen als https, von daher würde ich einfach eine möglichkeit wählen das System schnell in den Produktivbetrieb zu versetzen. Ob du jetzt auf einer Maschine mit XEN ein Virtuelles System aufsetzt oder auf einer kleinen Kiste ohne HDD ein Diskettensystem oder über Netzwerk das OS bootest ist egal, jedenfalls muss das System schnell wieder abzusichern sein.

Ich denke sein Projekt ist dazu gedacht ein Bastionshost zwischen meinen Zielsystem und dem Internet bereitzustellen, oder ist das einfach nur als zwischenstation zu einem Rootie gedacht, glaub das wäre leicht Overdozed.

Lord_Pinhead wrote:Host IDS/IPS bzw. Hybrid IDS/IPS wie Prelude setzen da aus wo die Application anfängt, und wenn ich nur den Apachen sichere (als Beispiel), was mache ich mit dem Mailserver, ggfl. dem Proxy fürs Intranet oder andere Sachen?

genau das gleiche wie beim Apachen. Wenn man die auch in einer Single-Machine-Lösung (und darum ging es dem OP wohl hauptsächlich) sichern will, dann muß man sofern man die Lösung auch für verschlüsselte Verbindungen implementieren will, den Weg gehen und für *jede* zu sichernde Anwendung einen Proxy zwischenschalten. Sicher sehr viel Arbeit, IMHO mehr als in einem Projekt von zwei, drei Leuten nebenbei erbracht werden kann, aber es kann gehen. Ansonsten muß halt die Aufgabenstellung umdefiniert, und das ganze nur für Klartext aufgebaut werden. Für so ein Hobby-Projekt wäre das ja auch ok.

Zugegeben, ich hab nie in mein Leben ein funktionierenden Exploit für Postfix gesehen auf den Mailinglists (jedenfalls kann ich mich nicht erinnern), allerdings heißt das nicht das es in der Zukunft nicht geht.

Zur Not gibt es ja noch Sendmail ... :twisted:

IDS/IPS Systeme sind für mich immer eigenständige Systeme die den Verkehr überwachen und jemanden unterstützen, richtig absichern kann man nur das Zielsystem bzw. deren Applicationen.

Was ja nicht heißt, deß es nur sowas geben muß, oder? Und wenn neodg das als Host-basiertes System bauen möchte, warum nicht? NIDS/NIPS und HIPS können sich gerade wegen der verschlüsselten Anwendungen sehr gut ergänzen.

Jain, das mit anti-evasive ist wieder etwas wo ich nicht 100% trauen würde. Neuste Exploits die verschlüsselt sind gehen immernoch durch denke ich.

Muss nicht unentdeckt bleiben. Natürlich laufen die meisten IDSen den Angriffen hinterher, aber die Payload-Inspection ist teilweise auch nur ein Hinweis von mehreren.

VPN´s ist ein großer Begriff,

eben ...

Eine https Verbindung ist schon ein VPN.

Das ist aber ein sehr eingeschränktes "N" sofern Du nicht von diesen unsäglichen SSL-VPNs redest.

Tunnel für ganze Netze sind sowisso viel kritischer zur schwieriger zu überwachen als https

die sind schon deshalb einfacher zu überwachen weil man einen definierten Übergabepunkt hat an dem die Daten im Klartext vorliegen und dem IDS/IPS übergeben werden können.

von daher würde ich einfach eine möglichkeit wählen das System schnell in den Produktivbetrieb zu versetzen. Ob du jetzt auf einer Maschine mit XEN ein Virtuelles System aufsetzt oder auf einer kleinen Kiste ohne HDD ein Diskettensystem oder über Netzwerk das OS bootest ist egal, jedenfalls muss das System schnell wieder abzusichern sein.

Und wegen des "schnell abzusichern sein" würde ich ein VPN-Gateway nicht mit einem "normalen" BS aufbauen dem man dauernd hinterherpatchen muß. Aber ...

Ich denke sein Projekt ist dazu gedacht ein Bastionshost zwischen meinen Zielsystem und dem Internet bereitzustellen, oder ist das einfach nur als zwischenstation zu einem Rootie gedacht, glaub das wäre leicht Overdozed.

... da er in seiner ersten Mail von "Server, später auch Workstations" geschrieben hat sehe ich halt überhaupt kein Gateway, sondern einfach nur eine Komponente die z.B. auf einem Root-Server installiert wird.

Freut mich das ich darüber eine Dikussion ausgelöst habe :-D

Also grundsätzlich müssen wir hier einmal unterscheiden:

Host-basierend (Server, Worstation)
Netzbasierend (als Gateway für Server oder wegen meiner Firmennetzwerke)

heißt, wird es auf dem selben Server/Rechner installiert, der auch geschützt werden soll, oder läuft es auf einer eigenständigen Maschine.

Nehmen wir jetzt mal grundsätlich als Vorgabe an:

IPTables-Firewall
bis auf Layer 7, damit kann man schon mal eingehenden und ausgehenden Traffic sperren/freigeben + angeben welcher Traffic über welchen Port kommen/gehen darf.

Das mit den verschlüsselten Verbindungen ist so eine Sache, grundsätzlich wäre es mit Squid relativ einfach machbar, einige Verschlüsselungen übernehmen zu lassen und dann zu scannen, aber so weit will ich noch gar nicht gehen. Der Ansatz für den Anfang soll ja mal ein Angriff,... sein, der erkannt werden soll (IDS) und gegebenenfalls Gegenmaßnahmen (IRS) eingeleitet werden sollen.

Beispiel: im Maillog, kommt regelmäßig ein Server daher und will eine Mail an jemanden schicken, den es gar nicht gibt, aber immer mit abwechselnden Namen (ist ja heute eh schon ein Standardgeschehen.

auswerten - erkennen - Host in IP-Tables für XStunden sperren

Beispiel 2: Auf Port 80 (http) kommen mehr als X Anfragen von einem Host in X Sekunden.

selbiges: auswerten - erkennen - Host in IP-Tables für x Stunden sperren

selbiges für Portscans, DDos,...

Das wäre mal der Anfang den ich angedacht hätte. Selbst für verschlüsselte Verbindungen auf Server-Basis gilt das, kommen zu viele Anfragen gleichzeitig -> Sperre

Wenn so etwas stabil läuft, kann man ja dann weiterdenken würde ich sagen...

neodg wrote:Beispiel: im Maillog, kommt regelmäßig ein Server daher und will eine Mail an jemanden schicken, den es gar nicht gibt, aber immer mit abwechselnden Namen (ist ja heute eh schon ein Standardgeschehen.

auswerten - erkennen - Host in IP-Tables für XStunden sperren

Beispiel 2: Auf Port 80 (http) kommen mehr als X Anfragen von einem Host in X Sekunden.

selbiges: auswerten - erkennen - Host in IP-Tables für x Stunden sperren

zumindest das geht doch jetzt schon per Logfileanalyse. Vielleicht baut Alexander sein Script ja auch für sowas um. Aber Snort und Konsorten benötigt man dafür nicht.

selbiges für Portscans,

Leute die sich auch immer gerne mal wieder freudig in den Fuß schießen nehmen dafür Portsentry.

DDos,...

Wird nichts ohne Unterstützung des Providers.

neodg wrote: IPTables-Firewall bis auf Layer 7, damit kann man schon mal eingehenden und ausgehenden Traffic sperren/freigeben + angeben welcher Traffic über welchen Port kommen/gehen darf.

Dazu braucht man aber nicht unbedingt Layer7, das kann ich zentral viel einfacher regeln als jetzt auf jedem Client. Zusammen mit Traffic Shaping ist das relativ einfach am Gateway zu lösen. (auch wenn der Gateway gleichzeitig das Hostssytem ist)

neodg wrote: Das mit den verschlüsselten Verbindungen ist so eine Sache, grundsätzlich wäre es mit Squid relativ einfach machbar, einige Verschlüsselungen übernehmen zu lassen und dann zu scannen, aber so weit will ich noch gar nicht gehen. Der Ansatz für den Anfang soll ja mal ein Angriff,... sein, der erkannt werden soll (IDS) und gegebenenfalls Gegenmaßnahmen (IRS) eingeleitet werden sollen.

Beispiel: im Maillog, kommt regelmäßig ein Server daher und will eine Mail an jemanden schicken, den es gar nicht gibt, aber immer mit abwechselnden Namen (ist ja heute eh schon ein Standardgeschehen.

auswerten - erkennen - Host in IP-Tables für XStunden sperren

Und dann probiert er es wieder, und wieder, und wieder. Also dem ist nicht viel geholfen denke ich. Diese Bots klappern ganze Netze ab und brauchen dafür ein ganzes Stück, von daher ist da eher eine Abusemail die bessere Variante. Allerdings, macht man das Automatisch reagieren die Abuse-Stellen nicht mehr, macht man das per Hand kann man sein Job kündigen und nur noch Abuses rausschicken.

neodg wrote: Beispiel 2: Auf Port 80 (http) kommen mehr als X Anfragen von einem Host in X Sekunden.
selbiges: auswerten - erkennen - Host in IP-Tables für x Stunden sperren

mod_evasive installieren und der Apache regelt das von selbst. Muss ich nicht mit Netzwerkfiltern anfangen und mit Scud-Racketen auf Mäusejagt gehen.

neodg wrote: selbiges für Portscans, DDos,...

Portscans die mit einer Anfrage die Stunde ankommen erkennst du nicht, das ist ein leidiges Thema. Ausserdem sind mir Portscans unwichtig, da würde ich eher Fallen ins System einbauen die an Port xy lauschen und bei Verbindungsversuchen sollen die Alarm schlagen oder eine IPTables regel auslösen für den Host. Lässt sich relativ einfach lösen und ist sicherer als man denkt. Binde auf Port 22 (SSH wurde dazu auf ein anderen Port verlegt) ein Perlscript das bei einem Verbindungsversuch die IP via IPT sperrt und ein Syslog Eintrag macht. Dürfte relativ einfach zu handeln sein und jeder Portscanner und pseudohacker fällt drauf rein. Allerdings solltest du definitv daran denken alle x Stunden die Blacklist zu flushen, jede Regel die du zusätzlich einbaust merkt man an der Geschwindigkeit beim normalen verbinden da IPT alle Regeln durchgeht bis eine passende gefunden wird oder die Default Regel wird verwendet. Wenn ich 1000 Einträge habe wird das ganz schon lange für eine simple verbindung dauern.

Beim Thema DDoS kann man sich jetzt streiten, allerdings, selbst wenn du die IP´s auf eine Blacklists setzt und dann keine Antwort mehr von dir gibst, die laufen weiter und machen deine Leitung nieder. Da hilft wirklich nur beim ISP anrufen das er die Leitung sperrt. Relativ einfach wäre eine DNS Reflection Attack zu handhaben und du wirst niemals den Verursacher ausmachen.

neodg wrote: Das wäre mal der Anfang den ich angedacht hätte. Selbst für verschlüsselte Verbindungen auf Server-Basis gilt das, kommen zu viele Anfragen gleichzeitig -> Sperre

Wenn so etwas stabil läuft, kann man ja dann weiterdenken würde ich sagen...

Eines nach dem anderen. Bei einer Verschlüsselten Verbindung kannst du nicht einfach sagen nach X Packeten ist es ein Angriff. Illegale Verbindungen haben weniger Packete als eine legale und sind langsamer (in den meisten Fällen). Die erkennung ist mal wieder so gut wie unmöglich, leider.

An sich sind deine Ideen schon gut, allerdings musst du immer dran denken das der Aufwand und das Pflegen des Systems auch wirklich Zeit kosten kann. Von den Kosten mal abgesehen die dadurch entstehen, oder bei falscher Ausführung eine lahmende Internetverbindung. Das einfachste für den Anfang ist einfach am Gateway zu arbeiten und dort eine Handvoll von Regeln und Einstellungen zu machen. Clients zu verwalten, sei es jetzt Firewall, IDS System etc. ist kein pappenstiel. Aber wie gesagt, der Grundgedanke ist an sich gut und muss nur ausgebaut werden ;)

@Nyxus
Bei den VPN´s kann man sich jetzt sicherlich streiten, die definition von einem VPN ist wirklich ein Allrounder. Allerdings, wenn jemand mit VPN anfängt, meint er meist sowas wie FreeSWAN o.ä. Jedenfalls ist das meine Erfahrung wenn ich die Fragen dazu oft lese *G*

Lord_Pinhead wrote:@Nyxus
Bei den VPN´s kann man sich jetzt sicherlich streiten, die definition von einem VPN ist wirklich ein Allrounder. Allerdings, wenn jemand mit VPN anfängt, meint er meist sowas wie FreeSWAN o.ä. Jedenfalls ist das meine Erfahrung wenn ich die Fragen dazu oft lese *G*

Einige der letzten mit denen ich gearbeitet habe haben auch mit VPNs gearbeitet und das Wort "Verschlüsselung" oder "Kryptographie" ist nicht ein einziges Mal gefallen. Und auch die hatten Recht mit der Benutzung dieses Begriffes. ;-)