Die Debianer verwenden halt imm alte und unsichere Software *fg* Nee, ich will nicht provozieren.
Aber schon seltsam, dass die Server die sicher von LinuxGurus aufgesetzt und gepflegt werden kompromittiert werden. Da siehts für OttoNormal Linux Home Server User sicher düster aus
Hatt vor einigen Jahren auch mak vergessen meine sshd zu updaten und schon hatte die halbe Welt Root Zugriff.
Mein dedicated-root läuft auch auf ner Debian Kiste.
2 Ports sind nach aussen offen: ssh http
ssh: dafür gibts fail2ban, und regelämssige updates, root ist im übrigen auch gleich disabled, dann per gpg key login, etc... http: mod-security (hätte wohl bei diesem "hack" schon geholfen), mod-chroot php: safe-mode
Alles erhältlich unter Debian !
Man _kann_ Debian einigermassen Sicher konfigurieren (wobei es 100% Sicherheit NIE gibt), aber dazu müsste man halt mehr machen als ein einfaches "apt-get install php4 apache mysql"
Von twi1qmsujx0ordp am Do, 7. September 2006 um 09:44 #
Hobbyinformatiker - das ist das einzige was mir zu den Debian Admins einfälllt. Wenn sich das mal nicht rächt. Falls es mal einem Hacker gelingen sollte, Code versteckt einzuschliessen, wir die ganze Linux Community und OpenSource Bewegung komprimitiert.
Da lob ich mir die Seriosität von RedHat. Aber seit ich 98 mit Linux beruflich zu tun hab, kam von Debian ja noch nie viel schlaues... Typische Lamer Distro für alle die Privat gerne was basteln.
Ohne den admins jetzt einen Vorwurf machen zu wollen, aber ich habe vorher bei Heise.de von dieser Lücke gelesen. Und wenn ich so einen wichtigen Server mit dem Wiki hätte, hätte ich es gepatched...
Aber wer weiss, vielleicht war der Angreifer ja schon vor dem patchen da...
Debian ist ein Distributor damit für die Pflege und Wartung der ausgeliferten Software verantwortlich. Gerade das so auf Sicherheit bedachte Debian oatzt mir hier zu oft. Schon aus Eigeninteresse sollte man sich beim betreiben der eigenen Server mehr Mühe geben. Wer setzt in kritischen Umgebungen schon eine Distribution ein die nichtmal der "Hersteller" sicher betreiben kann.
> Debian ist ein Distributor damit für die Pflege und Wartung der > ausgeliferten Software verantwortlich.
Nur gut, das PmWiki nicht mit Debian ausgeliefert wird. Es ist wohl kein Fehler des Distributors, wenn in der Zusatzsoftware eine Sicherheitslücke ist, und diese nicht gestopft wird.
Es steht aber schon in dem Artikel, das die Software ein Fremdpakete ist.
Ja, das ist nicht die erste Debianserverkomprimierung.. wann kappieren die endlich, dass standard Linuxsicherheit heutzutage unzureichend ist.. Man nehme z.B. SELinux, oder RSBAC, oder andere und man verbietet z.B. dem Apache die entsprechende Capabilitäts (hier Netzwerkfähigkeit auf fremde Ports zuzugreifen) und schon wird sowas eingedämpft.. Dann noch andere Securitylösungen kombinieren und so kann man sich gegen nicht vorhandene 0days, egal ob BOF-ähnliche, oder wie hier remote inclusion, usw schützen... Echt traurig..
Und vor allem, sollen zumindest die Admins Securitynews lesen und entsprechend handeln: http://www.securityfocus.com/bid/16421/ ( Bug ist seit Januar bekannt!!!)
>> Ja, das ist nicht die erste Debianserverkomprimierung.. >Was ist eine Debian-Komprimierung?
Er hat Kompromittierung gemeint. Außerdem hast Du durch das Weglassen des Worts "Server" denn Sinn der Aussage verändert, was insgesamt auf schlechten Stil hinweist.
>wann kapppieren die Leute endlich, dass es ein Fehler im Wiki war?
Lesen und verstehen musst Du noch etwas üben. Es ging hier darum, dass es zwar ein (lange bekannter aber ungepatchter) Fehler in der Anwendung war, dass man jedoch bei entsprechener Konfiguration des Systems solche Sicherheitsprobleme weitestgehend minimieren kann. Nur leider ist dies standardmäßig bei den meisten Distributionen nicht so voreingestellt.
Von smvdpsmviomjsdfßvo am Do, 7. September 2006 um 14:54 #
Bist Du denn nicht in der Lage, dir Informationen selbst zu beschaffen? Aber meine Güte kennt für Dich glücklicherweise keine Grenzen, darum hier ein kleiner Tipp: auf der Website von PmWiki (http://www.pmwiki.org) findest Du alle nötigen Informationen, um Deine Frage zu beantworten. Faulheit wird hier, wie auch im restlichen Leben, nicht belohnt!
Von filthgrinder am Do, 7. September 2006 um 09:51 #
Richtig!
Wer sagt denn, dass bei Novell/RedHat/usw. keine Einbrüche gelingen? Kommerzielle Linux-Distributoren wollen verkaufen, vor allem mit Hilfe des Arguments Sicherheit. Die werden den Teufel tun und gelungene Einbrüche veröffentlichen.
Von Martin Fernau am Do, 7. September 2006 um 09:49 #
AFAIK ist ein Cracker eine Person, die Software manipuliert um beispielsweise eine Laufzeitbeschränkung zu entfernen oder an Funktionen zu gelangen, die normalerweise nur freigeschaltet werden, wenn man einen Code eingibt. Ein Hacker ist eine Person, die Lücken im System ausnutzt um ein System zu zu seinem eigenen Nutzen zu mißbrauchen oder Daten zu entwenden.
Öh.. sonst wollte ich nichts Mir war nur gerade langweileig
Von Martin Fernau am Do, 7. September 2006 um 10:14 #
okay, ich lasse mich gern eines besseren belehren. Wobei selbst in diesem Artikel zu erkennen ist, dass es beide Definitionen in der Kultur gibt. Die eine, wie ich sie (vielleicht fälschlicherweise) dachte und die andere, wie sie ursprünglich mal angedacht war. Zumindest ist meine Aussage nur halb falsch. Ein Cracker ist (zumindest "auch") eine Person die Kopierschütze umgeht
Ein Cracker bezeichnet sowohl jemanden, der kompilierten Softwarecode manipuliert, als auch einen destruktiven Hacker. Und es gibt dann noch die Kekse, die auch als Cracker bezeichnet werden. Bis auf die Kekse handelt es sich also um Personen, die illegale/halblegale Handlungen vollziehen.
Ein Hacker hingegen ist ein sehr fortgeschrittener Computerbenutzer, der sein Wissen jedoch nicht destruktiv einsetzt und sich somit vom Cracker abgrenzt.
Wo gehört das Betriebssystem hin? Auf die Festplatte. -> Falsch, es gehört ins ROM. Nur manuell gebrannte ROMs stellen sicher, daß das System nicht verändert werden kann. O.K., ich gebe zu: Ein normales OS paßt nicht mehr ein einen ROM, aber da können die Debianer einfach mal den Serverumfang auf ein Minimum reduzieren und den Rest "klein-optimieren". Irgendwie wird das schon gehen - wenn man nur will.
Zu den guten alten C64-Zeiten waren Programme so direkt zugänglich und sicher vor jeder Manipulation.
>Ein normales OS paßt nicht mehr ein einen ROM *blubb* wenn ein ROM nicht reicht, dann nimm halt zwei oder noch mehr. Das geht wie mit Arbeitsspeicher, da darf man ruhig mehr verwenden. Tatsächlich gibt es Betriebssystem im ROM (z.b EPROM oder E2PROM) noch immer bei technischen Maschinen etc. Wenn das ROM zu teuer ist geht es auch mit CD-ROM beziehungsweise DVD (letztere liest sich erheblich schneller und ist daher zu bevorzugen).
So kompliziert muss es doch gar nicht sein. Warum nicht einfach die Applikationen auf verschiedenen Server aufsplitten, einen Webserver fürs Wiki, CVS Server alleine etc. dann kann man sowas auch viel einfacher warten und überblicken was auf einem System ist, nicht zu vergessen, wenn die Maschine nen Hardwareschaden hat, dass hat nur ein Dienst weg ist. Und nicht die komplette Palette.
Wenn man sieht, dass die Monate lang keine Updates einspielen, dann sind die einfach überfordert faul oder wissen gar nicht mehr was auf ihren Kisten läuft. Von daher bin ich der Meinung, dass es einfach am grunsätzlichen Design ihrer Infrastruktur hapert und das ist definitiv deren Schuld.
Bei den meisten Firmen, bei denen ich bisher gearbeitet habe liefen maximal 2 Anwendungen Dienste auf einem Frontline Server.
Es sagt ja niemand was gegen nen Konfigurationsfehler etc, sowas kann passieren, aber bei Debian passieren immer wieder die gleichen Fehler -> ewig lang keine Patches einspielen. Server die alles erledigen ->eierlegende Wollmilchsau
Also ich versteh es einfach nicht, jetzt wurde Debian einige Male in kurzen Abständen gehackt und sie stellen sich immer noch an wie kleine Buben.
Wieso muss auf nem Infrastruktur Server, der CVS etc hat auch noch BugTracker, Wiki etc laufen, das ist doch irrsinnig. Entweder sie haben zu wenig Maschinen um so Komponenten zu trennen oder sie wissen es nicht besser. So ein fetter Rechner ist auch schwierig zu warten.
Und permanent sind auf Debian frontline Servern Pakete mit Lücken vorhanden die lange nicht gepatcht werden. Bei ner normalen Firma könnte der Admin jetzt Rechner putzen.
Man kann hier Linux und PmWiki nicht die Schuld in die Schuhe schieben. Es ist einfach nur traurig, dass in der Öffentlichkeit der Eindruck entstehen könnte Linux sei unsicher, nur weil hier widerholt ein paar Dilentanten am Werk sind.
Ich habe einmal einen Bericht der Wochenzeitschrift "Profil" (Österreich) gelesen, in dem sie verschiedene Admins von diversen Servern (große Unternehmen, Banken, etc.) interviewed haben. Profil hat versprochen, die Namen der Interviewten nicht preiszugeben.
Fazit des Berichtes: Es passiert jedem Admin irgendwann einmal, und wenn ein Server kompromittiert wird, dann erfährt das niemand ausser denjenigen die es wissen müssen um den Schaden zu beheben. Es erfährt also meistens nicht einmal der jeweilige Boss der Firma (vor ALLEM der nicht, denn in seiner Unwissenheit würde er die einzigen Leute die das Problem verringern können entlassen).
Ich rechne damit, dass Debian keine schlechtere oder bessere Sicherheit hat als sonst ein Projekt. Man kann eher davon ausgehen, dass alle anderen (inklusive IBM, Redhat, Microsoft) ähnlich oft kompromittiert werden, nur dieses eben nicht an die große Glocke hängen.
Es erfährt also meistens nicht einmal der jeweilige Boss der Firma (vor ALLEM der nicht, denn in seiner Unwissenheit würde er die einzigen Leute die das Problem verringern können entlassen).
Hehe. Leider oft genug die erste Reaktion: Köpfe müssen rollen. Vernünftiger wäre der Ansatz, "Schert euch nicht um Verantwortung, löst das Problem". Aber das wirkt nicht so macher-mäßig, schätze ich.
Von Windows Kernel Hacker am Do, 7. September 2006 um 14:01 #
war es nicht schon beim letzten einbruch so, dass eine bereits gepatchte lücke genutzt wurde? ich würde dann mal empfehlen, dem admin eins auf die finger zu geben, und nicht den debian usern. zudem hat ja wohl php gefrickel nichts in professionellen anwendungen zu suchen.
Allso irgendwie scheint Untergegangen zu sein, daß 1. Angemeldete Nutzer auch die Erlaubnis haben php als Scriptsprache für ihre Internetseiten zu benutzen. 2. Die Einschränkunen Für PHP so gewählt waren, daß die gröstmögliche Sicherheit bei weitestgehender Kompatobilität zu den PHP-Scripten gegeben war. 3. Vom Debian-Paketmanagement unabhängig Software auf PHP-Basis installiert wurde. 4. Diese Software nicht mehr aktiv von den Installierern genutzt wurde.
Daraus Ergab sich das Problem, daß die Serveradministratorn nicht wußen, daß die Software installiert war und darum nicht aktuelle halten konnten. Die Software (speziell PHP) hatte relativ weitreichende Rechte (ist nötig um aus dem CVS lesen, oder auf das Bugtracking-System zugreifen zu können) Und das schlimmste war, daß die Software zwar noch akiv aber nicht mehr in Gebrauch war, es gab allso keinen, dem der Einbruch hätte auffallen können.
Nun Frage ich die hier, die sich scheinbar enorm gut mit Serveradminitration auskennen. Was hättet ihr denn bitte getan, um das zu verhindern? PHP verbieten? Geht nicht, da es "gebraucht" wird. PHP-Rechte einschränken? Geht nicht, da sonst viel Software nicht mehr laufen würde. Chrootumgebungen für alle Nutzer? geht auch nicht, da der dabei sehr viel Overhead Produziert wird und das den Server stark belastet, zudem wird das System darurch enorm komplex und schwer zu administrieren. Selbst feiner granulierbare Rechte hätte nicht viel geholfen, da die Rechte immer für den Einbruch gereicht hätten, zwangsweise, um die gewünschte Funktionalität zu ermöglichen.
Zu Punkt 3, sowas macht man allenfalls zuhause auf seinem Spielzeugrechner, im professionellen Umfeld erstellt man eben ein deb oder rpm oder ebuild, ein Admin sollte sowas innerhalb kurzer Zeit auf die Reihe bekommen. Also liegt hier schon der erste Murx vor. In keiner der Firmen in denen ich bisher war, gab es sowas, das mal schnelle manuell eine Software installiert wird. Bei einer Firma beispielsweise gabs Zentral auch eine Liste mit installierten Paketen, so dass nicht nur der Admin, der in die eine Colo betreut wusste welche Pakete auf irgendeinem Rechner sind sondern Global nachgeguckt werden konnte welcher Rechner welchen Softarestand hat und die Liste wurde automatisch vom Paketmanegement aktualisiert. Jede Software und sei es eigene Perlscripte , PHP und Configsfiles wurden da als Pakete gebaut und nur über das Paketmanagement eingespielt und zwar von dem Admin der für den jeweiligen Rechner verantwortlich war.
Zu Punkt 4, was heißt da Installierern, darf da jeder ein bisschen ruminstallieren oder gibts da eine Person, die weis was auf dem Rechner läuft, bzw Software installieren darf.
Also wenn du jetzt immer noch was nun fragst, dann weis ich nicht?
Sind da wirklich Hobbyadmins bei Debian oder Leute die das auch in der Praxis machen? Wenn die das wirklich in der Praxis auch so handhaben, möchte ich nicht deren Kunde sein. Hier fehlt es ganz klar an den Grundlagen.
Wir sprechen hier von einem Umfeld das dem Webhosting-Betrieb ähnlich ist, Kundenwebs werden auch nicht aus RPMs installiert
Vielmehr ergibt sich hier das Problem der PHP/Apache Konfiguration: Zu restriktiv - nichts geht mehr. Zu offen - es geht leider auch so mancher Hack. Machst du es so restriktiv wie der 0815-Massenwebhoster von nebenan, meckern aber die User, denn es sind ja eigentlich keine Fremden sondern Debian-Entwickler.
Mir scheint manch ein/e Kommentierende/r zu vergessen das die Menschen die hinter den Projekten stehen auch nur Menschen sind. Ich koennte mir vorstellen das da einfach ein Fehler passiert ist. Nicht mehr! Aber wer Fehlerfrei ist, darf Kritik kundtun - mir scheint ferner, viele der Kommentierenden haben noch nie Fehler gemacht, Respekt. Und es waere mir sehr recht, wenn hier mehr der "OpenSource-Gedanke" tragen wuerde.
Der beste Kommentar hier war von "mercantilus"!....nicht ganz
das ist nicht die erste Debianserverkomprimierung.. Kann man das irgendwo als Wortschröpfung des Jahres einreichen?:) Zumindest ist meine Aussage nur halb falsch. "Halb falsch" ist trotzdem falsch. Nunja. Halb daneben ist auch vorbei. Natürlich passt ein komplette Distri in ein "ROM"....Oder was meinst du was eine "CD"-ROM ist? Und schon geht wieder das Gelaber der Freizeit-Ich-Hab-Masse-Ahnung-Haus-Und-Hof-Frickel los. bevor wir aber die Frage der Verantwortung klären, muss erstmal die Zuständigkeit geklärt sein LOL
Von Windows Kernel Hacker am Fr, 8. September 2006 um 23:48 #
ich kritisiere nicht, dass jemand in den server eingebrochen ist, sowas kommt vor. ich will nicht wissen, wie netzwerkadmins bei microsoft ständig am virensäubern sind...
nur wie eingebrochen wurde, nämlich mit hilfe einer längst gepatchten lücke, welche durch ein scriptkiddie ausgenutzt wurde, das ist das letzte. und es war ja nicht das erste mal. auf den debian systemen sind wichtige daten, z.b. debian pakete cvs server und weiss der geier, sowas sollte man ordentlich administrieren.
mod-chroot
Und dann evt. noch Safe-Mode
Und schon ist die Kiste viiiel sicherer, auch wenn irgend eine PHP App ein Security Leck haben sollte.
Nee, ich will nicht provozieren.
Aber schon seltsam, dass die Server die sicher von LinuxGurus aufgesetzt und gepflegt werden kompromittiert werden.
Da siehts für OttoNormal Linux Home Server User sicher düster aus
Hatt vor einigen Jahren auch mak vergessen meine sshd zu updaten und schon hatte die halbe Welt Root Zugriff.
2 Ports sind nach aussen offen:
ssh
http
ssh: dafür gibts fail2ban, und regelämssige updates, root ist im übrigen auch gleich disabled, dann per gpg key login, etc...
http: mod-security (hätte wohl bei diesem "hack" schon geholfen), mod-chroot
php: safe-mode
Alles erhältlich unter Debian !
Man _kann_ Debian einigermassen Sicher konfigurieren (wobei es 100% Sicherheit NIE gibt), aber dazu müsste man halt mehr machen als ein einfaches "apt-get install php4 apache mysql"
gibt aber noch andere
google nach 'ssh authorized keys howto sshd_config debian'
fs
Da lob ich mir die Seriosität von RedHat. Aber seit ich 98 mit Linux beruflich zu tun hab, kam von Debian ja noch nie viel schlaues... Typische Lamer Distro für alle die Privat gerne was basteln.
Der Fehler liegt am Wiki und NICHT an GNU/Debian!!!
Aber wer weiss, vielleicht war der Angreifer ja schon vor dem patchen da...
Gerade das so auf Sicherheit bedachte Debian oatzt mir hier zu oft.
Schon aus Eigeninteresse sollte man sich beim betreiben der eigenen Server mehr Mühe geben.
Wer setzt in kritischen Umgebungen schon eine Distribution ein die nichtmal der "Hersteller" sicher betreiben kann.
> ausgeliferten Software verantwortlich.
Nur gut, das PmWiki nicht mit Debian ausgeliefert wird.
Es ist wohl kein Fehler des Distributors, wenn in der
Zusatzsoftware eine Sicherheitslücke ist, und diese
nicht gestopft wird.
Es steht aber schon in dem Artikel, das die Software
ein Fremdpakete ist.
Debian ist auf dem Server das beste was es gibt.
Der Hobbyadmin bist eher DU?
Sorry, aber das musste mal sein!
Und vor allem, sollen zumindest die Admins Securitynews lesen und entsprechend handeln: http://www.securityfocus.com/bid/16421/ ( Bug ist seit Januar bekannt!!!)
Gruß
BQ
Was ist eine Debian-Komprimierung?
> ann kappieren die endlich, dass standard Linuxsicherheit heutzutage unzureichend ist..
wann kapppieren die Leute endlich, dass es ein Fehler im Wiki war?
>Was ist eine Debian-Komprimierung?
Er hat Kompromittierung gemeint. Außerdem hast Du durch das Weglassen des Worts "Server" denn Sinn der Aussage verändert, was insgesamt auf schlechten Stil hinweist.
>wann kapppieren die Leute endlich, dass es ein Fehler im Wiki war?
Lesen und verstehen musst Du noch etwas üben. Es ging hier darum, dass es zwar ein (lange bekannter aber ungepatchter) Fehler in der Anwendung war, dass man jedoch bei entsprechener Konfiguration des Systems solche Sicherheitsprobleme weitestgehend minimieren kann. Nur leider ist dies standardmäßig bei den meisten Distributionen nicht so voreingestellt.
>
Schön, wenn man solche Ausreden findet...
Der oder die Angreifer haben einen bereits im Januar dieses Jahres gefundenen Fehler des Wiki-Systems ausgenutzt
Januar - heute haben wir September... Ich weiß nicht, wie lange man zum Patchen braucht, aber Monate erscheinen mir eindeutig zu lange.
Wieso, wann ist der Patch denn ERSCHIENEN?
bei der Aussage musste ich erst wirklich lachen^^ was sagst du dann zu windows?^^
Kann man das irgendwo als Wortschröpfung des Jahres einreichen?
Wer sagt denn, dass bei Novell/RedHat/usw. keine Einbrüche gelingen? Kommerzielle Linux-Distributoren wollen verkaufen, vor allem mit Hilfe des Arguments Sicherheit. Die werden den Teufel tun und gelungene Einbrüche veröffentlichen.
Grüße,
filthgrinder
Ein Hacker ist eine Person, die Lücken im System ausnutzt um ein System zu zu seinem eigenen Nutzen zu mißbrauchen oder Daten zu entwenden.
Öh.. sonst wollte ich nichts
Mir war nur gerade langweileig
Schönen Tag noch
So war jedenfalls mal die Definition.
Diese Lektuere duerfte dein Verstaendnis fuer die Begriffe etwas verbessern.
Wobei selbst in diesem Artikel zu erkennen ist, dass es beide Definitionen in der Kultur gibt. Die eine, wie ich sie (vielleicht fälschlicherweise) dachte und die andere, wie sie ursprünglich mal angedacht war.
Zumindest ist meine Aussage nur halb falsch. Ein Cracker ist (zumindest "auch") eine Person die Kopierschütze umgeht
Gruß
"Halb falsch" ist trotzdem falsch.
Ein Cracker bezeichnet sowohl jemanden, der kompilierten Softwarecode manipuliert, als auch einen destruktiven Hacker. Und es gibt dann noch die Kekse, die auch als Cracker bezeichnet werden. Bis auf die Kekse handelt es sich also um Personen, die illegale/halblegale Handlungen vollziehen.
Ein Hacker hingegen ist ein sehr fortgeschrittener Computerbenutzer, der sein Wissen jedoch nicht destruktiv einsetzt und sich somit vom Cracker abgrenzt.
Zu den guten alten C64-Zeiten waren Programme so direkt zugänglich und sicher vor jeder Manipulation.
So, das wars.
Knoppix läuft wunderbar von einem ROM
*blubb*
wenn ein ROM nicht reicht, dann nimm halt zwei oder noch mehr. Das geht wie mit Arbeitsspeicher, da darf man ruhig mehr verwenden. Tatsächlich gibt es Betriebssystem im ROM (z.b EPROM oder E2PROM) noch immer bei technischen Maschinen etc. Wenn das ROM zu teuer ist geht es auch mit CD-ROM beziehungsweise DVD (letztere liest sich erheblich schneller und ist daher zu bevorzugen).
Wenn man sieht, dass die Monate lang keine Updates einspielen, dann sind die einfach überfordert faul oder wissen gar nicht mehr was auf ihren Kisten läuft. Von daher bin ich der Meinung, dass es einfach am grunsätzlichen Design ihrer Infrastruktur hapert und das ist definitiv deren Schuld.
Bei den meisten Firmen, bei denen ich bisher gearbeitet habe liefen maximal 2 Anwendungen Dienste auf einem Frontline Server.
Es sagt ja niemand was gegen nen Konfigurationsfehler etc, sowas kann passieren, aber bei Debian passieren immer wieder die gleichen Fehler -> ewig lang keine Patches einspielen. Server die alles erledigen ->eierlegende Wollmilchsau
Wieso muss auf nem Infrastruktur Server, der CVS etc hat auch noch BugTracker, Wiki etc laufen, das ist doch irrsinnig.
Entweder sie haben zu wenig Maschinen um so Komponenten zu trennen oder sie wissen es nicht besser. So ein fetter Rechner ist auch schwierig zu warten.
Und permanent sind auf Debian frontline Servern Pakete mit Lücken vorhanden die lange nicht gepatcht werden.
Bei ner normalen Firma könnte der Admin jetzt Rechner putzen.
Man kann hier Linux und PmWiki nicht die Schuld in die Schuhe schieben. Es ist einfach nur traurig, dass in der Öffentlichkeit der Eindruck entstehen könnte Linux sei unsicher, nur weil hier widerholt ein paar Dilentanten am Werk sind.
Fazit des Berichtes: Es passiert jedem Admin irgendwann einmal, und wenn ein Server kompromittiert wird, dann erfährt das niemand ausser denjenigen die es wissen müssen um den Schaden zu beheben. Es erfährt also meistens nicht einmal der jeweilige Boss der Firma (vor ALLEM der nicht, denn in seiner Unwissenheit würde er die einzigen Leute die das Problem verringern können entlassen).
Ich rechne damit, dass Debian keine schlechtere oder bessere Sicherheit hat als sonst ein Projekt. Man kann eher davon ausgehen, dass alle anderen (inklusive IBM, Redhat, Microsoft) ähnlich oft kompromittiert werden, nur dieses eben nicht an die große Glocke hängen.
Hehe. Leider oft genug die erste Reaktion: Köpfe müssen rollen. Vernünftiger wäre der Ansatz, "Schert euch nicht um Verantwortung, löst das Problem". Aber das wirkt nicht so macher-mäßig, schätze ich.
Küss die Hand
Schöne Flache, Spitze und Eckige...
Steine? Will jemand Steine?
...die liegen super in der Hand!
zudem hat ja wohl php gefrickel nichts in professionellen anwendungen zu suchen.
Genau mein Reden !!111
Und wenn dazu noch ein professionelles Windowssystem genommen wird ist es praktisch invulnerable 1111
ein effektiv arbeitender FirmenAdministrator unter Windows
is denn schon freitag ? ^^
ich nutze gerne linux aber php ist wirklich dreck im vergleich dazu.
#PHP defenses
SecFilterSelective ARGS_NAMES "^(globals($|\[)|php:/)"
Mein Webserver meldet mal den 500InternalError, wenn ich ihm an ein PHP den "?GLOBALS&GLOBALS[FarmD]=http://www.example.com" anhänge.
Drum (auch wenn ich mich wiederhole): Schafft für den alioth nen Servadmin ran, der den Namen auch verdient...
1. Angemeldete Nutzer auch die Erlaubnis haben php als Scriptsprache für ihre Internetseiten zu benutzen.
2. Die Einschränkunen Für PHP so gewählt waren, daß die gröstmögliche Sicherheit bei weitestgehender Kompatobilität zu den PHP-Scripten gegeben war.
3. Vom Debian-Paketmanagement unabhängig Software auf PHP-Basis installiert wurde.
4. Diese Software nicht mehr aktiv von den Installierern genutzt wurde.
Daraus Ergab sich das Problem, daß die Serveradministratorn nicht wußen, daß die Software installiert war und darum nicht aktuelle halten konnten.
Die Software (speziell PHP) hatte relativ weitreichende Rechte (ist nötig um aus dem CVS lesen, oder auf das Bugtracking-System zugreifen zu können)
Und das schlimmste war, daß die Software zwar noch akiv aber nicht mehr in Gebrauch war, es gab allso keinen, dem der Einbruch hätte auffallen können.
Nun Frage ich die hier, die sich scheinbar enorm gut mit Serveradminitration auskennen. Was hättet ihr denn bitte getan, um das zu verhindern?
PHP verbieten? Geht nicht, da es "gebraucht" wird.
PHP-Rechte einschränken? Geht nicht, da sonst viel Software nicht mehr laufen würde.
Chrootumgebungen für alle Nutzer? geht auch nicht, da der dabei sehr viel Overhead Produziert wird und das den Server stark belastet, zudem wird das System darurch enorm komplex und schwer zu administrieren.
Selbst feiner granulierbare Rechte hätte nicht viel geholfen, da die Rechte immer für den Einbruch gereicht hätten, zwangsweise, um die gewünschte Funktionalität zu ermöglichen.
Allso was nun?
also feuern und neuen admin her.
In keiner der Firmen in denen ich bisher war, gab es sowas, das mal schnelle manuell eine Software installiert wird.
Bei einer Firma beispielsweise gabs Zentral auch eine Liste mit installierten Paketen, so dass nicht nur der Admin, der in die eine Colo betreut wusste welche Pakete auf irgendeinem Rechner sind sondern Global nachgeguckt werden konnte welcher Rechner welchen Softarestand hat und die Liste wurde automatisch vom Paketmanegement aktualisiert. Jede Software und sei es eigene Perlscripte , PHP und Configsfiles wurden da als Pakete gebaut und nur über das Paketmanagement eingespielt und zwar von dem Admin der für den jeweiligen Rechner verantwortlich war.
Zu Punkt 4, was heißt da Installierern, darf da jeder ein bisschen ruminstallieren oder gibts da eine Person, die weis was auf dem Rechner läuft, bzw Software installieren darf.
Also wenn du jetzt immer noch was nun fragst, dann weis ich nicht?
Sind da wirklich Hobbyadmins bei Debian oder Leute die das auch in der Praxis machen?
Wenn die das wirklich in der Praxis auch so handhaben, möchte ich nicht deren Kunde sein.
Hier fehlt es ganz klar an den Grundlagen.
Vielmehr ergibt sich hier das Problem der PHP/Apache Konfiguration: Zu restriktiv - nichts geht mehr. Zu offen - es geht leider auch so mancher Hack. Machst du es so restriktiv wie der 0815-Massenwebhoster von nebenan, meckern aber die User, denn es sind ja eigentlich keine Fremden sondern Debian-Entwickler.
hinter den Projekten stehen auch nur Menschen sind.
Ich koennte mir vorstellen das da einfach ein Fehler passiert ist.
Nicht mehr!
Aber wer Fehlerfrei ist, darf Kritik kundtun - mir scheint ferner,
viele der Kommentierenden haben noch nie Fehler gemacht, Respekt.
Und es waere mir sehr recht, wenn hier mehr der "OpenSource-Gedanke" tragen wuerde.
Der beste Kommentar hier war von "mercantilus"!
PS: Bitte recht freundlich *blitz*
:-P
das ist nicht die erste Debianserverkomprimierung..
Kann man das irgendwo als Wortschröpfung des Jahres einreichen?:)
Zumindest ist meine Aussage nur halb falsch.
"Halb falsch" ist trotzdem falsch.
Nunja. Halb daneben ist auch vorbei.
Natürlich passt ein komplette Distri in ein "ROM"....Oder was meinst du was eine "CD"-ROM ist?
Und schon geht wieder das Gelaber der Freizeit-Ich-Hab-Masse-Ahnung-Haus-Und-Hof-Frickel los.
bevor wir aber die Frage der Verantwortung klären, muss erstmal die Zuständigkeit geklärt sein
LOL
nur wie eingebrochen wurde, nämlich mit hilfe einer längst gepatchten lücke, welche durch ein scriptkiddie ausgenutzt wurde, das ist das letzte. und es war ja nicht das erste mal. auf den debian systemen sind wichtige daten, z.b. debian pakete cvs server und weiss der geier, sowas sollte man ordentlich administrieren.