Fingerprinting jetzt auch mit OpenBSD-PF

CW

Netswimmer
Wie ich gerade bei http://www.deadly.org erfahren habe, ist es mittlerweile möglich, mittels PF (PacketFilter) Fingerprinting auszuführen.

Hier der Link: http://www.w4g.org/fingerprinting.html

Sobald man auf diese Site gelangt, wird der jeweilige Rechner gescannt und man kann mithelfen, die Fingerprint-Datenbank zu aktualisieren.

Alles freiwillig natürlich. :)

Geht hin, informiert euch und helft die Datenbank auf dem neusten Stand zu halten.

CW
 
Zuletzt bearbeitet:
Das sollte sich der Junge schnell patentieren lassen, damit kann man bestimmt 'ne Menge Geld verdienen :-)
 
Ja, verdammt.
Ich überlege gerade meinen Router/FW auf OpenBSD umzustellen.
Nicht nur wegen des hier geposteten fingerprints, aber ich habe das Gefühl das die Jungs gerade sowas von Gas geben was security angeht, Hut ab.

Naja, wahrscheinlich wirds aber erstmal bei FreeBSD auch auf dem Router/FW bleiben, da mir OpenBSD keine Jails bereitstellt. Schade. Sollten die sich doch um Austausch von PF auch an Board holen...
 
Original geschrieben von asg
Ja, verdammt.
Ich überlege gerade meinen Router/FW auf OpenBSD umzustellen.


Tue das!

Wenn du Hilfe brauchst, dann poste doch hier rein ;)

Nicht nur wegen des hier geposteten fingerprints, aber ich habe das Gefühl das die Jungs gerade sowas von Gas geben was security angeht, Hut ab.

Genau.

Naja, wahrscheinlich wirds aber erstmal bei FreeBSD auch auf dem Router/FW bleiben, da mir OpenBSD keine Jails bereitstellt. Schade. Sollten die sich doch um Austausch von PF auch an Board holen... [/B]

Jails sind leider nicht aus dem FreeBSD-Codebaum in den OBSD-Codebaum portierbar.

Sowas müsste man from Scratch machen.

Die jails sind aber nicht die einzige Möglichkeit, deine Programme vorm "Ausrasten" zu schützen.

OpenBSD ist mit seiner gesamten Architektur darauf ausgelegt, dir soviel Freiraum wie möglich zu geben und dafür die Dienste/Programme zu kontrollieren.

Schon mal was von Systrace gehört.

Damit legst du fest, was ein Programm tun darf und was nicht.

Und das während du das Programm startest.

Jeder System-Call wird untersucht und überprüft.

Und du entscheidest ob "Permit" oder "Deny" ausgeführt werden soll.

Systrace ist fest in OpenBSD drin. Braucht nicht installiert zu werden.

Eine komfortable GUI hast du ja auch (für alle Fälle).

Hier die Manpage: http://www.openbsd.org/cgi-bin/man....manpath=OpenBSD+Current&arch=i386&format=html

Und hier die Homepage: http://www.citi.umich.edu/u/provos/systrace/

Unter FreeBSD soll es auch einen Port geben, der aber etwas älter ist.

NetBSD hat denselben Port wie OpenBSD.

Gruß

CW
 
Ok Leute, ich find das ja auch ziemlich cool mit dem Fingerprinting, aber nennt mir doch mal bitte ein paar _SINNVOLLE_ Anwendungsmoeglichkeiten fuer das Teil.

Mal abgesehen von Windows -> SMTP -> /dev/null. Aber das ist auch schon fast zuviel des Guten...
 
Original geschrieben von MrFixit
Ok Leute, ich find das ja auch ziemlich cool mit dem Fingerprinting, aber nennt mir doch mal bitte ein paar _SINNVOLLE_ Anwendungsmoeglichkeiten fuer das Teil.

Mal abgesehen von Windows -> SMTP -> /dev/null. Aber das ist auch schon fast zuviel des Guten...

Falls du es nicht mitbekommen hast, aber in letzter Zeit häuften sich doch die Meldungen über verschiedene Viren, die bestimmte Systeme befallen haben (z.B. Lovesan auf NT/2k/XP).

Mit so einer Regel, wäre es z.B. möglich, solche Rechner schon von vorne herein vom Zugriff auf die Mailserver fernzuhalten.

Das wäre eine Anwendungsmöglichkeit.

Oder z.B. wäre es möglich zu erkennen, welche ServicePacks (in der Win-Welt wohl bekannt) die jeweligen Rechner haben und die User auf eine Site redirecten, wo man die Updates holen könnte.

Viele, viele Möglichkeiten

CW
 
Zuletzt bearbeitet:
Original geschrieben von ColdWisdom
Wenn du Hilfe brauchst, dann poste doch hier rein ;)

Hehe, es gibt doch www.openbsd.org

Schon mal was von Systrace gehört.
Damit legst du fest, was ein Programm tun darf und was nicht.
Und das während du das Programm startest.
Jeder System-Call wird untersucht und überprüft.
Und du entscheidest ob "Permit" oder "Deny" ausgeführt werden soll.
Systrace ist fest in OpenBSD drin. Braucht nicht installiert zu werden.
Eine komfortable GUI hast du ja auch (für alle Fälle).

Yapp.
Nur, eine Jail ist für mich interessanter da ich ein System in einem System welches vollkommen autark arbeitet.
Naja, mal sehen, irgendwann schau ich mir OpenBSD auch mal an. Ich hätte ja längst, aber mein CD-ROM im Laptop bootet keine OpenBSD CD, und das Floppy ist defekt.
 
Original geschrieben von asg
Hehe, es gibt doch www.openbsd.org


Schon klar.

Jedoch ist es sehr gut, wenn wir von den Erfahrungen anderer profitieren.

Das macht das Board noch beliebter und bekannter.

Yapp.
Nur, eine Jail ist für mich interessanter da ich ein System in einem System welches vollkommen autark arbeitet.

Unter OpenBSD ist dies ebenfalls möglich, nur mit anderen Mitteln.

Ist halt 'ne Sache von Geschmack, Vorlieben und Erfahrung. :)

Naja, mal sehen, irgendwann schau ich mir OpenBSD auch mal an. Ich hätte ja längst, aber mein CD-ROM im Laptop bootet keine OpenBSD CD, und das Floppy ist defekt. [/B]

Schade :(

Gruß

CW
 
Irgendwie finde ich an den Jails was komisch:

Ich baue eine Jail, weil ich vermute, dass mein System unsicher ist, ich es gegen irgendetwas schützen muss oder quasi damit rechne, dass mein System kompromittiert wird.
Allerdings sind Jail und Hostsystem quasi dasselbe und somit in etwa gleich "unsicher". (Jaja, ich weiß, man kann in Jail und Hostsystem versch. Dienste laufen lassen, Ports auf- und zu machen etc. Es bleibt dennoch die gleiche Basis.). Demzufolge ist mein Hostsystem in etwa gleich sicher wie eine Jail.

Jetzt die andere Philosphie:
Wenn ich ein System habe, dass "in sich" sicher ist, muß man sich m. M. nach weniger Sorgen machen, da es einfach per Definition und von Grund auf sicher ist. Das hantieren mit Jails fällt weg.

Nur 'ne Meinung...

Gruß
RW

PS: Ihr dürft jetzt über mich herfallen und mich in der Luft zerfetzen. Aber bitte nicht an Formulierungen rummäkeln; der Grundgedanke wird wohl rübergekommen sein ;)
 
Original geschrieben von ReinerWein
Allerdings sind Jail und Hostsystem quasi dasselbe und somit in etwa gleich "unsicher". (Jaja, ich weiß, man kann in Jail und Hostsystem versch. Dienste laufen lassen, Ports auf- und zu machen etc. Es bleibt dennoch die gleiche Basis.). Demzufolge ist mein Hostsystem in etwa gleich sicher wie eine Jail.

Wo aber liegt der Vorteil?
Freunde wie mailserver etc. laden ab und an dazu ein gehackt zu werden, sendmail beispielsweise.
Der User muss nicht gleich root Zugriff haben, dennoch reicht es aus um im System herumzustöbern und es weiter zu probieren root zu werden, oder trojaner zu hinterlassen, etc.
Bekomme ich dies auf einem Hostsystem mit, dann muss ich ganz schön schwitzen um alle evtl. veränderten Datein ersetzen, bzw. nach backdoors ausschau halten. Vollkommen sicher wäre dann eine Neuinstallation.
Habe ich eine Jail, dann kann er dort einbreachen, das eigentliche system bleibt aber so wie es ist unverändert. So laufen evtl. auch andere Dienste (www, ftp) in anderen jails weiter die mir sonst hätten abgeschossen werden können. Wenn er das System verseucht. Was solls.
Ich bemerke das. Lösche die Jail, und kopiere an deren Stelle eine Backup-Jail, starten, fertig.
Das Hostsystem wird nicht betroffen, das ist der Vorteil.
Das selbe sind sie auch nicht, da man eine Jail wie ein normales FreeBSD System configurieren kann, so auch die Sicherheit erhöhen oder auch nicht...

Jetzt die andere Philosphie:
Wenn ich ein System habe, dass "in sich" sicher ist, muß man sich m. M. nach weniger Sorgen machen, da es einfach per Definition und von Grund auf sicher ist. Das hantieren mit Jails fällt weg.

Ich kann mit Jails für eine klare Trennung sorgen. So lasse ich in der einen den httpd rennen, in der anderen mailserver. Klappt wunderbar. Wird in eines eingebrochen kann das andere nicht in Mitleidenschaft gezogen werden.
Auch kann ich anderen Usern root ZUgriff auf jails geben, kein Problem.
Hoster können auf einer Maschine mehrere "virtuelle" FreeBSD laufen lassen, Kostenersparnis, administrativ einfacher zu gestalten, schnelle Wiederherstellung.

Jails bieten somit Sicherheit und Flexibilität, und das auf Kosten einer IP und etwas Plattenplatz. Warum also darauf verzichten?
 
Mit so einer Regel, wäre es z.B. möglich, solche Rechner schon von vorne herein vom Zugriff auf die Mailserver fernzuhalten.

Das wäre eine Anwendungsmöglichkeit.
Wie ich bereits schrieb, ist das die einzige Moeglichkeit, die ich da sehe. Aber danke, dass du mich da nochmal drauf hinweist :). Nur leider ist das Ganze mehr als nur zweifelhaft. Warum sollte ich einem User von OS xyz verbieten mir Mails zuzustellen? Ich kann doch nicht riechen ob er mir da Spam, Viren oder sonstwas zustellen will
Oder z.B. wäre es möglich zu erkennen, welche ServicePacks (in der Win-Welt wohl bekannt) die jeweligen Rechner haben und die User auf eine Site redirecten, wo man die Updates holen könnte.

So? Dann muss das aber ein verdammt gutes passives Fingerprinting sein, wenn die da mal eben die ServicePack Nummer aus den TCP Paketen ersehen koennen.

Aehnlich effektiv ist wohl:
block all from <random-ip>
 
Original geschrieben von MrFixit
Wie ich bereits schrieb, ist das die einzige Moeglichkeit, die ich da sehe. Aber danke, dass du mich da nochmal drauf hinweist :). Nur leider ist das Ganze mehr als nur zweifelhaft. Warum sollte ich einem User von OS xyz verbieten mir Mails zuzustellen? Ich kann doch nicht riechen ob er mir da Spam, Viren oder sonstwas zustellen will


Falls du es nicht weißt, aber OpenBSD hat sei 3.3 den sog. spamd (fake Sendmail-daemon) mit dem man die Spams filtern kann (in verbindung mit Spam-Datenbanken),

Man soll niemals von einer neuen Technologie erwarten, dass sie alles auf einmal kann, denn dann könnten doch Projekte nach gewisser Zeit dicht machen.

Gute Konfigurationen sind immer auf gute Zusammenarbeit von Komponeneten angewiesen und diese neue Komponenete von pf bringt noch mehr Möglichkeiten (auch wenn du diese vielleicht nicht siehst).

Besuche doch die http://www.deadly.org und überzeuge dich.

So? Dann muss das aber ein verdammt gutes passives Fingerprinting sein, wenn die da mal eben die ServicePack Nummer aus den TCP Paketen ersehen koennen.

Ich sehe, das du meine erste Mail nicht genau gelsene hast.

Der Typ, der dieses entworfen hat BITTET um mithilfe (so gehört sich das in der OSS-Community).

Er ist gerade dabei die Fingerprint-Datenbank zu erweitern.

Es läuft so ab wie bei nmap z.B.

Es wäre gut, mitzuhelfen und nicht sofort die Sache als zu schwach darzustellen.

Aehnlich effektiv ist wohl:
block all from <random-ip> [/B]

Wenn du der Meinung bist, dass man Fingerprints auf der Netzschicht erkennen kann bzw. diese schon auf der Netzschicht erledigt, sodass eine weitere Erkennung nicht nötig sei... bitte, nur zu ... aber dann poste dies doch auch in den einschlägigen Stellen, wie z.B. misc@openbsd.org.

Mal sehen, was die Profis dazu sagen. :)

Ich werde jetzt auf alle Fälle die frisch angefertigte pf-FAQ posten und auch ein PDF-File zum Download anbieten.

Hauptsache die Leute machen mit und versuchen anderen was beizubringen.

Darauf kommt es an.

CW
 
Zuletzt bearbeitet:
Original geschrieben von ColdWisdom
Falls du es nicht weißt, aber OpenBSD hat sei 3.3 den sog. spamd (fake Sendmail-daemon) mit dem man die Spams filtern kann (in verbindung mit Spam-Datenbanken)
Spamd ist aber ein sog. Teergrube und blockt letzten Endes alle eingehenden Mails. Eben das finde ich nicht gut, da es vollkommen legitim ist, wenn ein Windows Rechner direkt auf Port 25 beim MX seine Mails abliefert. Diese Nutzung wird aber dann aber unmoeglich gemacht.
Ich sehe, das du meine erste Mail nicht genau gelsene hast.
Der Typ, der dieses entworfen hat BITTET um mithilfe (so gehört sich das in der OSS-Community).
Er ist gerade dabei die Fingerprint-Datenbank zu erweitern.

OS Fingerprinting nur anhand von TCP-Pakete ist sowieso reines Voodoo und kann hoechstens noch Linux von BSD von Windows unterscheiden. Und da soll es erkennen koenne ob ein Hotfix eingespielt ist oder nicht? LOL

Immerhin behauptet nmap auch steif und fest dass es sich bei einer Acorn Kiste hier um NetBSD handelt (kein Wunder, schliesslich wurde einfach der NetBSD TCP/IP-Stack uebernommen). Und das ist ein aktiver Scan gewesen...
 
Original geschrieben von MrFixit
Spamd ist aber ein sog. Teergrube und blockt letzten Endes alle eingehenden Mails.


Stimmt nicht.

Spamd wird zusammen mit Black- und Whitelists betrieben.

Dazu noch kann man auch die immer wieder aktualisierten Spammer-Datenbaken holen.

Lies doch einfach die Manpage: http://www.openbsd.org/cgi-bin/man....5&arch=i386&apropos=0&manpath=OpenBSD+Current

Eben das finde ich nicht gut, da es vollkommen legitim ist, wenn ein Windows Rechner direkt auf Port 25 beim MX seine Mails abliefert.

Warum hälst du dich so sehr an 25 fest.

Ist es etwa der einzige Port?

Oder würdest du auch abnormale Anfragen, die 1000 Mal in der Sekunde passieren (a.k.a DoS-Attack) als etwas normales ansehen?

Gab es da nicht vor einigen Tagen einen Virus, der sowas mit MS-Servern machen wollte?

Und stell dir doch einfach vor, du weißt dass es sowas gibt und du weißt, welche Maschinen betroffen sind (also NT/2k/XP) und du weißt, welche Ports angesprochen werden sollen.

Was machst du dann?

Also ich würde nach Möglichkeiten suchen, es wirkungsvoll zu bekämpfen.

Diese Nutzung wird aber dann aber unmoeglich gemacht.

Stimmt einfach nicht.

Nur hypothetisch vielleicht, wenn man sich an den einen Port 25 festbeißt.

OS Fingerprinting nur anhand von TCP-Pakete ist sowieso reines Voodoo und kann hoechstens noch Linux von BSD von Windows unterscheiden.

Das sagst du.

Gehe bitte zu http://www.insecure.org und behaupte dies.

Oder am besten sage dies doch bei http://www.securityfocus.org

Gebe bitte Belege für deine Behauptung und keine Metaphern.

Und da soll es erkennen koenne ob ein Hotfix eingespielt ist oder nicht? LOL

Wenn du die Website besucht und mitgemacht hättest, um die Datenbank zu erweitern, dann hättest du auch eine einfach Abfrage vor dir gehabt, die auch nach einem potentiellen ServicePack in deinem Win-System gefragt hätte.

Aber ich sehe, du redest über etwas, was du nicht kennst.

Immerhin behauptet nmap auch steif und fest dass es sich bei einer Acorn Kiste hier um NetBSD handelt (kein Wunder, schliesslich wurde einfach der NetBSD TCP/IP-Stack uebernommen).

Also müssten wohl, deinen Worten zufolge, die ganzen Kenner ziemlich viel Zeit mit nmap & Co. verschwenden, weil du ja dich da so gut auskennst, dass du dies behaupten kannst.

Außerdem solltest du wissen, dass es auch eben ausreicht, die ART des Stacks zu erkennen, um das gesamte System zu übernehmen.

Es ist so wie bei einem BufferOverflow: nicht das OS muss ein Loch haben. Ein kleines Programm reicht da völlig aus.

Und das ist ein aktiver Scan gewesen... [/B]

Ja, ja, ja ... und wir alle anderen sind dabei unsere Zeit zu verschwenden, wenn wir nmap nutzen und viel lesen.

CW
 
Zuletzt bearbeitet:
Oder würdest du auch abnormale Anfragen, die 1000 Mal in der Sekunde
passieren (a.k.a DoS-Attack) als etwas normales ansehen?

Was kann spamd gegen DoS Attacken machen, oder der fingerprint?
Prinzipiell hilft da bekanntlich recht wenig.
Man könnte die forks beschränken bei beispielsweise Apache, dann wird der Rechner wenigstens nicht plattgemacht, aber normale User kommen auch nicht auf die webseite.
Was den fingerprint angeht so kann dieser sich dann darauf reagieren woher der DoS kommt, aber meist kommt der aus zig versch. Ecken, und arbeiten muss auf dem Rechner auch was und die Anfragen bearbeiten...
 
Original geschrieben von asg
Was kann spamd gegen DoS Attacken machen, oder der fingerprint?
Prinzipiell hilft da bekanntlich recht wenig.
Man könnte die forks beschränken bei beispielsweise Apache, dann wird der Rechner wenigstens nicht plattgemacht, aber normale User kommen auch nicht auf die webseite.
Was den fingerprint angeht so kann dieser sich dann darauf reagieren woher der DoS kommt, aber meist kommt der aus zig versch. Ecken, und arbeiten muss auf dem Rechner auch was und die Anfragen bearbeiten...

Spamd verbraucht die Anfragen der feindlichen Clients.

Es ist nämlich so, dass jede Anfrage auch eine Antwort haben mus, damit die anfragende Maschine weiter "reden" kann.

Und spamd greift eben dazwischen rein und lässt auf seine Antwort einfach "viel zu lage" warten.

Außerdem (wie ich schon mal sagte) MUSS man mehrere Komponenten miteinander Kombinieren.

PF, spamd, IDS (z.B. snort) usw.

CW
 
Zuletzt bearbeitet:
Wie dem auch sei, ich glaube nicht das dieser Verbund etwas gegen DoS machen kann. Man kann es hinauszögern, hoffen das der Angriff nicht so gross ist, aber Ende, wenn der DoS es will, verliert man immer.
 
Original geschrieben von asg
Wie dem auch sei, ich glaube nicht das dieser Verbund etwas gegen DoS machen kann. Man kann es hinauszögern, hoffen das der Angriff nicht so gross ist, aber Ende, wenn der DoS es will, verliert man immer.

Es gibt da Mittel und Wege, wie man es wenigstens versuchen sollte.

Denn schon von vorne herein zu sagen, "es bringt nichts", ist nicht gerade optimistisch für einen Admin.

Ich gehe immer davon aus, dass ich "überleben" werde. ;)

Gruß

CW
 
Sicher gibt es die, wie ich schon schrieb mit den forks beim Apache.
Eine Behauptung das spamd, PF und ein IDS aber für Ruhe sorgen und damit klar kommen ist aber dennoch falsch.
Sicher sollte ein Router/FW über diverse Sicherheitsfeature verfügen, nur sich gegen etwas wehren was eigentlich "normale" anfragen sind, und diese DoS Anfragen von den wirklichen zu unterscheiden, und dabei sollen dann auch noch die betroffenen Dienste normal auf die richtigen requests antworten, wie soll das funktionieren bei einem guten DoS?

Oder so machen wie MS und der Blaster Wurm der nicht auf die IP sondern den Namen ist. Den Namen einfach aus dem DNS löschen, dann hat man auch ruhe...
 
Original geschrieben von asg

Eine Behauptung das spamd, PF und ein IDS aber für Ruhe sorgen und damit klar kommen ist aber dennoch falsch.

Das habe ich niemals gesagt.

Ich sagte: mehrere Komponenten müssen zusammenspielen.

Außerdem spreche ich aus Erfahrung, da ich solche Features anwende, um einen Haufen großer Server zu schützen.

Und (bis jetzt zumindest) hat dies auch geklappt.

Aber ich habe nie gesagt, dass es DAS Heilmittel für alle Sicherheitsprobleme wäre.

Sicher sollte ein Router/FW über diverse Sicherheitsfeature verfügen,

Er MUSS über solche Features verfügen.

Sowas nennt man Defense in Depth, weil da alle Komponenten mitspielen.

Da wird nicht einfach die Security an einen Rechner übertragen, sondern in Schichten auf alle.

Und zwar so, dass sie alle eine funktionierende Einheit im Sinne der Aufgabe bilden --> d.h. als eine Sicherungs-Körperschaft fungieren und auf Anomalien mit ihren jeweiligen Mitteln und Kompetenzen regieren.

Und was ich damit meine, ist ja klar:

1.) PacketFilter filtert

2.) IDS versucht anomale Vorgänge zu erkennen

3.) Router routet nur das, was geroutet werden soll

4.) Switches haben ihre ACLs (Access Control Lists)

5.) Auf der Anwendungsebene laufen andere Tools, wie z.B. spamd oder systrace.

usw. usf.

Dies ist nur eine Beispiel-Liste und soll nicht irgendwelche Reihenfolgen der Wichtigkeiten ausdrücken.

Außerdem ist sie nicht vollständig.

nur sich gegen etwas wehren was eigentlich "normale" anfragen sind, und diese DoS Anfragen von den wirklichen zu unterscheiden, und dabei sollen dann auch noch die betroffenen Dienste normal auf die richtigen requests antworten, wie soll das funktionieren bei einem guten DoS?

Hast du schon mal von Honeypots / Honeytokens gehört?

Eine neue Technologie, die ich bereits getestet habe.

Hier ein Link: http://www.tracking-hackers.com

Wenn ein DoS stattfinden soll, dann wenigstens auf einem imaginären Host bzw. auf einem imaginären Netzwerk.

Auf http://www.securityfocus.org gibt es auch eine Menge an Dokumenten.

Ein HoneyD (ein Daemon) ist bereits für OpenBSD verfügbar.

Für andere BSDs wohl auch.

Hier der Link: http://www.citi.umich.edu/u/provos/honeyd/

Oder so machen wie MS und der Blaster Wurm der nicht auf die IP sondern den Namen ist. Den Namen einfach aus dem DNS löschen, dann hat man auch ruhe... [/B]

In diesem Falle hilft es vielleicht.

Man kommt aber um eine Security-Policy nicht herum.

CW
 
Original geschrieben von ColdWisdom
Spamd wird zusammen mit Black- und Whitelists betrieben.
Und in den Whitelists filterst du auf div. Betriebsysteme?
Warum hälst du dich so sehr an 25 fest.
Ist es etwa der einzige Port?
Nein, es war der Port, den Du mir genannt hast. Ich hatte extra gefragt ob es noch andere Anwendungsgebiete gibt. Bis jetzt steht die Frage offen im Raum...
Oder würdest du auch abnormale Anfragen, die 1000 Mal in der Sekunde passieren (a.k.a DoS-Attack) als etwas normales ansehen?
Was haben DoS Attacken mit passivem Fingerprinting zu tun? Wenn ich angegriffen werde, dann ist es mir doch voellig egal vom welchem OS aus dies geschiet. (Oder willst du etwas mit einem OOB Angriff kontern? :)

Und stell dir doch einfach vor, du weißt dass es sowas gibt und du weißt, welche Maschinen betroffen sind (also NT/2k/XP) und du weißt, welche Ports angesprochen werden sollen.
Was machst du dann?
Also ich würde nach Möglichkeiten suchen, es wirkungsvoll zu bekämpfen.
Ja, in dem ich _bei_mir_ diese Ports dicht halte. Aber doch nicht basierend auf dem _vermeintlichem_ OS des "Angreifers"!!

Fuer mich mal wieder EOT, da Uferlos. Ich habe nach echten Anwendungsmoeglichkeiten gefragt, bis jetzt wurden keine genannt.
 
Original geschrieben von MrFixit
Und in den Whitelists filterst du auf div. Betriebsysteme?


Kann es sein, dass du da Sachen miteinander vermischst?

Ich habe doch gesagt: dass man mehrere VERSCHIEDENE Technologien miteinader kombinieren muss.

Dazu kannst du dir das obere Posting an asg ansehen.

Was soll eigentlich so eine Argumentation?

Das führt doch das ganze ad Absurdum, wenn du die Konversation damit aufhälst. Solche Gedanken-Löcher bringen doch nichts.

Nein, es war der Port, den Du mir genannt hast. Ich hatte extra gefragt ob es noch andere Anwendungsgebiete gibt. Bis jetzt steht die Frage offen im Raum...

Und wo bitte ist der Unterschied zwischen einem Port und einer Anwendung die auf so ein Port zugreift.

Also bitte lese dir doch einfach diesen Thread durch: http://www.deadly.org/article.php3?sid=20030821153534&mode=flat

Du muss doch erst einmal wissen, was das ganze denn ist.

Und um deine Frage zu beantworten: JA es gibt sie.

Man kann z.B. die Zugriffe verschiedener OSe auf verschiedene Server (als Beispiel) umleiten .

Was haben DoS Attacken mit passivem Fingerprinting zu tun? Wenn ich angegriffen werde, dann ist es mir doch voellig egal vom welchem OS aus dies geschiet. (Oder willst du etwas mit einem OOB Angriff kontern? :)

Wenn du dir mein Posting an asg durchgelesen hättest, dann hättest du auch erfahren, wie man solchen Angriffen zuvorkommen könnte.

Und passives Fingerprinting wird eben deshalb angewandt, weil man eigene Pakete nicht verschicken muss und somit auch nicht von den IDS-Systemen erwischt wird.

Schon mal darüber nachgedacht.

Aber jetzt wollen wir doch nicht in eine andere Diskussion abgleiten, nicht wahr?

Ja, in dem ich _bei_mir_ diese Ports dicht halte. Aber doch nicht basierend auf dem _vermeintlichem_ OS des "Angreifers"!!

Fuer mich mal wieder EOT, da Uferlos. [/B]

Ich glaube, du hast da was verwechselt.

Es geht darum zu erkennen, wer z.B. meine Server anfragen KÖNNTE und für den Fall, dass ich es weiß, kann ich ZUMINDEST die bekannten Systeme schon mal aussondern (aus welchen Gründen auch immer) und mich, unter Anwendung anderer Verfahren & Technologien, mit den übrigen Hosts beschäftigen.

Es geht nicht automatisch darum, Angreifer über ihr OS zu erkennen. Sowas ist ja eh doof und darüber habe ich eh nicht geschrieben. Das hast du so auf die Schnelle wohl aufgefasst.

Man soll diese Technologie etwas abstrakter sehen und nicht auf der flachen Sicht bleiben.

Diese Technik kann für vieles benutzt werden.

Und Filtern nach Ports, Systemen und (auch) Patchleveln sind die Methoden, die sofort ins Auge fallen.

Daher lese dir doch die Posts, die ich dir angeboten habe doch einfach mal durch.

Es macht doch keinen Sinn, wenn ich mir erst einmal alles durchlese und dann hier Leuten erst einmal beibringen muss, worum es geht.

In einer Diskussion müssen gleichwertige Informationsgehalte mit neuen Ideen vermengt werden und nicht, dass einer hier sitzt und erst einmal Hirnschmalz verteilt.

Sowas macht doch keinen Spaß.

Man kann mit solchen Methoden doch alles plattmachen.

Und das bringt niemandem was.


CW
 
Zuletzt bearbeitet:
wegen systrace gibt es eine url in der links section (da ist schon laenger nichts mehr neues erschienen, vielleicht ist das projekt tot?).

was den fingerprint angeht, finde ich es definitiv interessant zu wissen von was fuer einer platform aus ich angegriffen werde. es eroeffnet moeglichkeiten aber mindert nicht die qualitaet von pf... also warum nicht?!
 
ich denke eine identifikation des (von einem angreifer) verwendeten betriebssystems laesst (bis zu einem gewissen grade) rueckschluesse auf die person/den angriff zu.

fuer mich gibt es einfach unterschiede ob ich von einer t-online ip mit windows98 als OS gescannt/geprobed/penetrated werde, oder von einer unix kiste die womoeglich bei einer groesseren firma in der dmz steht... bei letzterem ist mir einfach klar das der angreifer womoeglich wirklich weiss was er tut und die box in der dmz nur eine node in "seinem" netz sein koennte.
(ich hoffe ich habe mich halbwegs verstaendlich ausgedrueckt... urrghs... was fuer ein posting! :D)
 
Original geschrieben von asg

Da es im weiteren Sinne hier um security geht, habe ich jails erwähnt und wie man einer DoS Attacke mttels Obergrenze der forks beim Apache, etwas herr werden kann.


Jedoch gilt dies natürlich nur für den Port 80/443 bzw. http/https.

Alle anderen Ports die auch offen wären (je nach Konfiguration), müssten mit einer anderen Technik (oder Kombinationen der Techniken) speziell geschützt werden.

Und das steigert natürlich den Arbeitsaufwand.

Auch portsentry wäre in dem verbund noch zu nennen, da scans auf ports dann eben dynamisch geblockt werden.

Portsentry hat leider den gravierenden Nachteil, dass sie erst nachdem die vermeintliche Attacke passiert ist, die Alarmglocke lauten lässt. Und ein PacketFilter in Verbindung mit einem Fingerprint soll zeitgleich reagieren und die jeweilige Aktion (je nach Verbindungs-/Angriffs-Szenario) starten.

Folgende Aktionen wären denkbar (ich bitte um Erweiterung bzw. Verbesserung):

--------------------------------------------------------------------------

1.) Umleitung auf Honeypots (also nicht-existente Rechner)

2.) Umleitung auf andere Server (wenn also keine Attacke, sondern eine Belastung durch User --> Stichwort: Microsoft-Attacke durch Lovesan ... da hat man alle Euro-IPs umgeleitet)

3.) Umleitung einiger Connections auf einen speziell präparierten Host für die weitere (forensische) Analysen

4.) Direktes Blocken der Malicious-IPs und das am-Leben-Lassen der wohlbekannten IPs, um trotz einer vermeintlichen Attacke die Servicedienste nicht unterbrechen zu müssen (weil man z.B. keine Ausfallserver hat o.ä.)

-----------------------------------------------------------------------------

Es wird beispielsweise eine IPFW Rule hinzugefügt die alle Anfragen von der IP Adresse sofort blockt. Aus Ende.

IPs können sich ändern.

Außerdem können Attacken auch aus dem Inneren des Netzes kommen.

Man sagt ja (es gibt auch Belege dafür), dass ca. 60-70% der Attacken (aller Art) im Innern passieren (also nicht so sehr durch böse Hacker :)

Diese IP wird dann auch noch in einer DB abgelegt.

Prima, jedoch kann man über 4 Milliardem IPs theoretisch haben.

Und ein wirklich versierter Angreifer wird oft seine wahre IP verschleiern und (was noch schlimmer ist), einen anderen Rechner übernehmen und von dort aus attackieren.

DDoS-Attacken laufen so z.B. ab.

Desweiteren natürlich Programm wie aide oder tripwire nutzen.

Natürlich, denn 95% der Attacken werden ja erst gar nicht erkannt. Leider!

Daher sollte man sich wegen ein paar Filter, IDSe u.ä. nicht in Sicherheit wähnen.

Wobei viele den Fehler machen die erstellte DB auf dem Rechner liegen zu lassen, man sollte dies schon von dem Rechner wegschaffen, hier bietet sich eine Floppy an (ja, die Dinger sind sogar zu gebrauchen).

Oder aber einen Host aufsetzen und mit einem Script per ssh die Daten rüberscheffeln.

So habe ich es mit meinen Firewall-Logdateien gemacht.

Da habe ich eine fette Platte in die Logmaschine eingebaut und per ssh von den Firewalls die Logs geholt, sodass die Firewall nicht einmal die Logs auf ihre Platte zwischenspeichern sollte.

Alles ging direkt vom logischen pflog0-Device (mit 100Mbit per ssh) auf die Logmaschine rüber.

Dies ist natürlich nur eine der viele, guten Möglichkeiten.

Eine Firewall seiner Wahl ist Pflicht, logisch.

So selbstverständlich, wie das Amen in der Kirche.

Oder den secureleve hochsetzen, das keine kernelmodule geladen werden können,... .

OpenBSD zumindest läuft out-of-the-box mit Securelevel 1.

Ich habe auf einer Website einige gute Skripte gefunden, die dann systemwichtige Dateien auf schg setzen und Seclevel 2 einschalten.

Da kann man nix mehr ändern.

Bei interesse, kann ich ja die Webseiten posten (sind aber sehr OpenBSD-zentrisch)

Nicht zuvergessen die Dateien mit schg flag zu versehen....

Yepp!

Und, logs anschauen. Logs anschauen.

Aber bitte auf der Logmaschine ;)

In diesem Verbund mach sich dann natürlich noch der von Dir genannten fingerprint bemerkbar.

Genau das war meine Intention.

Nicht ein Allheilmittel, sondern eine Komponente mehr, die weder fett und träge ist, noch die das System, so wie man es kennt, zu stark ändert oder schlimmstenfalls bloated macht.

Es gibt viele Tools, die zwar viel versprechen, jedoch auch viel zu bloated sind.

Eine zusätzliches Sicherheitsfeature. Je mehr desto besser so lange das System noch zu gebrauchen ist und die logs die angelegt werden von der Masse nicht überhand nehmen das man diese nicht mehr liest.

Daher läuft ja auch diese Technik fest im PF drin. Dadurch wird der Fokus nicht auf ein neues Tool oder Modul, sondern vielmehr auf eine neue Option, eine neue Möglichkeit im PF gerichtet.

Und wenn man schon vorher Logs auf die Logmaschine geschickt hat, dann schickt man jetzt dieselben Logs, mit mehr Informationen (mehr Details also), weil man eben dieses neue Feature aktiviert hat.

Und auf der Logmaschine wartet ein freundliches, kleines Tool, dass daraus html, pdf, xml oder txt Dateien generieren kann.

Auf OpenBSD gibt es ein Tool, das PF-Logs so verarbeiten kann.

Unter FBSD müsste es bestimmt sogar mehrere geben. :)

Mann, da beneide ich FBSD-User :D

Interessant wäre in diesem Zusammenhang sicher ein thread oder howto von Free- Open- NetBSD was security angeht. In dem unbedarften Usern gesagt wird was zu machen ist.

Das ist doch eine gute Sache und bringt uns allen was.

So, das waren meine Meinungen dazu ... nochmal: es waren nur Meinungen, denn ein Problem hat (zum Glück) meistens mehrere Lösungsmöglichkeiten.

Gruß

CW
 
Zurück
Oben