Archiv verlassen und diese Seite im Standarddesign anzeigen : Statische IP = große Sicherheitsgefahr?
-Sensemann-
18.07.04, 14:09
Moin moin,
ich hab mir überlegt ob ich mir nicht mal ne Standleitung kaufe. bzw es Gibt keine 24h Trennung und wenn ich online gehe habe ich immer dieselbe IP.
Ist das nun gefährlicher? weil die Leute halt wissen der und der ist immer unter der IP zu erreichen?
Freekazonid
18.07.04, 14:13
dann muessten ja auch alle leute die bei dyndns sind unsicher sein
genauso wie alle server (spiele, web, ftp etc) haben auch alle statische
also ich wuerd sagen das ist total latte von der sicherheit. wenn du hinter einen gnu/linux nat stehst der gut geconfed bist, bist du schon recht sicher. und die hacker, die es schaffen deinen nat zu cracken, denen ist es auch latte ob du dyn ip oder statische hast
Prinzipiell bestehen die gleichen Risiken (ungepatchte oder falsch konfigurierte Dienste, trojanische Pferde, viren,...), egal ob du eine statische oder eine dynamische IP-Adresse hast.
Wenn du über die IP irgendwas der Öffentlichkeit anbieten willst (also z. B. einen Webserver), wird man natürlich leichter auf dich aufmerksam, als wenn du ohne irgendwelche Dienste anzubieten nur im Web rumsurfst und E-Mails verschickst.
Das Problem des "auf sich aufmerksam machen", ergibt sich natürlich mit dyndns+dynamische IP-Adresse genauso.
Da man sich allerdings so oder so nie darauf verlassen sollte, schon nicht "entdeckt" zu werden, macht es also keinen wirklichen Unterschied, ob man eine dynamische oder eine statische IP-Adresse hat.
steve-bracket
18.07.04, 17:37
Natürlich ist man bei einer gleichbleibenden Adresse angreifbarer, keine Frage.
Aber sobald man nach aussen hin erreichbar sein will, ist das ein Risiko das man wohl eingehen muss.
Grundsätzlich ist bei Festverbindungen (oder einem DSL Dialup mit fixem Netz) eine vernünftige Firewall PFLICHT. (ob du nun IPTables, eine Pix oder ne Checkpoint verwendest, ist im semiprofessionellen Bereich eher nebensächlich)
Im Worst Case kann es natürlich sein, dass dein Access durch einen versuchten Angriff dichtgemacht wird.
Grüsse
Steve
Eine Frage der Statistik?
Ist es mit oder ohne Führerschein wahrscheinlicher, von einem Auto überfahren zu werden?
Und was bitte bedeutet das NAT cracken?
Selbstverständlicher ist es um einiges "leichter", ein System mit gleichbleibender IP-Adresse anzugreifen - ABER, und deswegen steht das leichter auch in Anführungszeichen, das liegt eigentlich nur daran, daß man subjektiv mehr Zeit hat.
Entscheidend sind Deine Maßnahmen dagegen.
cu/2 iae
Und was bitte bedeutet das NAT cracken?
Habe ich mich auch gefragt... :-). Das Argument mit der längeren Onlinephase stimmt natürlich, aber inzwischen bist Du mit einer dynamischen (t-online) IP warscheinlich gefährdeter als mit einer festen IP. Nicht wenig Scriptkiddies/Cracker scanen ununterbrochen den Adressraum der Telekom auf der Suche nach Opfern.
steve-bracket
18.07.04, 18:10
Habe ich mich auch gefragt... :-). Das Argument mit der längeren Onlinephase stimmt natürlich, aber inzwischen bist Du mit einer dynamischen (t-online) IP warscheinlich gefährdeter als mit einer festen IP. Nicht wenig Scriptkiddies/Cracker scanen ununterbrochen den Adressraum der Telekom auf der Suche nach Opfern.
Naja, so ist das nicht richtig.
Generell stellt sich der Cracker mal die Frage an welchen Adressen man am schnellsten bzw am sichersten Erfolg erzielen kann.
Und das sind definitiv NICHT die dynamischen die alle paar Stunden wechseln.
Jedes Telekom-Unternehmen hat mehrere Adress-Bereiche zugewiesen.
Davon werden bestimmte Bereiche nur für fix geroutete Netze verwendet und bestimmte Adress-Bereiche für dynamische Dialup Zugänge.
Diese Einteilung lässt sich rausfinden, und anhand dieser Info werden in erster Linie die gleichbleibenden Adressen durchgescannt bzw. "bearbeitet".
Was bringt es einem Cracker (auch wenn es nur ein Script-Kiddy ist) sich über eine Anschluss herzumachen der in 2 Stunden eh wieder ne andere Addy hat und dadurch nicht mehr zu finden ist.
Viele Grüsse
Naja, so ist das nicht richtig.
Generell stellt sich der Cracker mal die Frage an welchen Adressen man am schnellsten bzw am sichersten Erfolg erzielen kann.
Und das sind definitiv NICHT die dynamischen die alle paar Stunden wechseln.
Das glaube ich nicht - Tim! :-) Das leichteste Opfer ist ja wohl $DAUUSER, welcher weder sonderlich viel Ahnung von Computern hat noch er sich dafür interessiert. Ein solcher Gelegenheitssurfer dürfte des Crackers liebstes Clientel sein. Ich gehe davon aus, dass die Mehrheit der Standleitungskunden sich besser gegen Angriffe absichert, als eben jene $DAUUSER.
Jedes Telekom-Unternehmen hat mehrere Adress-Bereiche zugewiesen.
Davon werden bestimmte Bereiche nur für fix geroutete Netze verwendet und bestimmte Adress-Bereiche für dynamische Dialup Zugänge.
Korrekt. Aber stand das zur Debatte? Die Adressräume, welche für die dynamische Einwahl verwendet werden. Kann man sich schön nach art der Anbindung aufschlüsseln lassen.
Diese Einteilung lässt sich rausfinden, und anhand dieser Info werden in erster Linie die gleichbleibenden Adressen durchgescannt bzw. "bearbeitet".
Korrekt (siehe oben). Beim zweiten Punkt wiederspreche ich Dir allerdings klar (siehe wieder oben).
Was bringt es einem Cracker (auch wenn es nur ein Script-Kiddy ist) sich über eine Anschluss herzumachen der in 2 Stunden eh wieder ne andere Addy hat und dadurch nicht mehr zu finden ist.
Sobald ein Angriff erfolgreich war spielt es keine Rolle, wie oft man sich neu einwählt. Jeder x-beliebige Trojaner verkündet fröhlich seinen Socket mit jeder Einwahl an den (oder mehrere) "Kunden". Das funktioniert per integrierter SMTP Engine genauso wie per ICQ oder IRC.
viele Grüsse
Natürlich ist man bei einer gleichbleibenden Adresse angreifbarer, keine Frage.
Aber sobald man nach aussen hin erreichbar sein will, ist das ein Risiko das man wohl eingehen muss.
Grundsätzlich ist bei Festverbindungen (oder einem DSL Dialup mit fixem Netz) eine vernünftige Firewall PFLICHT. (ob du nun IPTables, eine Pix oder ne Checkpoint verwendest, ist im semiprofessionellen Bereich eher nebensächlich)
Im Worst Case kann es natürlich sein, dass dein Access durch einen versuchten Angriff dichtgemacht wird.
Grüsse
Steve
Nur so aus neugierde, was wird im professionellen Bereich eingesetzt?
Nur so aus neugierde, was wird im professionellen Bereich eingesetzt?
Im Idealfall eine Kombination aus IDS IPS und dedizierter Firewall. Ganz ausgefuchste Systemadministratoren setzen auch eventuell noch ein Honeynet zusätzlich auf.
steve-bracket
18.07.04, 18:34
Kommt auf den jeweiligen Einsatz an.
Bei größeren Netzen/Firmen werden nach meiner Erfahrung in erster Linie Produkte wie Cisco-Pix, Checkpoint oder ev. auch Sonicwalls verwendet.
Aber Erfahrungswerte sind ja individuell verschieden, dh. es gibt bestimmt auch Firmen die zB. eine Linuxdistri in Verbindung mit IPTables als Firewall anbieten.
Viele Grüsse
Grundsätzlich ist bei Festverbindungen (oder einem DSL Dialup mit fixem Netz) eine vernünftige Firewall PFLICHT. (ob du nun IPTables, eine Pix oder ne Checkpoint verwendest, ist im semiprofessionellen Bereich eher nebensächlich)
Steve
Firewall (=Sicherheitskonzept): ja. Paketfilter: nicht unbedingt.
Wenn du einen einzelnen Rechner an den Anschluss dranhängst brauchst du nicht unbedingt einen Paketfilter. Wozu auch? Dienste, die man nicht braucht, bietet man halt nicht an. Dienste die man braucht, müsste man bei iptables so oder so auch erlauben.
Wenn hinter dem Anschluss allerdings ein Netzt mit mehreren Rechnern steht, sieht das natürlich anders aus.
steve-bracket
18.07.04, 18:47
Das glaube ich nicht - Tim! :-) Das leichteste Opfer ist ja wohl $DAUUSER, welcher weder sonderlich viel Ahnung von Computern hat noch er sich dafür interessiert. Ein solcher Gelegenheitssurfer dürfte des Crackers liebstes Clientel sein. Ich gehe davon aus, dass die Mehrheit der Standleitungskunden sich besser gegen Angriffe absichert, als eben jene $DAUUSER.
Korrekt. Aber stand das zur Debatte? Die Adressräume, welche für die dynamische Einwahl verwendet werden. Kann man sich schön nach art der Anbindung aufschlüsseln lassen.
Korrekt (siehe oben). Beim zweiten Punkt wiederspreche ich Dir allerdings klar (siehe wieder oben).
Sobald ein Angriff erfolgreich war spielt es keine Rolle, wie oft man sich neu einwählt. Jeder x-beliebige Trojaner verkündet fröhlich seinen Socket mit jeder Einwahl an den (oder mehrere) "Kunden". Das funktioniert per integrierter SMTP Engine genauso wie per ICQ oder IRC.
viele Grüsse
Naja, dass ist wohl Ansichtssache und jeder wird sich wohl seine eigenen Gedanken darüber bilden.
Deine Ansicht eines $DAUUSER (schöne bezeichnung) ist schon etwas "hart", und ich denke, dass der beschriebene DAU nicht so oft anzutreffen ist wie du denkst.
Aber gut, auch wenn es so ist, generell kann man davon ausgehen, dass hinter einem fix geroutetem Netz auch Geräte stehen, die permanent laufen und dadurch permanent "angreifbar sind".
Dadurch ergibt sich der "längere Zeitraum" den man zur Verfügung hat um zu "arbeiten", und im Falle eines Erfolges hat man auch länger Zeit um "Aktionen" auszuführen. Bei nem Dialup wird wohl irgendwann die Verbindung bzw. der dahinterliegende Rechner abgestellt.
Korrekt. Aber stand das zur Debatte? Die Adressräume, welche für die dynamische Einwahl verwendet werden. Kann man sich schön nach art der Anbindung aufschlüsseln lassen.
NATÜRLICH STAND ZUR DEBATTE ob dynamische oder gleichbleibende Adressen verwendet werden.
Genau darauf bezieht sich meine Aussage.
Grüsse
Firewall (=Sicherheitskonzept): ja. Paketfilter: nicht unbedingt.
Wenn du einen einzelnen Rechner an den Anschluss dranhängst brauchst du nicht unbedingt einen Paketfilter. Wozu auch? Dienste, die man nicht braucht, bietet man halt nicht an. Dienste die man braucht, müsste man bei iptables so oder so auch erlauben.
Wenn hinter dem Anschluss allerdings ein Netzt mit mehreren Rechnern steht, sieht das natürlich anders aus.
<edit>
Dienste die man braucht, müsste man bei iptables so oder so auch erlauben.
Mitnichten, nur wenn man die Policy auf DENY/DROP setzt
</edit>
Und damit sind wir wieder bei der vielbeliebten blauäugigkeit ;)
Wenn ich Dienste bereitstelle, sind diese angreifbar. Wenn ich also einen Rechner ins Netz hänge, der Web anbietet und ich keine (zB iptables) Sicherungsmaßnahmen für das System ergreife, "da ich ja eh nur http/s anbiete", reicht ein php-Script, um das ganze System zu kompromittieren. Eine Shell ist schnell installiert und mit einem Port > 1024 offen und schon ist er drin. Mit der einfachsten Methode, per iptables grundsätzlich alles zu verbieten und http separat zu erlauben, ist kein Zugriff möglich. Hat man ferner noch Tripwire und entsprechende Scripte und daemons, ist eine Veränderung der iptables kaum noch möglich... etc.
Detailierte Beispiele sind an dieser Stelle natürlich unangebracht.
cu/2 iae
steve-bracket
18.07.04, 18:51
Und damit sind wir wieder bei der vielbeliebten blauäugigkeit ;)
Jaja. das is vielleicht ne verzwickte Sache.
:ugly:
Steve
Naja, dass ist wohl Ansichtssache und jeder wird sich wohl seine eigenen Gedanken darüber bilden.
Ja und das ist auch gut so.
Deine Ansicht eines $DAUUSER (schöne bezeichnung) ist schon etwas "hart", und ich denke, dass der beschriebene DAU nicht so oft anzutreffen ist wie du denkst.
Also ich befürchte, dass meine Sichtweise eines solchen Users noch viel zu blauäugig ist. Tatsächlich sind User beschriebener Spezifikation warscheinlich noch um einiges häufiger anzutreffen, also du oder ich befürchten wollen (ich sage dazu nur, dass ich eine Zeit lang als Systemadministrator in einer Windows-IT Firma gearbeitet habe - was mich leider völlig desillusionierte). Allein wenn man die Statistiken der Spamaufkommen ansieht, fällt auf, dass Spam inzwischen zu 99% von eben diesen Dialuprechnern verschickt werden. Dies kann auf einen Befall mit einem Trojaner zurückgeführt werden, welcher als anonymer Spamrelay fungiert.
Aber gut, auch wenn es so ist, generell kann man davon ausgehen, dass hinter einem fix geroutetem Netz auch Geräte stehen, die permanent laufen und dadurch permanent "angreifbar sind".
Dadurch ergibt sich der "längere Zeitraum" den man zur Verfügung hat um zu "arbeiten", und im Falle eines Erfolges hat man auch länger Zeit um "Aktionen" auszuführen. Bei nem Dialup wird wohl irgendwann die Verbindung bzw. der dahinterliegende Rechner abgestellt.
Maaan, wie lang brauchst Du denn um ein Exploit zu auszuführen?! :-)
ciao
Allein wenn man die Statistiken der Spamaufkommen ansieht, fällt auf, dass Spam inzwischen zu 99% von eben diesen Dialuprechnern verschickt werden. Dies kann auf einen Befall mit einem Trojaner zurückgeführt werden, welcher als anonymer Spamrelay fungiert.
Warum nehmen die Mailserver auch eMails von Dialups an? Die wenigen die es benötigen, wenn überhaupt, kann man in eine Whitelist einpflegen.
Durch unseren Mailserver haben wir Spammails in den "Postkörben" auf durchschnittlich 1 Spammail pro Domaine pro Monat heruntergedrückt. Da ist Spamassin kein Thema mehr ...
cu/2 iae
Das ist halt wieder eine *Glaubensfrage*. Problemlösung durch Einschränkung ist halt nicht wirklich befriedigend. Eine zeitgemäße Weiterentwicklung ist da schon eher sinnvoll. Naja, man wird sehen....
steve-bracket
19.07.04, 10:03
Ja und das ist auch gut so.
Also ich befürchte, dass meine Sichtweise eines solchen Users noch viel zu blauäugig ist. Tatsächlich sind User beschriebener Spezifikation warscheinlich noch um einiges häufiger anzutreffen, also du oder ich befürchten wollen (ich sage dazu nur, dass ich eine Zeit lang als Systemadministrator in einer Windows-IT Firma gearbeitet habe - was mich leider völlig desillusionierte). Allein wenn man die Statistiken der Spamaufkommen ansieht, fällt auf, dass Spam inzwischen zu 99% von eben diesen Dialuprechnern verschickt werden. Dies kann auf einen Befall mit einem Trojaner zurückgeführt werden, welcher als anonymer Spamrelay fungiert.
Maaan, wie lang brauchst Du denn um ein Exploit zu auszuführen?! :-)
ciao
desillusionierte, hah, das kenne ich, glaub mir.
:ugly:
Jedem seine Meinung und jedem das letzte Wort.
Grüsse
Steve
<edit>
Wenn ich Dienste bereitstelle, sind diese angreifbar. Wenn ich also einen Rechner ins Netz hänge, der Web anbietet und ich keine (zB iptables) Sicherungsmaßnahmen für das System ergreife, "da ich ja eh nur http/s anbiete", reicht ein php-Script, um das ganze System zu kompromittieren. Eine Shell ist schnell installiert
Wenn man eine Shell installieren kann, kann man auch "iptables --flush; iptables -P OUTPUT ACCEPT; iptables -P INPUT ACCEPT" ausführen.
und mit einem Port > 1024 offen und schon ist er drin. Mit der einfachsten Methode, per iptables grundsätzlich alles zu verbieten und http separat zu erlauben, ist kein Zugriff möglich. Hat man ferner noch Tripwire und entsprechende Scripte und daemons, ist eine Veränderung der iptables kaum noch möglich... etc.
Und was hindert den Angreifer dann, tripwire oder die "Scripte und daemons" so zu verändern, dass sie bestimmte Manipulationen nicht anzeigen?
Iptables kann (eventuell) je nach Unfähigkeitsgrad des Angreifers helfen, sollte aber (wenn es auf dem zu schützenden Rechner selbst läuft) nicht als verlässlicher Schutz angesehen werden. Genausowenig wie Prüfungen nach veränderten Dateien oder Rootkits im laufenden Betrieb.
Iptables sollte in keinem Fall als Schutz gegen schlecht programmierte php-Scripts verwendet werden. Dafür ist es nämlich schlicht und ergreifend weder gedacht, noch brauchbar.
Fazit: Ein Paketfilter, der auf dem zu schützenden System selbst läuft bringt generell kaum ein mehr an Sicherheit, da er, sobald das System kompromittiert worden ist, selbst leicht ausgehebelt werden kann.
Gegen Amok laufende Scripte hilft der Einsatz des Rechtesystems sowie chroot-Umgebungen. Und natürlich eine Schulung desjenigen, der die Scripte erstellt.
Wenn man eine Shell installieren kann, kann man auch "iptables --flush; iptables -P OUTPUT ACCEPT; iptables -P INPUT ACCEPT" ausführen.
Wer den Paketfilter auf dem selben Rechner laufen läßt, auf dem auch öffentliche Dienste angeboten werden, ist selber schuld, wenn man ihm seine "schönen" Filterregeln ändert.
MfG elwood
Wer den Paketfilter auf dem selben Rechner laufen läßt, auf dem auch öffentliche Dienste angeboten werden, ist selber schuld, wenn man ihm seine "schönen" Filterregeln ändert.
Nichts anderes habe ich behauptet. Auf einem Rechner, der direkt, ohne irgendwas dazischen, mit dem Internet verbunden ist, wird häufig kein iptables benötigt.
Sobald man ein Netz hat (also I-Net -- Firewall -- [wasauchimmer]) sieht das natürlich anders aus.
Das ist halt wieder eine *Glaubensfrage*. Problemlösung durch Einschränkung ist halt nicht wirklich befriedigend. Eine zeitgemäße Weiterentwicklung ist da schon eher sinnvoll. Naja, man wird sehen....
Ich kann es auch anders ausdrücken:
99% der DialUps senden nicht RFC-Konform.
Und die Ablehnungen aufgrund der Software interessiert mich auch nicht, warum nehmen die Leute auch diese Software?
Und durch bestehen auf Einhaltung von Standards wird Druck aufgebaut.
Das ist keine Glaubensfrage.
cu/2 iae
Wenn man eine Shell installieren kann, kann man auch "iptables --flush; iptables -P OUTPUT ACCEPT; iptables -P INPUT ACCEPT" ausführen.
Dafür brauch er ziemlich viele Rechte und die hat kein wwwuser & co.
Und was hindert den Angreifer dann, tripwire oder die "Scripte und daemons" so zu verändern, dass sie bestimmte Manipulationen nicht anzeigen?
Nichts, nur meine Ausführungen oben richtig umgesetzt sorgen im Zweifelsfall dafür, daß der "Angreifer" eher bemerkt wird, als er diese Scripte und Daemons findet.
Iptables kann (eventuell) je nach Unfähigkeitsgrad des Angreifers helfen, sollte aber (wenn es auf dem zu schützenden Rechner selbst läuft) nicht als verlässlicher Schutz angesehen werden. Genausowenig wie Prüfungen nach veränderten Dateien oder Rootkits im laufenden Betrieb.
Danke, aber Du wirst hier mehrere Sachen in einen Topf, wo sie nicht hingehören.
Woher kommt diese Theorie? Weder preferiere ich es als verlässlichen Schutz, noch als einziges Mittel.
Und wie ist das mit der Integritätsprüfung. Die Killerargumente gegen einen Einsatz im laufenden Betrieb hätte ich zumindest dargelegt, optional erläutert.
Iptables sollte in keinem Fall als Schutz gegen schlecht programmierte php-Scripts verwendet werden. Dafür ist es nämlich schlicht und ergreifend weder gedacht, noch brauchbar.
Liegt es an meiner Argumentation? Parkst Du mit einer Kollisionsgeschwindigkeit von 35 Km/h ein, nur weil Du Airbag hast?
Fazit: Ein Paketfilter, der auf dem zu schützenden System selbst läuft bringt generell kaum ein mehr an Sicherheit, da er, sobald das System kompromittiert worden ist, selbst leicht ausgehebelt werden kann.
Eine mutige Aussage, die in sich selbst widersprüchlich ist. Ich zumindest rede von einem Teil der Möglichkeit zur Verhinderung der Komprottierung. Die hier gebrachten Argumente setzen sich aber ganz genau nicht damit auseinander, sondern sollen die genannten Möglichkeiten offensichtlich nur diskreditieren, was ich nicht als konstruktiv, produktiv, oder gar progressiv empfinde ...
Gegen Amok laufende Scripte hilft der Einsatz des Rechtesystems sowie chroot-Umgebungen. Und natürlich eine Schulung desjenigen, der die Scripte erstellt.
Darum verdient man im Bereich Sicherheit grundsätzlich viel Geld, weil es mehr unbedarfte, als kundige Menschen gibt ...
cu/2 iae
Nichts anderes habe ich behauptet. Auf einem Rechner, der direkt, ohne irgendwas dazischen, mit dem Internet verbunden ist, wird häufig kein iptables benötigt.
Sobald man ein Netz hat (also I-Net -- Firewall -- [wasauchimmer]) sieht das natürlich anders aus.
Sorry, aber eindeutig das Thema verfehlt.
cu/2 iae
Sorry, aber eindeutig das Thema verfehlt.
Ohne darauf rumreiten zu wollen: Nein.
Überflieg einfach nochmal kurz den ganzen Thread. Bei Unklarheiten bitte per PM nachfragen, da diese ja/nein-Debatte jetzt wirklich am Thema vorbei geht.
Dafür brauch er ziemlich viele Rechte und die hat kein wwwuser & co.
ein wwwuser sollte aber auch keine shell installieren dürfen, geschweigedenn die angelegte shell dann auch starten können.
Natürlich [I]kann ein Angreifer durch solche "Scripte und Daemons" schneller gefunden werden. Aber er kann eben auch unerkannt bleiben.
Und genau das muss man sich meiner Meinung nach immer im Hinterkopf behalten: Vielleicht können viele Angriffe aufgedeckt werden. Aber eben nicht alle.
Jetzt dazu, was gegen einen Einsatz von Integritätsprüfung im laufenden Betrieb spricht: Solange man die Ressourcen dazu aufbringen kann: Ersmtal nichts.
Allerdings haben im laufenden Betrieb eingesetzte Integritätsprüfungen das prinzipielle Problem, dass man nicht sicher sein kann, ob die von ihnen gelieferten Ergebnisse stimmen.
Sagt tripwire jetzt, dass alles o.k. ist, weil alles o.k. ist, oder nur, weil es ausgetauscht worden ist, der Kernel kompromittiert worden ist, und bestimmte Dateien versteckt (es gab da sogar mal ein Kernelmodul, das genau das gemacht hat. Wenn ich mal Zeit hab such ichs raus),..?
Die Frage kann man nur sicher beantworten, wenn man die Daten regelmäßig von einem sauberen System aus (->Bootdiskette/CD) prüft. Ob das nötig ist, oder man das Risiko einer längers unbemerkten Kompromittierung eingehen kann, hängt natürlich vor Allem vom Schutzbedarf der Daten ab. Die private Webseite braucht diese Sicherheit vielleicht nicht. Die digital archivierten Akten bei einem Anwalt schon eher.
Liegt es an meiner Argumentation? Parkst Du mit einer Kollisionsgeschwindigkeit von 35 Km/h ein, nur weil Du Airbag hast?
Nein. Aber ich parke auch nicht rückwärts blind ein, selbst wenn das Auto normalerweise bei einem bestimmten Abstand zur Wand mit piepsen anfängt.
Eine mutige Aussage, die in sich selbst widersprüchlich ist. Ich zumindest rede von einem Teil der Möglichkeit zur Verhinderung der Komprottierung.
Wie willst du mit einem IDS eine Kompromittierung verhindern? Wenn das IDS irgendwas sagt, ist das System bereits Kompromittiert, muss vom Netz genommen und erstmal genau untersucht werden. Das selbe gilt, wenn iptables "bösartigen" ausgehenden Datenverkehr blockt.
Was du vermutlich meinst, ist die möglichst schnelle Entdeckung einer stattgefundenen Kompromittierung. Aber wie schon oben erwähnt: Wenn der Angreifer ein Kernelmodul einbinden kann, das seine Veränderungen versteckt, dann hebelt er damit alle "Scripte und Daemons" gleichzeitig aus.
Ich möchte die von dir genannten Möglichkeiten mit Sicherheit nicht "nur diskreditieren". Ich möchte nur darlegen, dass gewisse Restrisiken bei den angesprochenen Möglichkeiten bestehen bleiben. Diese muss man überdenken und je nachdem sein Konzept anpassen (z. B. Rechner 1x alle 2 Wochen vom Netz nehmen und von nem sauberen Medium aus die Integritätstests durchführen), oder halt mit dem Risiko leben ("So paranoid bin ich dann auch wieder nicht...").
Stimm, alles Blödsinn was ich sage,
- ein einzelnes System braucht nicht abgesichert werden
- IDS erkennt nur erfolgte Kompromittierungen
- Packetfilter ergeben keinen Sinn
- unter Linux gibt es keine Viren
- bindshell ist nur Illusion
- und jede Sicherung wird von jedem sofort ausgehebelt.
In welcher Welt lebt ihr denn bitte? Genau das hat schon einige Server davor bewahrt, übernommen und / oder mißbraucht zu werden.
Aber egal, is eh Blädsinn was ich erzähle ...
Stimm, alles Blödsinn was ich sage,
- ein einzelnes System braucht nicht abgesichert werden
Behauptet doch niemand. Aber die Art, wie man Ein Netzwerk absichert und die, wie man ein einzelnes System absichert, ist leicht anders. Oder bestreitest du das?
- IDS erkennt nur erfolgte Kompromittierungen
Korrekt. Intrusion Detection System. Was an Einbruchserkennung verstehst du nicht? Oder muss dir der Unterschied zwischen erkennen und verhindern erklärt werden? Nicht wirklich, oder?
- Packetfilter ergeben keinen Sinn
Sie sind keine Patentlösung gegen alles.
- unter Linux gibt es keine Viren
Äh?
- bindshell ist nur Illusion
- und jede Sicherung wird von jedem sofort ausgehebelt.
Aber man wird doch wohl noch die Restrisiken, die bei bestimmten Verfahren bestehen bleiben, nennen dürfen, oder?
Mbo, ohne dich jetzt angreifen zu wollen, aber was genau wolltest du mit deinem letzten Post bezwecken? Oder gehst du jetzt halt zu Zynismus über, da dir die Argumente ausgehen, du aber nicht zugeben kannst, dass meine Sichtweise nicht völlig falsch ist? Oder willst du meinen Artikel "offensichtlich nur diskreditieren, was ich nicht als konstruktiv, produktiv, oder gar progressiv empfinde"?
Wie dem auch sei, es macht an dieser Stelle absolut keinen Sinn mehr, mit dir weiter zu diskutieren. Bring Argumente, und sag mir, warum die von mir genannten Risiken nicht bestehn sollen.
Ansonsten ist hier für mich EOD. Ich denke jeder kann sich an dieser Stelle selbst ein Bild der Diskussionslage machen. Dein kindisches "Ich-verstehe-absichtlich-nicht-was-du-schreibst-und-bock-ich-jetzt-rum" -Gehabe ist meiner Meinung nach keine Grundlage für eine weitere sachliche Debatte.
Dein kindisches "Ich-verstehe-absichtlich-nicht-was-du-schreibst-und-bock-ich-jetzt-rum" -Gehabe ist meiner Meinung nach keine Grundlage für eine weitere sachliche Debatte.
Leicht daneben, aber eh egal.
Als erstes: Ihr habt von IDS geschrieben. Das was ich an Daemons- und Scripten am laufen habe, würde ich nach Wortlautdefinition nicht IDS nennen. sondern System- und Diensteintegrationsprüfung.
Grundsätzlich: Es ist Blauäugig zu behaupten, ein einzelner Server, zB Webserver , braucht keine Paketfilter oder andere "Filter".
Jeder Webserver, selbst wenn er nur http über Port 80 anbietet, ist ein potentielles Opfer, welches es dem Angreifer es in jeder Hinsicht sehr angenehm erleichtert:
Bsp: Irgend ein PHP-Script (übrigens, ich schätze mal grob 70% aller PHP-Seiten von Privatpersonen betrifft es) bietet das cmd oder den Download von fremden Seitenmaterial an. Kann jeder auf seinem eigenen WebServer ja mal prüfen:
- Documentroot in /var/www/html
- index.php mit include und Zielübergabe in Variablen
- Aufruf: http://www.webseite.tld/index.php?../../../etc/passwd
Über dieses lade ich mir irgendeine Shell (siehe Bugtraq und Google); üblicher Ablauf:
- wechsel in /tmp
- download von shell
- chmod 755 /tmp/shell
- starten von shell mit Connect über 1500 (zb)
Dann noch durch dummen Zufall ein für einen Exploit anfälliger Rechner, schon haben wir root-Rechte.
Das alles bei Kunden oft genug erlebt. Inklusive RST (siehe Google).
Ein Paketfilter hat hier enorme Vorteile:
Solange es kein Remoteexploit ist, wie vor knapp zwei Jahren bei OpenSSH, der gleiche ein Command oder eine Shell mit root-Rechten öffnet, kann es nur eine Shell sein, die mit den Benutzerrechten des betroffenen Dienstes läuft, darum machen zB Bindshell & Co immer Ports über 1024 auf, da sie darunter priviligierte Rechte bräuchten. Ein Paketfilter würde zwar die Shell und den Port nicht verhindern, aber zumindest den Connect von außen.
Für den Fall einer Shell mit root-Rechten, prüft zB ein Script / Daemon alle 5 Minuten die Integrität der Referenzausgabe von iptables -L zB mittels Tripwire, Tripwire prüft seine eigene Integrität, und danach im Vergleich die aktuelle Ausgabe von iptables -L. Sollten irgendwo Unterschiede auftauchen, gibt es eine Benachrichtigung. Nächster Schritt wäre zB der Loginprüfung. Ist in der Processtable eine Shell mit root-Rechten, muß es (bei vorgestellter Konstellation) auch ein su-Process geben, da ein remotelogin vom Grundsatz her nicht erlaubt ist. Gibt es den nicht, ist es eine Fehlersituation.
Drittens wäre die Prüfung der offenen Ports im listening. Taucht ein Port auf, günstiger Weise vielleicht auch noch mit ProcessID, der nicht in einer gesicherten Datei steht, ist dies eine Fehlersituation ...
und so weiter und so fort ...
Je mehr Details, um so unwahrscheinlicher die Kompromittierung etc ...
Die Erfahrungen haben ich zur Genüge gemacht.
Und nun mal zur Sachlichkeit:
Es ist schlichtweg eine Falschaussage von Dir, wenn Du behauptest, Du hättest von Restrisiken gesprochen. Tu mir den Gefallen, und ließ Deine Postings noch einmal durch, und Du wirst erkennen, daß die Diskussion dadurch eskalierte, weil die Behauptung aufgestellt wurde, Paketfilter machen auf einem Webserver, der nicht hinter einer Firewall steht, keinen Sinn, und das IDS und Integritätsprüfung im laufenden Betrieb unnötig wären.
Und zum Abschluß: meine Server habe genau durch solche Methoden 3x mal vor der Kompromittierung bewahrt. Forensik gibt es nicht nur bei Toten ...
cu/2 iae
PS: Es war Ironier von mir, nicht "Zynismus"
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.