Komischer offener Port?

[obsolete]

*puh* da hab ich ja einiges zu beantworten..

Nein. Ein kompromitierter Rechner muss IMMER neu installiert werden..

deine meinung... kann man meines erachtens so nicht pauschalisieren. wenn ich mir sicher bin, das der angreifer nicht weit gekommen ist, (sei es auf grund der lücke oder eben dann vom system allgemein) sehe ich keinen grund neu auf zu setzten. die gegebenen umständen (wie jetzt schon so oft erwähnt / www-data / ftp installiert / nicht versteckt) stärken meine haltung.

Du willst also sagen, nur ein weil ein Anfänger das könnte, muss es auch ein Anfänger gewesen sein.

hab ich das? wo, zeig mir die stelle auf? ich habe jediglich gesagt das die lücke public war, exploits auch, und jeder linux anfänger damit eine box aufmachen hätte können. (wer lesen kann ist im vorteil).
ich denke, wäre der angreifer ein experte gewesen, hätte er den ftpd gar nie gefunden.

Zum Glück bist du das nicht.

unüberlegt, unqualifiziert, uninteressant. persönliche angriffe bringen dich in deiner stellung nicht weiter, bleib sachlich.

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

Daraus darf man aber nicht schliessen, dass der Angreifer ein "Kiddie" war

das es ein kiddie war ist natürlich nur eine annahme. wer kann das nun schon wirklich sagen? ich meine nur: wäre der angreifer versiert genung gewesen, würde der ftpd nie gefunden worden. jedoch: die gegeben umstände festigen mich in meiner haltung, dass es sich um einen nicht wirklich "erfahrenen" hacker handelte.

sondern im Gegenteil, dass er BESSER als der SysAdmin war.

kann man so meiner meinung auch nicht sagen. ist das scriptkid, dass von k-otik einen exploit lädt, mein phpbb rooted, und dann gerade mal in /tmp es schafft mit www-data einen ftpd zu starten BESSER als ich, nur weil ich mal ein wochenende nicht daheim war, oder mal keine zeit hatte mich um meine software zu kümmern? gerade bei solch bekannten lücken, die natürlich hauptsächlich von kids ausgenutzt werden, trifft das meiner ansicht nach nicht zu...

Nettes Beispiel: Ich wäre Hoster von 10 Kunden. EINER hat ein unsicheres Script, und
dadurch wird einem Angreifer ermöglicht alle Sourcen der anderen Kunden zu lesen. Und
evtl. die DBs auszulesen. Was soll ich machen?

eben hier gibt es natürlich überhaupt gar keine andere möglchkeit, als die kiste neu auf zu setzten und die kunden zu informieren. aber das sind natürlich auch ganz andere umstände, ich sage ja nicht generell nein zur neuinstallation. ich meine nur, man muss abwägen. eine neuinstallation zu pauschalisieren ist meines erachtens "die mitläuferische meinung vieler". ist ja auch ganz easy hin zu schreiben, "setz den server neu auf, eine andere möglichkeit gibt es nicht". ich meine jedoch, die problematik liegt tiefer / man sollte aus den umständen heraus abwägen was zu tun ist.

Hast du mal geschaut, was für Posts ich so schreibe? (Jetzt profilier ich mich mal: Hast du mal in der FAQ geschaut unter "Was tun wenn server gehackt?")

nein, ich schaue mir nicht jedes posting anderer leute an...

Dass der "Besitzer" keine Ahnung hatte, ist zweitrangig. Er IST Verantwortlich.

sehe ich auch nicht zwangsläufig so. die schuld liegt meines erachtens ganz klar beim angreifer (außer bei stark fahrlässigem verhalten des admins), denn er (der hacker) ist die person die schaden zufügt. ich soll also schuld sein, für schäden die durch löchrige php software für die es vielleicht noch nicht einmal advisories geschweige denn patches gibt? no way.....

Als "root" ist man für seine Kiste verantwortlich.

sehe ich auch so, aber nur dann wenn man fahrlässig handelt.

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

Wenn er durch erneutes konfigurieren noch lernt und nicht einschläft sollte er den Server kündigen

schläfst du beim serverkonfigurieren ein? oder bist du so ein nolife mensch, der schon alle ./configure parameter auswendig weis? ich meine
man hat hier auf jeden fall einen lerneffekt, nämlich gerade nach so einem vorfall sollte man alle optionen zwei mal checken.

der Admin hat gepennt/seinen Meister auf die unsanfte Art gefunden.

wenn ich das höre... meinst du der grsec admin, oder der ccc mensch hat damals gepennt? manchmal hast du keine chance. und ein kidi das von dem freund des freundes vom besten freund nen 0day kriegt soll dann dein meister sein? errr. don't think so.

Ein Nick macht Programm *scnr*

auch dir sage ich: lass die unqualifizierten beiträge, bringt weder dir noch der thematik was.

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

alles in allem muss das problem meiner meinung nach viel differenzierter betrachtet werden. die sture "neu-auf-setz" masche ist zu borniert.

schlussendlich bleibt mir nur zu sagen: jeder muss natürlich selber wissen was er tut. ich jedenfalls, werde je nach situation entscheiden. eine pauschale neuinstallation halte ich für unsinn.

obsolete

[oxygen]

Du willst also sagen, nur ein weil ein Anfänger das könnte, muss es auch ein Anfänger gewesen sein.

hab ich das? wo, zeig mir die stelle auf? ich habe jediglich gesagt das die lücke public war, exploits auch, und jeder linux anfänger damit eine box aufmachen hätte können. (wer lesen kann ist im vorteil).
ich denke, wäre der angreifer ein experte gewesen, hätte er den ftpd gar nie gefunden.

Vielleicht sollte der ftpd gefunden werden um von einer anderen Veränderung ablenken, also ein Art Honeypot? Das es so ist, klingt jetzt vielleicht eher unwahrscheinlich, aber eben nicht unmöglich.

das es ein kiddie war ist natürlich nur eine annahme. wer kann das nun schon wirklich sagen? ich meine nur: wäre der angreifer versiert genung gewesen, würde der ftpd nie gefunden worden. jedoch: die gegeben umstände festigen mich in meiner haltung, dass es sich um einen nicht wirklich "erfahrenen" hacker handelte.

s.o.

Dass der "Besitzer" keine Ahnung hatte, ist zweitrangig. Er IST Verantwortlich.

sehe ich auch nicht zwangsläufig so. die schuld liegt meines erachtens ganz klar beim angreifer (außer bei stark fahrlässigem verhalten des admins), denn er (der hacker) ist die person die schaden zufügt. ich soll also schuld sein, für schäden die durch löchrige php software für die es vielleicht noch nicht einmal advisories geschweige denn patches gibt? no way.....

Dann sollte man keiner löchrige php software einsetzten. Oder anderweitig für Sicherheit sorgen. Wenn ich nicht sicher bin, dass mein Auto sicher ist, fahre ich auch nicht damit rum und gebe dem Hersteller/Händler/Straßenbauamt/etc die Schuld wenn etwas passiert.
Natürlich ist in erster Linie der Hacker Schuld, aber erklär das mal deinen Kunden. Es ist nunmal so, Gelegenheit macht Diebe... oder was machst du, wenn der Hacker z.B. ein Wurm ist?

alles in allem muss das problem meiner meinung nach viel differenzierter betrachtet werden. die sture "neu-auf-setz" masche ist zu borniert.

schlussendlich bleibt mir nur zu sagen: jeder muss natürlich selber wissen was er tut. ich jedenfalls, werde je nach situation entscheiden. eine pauschale neuinstallation halte ich für unsinn.

Musst du wissen. Aber es steht nicht umsonst auf Seite 1 von jedem besseren Buch, dass sich mit IT-Security beschäftigt.

[outofbound]

ich denke, wäre der angreifer ein experte gewesen, hätte er den ftpd gar nie gefunden.

Oder er sollte gefunden werden.

das es ein kiddie war ist natürlich nur eine annahme. wer kann das nun schon wirklich sagen? ich meine nur: wäre der angreifer versiert genung gewesen, würde der ftpd nie gefunden worden. jedoch: die gegeben umstände festigen mich in meiner haltung, dass es sich um einen nicht wirklich "erfahrenen" hacker handelte.

Und alleine durch diese Haltung, hättest du beim "versierten" Angreifer genau das getan, was er von dir erwartet hätte.

Dass der "Besitzer" keine Ahnung hatte, ist zweitrangig. Er IST Verantwortlich.

sehe ich auch nicht zwangsläufig so. die schuld liegt meines erachtens ganz klar beim angreifer
(außer bei stark fahrlässigem verhalten des admins), denn er (der hacker) ist die person die schaden zufügt. ich soll also schuld sein, für schäden die durch löchrige php software für die es vielleicht noch nicht einmal advisories geschweige denn patches gibt? no way.....

Doch, nämlich dann, wenn du dein System nicht nach entsprechenden Regeln der Technik
aufgesetzt hast. Spätestens dann kann und wird dir eine Mitschuld zugesprochen werden.
Das ist nur eine Frage von ein paar Gutachten.
Zum Glück sehen Staatsanwälte und Richter das anders.
Angriff kommt von Rechner X. Dessen Besitzer ist verantwortlich. Wenn er nicht
beweisen kann, dass es jemand anderes war, werden alle Indizien auf ihn als
Täter hinweisen, und somit kommt es auch zu einem Urteil.

alles in allem muss das problem meiner meinung nach viel differenzierter betrachtet werden. die sture "neu-auf-setz" masche ist zu borniert.

Seit über 20 Jahren werden Rechner administriert, und seit über 20 Jahren wird genau
das gepredigt. Nenn mir einen Grund, warum man das nicht so machen sollte? Mit
einer guten Backupstrategie dürfte der ReInit < 2 Stunden dauern. Wenn du so viel Ahnung
hast, dass du darauf verzichten kannst, dann tu das. Aber eines sollte dir klar sein: Die
meisten Leute, denen die Kisten aufgemacht werden (Hier im Forum) haben kaum Ahnung
von der Materie. Und genau solchen Leuten "falsche" Sicherheit zu predigen halte ich
für Gemeingefährlich. Dann sollen Sie lieber mal ne Stunde länger am Reinit sitzen, Schaden
kann es nicht. Wenn solche Leute "Kunden" haben, die ihnen auf den Füssen stehen: UM SO BESSER, vielleicht lernen sie dann mal was.


Oh, vergessen:

kann man so meiner meinung auch nicht sagen. ist das scriptkid, dass von k-otik einen exploit lädt, mein phpbb rooted, und dann gerade mal in /tmp es schafft mit www-data einen ftpd zu starten BESSER als ich, nur weil ich mal ein wochenende nicht daheim war, oder mal keine zeit hatte mich um meine software zu kümmern? gerade bei solch bekannten lücken, die natürlich hauptsächlich von kids ausgenutzt werden, trifft das meiner ansicht nach nicht zu...

Doch, natürlich war er besser als du. Er greift deine Verteidigung an, durchbricht sie und hat ein Tor geschossen. 1:0 für den Angreifer, Schlusspfiff. Fazit: Deine Verteidigung ist Schrott,
und du hast keine Ahnung, was er auf dem Weg zwischen deiner Verteidigung und dem Tor
noch alles für Umwege gemacht hat. Ein einfacher Keylogger reicht doch schon, oder
vielleicht den sshd ausgetauscht, hier oder da noch ein Kernelmodul geladen, hier und dort
ein Binary gepatcht... alles eine Sache von ein paar Minuten...

Denn:
a) Er kann was auf einem Server compilen!
b) Er kann in /tmp was ausführen!
c) Die Portbindings werden nicht gecheckt!
d) Er konnte EINE BEKANNTE!!!!! Lücke ausnutzen, gegen die es Schutzmechanismen gibt.

Ausgehend von der These das man einen Rechner beim Angriff durch versierte Angreifer neu aufsetzen sollte, gilt:
Da du nicht beurteilen kannst, ob der Angreifer ein Kiddie war oder ein Profi der nur wie ein
Kiddie aussehen will, (z.B. um genau diese "Der ftpd wird schon alles gewesen sein") gilt das
Worst Case Scenario: Im Zweifelsfalle wars ein Profi.

Gruss,

Out

[mausgreck]

Seit über 20 Jahren werden Rechner administriert, und seit über 20 Jahren wird genau
das gepredigt. Nenn mir einen Grund, warum man das nicht so machen sollte?

Naja, wenn man das weiterdenkt, dann müsste praktisch *jeder* Rechner regelmäßig neu aufgesetzt werden. Also ich würde mich nicht darauf verlassen, dass der safemode von php verhindert, dass User beliebige Befehle ausführen können. Und wer garantiert mir, dass meine User nicht schlampig mit ihren Passwörtern umgehen?

Die meisten Leute, denen die Kisten aufgemacht werden (Hier im Forum) haben kaum Ahnung
von der Materie.

Das halte ich schon eher für das Problem. Diese Leute sollten eigentlich überhaupt keinen Server betreuen.

Deine Verteidigung ist Schrott,
und du hast keine Ahnung, was er auf dem Weg zwischen deiner Verteidigung und dem Tor
noch alles für Umwege gemacht hat. Ein einfacher Keylogger reicht doch schon, oder
vielleicht den sshd ausgetauscht, hier oder da noch ein Kernelmodul geladen, hier und dort
ein Binary gepatcht... alles eine Sache von ein paar Minuten...

Als httpd-User? Also ein System auf dem der httpd-User eines von diesen Dingen machen kann ist wirklich schrottreif. Schrottreifer als ein System mit einer alten awstats-Version. Auf jeden Fall ist ein "find / -user httpd" und ein Check der Kernelversion fällig.

[Roger Wilco]

Naja, wenn man das weiterdenkt, dann müsste praktisch *jeder* Rechner regelmäßig neu aufgesetzt werden.

Es geht darum, dass die Kiste nach einer entdeckten Kompromittierung neu aufgesetzt werden muss.

Das halte ich schon eher für das Problem. Diese Leute sollten eigentlich überhaupt keinen Server betreuen.

Dito, aber dann heißt es ja gleich wieder, der Umgangston hier wäre zu unfreundlich.

Als httpd-User? Also ein System auf dem der httpd-User eines von diesen Dingen machen kann ist wirklich schrottreif. Schrottreifer als ein System mit einer alten awstats-Version. Auf jeden Fall ist ein "find / -user httpd" und ein Check der Kernelversion fällig.

Du wärst überrascht, auf wievielen dedizierten Servern

a) ein veralteter Kernel läuft
b) keine Trennung von verschiedenen Benutzern und/oder Diensten vorhanden ist
c) anfällige Software läuft, über die man schnell höhere Rechte auf dem System erlangt.

[mc5000]

Ich glaube einer der Kernpunkte ist:

... Mit einer guten Backupstrategie dürfte der ReInit < 2 Stunden dauern...

Da kann ich nur voll und ganz zustimmen, besonders wenn auf der Maschine keine so wichtigen Sachen laufen, dass der Datenverlust einen in Teufelsküche bringt (wo man ja eh schon ist ).

Auf diese Weise hat man die Maschine schneller am laufen, als online nach den Fehlern und Ã?nderungen zu suchen, dass sollte lieber offline auf einer Kopie geschehen - so lernt man trotzdem was und im Netz steht erst mal wieder ein Rooty der einem selbst gehört ( :twisted: ).

Doch "ReInit and Forget" ist ja auch keine Lösung, der Fehler muss gefunden werden, sonst ..... naja, Teufelsküche halt! :o

So long
MC

[chaosad]

Bringt doch nichts die Daten so schnell wie möglich wieder online zu bringen ohne zu Wissen wie der Server übernommen worden ist. Denn was spricht dagegen das derjenige es nicht nochmal versucht?

[mc5000]

Bringt doch nichts die Daten so schnell wie möglich wieder online zu bringen ....

Aber besser eine neu aufgesetzte Machine online, als die gecrackte. Oder?!

[captaincrunch]

Was bringt dir die neu aufgesetzte Kiste, wenn derjenige das alte Loch 5 Minuten, nachdem du das Backup wieder eingespielt, und sie wieder online gebracht hast wieder nutzt?

[mc5000]

Was bringt dir eine gecrackte Maschine von der Du "glaubst" alle offensichtlichen Sicherheitslöcher geschlossen zu haben :?:

Nur zur Ergänzung:

Doch "ReInit and Forget" ist ja auch keine Lösung, der Fehler muss gefunden werden, sonst ..... naja, Teufelsküche halt!

-> Dieser anscheinend unverständliche Hinweis sollte auf die angesprochene Problematik hinweisen. :roll:

Beim besprochenen Fall drehte sich die Diskussion doch um die Frage, ob eine gecrackte Maschine nur notdürftig verarztet oder besser neu aufgesetzt werden sollte. Wenn der primäre Weg ins System (wie angegeben) gefunden wurde, sollte die Maschine doch lieber reinitialisiert werden ...

[tcs]

obsolete Serveradmins sind ein Grund warum ich manchmal meine Kiste einfach nur runterfahren und kündigen will... :roll:

Cheers

tcs

[mausgreck]

Naja, wenn man das weiterdenkt, dann müsste praktisch *jeder* Rechner regelmäßig neu aufgesetzt werden.

Es geht darum, dass die Kiste nach einer entdeckten Kompromittierung neu aufgesetzt werden muss.

Klar. Der Knackpunkt ist halt, was eine Kompromittierung darstellt und was nicht. Aus der hier vorherrschende Meinung, dass erstens gerootede Server nicht zu erkennen sind, und dass zweitens Ausführen von beliebigem Code mit einem unprivilgierten User eine systemgefährdende Kompromittierung darstellt, schließe ich, dass jeder Rechner, auf dem PHP installiert ist, neuinstalliert werden muss. Denn ich würde mich niemals darauf verlassen, dass man mit PHP nicht beliebigen Code ausführen kann.

Die hier vorherrschende Prämisse ist offensichtlich, dass auf einem gut gewarteten System PHP und die üblichen CGIs (awstats, etc...) sicher sind, während man sich auf das Rechtesystem eines Unix-Systems nicht verlassen kann. Ich gehe genau von der umgekehrten Prämisse aus: User können mit PHP oder CGIs kompletten System-Zugriff mit ihrem Unix-User erhalten, aber das System ist so hingetrimmt, dass sie damit nichts anstellen können. (Das heisst jetzt nicht, dass ich es ihnen leicht mache - FTP und sftp sind gechroot()et, PHP läuft im safemode und Upload von CGIs ist verboten.) Das bedeutet natürlich, dass bei allen VHosts SuExec eingeschalten ist, und die User dazu angehalten sind, ihre PHP-Skripts auf 0600 zu setzen und davon auszugehen, dass alle statischen Files von jedermann eingesehen werden können. Wenn sie sich nicht daran halten, und jemand liest ihnen ihr DB-Passwort aus einem PHP-File mit falschen Berechtigungen aus, dann haben sie Pech gehabt. Wenn ein Kunde sein Passwort verschludert und ein Angreifer es schafft über PHP lokale Kommandos ausführen, dann werde ich dem so gut wie möglich auf den Grund gehen, aber sicher nicht aus Prinzip den Rechner neu aufsetzen. Ich schätze diese unterschiedlichen Auffassungen kommen daher, dass ich seit vielen Jahren auf Multiuser-Unixen arbeite, aber erst seit kurzem PHP-Hosting mache, aber die meisten Leute hier wahrscheinlich mit Webhosting angefangen haben. Unterschiedliche Perspektiven halt.

Mir kommt das so vor, als ob das Neuinstallieren in diesem Fall wie eine art Strafe für schlechte Systemadministration gehandhabt wird. Und das finde ich schon ein bisschen kindisch.

[outofbound]

Klar. Der Knackpunkt ist halt, was eine Kompromittierung darstellt und was nicht. Aus der hier vorherrschende Meinung, dass erstens gerootede Server nicht zu erkennen sind, und dass zweitens Ausführen von beliebigem Code mit einem unprivilgierten User eine systemgefährdende Kompromittierung darstellt, schließe ich, dass jeder Rechner, auf dem PHP installiert ist, neuinstalliert werden muss. Denn ich würde mich niemals darauf verlassen, dass man mit PHP nicht beliebigen Code ausführen kann.

Da verstehst du glaube ich einige Leute hier nicht ganz richtig. ;)

Es gibt imho. versch Formen von Kompromitierung.

Die übelste ist nämlich die, in der ich ohne irgendwelche Logs, Vor oder Anzeichen
und völlig überrascht vor die Tatsache gestellt werde, dass ich nicht mehr alleine
auf einem System bin, auf dem ich es eigentlich sein sollte. (Worst Case, würde ich
mal sagen). Ich kann in keiner Form irgendwie zurückverfolgen, was wann wie passiert
ist. Dann kann ich mich nicht mehr drauf verlassen, dass das System noch sicher ist.

Die hier vorherrschende Prämisse ist offensichtlich, dass auf einem gut gewarteten System PHP und die üblichen CGIs (awstats, etc...) sicher sind, während man sich auf das Rechtesystem eines Unix-Systems nicht verlassen kann.

Das eine hat mit dem anderen Nichts zu tun. Ob der Angreifer per SSH und geklauten
Pwd, oder per PHP Lücke auf das System gekommen ist, ist unerheblich. Die Frage ist,
wie weit kann ich nachvollziehen was passiert ist?

Ich gehe genau von der umgekehrten Prämisse aus: User können mit PHP oder CGIs kompletten System-Zugriff mit ihrem Unix-User erhalten, aber das System ist so hingetrimmt, dass sie damit nichts anstellen können.

Ah, und wieviele Rootserver- User machen das?

[... jede Menge technische Umsetungsideen ...]

Wie gesagt, wie viele Rootserver- Owner machen das? ;)

sicher nicht aus Prinzip den Rechner neu aufsetzen. Ich schätze diese unterschiedlichen Auffassungen kommen daher, dass ich seit vielen Jahren auf Multiuser-Unixen arbeite, aber erst seit kurzem PHP-Hosting mache, aber die meisten Leute hier wahrscheinlich mit Webhosting angefangen haben. Unterschiedliche Perspektiven halt.

Nein, auch ich komme aus der Multiuser- Systemwelt... und solche Systeme werden normalerweise auch ordentlich geauditet, Remote geloggt, regelmäßig geprüft, etc.,
d.h. der Zeitraum Angriff <--> Angriff bemerkt ist meist wesentlich kleiner.

Mir kommt das so vor, als ob das Neuinstallieren in diesem Fall wie eine art Strafe für schlechte Systemadministration gehandhabt wird. Und das finde ich schon ein bisschen kindisch.

Na, das würde ich mal nicht behaupten. Mal angenommen ich habe ein System mit mehreren
Usern, dann habe ich doch auch ein Backup oder Standbysystem, das ich mal kurz
"zwischenschalten" kann? Oder ich habe meine Kiste normalerweise "im Griff", d.h. mir
Fallen ungewöhnliche Ports auf, die plötzlich gebunden werden, oder ich habe entsprechende
Sicherheitsmaßnahmen ergriffen, die mir z.B. Manipulationen an Files anzeigen. Dann kann ich ja mit ziemlich großer Sicherheit rausfinden, ob ein System manipuliert wurde oder nicht, und
DANN entscheiden.

Wenn ich solche Maßnahmen aber nicht ergreife, kann ich es nicht entscheiden und muss
mit dem schlimmsten Rechnen. ;)

Gruss,

Out

[obsolete]

Vielleicht sollte der ftpd gefunden werden um von einer anderen Veränderung ablenken, also ein Art Honeypot?

klingt für mich unlogisch. warum sollte der angreifer auf sich aufmerksam machen, wenn er die möglichkeit hat, ganz ungesehen zu operieren.
würdest du beim einbruch in ein haus die tür einschlagen wenn du den tresor auch durchs offene fenster stehlen könntest, nur um damit den anschein zu erwecken nur die tür eingeschlagen zu haben? wohl kaum... sowas rüttelt den admin ja erst richtig wach, und veranlasst ihn zum nachforschen.

Dann sollte man keiner löchrige php software einsetzten. Oder anderweitig für Sicherheit sorgen. Wenn ich nicht sicher bin, dass mein Auto sicher ist, fahre ich auch nicht damit rum und gebe dem Hersteller/Händler/Straßenbauamt/etc die Schuld wenn etwas passiert.

wer setzt denn schon bewusst löchrige software ein? ich meine damit, dass keine software vor lücken gefeit ist und ich wohl auch schlecht schuld sein kann, wenn irgendwelche hacker lücken die bis dato nicht bekannt sind ausnutzen. in meinen augen ist nur dann der admin schuld, wenn er grob fahrlässig handelt (also z.b. nach einer woche immer noch nicht gepatched hat).

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

Und alleine durch diese Haltung, hättest du beim "versierten" Angreifer genau das getan, was er von dir erwartet hätte.

siehe oben. warum aufmerksamkeit erregen, wenns auch ganz ohne geht? natürlich muss der rechner dann einer konsistenter nachüberwachung unterliegen bzw. das system wirklich ausserordentlich auf zusätzliche veränderungen überprüft werden.

Seit über 20 Jahren werden Rechner administriert, und seit über 20 Jahren wird genau
das gepredigt. Nenn mir einen Grund, warum man das nicht so machen sollte? Mit
einer guten Backupstrategie dürfte der ReInit < 2 Stunden dauern.

1. es dürfte hier wohl reichlich wenige user geben die in ordentlichen zeitabständen backups durchführen (wenn überhaupt).

2. wenn ich mir sicher bin, dass keine weiteren veränderungen statt gefunden haben, dann nenn du mir einen grund warum ich den rechner komplett zurücksetzten sollte?!

3. meine haltung gilt nur ganz speziell für diesen fall. damit ich nicht missverstanden werde: natürlich ist ein reinit in vielen fällen der "nachuntersuchung" vor zu ziehen. aber dafür müssen dann auch die "äußeren" umstände passen (backups müssen bereit liegen, der server darf ohne meckern anderer user mal eben geschwind 2 stunden (dann gehts aber schnell) weg sein etc etc)....

Doch, natürlich war er besser als du. Er greift deine Verteidigung an, durchbricht sie und hat ein Tor geschossen. 1:0 für den Angreifer, Schlusspfiff. Fazit: Deine Verteidigung ist Schrott

das mit dem "besser sein als"... kann ich so nicht nachvollziehen. dann ist ja jedes script kid "besser" als admins die schon jahre lang netze administrieren und ausversehen mal vergessen apt-get update aus zu führen... dem kann ich so nicht zustimmen.

Ausgehend von der These das man einen Rechner beim Angriff durch versierte Angreifer neu aufsetzen sollte, gilt:
Da du nicht beurteilen kannst, ob der Angreifer ein Kiddie war oder ein Profi der nur wie ein
Kiddie aussehen will, (z.B. um genau diese "Der ftpd wird schon alles gewesen sein") gilt das
Worst Case Scenario: Im Zweifelsfalle wars ein Profi.

tja, was weiss man schon über den angreifer. ich glaube jedenfalls nicht, dass ein profi einen ftpd installiert, nur um zu sagen, hey hier war ich, und das war alles was ich gemacht habe. warum sollte er dadurch überhaupt erst auf sich aufmerksam machen?!? klingt für mich unlogisch.

auszug aus dem bericht zum einbruch auf debian.org:

After a disk-image was
made via serial console login to a local machine on a firewalled
network connection, the root-kit was removed, the kernel exchanged and
hardened, binaries double-checked and the security archive verified
against several different external sources. This machine will be
re-installed in the next few weeks.

hier wurde, obwohl man hier wirklich davon ausgehen konnte, dass experten am werk waren, vorerst auch nur ein neuer kernel installiert und alle binaries gecheckt... und dass bei einem wirklich ominösen einbruch!!!!!

++ meine ganzen antworten beziehen sich jetzt auch nur auf diesen speziellen fall, es gibt natürlich szenarien wo man gar keine andere wahl hat, als zum backup-tape zu greifen. ++

obsolete

[ticool]

Zum Thema neuinstallieren oder nicht?!

http://www.heise.de/security/artikel/47520

MICROSOFT SAGT ;)

[outofbound]

Du sagst ja selbst, ein fähiger Admin, ein Profi, der Logfiles, Systemchecks, Backups, Systemintegritätstests und Erfahrung hat, KANN evtl. ein System sauber kriegen. Ich schätze mal 99% der User hier können das nicht. Daher ist die Pauschalaussage "Plätten lassen" mit nahezu 100%iger Wahrscheinlichkeit korrekt. Was verliert man denn durchs neuaufsetzen? Eine oder zwei Stunden Zeit? Wenn man "Kunden" auf so einer Kiste hat, wird man doch eine Ausfall- Lösung haben... daher kann man die Kiste in Ruhe offline nehmen, sich Zeit lassen, es besser machen.
Alles in allem: In sehr seltenen Fällen, wirklich sehr seltenen Fällen kann man sich das Plätten sparen. Dann muss man aber mal wirklich wissen, was man tut, und vor allem alle Nötigen Vorkehrungen VORHER getroffen haben. Ich bezweifle, dass es hier im Forum jemanden gibt,
der ein solches System auf einem "Rootserver" produktiv betreibt.

Ich traue mir das bei meinen Kisten ehrlich gesagt nicht zu. Trotz Backupkonzepten, internen und externen Sicherungsmechanismen, und doch einiger Erfahrung würde ich mal behaupten.

Deswegen: Save early, save often + Plätten ist und bleibt die richtige Lösung.

Gruss,

Out