iptables Frage

[jdkbx]

da fast alle "wichtigen" Dienste auf extrem vielen Plattformen laufen

für shellcode macht es aber schon nen unterschied was für ne plattform und os dahinterliegt.

Präventives Konzentrieren auf einzelne, eng gefasste, Szenarien verändert deine Gesamtsicherheit so gut wie überhaupt nicht

andersherum. es wird einfach eine sache mehr miterfasst. und zur gesammtsicherhiet dazu addiert. is ja nich so als wäre DROP der zentraler inhalt irgendeiner sicherheitsstrategie.

mit anderen worten:
ich machs nem potenziellen angreifer lieber möglichst schwer. und genau da hilft mir DROP (wenn auch nur in einem speziellen fall)

 

[arkelanfall]

für shellcode macht es aber schon nen unterschied was für ne plattform und os dahinterliegt.

1) Deine Dienste sind in einer Skriptsprache programmiert?
2) Falls du code injection meinst (als Beispiel: sql, perl,...; sprich: (hauptsächlich) Webserver): Sobald du einen Dienst anbietest, sendet dein Rechner auf Anfrage tcp/syn, tcp/ack, tcp/fin Pakete, aus denen sich ebenso wunderschön die gleichen OS-Fingerprints erstellen lassen, wie aus tcp/rst oder icmp-Nachrichten. Eher noch bessere. Dein Drop bringt dann also noch weniger.

mit anderen worten:
ich machs nem potenziellen angreifer lieber möglichst schwer. und genau da hilft mir DROP (wenn auch nur in einem speziellen fall)

Du machst es aber weniger dem Angreifer, als vielmehr den regulären Benutzern schwer.

 

[jdkbx]

1) Deine Dienste sind in einer Skriptsprache programmiert?
2) Falls du code injection meinst (als Beispiel: sql, perl,...; sprich: (hauptsächlich) Webserver)

google mal nach shellcode

 

[arkelanfall]

Du bist auf mein eigentliches Argument nicht eingegangen. Heißt das, dass du mir Recht gibst, dass DROP von tcp/udp nicht mal mehr theoretisch die geringste Spur eines Sinnes macht, sobald man irgendeinen Dienst anbietest?

 

[jdkbx]

wenn der dienst auch von jederman erreichbar ist, ja.
wenn du aber noch zugriffe selektierst ergänzt sich das mit DROP recht gut.

 

[arkelanfall]

wenn der dienst auch von jederman erreichbar ist, ja.

Danke.

wenn du aber noch zugriffe selektierst ergänzt sich das mit DROP recht gut.

Dann muss die Selektion aber auf jeden Fall durch iptables erfolgen. Und das ist meistens nicht praktikabel (ja, ich weiß, Stichwort portknocking, aber auch das ist oft (je nachdem, wer alles Zugriff haben soll) in der Praxis nicht umzusetzen).

Gegen das generelle Blocken von ICMP bin ich aber weiterhin konsequent. Block von mir aus echo requests, aber manche ICMP-Nachrichten (ich reite gerne auf "fragmentation needed" herum), sollten doch zugelassen werden. Ein schönes Beispiel für so einen kaputten Server ist http://crossfire.real-time.com, der sich über DSL nicht ansurfen lässt (Stichwort MTU).

Fazit:
- Droppen von tcp/udp-Anfragen kann (!) Fingerprinting erschweren, solange kein einziger Dienst erreichbar ist. An der Systemsicherheit an sich ändert sich allerdings nichts.
- Blindes Blocken von ICMP-Nachrichten kann extreme Probleme verursachen, über das gezielte Blocken einzelner ICMP-Typen kann man sich streiten.
- Ein korrekt konfiguriertes und aktuelles System hat das Droppen von Verbindungsanfragen im Grunde nicht nötig. Wo kein Dienst erreichbar ist, kann auch keiner "exploitet" werden.
- Ein unsicheres, nicht gepatchtes, falsch konfiguriertes System wird auch durch das droppen von Verbindungsanfragen nicht signifikant sicherer.

Ach so, noch eine Randbemerkung: "Droppen" von udp kann vor allem bei Dialup-IPs zu erhöhtem Traffic beitragen, da bei udp "keine Antwort" mit "Alles ok" gleichgesetzt wird. Hat der Vorbesitzer der IP also einen Videostream angesehen, und die Verbindung unsauber getrennt, streamt der Server an die IP fröhlich weiter, solange er kein icmp "destination unreachable" bekommt.

Können wir uns darauf einigen?

 

[*cerox*]

Und spätestens der letzte Router deines Providers, der die Daten dann an deinen Anschluss weiterleitet, weiß, ob du online bist oder nicht. Und schickt, so er nicht völlig kaputtkonfiguriert wurde, entweder eine Fehlermeldung "host unreachable" an den Absender, oder leitet das Paket an dich weiter. Jetzt klarer?

Nein, ich habe gerade eine Person gebeten mal auf meine Homepage zu gehen, wodurch ich dann ihre IP habe. Nun habe ich einen Ping gesendet - als Meldung kam: "Zeitüberschreitung" - genauso als wenn der Host nicht existieren würde.

Er existiert aber - das beweist schon ein Nachfragen^^ oder ein Tracen mit NeoTrace z.B.

 

[arkelanfall]

Nein, ich habe gerade eine Person gebeten mal auf meine Homepage zu gehen, wodurch ich dann ihre IP habe. Nun habe ich einen Ping gesendet - als Meldung kam: "Zeitüberschreitung" - genauso als wenn der Host nicht existieren würde.

Hä?
Ich probiers nocheinmal langsam von vorne:
Es geht jetzt NUR um tcp-Verbindungen:
Du möchtest eine TCP-Verbindung mit einem Rechner X im Internet aufbauen:
a) Der Rechner akzeptiert die Verbindung, und antwortet mit einem tcp/syn,ack
b) Der Rechner akzeptiert die Verbindung nicht, und antwortet mit einem tcp/rst
c) Der Router vor dem Rechner blockt die Verbindung schon und antwortet mit einem
icmp/dest. unreachable (mit der genaueren begründung host/port unreachable oder "prohibited"
d) Der Rechner X ignoriert die Anfrage, woraufhin dein Rechner die Anfrage noch ein paarmal stelt, und irgendwann per Zeitüberschreitung aufgibt.
e) Die IP-Adresse ist nicht vergeben. Der ISP-Rechner, der für die Weitervermittlung zuständig wäre, Schickt dir ein "host unreachable" zurück.

Er existiert aber - das beweist schon ein Nachfragen^^ oder ein Tracen mit NeoTrace z.B.

Sein Paketfilter wird eben (die Windows XP-Firewall reicht in der Standardeinstellung da auch schon) eingehende icmp echo-requests verwerfen. ICMP ist ja gerade zu Diagnosezwekcen gedacht. Auf ein icmp-echo-request mit "host unreachable" zu antworten wäre sinnlos, da das ja dann eine "echo reply" bedeuten würde, was ja implizieren würde, dass der Host da war.

Du solltest dich wirklich mit den Grundlagen von tcp/udp/icmp/ip vertraut machen, bevor du versuchst einen Paketfilter aufzusetzen. Eine gute Einführung findest du unter Anderem unter http://www.netzmafia.de/skripten/netze/

Nachtrag:
http://www.linkblock.de könnte für dich auch recht interessant sein. Ist zwar viel zum Lesen, lohnt sich aber allemal.

 

[jdkbx]

Fazit:
- Droppen von tcp/udp-Anfragen kann (!) Fingerprinting erschweren, solange kein einziger Dienst erreichbar ist. An der Systemsicherheit an sich ändert sich allerdings nichts.

wäre es in dem fall nich sogar unmöglich?

- Blindes Blocken von ICMP-Nachrichten kann extreme Probleme verursachen, über das gezielte Blocken einzelner ICMP-Typen kann man sich streiten.

kann (!), muss aber nich

- Ein korrekt konfiguriertes und aktuelles System hat das Droppen von Verbindungsanfragen im Grunde nicht nötig. Wo kein Dienst erreichbar ist, kann auch keiner "exploitet" werden.

naja, die logik erschliesst sich mir nicht. korrekt konfiguriert und aktuell = kein dienst?

die idee is, so wenig infos über das system wie möglich nach draussen zu lassen bzw schwer zugänglich zu machen. das sich um so ziehmlich jede barriere ein weg drum herum finden lässt, is ja bekannt, aber deshalb drauf zu verzichten ...

 

[MountWalker]

die idee is, so wenig infos über das system wie möglich nach draussen zu lassen bzw schwer zugänglich zu machen. das sich um so ziehmlich jede barriere ein weg drum herum finden lässt, is ja bekannt, aber deshalb drauf zu verzichten ...

Es ist und bleibt eine Placebo-Barriere...

 

[arkelanfall]

wäre es in dem fall nich sogar unmöglich?

Nein. Der Hacker kann sein "Opfer" auch dazu bringen, eine Verbindung mit ihm (oder einem von ihm kontrollierten Rechner) zu initiieren (Besuch einer Webseite,...). Und schon hat er wieder alle Informationen, die du so krampfhaft verheimlichen wolltest.
IP-Daten sind so geheim wie Postkarten.

naja, die logik erschliesst sich mir nicht. korrekt konfiguriert und aktuell = kein dienst?

Klar. Nicht alles im Internet ist ein Server. Clients müssen keine Dienste anbieten. Server sollen erreichbar sein. Warum also sollte der Admin die Erreichbarkeit erschweren?

die idee is, so wenig infos über das system wie möglich nach draussen zu lassen bzw schwer zugänglich zu machen.

Das funktioniert aber nicht. Das ist "security by obscurity". Dass das nicht funktioniert, wurde schon duzende Male demonstriert.
Das fängt beim Umbenennen von "root" an, und hört bei nicht offengelegten Verschlüsselungsalgorithmen (Stichwort "Magenta" von der Telekom) auf.
Der Trick ist, dass ein System sicher sein muss, obwohl alle Informationen darüber verfügbar sind.

 

[jdkbx]

Der Trick ist, dass ein System sicher sein muss, obwohl alle Informationen darüber verfügbar sind.

klar, keine frage. wenn das möglich wär ...
nur weil alle bekannten lücken gestopft sind, heisst es ja nicht, das es keine gibt.
und jede info die nich nach draussen kommt, lässt sich nicht auswerten.

 

[arkelanfall]

nur weil alle bekannten lücken gestopft sind, heisst es ja nicht, das es keine gibt.

Korrekt. Es gab übrigens auch schon Lücken in Netfilter. D.h. die Implementierung des "stealth"-Modus hat hier neue Sicherheitslücken aufgerissen.
Deshalb ist es umso wichtiger systematisch vorzugehen und sein Sicherheitssystem möglichst einfach zu halten, und nicht zu versuchen einzelne eng begrenzte Szenarien Punkt für Punkt auszuschalten.

und jede info die nich nach draussen kommt, lässt sich nicht auswerten.

Aber krampfhaft Informationen zu verheimlichen, die sowieso früher oder später nach außen dringen, und die im Sicherheitskonzept keine Rolle spielen dürfen (eben weil man davon ausgehen muss, dass der Angreifer die Informationen besitzt) ist keine brauchbare Abwehrmaßnahme.
Wenn reguläre Kommunikation unter einer Maßnahme leidet, muss der Sicherheitsgewinn schon sehr hoch sein, um diese Maßnahme zu rechtfertigen. Und das ist hier schlicht nicht der Fall.
Ein fehlender Eintrag im Telefonbuch schützt dich auch nicht vor Einbrechern. Ein Schild "Dies ist keine Tür", das am Türknopf hängt, auch nicht. Ein vernünftiges Schloss dagegen schon.

 

[*cerox*]

Eine Sache verstehe ich an deinen ip-tables nicht.

Zuerst setzt du die OUTPUT-Policy auf DROP, dann

iptables -A OUTPUT -j ACCEPT

erlaubst du alle ausgehenden Verbindungen.

Was soll das denn ?

 

[arkelanfall]

Im Grunde hast du völlig Recht. Die OUTPUT-Regel für lo ist genauso überflüssig. Ebenso das explizite Erlauben von ausgehenden ICMP-Nachrichten.
Nenn es Gewohnheit von Systemen, auf denen nicht alles Ausgehende erlaubt wird. Ich setze die Policies generell erstmal auf DROP, um dann aktiv das zu erlauben, was ich erlaubt haben möchte.
Wenn ich jegliche Kommunikation erlauben will, dann muss ich das bewusst als Regel formulieren. Es ist für mich persönlich im Regelwerk übersichtlicher und erleichtert mir meiner Meinung nach das Editieren der Regeln im Bedarfsfall.
Das ist allerdings ausschließlich eine persönliche Vorliebe und hat keinen tieferen Sinn. Ein
iptables -P OUTPUT ACCEPT
hätte genau denselben Effekt.

Der durch die zusätzlichen Regeln entstehende geringe Performanceverlust spielt in meinem Fall keine Rolle.

 

[jdkbx]

Deshalb ist es umso wichtiger systematisch vorzugehen und sein Sicherheitssystem möglichst einfach zu halten, und nicht zu versuchen einzelne eng begrenzte Szenarien Punkt für Punkt auszuschalten.
Aber krampfhaft Informationen zu verheimlichen, die sowieso früher oder später nach außen dringen, und die im Sicherheitskonzept keine Rolle spielen dürfen (eben weil man davon ausgehen muss, dass der Angreifer die Informationen besitzt) ist keine brauchbare Abwehrmaßnahme.

alles was ich mache ist ICMP nicht explizit zu erlauben. was fürn krampf.

Wenn reguläre Kommunikation unter einer Maßnahme leidet, muss der Sicherheitsgewinn schon sehr hoch sein, um diese Maßnahme zu rechtfertigen. Und das ist hier schlicht nicht der Fall.

vielleicht merk ichs einfach nicht oder bin betriebsblind, aber es geht alles wunderbar.

dass es in die richtung security by obscurity geht, geb ich ja zu, aber es is ja auch nich so, als ob daran die systemsicherheit hängen würde.

 

[arkelanfall]

vielleicht merk ichs einfach nicht oder bin betriebsblind, aber es geht alles wunderbar.

Klar. tcp/ip wurde entworfen um auch nach einer Atombombe noch zu funktionieren. Es ist prinzipbedingt extrem fehlertolerant.
Aber nochmal: Es geht mir nicht darum, dass irgendwelche ICMP-Typen blockiert werden, sondern dass oftmals auch völlig harmlose Typen, die nichtmal für dein "Drop"-Verhalten nötig sind, blockiert werden (fragmentation needed, parameter problem, eingehendes destination unreachable,...). Diese Typen zu blockieren bringt eben nichteinmal "obscurity", sondern bestenfalls "kein sichtbares Fehlverhalten".

Dass das Blockieren von ausgehenden destination unreachable oder echo-reply-Paketen nicht sofort die gesamte Internetkommunikation lahmlegt, habe ich nie behauptet, und es tut mir leid, wenn es sich so angehört hat.

dass es in die richtung security by obscurity geht, geb ich ja zu, aber es is ja auch nich so, als ob daran die systemsicherheit hängen würde.

Es ist aber bei vielen Leuten so und wird oft als Wundermittel um "unsichtbar" (und damit quasi unangreifbar) zu werden angepriesen. Die elektronische Tarnkappe sozusagen.
Deshalb reagiere ich in der Zwischenzeit bei sowas recht verschnupft, weil es extrem leichtsinnig wäre diese "Sicherheits"maßnahme überzubewerten.
Nochmals sorry, falls ich dir auf deinen Fuß getreten sein sollte.