Wie hoch ist die Gefahr ohne FW und ohne lauschenden Prozessen?
Hi Leute, zuerst mal: Ich weiss, dass man sowas nicht macht, und ich hab es auch nicht vor!!! Aber mich beschäfftigt die Frage ein wenig... Wenn ich auf meinem Rechner keinen inetd laufen habe und auch sonst eigentlich kein Prozess an irgendeinem Port lauscht, wie hoch ist dann die Gefahr einer "feindlichen Übernahme"? Ich meine wenn kein Server antwortet kann man doch auch nirgens ansetzen, oder? Sorry, wenn ich so blöd frag, aber ich kenn mich mit den Taktiken der bösartigen Hacker halt nicht sonderlich aus... Wär trotzdem nett wenn ihr antwortet.. CU Martin -- Ich war jung und brauchte das Geld...
Hallo, am Mittwoch, 16. Oktober 2002 um 20:35 schrieb Martin Kropfinger
Wenn ich auf meinem Rechner keinen inetd laufen habe und auch sonst eigentlich kein Prozess an irgendeinem Port lauscht, wie hoch ist dann die Gefahr einer "feindlichen Übernahme"?
IMHO keine Gefahr. cu stonki -- Deutsche ProFTP Docs: http://www.proftpd.de EFNET: #proftpd
*** Stefan Onken (it-support@bikealert.de) schrieb in suse-linux heute:
[...]
Wenn ich auf meinem Rechner keinen inetd laufen habe und auch sonst eigentlich kein Prozess an irgendeinem Port lauscht, wie hoch ist dann die Gefahr einer "feindlichen Übernahme"?
IMHO keine Gefahr.
Jo! Und wieder jemand, der eine Bauch-Aussage und sogar noch eine
falsche macht.
Merke: Auch Kernel-Routinen sind vor Pufferüberläufen nicht sicher. Das
gilt allerdings auch nicht für die Routinen, die FW-Funktionalitäten
implementieren.
Oder genauer: "*keine* Gefahr" *gibt es nicht*!
MG Henning Hucke
--
"24-Aug-95 10:55:52 1> too many flames, message base is melting."
Matthias Scheler in
Hallo, am Donnerstag, 17. Oktober 2002 um 09:58 schrieb Henning Hucke
Merke: Auch Kernel-Routinen sind vor Pufferüberläufen nicht sicher. Das gilt allerdings auch nicht für die Routinen, die FW-Funktionalitäten implementieren.
gut, aber wie kommt man an die (nun mal angenommenen) Bugs im Kernel ran, wenn nirgendwo ein Port offen ist ? Wir gehen ja in dem Beispiel davon aus, das nix laeuft. cu stonki -- Deutsche ProFTP Docs: http://www.proftpd.de EFNET: #proftpd
*** Stefan Onken (it-support@bikealert.de) schrieb in suse-linux heute:
[...] gut, aber wie kommt man an die (nun mal angenommenen) Bugs im Kernel ran, wenn nirgendwo ein Port offen ist ? Wir gehen ja in dem Beispiel davon aus, das nix laeuft.
<seufz/>Überleg Dir bitte, was passiert, wenn jemand einen "nicht offenen" port anspricht. Hint: Es muß ja erstmal festgestellt werden, dass er "nicht offen" ist. MfG Henning Hucke -- Führst Du wieder Deine intellektuellen Defizite Gassi? Verlauf Dich einfach und find' nicht zurück, dann ist allen geholfen. [Rainer Blankenagel zu Michael Enezian in dang]
Hallo Henning, Am Donnerstag, 17. Oktober 2002 11:46 schrieb Henning Hucke:
*** Stefan Onken (it-support@bikealert.de) schrieb in suse-linux heute:
[...] gut, aber wie kommt man an die (nun mal angenommenen) Bugs im Kernel ran, wenn nirgendwo ein Port offen ist ? Wir gehen ja in dem Beispiel davon aus, das nix laeuft.
<seufz/>Überleg Dir bitte, was passiert, wenn jemand einen "nicht offenen" port anspricht. Hint: Es muß ja erstmal festgestellt werden, dass er "nicht offen" ist.
gibt es dann nicht einfach ein "reject"?. Eine davor geschaltete FW gibt mir doch auch nur ein reject oder drop. Kai
On Thu, Oct 17, 2002 at 11:46:00AM +0200, Henning Hucke wrote:
*** Stefan Onken (it-support@bikealert.de) schrieb in suse-linux heute:
[...] gut, aber wie kommt man an die (nun mal angenommenen) Bugs im Kernel ran, wenn nirgendwo ein Port offen ist ? Wir gehen ja in dem Beispiel davon aus, das nix laeuft. <seufz/>Überleg Dir bitte, was passiert, wenn jemand einen "nicht offenen" port anspricht. Hint: Es muß ja erstmal festgestellt werden, dass er "nicht offen" ist. Dein Wissen und Deine Kompetenz stellt doch niemand in Frage, aber mal ehrlich: wenn alle Ports "zu sind" ist das "Heimnetz" und das kleine Firmennetzwerk (solange man nicht VW oder ähnlich heisst) sicher.
Warum? Wieviele Hacker gibt es denn, die einen derartigen Aufwand um ein 08/15 System zu knacken fahren? Solange nicht www.superineterressant-und-oberwichtig.de gehostet wird? Wenn tatsächlich keine Ports nach aussen lauschen (auch Highports mit nmap überprüfti?!) sowie regelmässig Sicherheitsupdates eingespielt werden _hat_man_ein_sicheres_system_ und Angriffe sind wohl eher "aus dem Besucherkreis" zu erwarten als von ausserhalb. Vor Script Kiddies und ähnlichen Dilletanten ist man auf jeden Fall sicher. Fazit: Man kanns übertreiben - vollständige Sicherheit ist auch nicht über ausschalten erreichbar (kann ja ein "Einbrecher" einfach anschalten) - und die Schreibmaschinen und Aktenschrank Zeit ist in dieser Beziehung auch nicht sicherer (Schloss aufbrechen, Akten mitnehmen). greetinXs, Telefon: 07275/618351 Michael Hilscher Telefax: 07275/618352 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
*** Michael Hilscher (macvampi@michael-hilscher.de) schrieb in suse-linux heute:
[...] Dein Wissen und Deine Kompetenz stellt doch niemand in Frage, aber mal ehrlich: wenn alle Ports "zu sind" ist das "Heimnetz" und das kleine Firmennetzwerk (solange man nicht VW oder ähnlich heisst) sicher.
Warum? Wieviele Hacker gibt es denn, die einen derartigen Aufwand um ein 08/15 System zu knacken fahren? Solange nicht www.superineterressant-und-oberwichtig.de gehostet wird?
Ähmmm... Ein Netz ist nicht deshalb sicher, weil sich niemand - in welchem Umfang auch immer - die Mühe macht, einzubrechen. Das würde ja implizieren, dass auch ein Netz sicher ist, in dem alle aber auch wirklich alle Scheunentore offen stehen, solange sich niemand die "Mühe" macht, dieses System zu finden. Ein System ist "sicher", wenn es keinen Ansatzpunkt für einen Einbruch gibt. Und ein solches System gibt es nicht. Es gibt höchstens Systeme, deren Schwachstellen man noch nicht gefunden hat. Und mit Aufwand hat das nicht wirklich etwas zu tun. Sobalb eine entsprechender Fehler in den Kernel-Routinen gefunden wurde, wird es auch ein "interessantes" System geben, bei dem es sich zumindest lohnt, nachzuschauen, ob es diese Schwachstelle enthält. Also wird irgend ein Cracker (schon Deine Begriffsverwendung läßt erkennen, dass Du Dich noch nicht mit diesem Thema beschäftigt hast) ein Kit schreiben, dass sich dieser Schwachstelle zu bedienen versucht. Und wenn es dann existiert, ist es ein leichtes, ganze IP-Bereiche nach der entsprechenden Schwach- stelle abzugrasen...
Wenn tatsächlich keine Ports nach aussen lauschen (auch Highports mit nmap überprüfti?!) sowie regelmässig Sicherheitsupdates eingespielt werden _hat_man_ein_sicheres_system_ und Angriffe sind wohl eher "aus dem Besucherkreis" zu erwarten als von ausserhalb.
Nochmal: Es _gibt_ schlichtweg kein *sicheres* System. Meist kreisen die entsprechenden Kits bereits in cracker / black hacker kreisen, bevor ein Bugfix herausgegeben wird. Es gibt also höchstens Systeme, die das Glück hatten, von einem bestimmten Exploit-Scanner noch nicht erfaßt worden zu sein. Nochmal: Ein Port ist nicht deshalb "zu", weil er nicht antwortet, sondern weil das System _entscheidet_, dass es nicht antwortet. Und in schon in dieser Routine kann eine Möglichkeit für einen Pufferüberlauf stecken. Und dann ist man nicht nur "root", sondern steckt sogar im Kernel!... Begreifst Du _jetzt_, wo das Probelm liegt!?
[...]
Ich glaube, dass Du eine sehr merkwürdige Vorstellung von Sicherheit - auch privater Systeme - hast... MG Henning Hucke -- "Ich weiß nicht mit welchen Waffen sich die Menschen im 3. Weltkrieg bekaempfen, aber im 4. werden es Keulen sein." (Albert Einstein)
Hallo zusammen,
*** Michael Hilscher (macvampi@michael-hilscher.de) schrieb in suse-linux heute:
[...] Dein Wissen und Deine Kompetenz stellt doch niemand in Frage, aber mal ehrlich: wenn alle Ports "zu sind" ist das "Heimnetz" und das kleine Firmennetzwerk (solange man nicht VW oder ähnlich heisst) sicher.
Warum? Wieviele Hacker gibt es denn, die einen derartigen Aufwand um ein 08/15 System zu knacken fahren? Solange nicht www.superineterressant-und-oberwichtig.de gehostet wird?
Ähmmm... Ein Netz ist nicht deshalb sicher, weil sich niemand - in welchem Umfang auch immer - die Mühe macht, einzubrechen. Das würde ja implizieren, dass auch ein Netz sicher ist, in dem alle aber auch wirklich alle Scheunentore offen stehen, solange sich niemand die "Mühe" macht, dieses System zu finden.
Ein System ist "sicher", wenn es keinen Ansatzpunkt für einen Einbruch gibt. Und ein solches System gibt es nicht. Es gibt höchstens Systeme, deren Schwachstellen man noch nicht gefunden hat.
Und mit Aufwand hat das nicht wirklich etwas zu tun. Sobalb eine entsprechender Fehler in den Kernel-Routinen gefunden wurde, wird es auch ein "interessantes" System geben, bei dem es sich zumindest lohnt, nachzuschauen, ob es diese Schwachstelle enthält. Also wird irgend ein Cracker (schon Deine Begriffsverwendung läßt erkennen, dass Du Dich noch nicht mit diesem Thema beschäftigt hast) ein Kit schreiben, dass sich dieser Schwachstelle zu bedienen versucht. Und wenn es dann existiert, ist es ein leichtes, ganze IP-Bereiche nach der entsprechenden Schwach- stelle abzugrasen...
Wenn tatsächlich keine Ports nach aussen lauschen (auch Highports mit nmap überprüfti?!) sowie regelmässig Sicherheitsupdates eingespielt werden _hat_man_ein_sicheres_system_ und Angriffe sind wohl eher "aus dem Besucherkreis" zu erwarten als von ausserhalb.
Nochmal: Es _gibt_ schlichtweg kein *sicheres* System. Meist kreisen die entsprechenden Kits bereits in cracker / black hacker kreisen, bevor ein Bugfix herausgegeben wird. Es gibt also höchstens Systeme, die das Glück hatten, von einem bestimmten Exploit-Scanner noch nicht erfaßt worden zu sein. Nochmal: Ein Port ist nicht deshalb "zu", weil er nicht antwortet, sondern weil das System _entscheidet_, dass es nicht antwortet. Und in schon in dieser Routine kann eine Möglichkeit für einen Pufferüberlauf stecken. Und dann ist man nicht nur "root", sondern steckt sogar im Kernel!... Begreifst Du _jetzt_, wo das Probelm liegt!?
[...]
Ich glaube, dass Du eine sehr merkwürdige Vorstellung von Sicherheit - auch privater Systeme - hast...
MG Henning Hucke
Ich bin geneigt Henning zuzustimmen. Ein Port ist wie eine Tür. Man kann sie zwar abschließen, aber wenn man sie nicht kontrolliert/sichert, kann da jeder rein der das passende Werkzeug/Nachschlüssel hat. Ich bin als Privatmensch schon mehrmals Ziel von versuchten elektronischen Einbrüchen gewesen. Dabei gibt es bei mir nichts außergewöhnliches oder wichtiges auf dem privaten Rechner (weil ich bei so etwas ein wenig Paranoid bin). Eine abgeschlossene Tür übt auf manche Menschen den Reiz aus, sie zu öffnen, nur weil sie da ist. Ich bin froh über meine restriktive Firewall-Configuration. -- Mit freundlichen Grüßen René Falk --------------------------------------- E-Mail: falcon@falconeyes.de
On Thu, Oct 17, 2002 at 02:33:07PM +0200, René Falk wrote:
Ich bin geneigt Henning zuzustimmen. Ein Port ist wie eine Tür. Man kann sie zwar abschließen, aber wenn man sie nicht kontrolliert/sichert, kann da jeder rein der das passende Werkzeug/Nachschlüssel hat. Henning hat ja nicht unrecht mit dem was er sagt, aber ...
Ich bin als Privatmensch schon mehrmals Ziel von versuchten elektronischen Einbrüchen gewesen. Dabei gibt es bei mir nichts außergewöhnliches oder wichtiges auf dem privaten Rechner (weil ich bei so etwas ein wenig Paranoid bin). Eine abgeschlossene Tür übt auf manche Menschen den Reiz aus, sie zu öffnen, nur weil sie da ist. Ich bin froh über meine restriktive Firewall-Configuration. Ja und? Warum denkst Du denn, dass eine Firewall die Kiste sicherer macht als wenn sämtliche Ports zu sind - sprich also keine Dienste nach aussen lauschen? Vor einem Kernel-Bug schützt Dich auch die Firewall nicht. Insofern wiegst Du Dich "in falscher Sicherheit".
greetinXs, Telefon: 07275/618351 Michael Hilscher Telefax: 07275/618352 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
On Thu, Oct 17, 2002 at 02:01:19PM +0200, Henning Hucke wrote:
*** Michael Hilscher (macvampi@michael-hilscher.de) schrieb in suse-linux heute:
Warum? Wieviele Hacker gibt es denn, die einen derartigen Aufwand um ein 08/15 System zu knacken fahren? Solange nicht www.superineterressant-und-oberwichtig.de gehostet wird?
Ähmmm... Ein Netz ist nicht deshalb sicher, weil sich niemand - in welchem Umfang auch immer - die Mühe macht, einzubrechen. Das würde ja implizieren, dass auch ein Netz sicher ist, in dem alle aber auch wirklich alle Scheunentore offen stehen, solange sich niemand die "Mühe" macht, dieses System zu finden. Eben das habe ich nicht geschrieben - Schutz vor Exploits die automatisiert losgelassen werden ist sehr wichtig - daher habe ich ja darauf hingewiesen, dass sicherheitspatches unbedingt eingspielt werden sollten.
Ein System ist "sicher", wenn es keinen Ansatzpunkt für einen Einbruch gibt. Und ein solches System gibt es nicht. Es gibt höchstens Systeme, deren Schwachstellen man noch nicht gefunden hat. Allein die theorethische Möglichkeit in jedes System einzudringen macht das System nicht unbedingt unsicher. Das ist einfach zu hypothetisch.
(...) Also wird irgend ein Cracker (schon Deine Begriffsverwendung läßt erkennen, dass Du Dich noch nicht mit diesem Thema beschäftigt hast) ein Kit schreiben, dass sich was soll das? Heute schlecht drauf? Es ist mir bewusst, dass der Begriff Hacker ursprünglich für den erfahrenen Programmierer der mal so eben anspruchsvolle Quellcodes in die tastatur hackt stand. Heute spricht man aber eben auch von in einen rechner einhacken. Hacker wird schon seit ewigkeiten nicht mehr so (wie früher) verstanden.
dieser Schwachstelle zu bedienen versucht. Und wenn es dann existiert, ist es ein leichtes, ganze IP-Bereiche nach der entsprechenden Schwach- stelle abzugrasen... Sicher - spätestens dann wirds bekannt und man kann das Sicherheitsupdate einspielen und wenn das nicht zur Verfügung steht gehört der Dienst halt solange deaktiviert (wenn irgendwie möglich :-)
Nochmal: Es _gibt_ schlichtweg kein *sicheres* System. Meist kreisen die entsprechenden Kits bereits in cracker / black hacker kreisen, bevor ein Bugfix herausgegeben wird. Es gibt also höchstens Systeme, die das Glück hatten, von einem bestimmten Exploit-Scanner noch nicht erfaßt worden zu sein. Nochmal: das ist einfach zu hypothetisch. Was willst Du uns denn sagen? Nicht mehr mit dem Computer ans Netz (also auch nicht mehr das lokale) gehen, weil zu unsicher? LOL - so kann man nicht arbeiten.
Nochmal: Ein Port ist nicht deshalb "zu", weil er nicht antwortet, sondern weil das System _entscheidet_, dass es nicht antwortet. Und in schon in dieser Routine kann eine Möglichkeit für einen Pufferüberlauf stecken. Und dann ist man nicht nur "root", sondern steckt sogar im Kernel!... Begreifst Du _jetzt_, wo das Probelm liegt!? Das ist mir alles bekannt, aber thats life - fahr Auto, nutze das Flugzeug, geh spazieren oder bleib zu Hause --- alles ist unsicher, aber man kann dafür sorgen dass es sicherer wird. Und da sind wir bestimmt gleicher Meinung.
Ich glaube, dass Du eine sehr merkwürdige Vorstellung von Sicherheit - auch privater Systeme - hast... Das ist doch alberne Haarspalterei. Lach mal wieder, nimms locker und "have fun" - oder frag doch mal die Marketingabteilung ob nicht doch ein Hinweis "Warung jedes Betriebssystem auch Linux ist unsicher" auf die Packung sollte ,-)
Wenn es wirlich so schlimm mit dem Systemknacken wäre, dann frage ich mich wieso es immer wieder den berühmten Linux / BSD - Server gibt, der trozt seiner ständigen Internetanbindung als Webserver, selbst bei Rudimentären einspielen von Sicherheitspatches eben nicht geknackt wird. greetinXs, Telefon: 07275/618351 Michael Hilscher Telefax: 07275/618352 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Am Don, 17 Okt 2002 schrieb Michael Hilscher:
On Thu, Oct 17, 2002 at 02:01:19PM +0200, Henning Hucke wrote:
Ich glaube, dass Du eine sehr merkwürdige Vorstellung von Sicherheit - auch privater Systeme - hast... Das ist doch alberne Haarspalterei. Lach mal wieder, nimms locker und "have fun" - oder frag doch mal die Marketingabteilung ob nicht doch ein Hinweis "Warung jedes Betriebssystem auch Linux ist unsicher" auf die Packung sollte ,-)
Zumindest ist die Vorstellung, daß Linux per defintionem besonders sicher sein, falsch.
Wenn es wirlich so schlimm mit dem Systemknacken wäre, dann frage ich mich wieso es immer wieder den berühmten Linux / BSD - Server gibt, der trozt seiner ständigen Internetanbindung als Webserver, selbst bei Rudimentären einspielen von Sicherheitspatches eben nicht geknackt wird.
Was verstehst Du unter rudimentärem Einspielen von Patches, wenn ich mal allein überlege, wie viele Sicherheitslücken und Probleme allein in bind und openssh aufgetreten sind, also rudimentäres Einspielen war da sicher nicht die Methode der Wahl und der von Dir angesprochene berühmte ungeknackte Server ist nicht mehr als eine Legende, denke ich. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
On Thu, Oct 17, 2002 at 03:02:32PM +0200, Christoph Maurer wrote:
Was verstehst Du unter rudimentärem Einspielen von Patches, wenn ich mal allein überlege, wie viele Sicherheitslücken und Probleme allein in bind und openssh aufgetreten sind, also rudimentäres Einspielen war da sicher nicht die Methode der Wahl und der von Dir angesprochene berühmte ungeknackte Server ist nicht mehr als eine Legende, denke ich. Nicht ganz. Ich selbst spiele Patches sehr gewissenhaft ein, kenne aber beispielsweise einen BSD-Server der schon seit Ewigkeiten (länger als ein Jahr) nicht mehr mit Patches versorgt wurde (der Admin kennt sich mit dem System nicht aus -> ded. mietserver).
Sicher ist das gewaltiges Glück, dass noch nichts passiert ist und man sollte es nicht überstrapazieren - dennoch gibt es auch solche Fälle. Noch fragen? Ich bin kein Arsch und werde an dieser Stelle IP des BSD-Systems nicht verraten, aber ich denke dass Admins dedizierter Server wissen, das es genug solcher offenen Rechner gibt und nicht alle davon in Beschlag genommen werden. greetinXs, Telefon: 07275/618351 Michael Hilscher Telefax: 07275/618352 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Am Don, 17 Okt 2002 schrieb Michael Hilscher:
On Thu, Oct 17, 2002 at 03:02:32PM +0200, Christoph Maurer wrote:
Was verstehst Du unter rudimentärem Einspielen von Patches, wenn ich mal allein überlege, wie viele Sicherheitslücken und Probleme allein in bind und openssh aufgetreten sind, also rudimentäres Einspielen war da sicher nicht die Methode der Wahl und der von Dir angesprochene berühmte ungeknackte Server ist nicht mehr als eine Legende, denke ich. Nicht ganz. Ich selbst spiele Patches sehr gewissenhaft ein, kenne aber beispielsweise einen BSD-Server der schon seit Ewigkeiten (länger als ein Jahr) nicht mehr mit Patches versorgt wurde (der Admin kennt sich mit dem System nicht aus -> ded. mietserver).
Sicher ist das gewaltiges Glück, dass noch nichts passiert ist und man sollte es nicht überstrapazieren - dennoch gibt es auch solche Fälle.
Eben. Es ist Glück, aber das hat mit Sicherheit nichts zu tun und auch nicht mit dem Betriebssystem, das könnte Dir bei einem Windows-Server auch passieren, daß ihn zufällig niemand knackt... Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Klasse Diskussion ... Ich sagte ja schon dass die einzigste Moglichkeit die Uebanahme zu verhindern das Auschalten (oder besser: nicht einschalten) ist. Oops stopp: theoretisch (nach Gesetzten der Wahrscheinlichkeit) nutzt auch das nichts. Stichwort Murphy, oder: wie lange brauchen 1000 Affen um Hamlet zu schreiben ;-) Damit ist doch die urspruengliche Frage: > .. verhindern .. Gefahr einer "feindlichen Übernahme"? hinreichend erklaert. Die Antwort ist eindeutig: *nein, es ist nie moeglich* Punkt. Jeder andere Antwort, egal ob "ja, aber ..." oder "nein, aber ..." ist rein philosophischer Natur, bzw. entspricht den Vorlieben des Autors Beispiele siehe unten: Marketing -> ja, aber .. oder des Security-Paranoikers --> nein, aber .. jeder hat die Antwort halt auf seine Beduerfnisse abgestellt. Das aendert aber nichts an der Tatsache das die Atwort (zur Frage) eindeutig ist: die Gefahr besteht immer. Alles andere sind wenn und aber, d.h. haengt vom Kontext ab. Natuerlich koennte mit der Frage was anderes gemeint sein, aber das muss uns der Autor selber sagen. Technisch ist die Erklaerung von Henning IMO richtig, in der Praxis gibt es natuerlich Faelle von Rechnern die der Gefahr nicht erlegen sind (wie Michael behauptet). Dass deshalb die Gefahr aber ausschliesbar ist, ist damit nicht gesagt, und kann auch nicht bewiesen werden (oder doch?), man kann nur versuchen es sicherer zu machen. Aber nicht mit der Vogel-Strauss-Methode: kein Listen auf Port, daraus folgt: sicher. Es ist wie mit dem Leben, es endet eben immer mit dem Tod (ob ich nun fliege, Auto fahre, oder auch nicht). Und trotzdem habe ich "fun" mit meinem Rechner (auch wenn ich bzgl. Sicherheit paranoide Vorstellungen habe:), das schliesst sich nicht aus. Apropos "reject" (an FW, und/oder Rechner): als Cracker/Hacker warte ich auf dieser Wink mit dem Zaunpfahl :-) Jetzt alles klar? Achim On Thu, 17 Oct 2002, Michael Hilscher wrote:
On Thu, Oct 17, 2002 at 02:01:19PM +0200, Henning Hucke wrote:
*** Michael Hilscher (macvampi@michael-hilscher.de) schrieb in suse-linux heute:
Warum? Wieviele Hacker gibt es denn, die einen derartigen Aufwand um ein 08/15 System zu knacken fahren? Solange nicht www.superineterressant-und-oberwichtig.de gehostet wird?
Ähmmm... Ein Netz ist nicht deshalb sicher, weil sich niemand - in welchem Umfang auch immer - die Mühe macht, einzubrechen. Das würde ja implizieren, dass auch ein Netz sicher ist, in dem alle aber auch wirklich alle Scheunentore offen stehen, solange sich niemand die "Mühe" macht, dieses System zu finden. Eben das habe ich nicht geschrieben - Schutz vor Exploits die automatisiert losgelassen werden ist sehr wichtig - daher habe ich ja darauf hingewiesen, dass sicherheitspatches unbedingt eingspielt werden sollten.
Ein System ist "sicher", wenn es keinen Ansatzpunkt für einen Einbruch gibt. Und ein solches System gibt es nicht. Es gibt höchstens Systeme, deren Schwachstellen man noch nicht gefunden hat. Allein die theorethische Möglichkeit in jedes System einzudringen macht das System nicht unbedingt unsicher. Das ist einfach zu hypothetisch.
(...) Also wird irgend ein Cracker (schon Deine Begriffsverwendung läßt erkennen, dass Du Dich noch nicht mit diesem Thema beschäftigt hast) ein Kit schreiben, dass sich was soll das? Heute schlecht drauf? Es ist mir bewusst, dass der Begriff Hacker ursprünglich für den erfahrenen Programmierer der mal so eben anspruchsvolle Quellcodes in die tastatur hackt stand. Heute spricht man aber eben auch von in einen rechner einhacken. Hacker wird schon seit ewigkeiten nicht mehr so (wie früher) verstanden.
dieser Schwachstelle zu bedienen versucht. Und wenn es dann existiert, ist es ein leichtes, ganze IP-Bereiche nach der entsprechenden Schwach- stelle abzugrasen... Sicher - spätestens dann wirds bekannt und man kann das Sicherheitsupdate einspielen und wenn das nicht zur Verfügung steht gehört der Dienst halt solange deaktiviert (wenn irgendwie möglich :-)
Nochmal: Es _gibt_ schlichtweg kein *sicheres* System. Meist kreisen die entsprechenden Kits bereits in cracker / black hacker kreisen, bevor ein Bugfix herausgegeben wird. Es gibt also höchstens Systeme, die das Glück hatten, von einem bestimmten Exploit-Scanner noch nicht erfaßt worden zu sein. Nochmal: das ist einfach zu hypothetisch. Was willst Du uns denn sagen? Nicht mehr mit dem Computer ans Netz (also auch nicht mehr das lokale) gehen, weil zu unsicher? LOL - so kann man nicht arbeiten.
Nochmal: Ein Port ist nicht deshalb "zu", weil er nicht antwortet, sondern weil das System _entscheidet_, dass es nicht antwortet. Und in schon in dieser Routine kann eine Möglichkeit für einen Pufferüberlauf stecken. Und dann ist man nicht nur "root", sondern steckt sogar im Kernel!... Begreifst Du _jetzt_, wo das Probelm liegt!? Das ist mir alles bekannt, aber thats life - fahr Auto, nutze das Flugzeug, geh spazieren oder bleib zu Hause --- alles ist unsicher, aber man kann dafür sorgen dass es sicherer wird. Und da sind wir bestimmt gleicher Meinung.
Ich glaube, dass Du eine sehr merkwürdige Vorstellung von Sicherheit - auch privater Systeme - hast... Das ist doch alberne Haarspalterei. Lach mal wieder, nimms locker und "have fun" - oder frag doch mal die Marketingabteilung ob nicht doch ein Hinweis "Warung jedes Betriebssystem auch Linux ist unsicher" auf die Packung sollte ,-)
Wenn es wirlich so schlimm mit dem Systemknacken wäre, dann frage ich mich wieso es immer wieder den berühmten Linux / BSD - Server gibt, der trozt seiner ständigen Internetanbindung als Webserver, selbst bei Rudimentären einspielen von Sicherheitspatches eben nicht geknackt wird.
greetinXs, Telefon: 07275/618351 Michael Hilscher Telefax: 07275/618352
-- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
On Thu, Oct 17, 2002 at 03:40:14PM +0200, Achim Hoffmann wrote:
Apropos "reject" (an FW, und/oder Rechner): als Cracker/Hacker warte ich auf dieser Wink mit dem Zaunpfahl :-) Du kannst das Paket auch einfach fallen lassen. Ich persönlich nutze diese Möglichkeit sogar bei eingehenden "echo requests" aber "rejecte Anfragen an inetd". Auch darüber kann man streiten und ich selbst verstehe mich ebenfalls als Paranoiker (FTP-Einmalpasswörter - leider kann ich nicht allen Windows Usern SFTP abverlangen, Pop3s, Backups auf ReadOnly Medien die an zwei verschiedenen Orten aufbewahrt werden usw.).
Ich denke nicht, dass Black Hats in erster Linie nach reject schauen sondern erstmal gucken was offen ist und ob da nicht gleich die Lücke gefunden wurde. Erst dann werden die Jungs ins Detail einsteigen oder einfach sich dem nächsten System zuwenden ... greetinXs, Telefon: 07275/618351 Michael Hilscher Telefax: 07275/618352 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
On Thu, Oct 17, 2002 at 03:47:48PM +0200, Michael Hilscher wrote:
On Thu, Oct 17, 2002 at 03:40:14PM +0200, Achim Hoffmann wrote:
Apropos "reject" (an FW, und/oder Rechner): als Cracker/Hacker warte ich auf dieser Wink mit dem Zaunpfahl :-) Du kannst das Paket auch einfach fallen lassen. Ich persönlich nutze diese Möglichkeit sogar bei eingehenden "echo requests" aber "rejecte Anfragen an inetd". Auch darüber kann man streiten und ich selbst Quatsch - es sollte heissen rejecte ident / auth (tcp und udp 113)
greetinXs, Telefon: 07275/618351 Michael Hilscher Telefax: 07275/618352 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Hi Leute, erstmal muss ich sagen, ich freue mich über die vielen Antworten auch wenn ich, wie ich zugeben muss, schon fast befürchtet habe, dass das in ne Art Flamewar ausarten könnte.... On Thu, Oct 17, 2002 at 03:40:14PM +0200, Achim Hoffmann wrote:
Natuerlich koennte mit der Frage was anderes gemeint sein, aber das muss uns der Autor selber sagen. Ich wollte einfach nur wissen ob ein Rechner auch dann angegriffen werden kann wenn der Rechner selber eigentlich nicht (geplant) auf Anfragen aggiert. Damit mein ich natürlich wenn ein Dienst hinter einem Port lauscht.
Wie ihr mir jetzt vermittelt habt habe ich daraus jetzt mal geschlossen, dass es ohne lauschende Ports zwar nicht (unbedingt) so trivial sein muss ins System zu kommen, allerdings das System dennoch anfällig sein kann wenn ein Bug im Kernel vorliegt. Aus diesem Grund und weil der Rechner evtl als "Sprungbrett" dienen kann sollte auf alle Fälle eine FW eingesetzt werden. Ich hoffe mein Resume war soweit richtig und ich denke dass ich damit den Thread schliessen sollte. Alles weitere artet wohl zuweit aus. Danke! CU Martin -- Geben ist seliger denn Nehmen. M.Ali
On Donnerstag, 17. Oktober 2002 17:33, Martin Kropfinger wrote:
Hi Leute,
erstmal muss ich sagen, ich freue mich über die vielen Antworten auch wenn ich, wie ich zugeben muss, schon fast befürchtet habe, dass das in ne Art Flamewar ausarten könnte....
Sehe ich nicht so. Zwischen einer Diskussion mit gesundem Halbwissen und einem Flamewar besteht ein gewisser Unterschied ;-)
Ich wollte einfach nur wissen ob ein Rechner auch dann angegriffen werden kann wenn der Rechner selber eigentlich nicht (geplant) auf Anfragen aggiert. Damit mein ich natürlich wenn ein Dienst hinter einem Port lauscht.
Der Rechner kann natürlich nur so sicher sein, wie das schwächste Glied in der Kette. Eine Anfrage vom Netz wird vom Kernel verarbeitet und an den Dienst oder Applikation weitergeleitet. Findet der Angreifer eine Möglichkeit, ein Datenpacket so zu formatieren, das dies zu _nicht_vorgesehenen_ Reaktionen auf der Maschine führt, hat er seinen Fuß in der Tür.... er braucht dann nur noch das Paket soweit umzuwandeln, das es wieder zu gewünschten Reaktionen führt. Und die sind meist nicht im Sinne des Administrators der Maschine.
Wie ihr mir jetzt vermittelt habt habe ich daraus jetzt mal geschlossen, dass es ohne lauschende Ports zwar nicht (unbedingt) so trivial sein muss ins System zu kommen, allerdings das System dennoch anfällig sein kann wenn ein Bug im Kernel vorliegt.
Man kann davon ausgehen, das der Kernel sicher ist. Besser: Man sollte davon ausgehen, sonst kann man die Maschine abschalten. Was macht der Kernel da eigentlich? Der Kernel schmeißt alle Packete ungelesen weg, die er nicht kennt. In Falle von UDP-Paketen guckt er nur nach, ob es ein Programm gibt, an den er es weiterleiten kann. Gibt es die nicht, wird es verworfen. Bei TCP reagiert er nur auf ein SYNC, und das kann keine Daten enthalten, sonst wäre es kein SYNC. Der SYNC enthält wiederum ein Port, gibts den nicht, schickt er ein RST zurück. Diese Dinge sind in _stable_ Kernels millionenfach getestet worden, und was dabei alles passiert, wird nicht nur von einer kleinen Gruppe von Entwicklern verstanden, man kann ja selber nachgucken, da alles auch im Sourcecode vorliegt. Das heißt natürlich nicht, das in Zukunft nicht doch jemanden gibt, der eine Lücke findet. Man kann sich aber sicher sein, das wenn so ein Fehler gefunden wird, es nur wenige Minuten dauert, bis ein Patch dagegen geschrieben ist.
Aus diesem Grund und weil der Rechner evtl als "Sprungbrett" dienen kann sollte auf alle Fälle eine FW eingesetzt werden.
*g* Der Firewall braucht auch einen Kernel. Das ist dann __das__ Sprungbrett :-)) Außerdem verarbeitet ein Firewall ja alle Pakete... er muß ja in jedes reingucken, und in seinen Tables nachgucken, was er damit anstellen soll. Eine trügerische Sicherheit. Das kann ja nur funktionieren, wenn der Firewall-Code keinen Fehler enthält. Das ist aber eine Erweiterung des IP-Stacks. Denke selber weiter....
Ich hoffe mein Resume war soweit richtig und ich denke dass ich damit den Thread schliessen sollte. Alles weitere artet wohl zuweit aus.
Das muß jeder selbst entscheiden.
Danke!
Bitte :-) <Earny>
*** Ernst Herzberg (earny@net4u.de) schrieb in suse-linux heute:
[...] Sehe ich nicht so. Zwischen einer Diskussion mit gesundem Halbwissen und einem Flamewar besteht ein gewisser Unterschied ;-)
In der Tat. ... Apropos "gesundes Halbwissen"...
[...] Man kann davon ausgehen, das der Kernel sicher ist. Besser: Man sollte davon ausgehen, sonst kann man die Maschine abschalten.
Schonmal falsch. Einfach davon auszugehen, ignoriert schonmal Reali- täten. _Nicht_ davon auszugehen, hilft einem, gegenüber ungewöhnlichen Meldungen im syslog nicht blind zu werden.
Was macht der Kernel da eigentlich? Der Kernel schmeißt alle Packete ungelesen weg,
... Whuaaaaa! Und was macht die Routine, die die IP-Pakete von der Karte einliest? Die checkt die Verbindungsdaten, checkt sequence numbers und *irgendwann* checkt sie auch mal, ob das SYN-Bit gesetzt ist. Nämlich genau dann, wenn sie durch allerlei Arbeit festgestellt hat, dass das Paket zu keiner bestehenden Verbindung gehört. Darüber hinaus gibt es bei UDP keine SYN-Bits. Und bei dem, was alles passiert, *bis* ein Paket verworfen wird, kann durchaus ein Pufferüberlauf möglich sein. Punkt.
[...] *g* Der Firewall braucht auch einen Kernel. Das ist dann __das__ Sprungbrett :-))
Und "der" Firewall ist schonmal nicht männlich, weil die Übersetzung von "wall" nicht "Wall" sondern "Wand" ist, die bekanntlich weiblich ist, weshalb es *"die Firewall"* heißt. Das mag jetzt korintenkackerei sein aber zeigt oft genug, mit welcher (eben nicht vorhandenen) Präzision viele Leute denken.
[...]
Ansonsten sind die Gedanken hier in der Tat nicht falsch. MG Henning Hucke -- Heute habe ich mal etwas probiert. Wie es ist, ohne Sex, Drogen und Computer auszukommen. Tja - es war die härteste Viertelstunde meines Lebens ;). Geklaut aber toll. (Uuups. Es ist schon wieder passiert :-})
On Donnerstag, 17. Oktober 2002 18:35, Henning Hucke wrote:
Man kann davon ausgehen, das der Kernel sicher ist. Besser: Man sollte davon ausgehen, sonst kann man die Maschine abschalten.
Schonmal falsch. Einfach davon auszugehen, ignoriert schonmal Reali- täten. _Nicht_ davon auszugehen, hilft einem, gegenüber ungewöhnlichen Meldungen im syslog nicht blind zu werden.
Nagut. Laß ich auch gelten. Kommt drauf an, welches Wissen der Anwender hat. Es ist ja nicht so, das ein Angriff zu ungewöhnlichen Einträgen führt. dann gibt es ja schon eine Funktion, die etwas ungewöhliches erkennt. Gefährlich sind gewöhliche Einträge, die ungewöhlich sind. Zähle mir die Leute auf, die in der Lage sind, das zu unterscheiden.
Was macht der Kernel da eigentlich? Der Kernel schmeißt alle Packete ungelesen weg,
... Whuaaaaa! Und was macht die Routine, die die IP-Pakete von der Karte einliest? Die checkt die Verbindungsdaten, checkt sequence numbers und *irgendwann* checkt sie auch mal, ob das SYN-Bit gesetzt ist. Nämlich genau dann, wenn sie durch allerlei Arbeit festgestellt hat, dass das Paket zu keiner bestehenden Verbindung gehört. Darüber hinaus gibt es bei UDP keine SYN-Bits. Und bei dem, was alles passiert, *bis* ein Paket verworfen wird, kann durchaus ein Pufferüberlauf möglich sein.
Punkt.
Die physikalische Länge eines Pakets ist begrenzt. Kommt es da zu einem Overflow, ist die Hardware defekt, falsch designed, der Treiber kann mit der Karte nicht um, oder der Entwickler wußte nicht, was er da geschrieben hat. Sollten nun noch Kopieroperationen statfinden, sind die (max) Längen bekannt. Ein BufferOverflow ist dann ein BUG(). Gefährlich wirds erst, wenn eine TCP-Verbindung steht, und z.B. fragmentierte Pakete wieder assembled werden müssen. Und bis das soweit ist, muß ein SYNC erstmal durch. Ein RST braucht übrigends keine SeqNumber... wenn du eine Auswertung vor dem RST findest, sollte man den Code etwas umstellen ;-) Google doch mal nach 'zero copy TCP/IP', damit kann es nur eine einzigste Stelle geben, wo ein BufferOverflow möglich ist. (das mit UDP laß ich mal weg, das ist klar, habe ich auch nie behauptet).
[...] *g* Der Firewall braucht auch einen Kernel. Das ist dann __das__ Sprungbrett
:-))
Und "der" Firewall ist schonmal nicht männlich, weil die Übersetzung von "wall" nicht "Wall" sondern "Wand" ist, die bekanntlich weiblich ist, weshalb es *"die Firewall"* heißt.
Pedant! :-)
Das mag jetzt korintenkackerei sein aber zeigt oft genug, mit welcher (eben nicht vorhandenen) Präzision viele Leute denken.
Viele ist untertrieben. Aber müssen das denn alle? In _diesem_ Fall reichen eine Handvoll. Und noch mal eine Handvoll, die denen genau auf die Finger gucken. Das meine ich auch damit, das sich Anwender darauf verlassen sollten... oder sich darauf verlassen müssen. Wenn ein Entwickler einen Dienst schreibt, braucht er ihn nur so sicher zu machen, wie den Kernel. Es kann keinen Dienst geben, der sicherer ist als der Kernel (das Prinzip der Kette). Eine Firewall kann nicht sicherer sein als der Kernel, auf der sie läuft. Und ein Rechner nicht sicherer als sein 'präziser' Administrator. Und jetzt sage mir, wo das schwächste Glied in der Kette ist.
Ansonsten sind die Gedanken hier in der Tat nicht falsch.
BUG(). Der nächste Cracker wird dir u.U. das Gegenteil beweisen.
MG Henning Hucke
Die Hoffnung halt nie aufgeben..... <Earny>
Hallo, On Thu, 17 Oct 2002, Henning Hucke wrote:
Ein System ist "sicher", wenn es keinen Ansatzpunkt für einen Einbruch gibt. Und ein solches System gibt es nicht.
Doch! *snigger* Sogar eins von M$ und mit IIS: ==== $ siggrep concr | sed '/^%$/d' ==== They ARE right, you CAN secure an IIS against intrusion. First you turn off all the services and other hooks that lets it do all the things they brag on that makes IIS "better", then you imbed an axe in the machine, then you unplug it, encase it in glass, put it in a concrete vault, cover that with urethane, and toss the whole thing into the depest part of the ocean, cover it with 150 meters of silt, create a concrete sarcophogus over the silt pile, and liberally seed the area with spent nuclear fuel to kill anything that gets too close to it. No problem. -- random in asr ==== -dn'*wie?"daswarnichgefragt"?!?*'h PS: Wofuer steht IIS nochmal? "Intrusion for Imbeciles"-Server? -- Und nein, der sogenannte RAM-Test beim Booten ist zumeist nichtmal geeignet, einen völlig defekten RAM-Riegel von einer völlig intakten Schuhsohle zu unterscheiden. -- A. Beck in dasr
Griasde Michael! Am Donnerstag, 17. Oktober 2002 13:20 schrieb Michael Hilscher:
Warum? Wieviele Hacker gibt es denn, die einen derartigen Aufwand um ein 08/15 System zu knacken fahren? Solange nicht www.superineterressant-und-oberwichtig.de gehostet wird?
Les' Dir mal bitte dazu folgenden Beitrag durch: http://www.tecchannel.de/betriebssysteme/720/index.html Wie heisst es dort so schön:
Wer seinen Rechner nicht vernünftig absichert, bringt das gesamte Netz in Gefahr."<<
Also nur nicht davon ausgehen, daß nur wichtige Server im Netz attakiert werden - auch das 08/15 System kann von entscheidender Bedeutung sein! Pfiade, BC -- Michael Nausch Anzinger Str. 20 85586 Poing +49-8121-971940 (voice) +49-8121-971941 (fax) http://omni128.de michael@nausch.org
On Thu, 17 Oct 2002, Henning Hucke wrote:
*** Stefan Onken (it-support@bikealert.de) schrieb in suse-linux heute:
[...]
Wenn ich auf meinem Rechner keinen inetd laufen habe und auch sonst eigentlich kein Prozess an irgendeinem Port lauscht, wie hoch ist dann die Gefahr einer "feindlichen Übernahme"?
IMHO keine Gefahr.
Jo! Und wieder jemand, der eine Bauch-Aussage und sogar noch eine falsche macht.
Merke: Auch Kernel-Routinen sind vor Pufferüberläufen nicht sicher. Das gilt allerdings auch nicht für die Routinen, die FW-Funktionalitäten implementieren.
Oder genauer: "*keine* Gefahr" *gibt es nicht*!
.. oder: nur ein ausgeschalteter Rechner ist (in diesem Zustand: ausgeschaltet) nicht uebernehmbar (Uebernehmen im Sinne von Software/Programm). Punkt. Achim Disclaimer: Aussage ungetestet, aber Gegenbeweis konnte noch keiner machen:-)
participants (12)
-
Achim Hoffmann -
Christoph Maurer -
David Haller -
Ernst Herzberg -
Henning Hucke -
Kai Lindenberg -
Martin Kropfinger -
Michael Hilscher -
Michael Hilscher -
Michael Nausch -
Ren� Falk -
Stefan Onken