Dos out Attacke

[Joe User]

On-Topic vorweg:
Dem OP wurde seinem Kenntnisstand entsprechend sachgerecht und schnell geholfen (Neuinstallation), ganz so, wie es die (neue) SSF-Philosophie verlangt. Sollte der OP Probleme beim Installieren/Konfigurieren des neuen Systems haben, so empfiehlt sich ein neuer Thread.


Off-Topic:

Offtopic, weil der Thread eh schon wieder abgedriftet ist:

Danke für die teilweise vorherrschende Einsicht.

Jepp, die Posts, welche Deine Meinung gar nicht teilen, hast Du ja fein gelöscht und damit eine künstliche Einsicht erzeugt. So macht man normalerweise Politik, aber so führt man keine Diskussion. Schade, ich hatte gehofft, dass dieses Niveau nicht wieder Einzug hält...

EOD

 

[TerraX]

Und Du kannst garantieren, dass über besagte Lücke ausschliesslich die von Dir aufgeführten Scripte eingeschleust werden?
Gewagte These...

Yepp - der "theoretischen" Frage stimme ich zu. Es gehört schon sehr viel Fachkenntnis dazu, um zu beurteilen, was das Script in der Vergangenheit bereits auf dem Server angerichtet hat.

Alles vor der Prämisse, dass es sich tatsächlich um eine Sicherheitsverletzung handelt. Wie gesagt, es stehen atm auch noch andere Optionen im Raum, über die der TE nichts gesagt hat bisher.

 

[Huschi]

Und Du kannst garantieren, dass über besagte Lücke ausschliesslich die von Dir aufgeführten Scripte eingeschleust werden?

Philosophie mit Praxis verwechselt. Setzen Sechs!

ganz so, wie es die (neue) SSF-Philosophie verlangt

Zwei Fehler: Es ist die Alte (im Sinne von "ursprüngliche") SSF-Philosophie. (Für Dich mag das ja neu sein, ich praktiziere dies seit 10 Jahren.)
Und nein, die SSF-Philosophie "verlangt" dass man dem Newbie hilft die Einbruchs-Lücke zu finden.
Also nochmal: Setzen Sechs!

Jepp, die Posts, welche Deine Meinung gar nicht teilen, hast Du ja fein gelöscht und damit eine künstliche Einsicht erzeugt.

Dein gelöschter Beitrag war lediglich Offtopic-Blabla mit persönlichen Angriffen und damit ein Verstoß gegen die Nutzungsbedingung.
Wegen Uneinsichtigkeit: Setzen Sechs!


On-Topic:

Es gehört schon sehr viel Fachkenntnis dazu, um zu beurteilen, was das Script in der Vergangenheit bereits auf dem Server angerichtet hat.

Mein Ansatz besagt nicht ausschließlich, dass nur das betroffene Web bereinigt werden soll. Sondern dass es wichtig ist die Lücke zu finden um diese im Falle einer Wiederherstellung schließen zu können.
Und wer hier weiter Diskutieren will, sollte genau zu diesem essentiellen Punkt Stellung nehmen: Ist es wichtig die Lücke zu finden oder nicht? Und ist die Lücke auf einem sauberen System zu finden oder auf einem befallenen?

huschi.

 

[infinitnet]

Ich weiß gar nicht, was es hier so viel zu disskutieren gibt. Es ist klar und wurde schon oft erwähnt, dass der infizierte Server sofort vom Netz genommen werden sollte. Der nächste Schritt wäre dann alle Daten zu sichern, die Lücke zu finden (wenn er das selbst nicht kann, jemanden dafür bezahlen), den Server neu aufzusetzen und die Lücke zu schließen. Falls der OP es anders macht, so wurde er oft genug darauf hingewiesen, dass er selbst für Folgeschäden haftbar ist. Ob er ein Risiko eingeht oder nicht, ist seine Entscheidung. Bei so etwas ist es mir wirklich schleierhaft, wie das in ewige OT Diskussionen zwischen Huschi und Joe User ausarten kann. Vielleicht solltet ihr einfach mal zusammen ein Bierchen trinken gehen?

 

[d4f]

Der nächste Schritt wäre dann alle Daten zu sichern, die Lücke zu finden (wenn er das selbst nicht kann, jemanden dafür bezahlen), den Server neu aufzusetzen und die Lücke zu schließen

Das ist ja eben genau der Punkt. Wenn bsp. eine Joomla-Installation verseucht wurde ist es schlichte Zeitverschwendung ein ganzes Server-System neu zu installieren.

Vielleicht solltet ihr einfach mal zusammen ein Bierchen trinken gehen?

Nächstes OT; welches Angebot welcher Brauerei empfehlenswerter ist und welche Bar die beste Diskussionsumgebung bietet

 

[infinitnet]

Das ist ja eben genau der Punkt. Wenn bsp. eine Joomla-Installation verseucht wurde ist es schlichte Zeitverschwendung ein ganzes Server-System neu zu installieren.

Naja, auch wenn's nur eine Joomla!-Installation war, kann es trotzdem möglich sein, dass der Angreifer irgendeine Shell hochgeladen hat, über welche er /etc auslesen konnte, wenn PHP als mod_php lief. Ohne eine entsprechende Analyse kann man das nur erraten. Hier würde die Entscheidung aber wieder beim OP liegen, ob er nun das ganze System neu aufsetzt oder nicht. Ich würde es in jedem Fall empfehlen, andere vielleicht nicht, was auch nicht unbedingt falsch ist, solange das System anständig analysiert wird. Wenn die Meinungen da auseinander gehen, kann man ja ewig disskutieren und zu keinem Ergebnis kommen. Es müsste doch auch möglich sein, dass eben jeder User seine Meinung postet und der OP dann entscheidet was er tut, ohne dass eine ewige Diskussion zwischen den Usern entsteht. Er wurde auf die Haftung hingewiesen, er wurde auf die Risiken hingewiesen, wenn er das System so weiter betreibt und über den Mehraufwand einer Neuinstallation wird er sich auch im Klaren sein (wobei das Überprüfen auf Backdoors fast zeitaufwändiger sein könnte). Also ich finde das sollte so passen, man kann ja nicht immer gleicher Meinung sein. Nur die Meinung von Anderen zu akzeptieren, scheint hier einigen Leuten etwas schwer zu fallen. Ich bin hier noch nicht so lange dabei, aber habe schon zig Topics gesehen, die fast den gleichen Verlauf hatten. Die ersten paar Antworten sind sachlich und danach arten die restlichen 20 Antworten in eine Diskussion zwischen einigen wenigen Usern aus, wobei sich beide Parteien drauf versteifen, dass ihre Ansicht die richtige ist und keine andere in Frage kommt.

Nächstes OT; welches Angebot welcher Brauerei empfehlenswerter ist und welche Bar die beste Diskussionsumgebung bietet

Stimmt, ich seh's schon kommen!

 

[d4f]

dass der Angreifer irgendeine Shell hochgeladen hat, über welche er /etc auslesen konnte, wenn PHP als mod_php lief.

Die Relation musst du mir erklären. Auch andere PHP-Wrapper können, vorausgesetzt Dateirechte, open_basedir und Funktion-Blacklist erlauben es, auf alle Dateien zugreifen und Programme ausführen.

Wie das Auslesen von /etc aber überhaupt ein Sicherheitsloch darstellt ist mir unklar. Standardmässig sind alle relevanten Dateien einem nicht-priviligierten Account, wie www-data, nicht zugreifbar unter anderem die (eh verschlüsselte) /etc/shadow oder bsp /etc/mysql/debian.cnf. Ich gehe mal davon aus dass ein ähnlich peinlicher faux-pas wie 2011 bei Hetzner's Webhostings nicht vorhanden ist.

 

[infinitnet]

Die Relation musst du mir erklären. Auch andere PHP-Wrapper können, vorausgesetzt Dateirechte, open_basedir und Funktion-Blacklist erlauben es, auf alle Dateien zugreifen und Programme ausführen.

Wie das Auslesen von /etc aber überhaupt ein Sicherheitsloch darstellt ist mir unklar. Standardmässig sind alle relevanten Dateien einem nicht-priviligierten Account, wie www-data, nicht zugreifbar unter anderem die (eh verschlüsselte) /etc/shadow oder bsp /etc/mysql/debian.cnf.

Das war nur ein Beispiel, da man eben nicht weiß, wie der OP seinen (Web)Server konfiguriert hat, unter welchem User der Apache läuft, usw. Ich hab's schon mehr als ein Mal erlebt, dass es auf einem System dem Apache User möglich war, alle möglichen Dateien auszulesen, wenn das System von jemandem ohne Wissen konfiguriert wurde. Hat natürlich nicht zwangsweise etwas mit dem PHP-Wrapper zu tun. Da wir keinerlei Infos über das System oder das Wissen des OP haben, kann man es auch schlecht ausschließen, dass Apache unter einem privligierten User lief, open_basedir deaktiviert oder shellexec aktiviert war, usw.

 

[Joe User]

Aktueller Real-World-Vergleich:
Wenn die NYT nach Huschis Empfehlungen vorgegangen wäre, würden in deren Netzwerk noch immer 44 Malwares ihr Unwesen treiben und keine Lücke wäre gestopft.
Da die NYT aber nach meiner Empfehlung, nämlich dem seit Jahrzehnten gültigen Best-Practise, vorging, ist deren Netzwerk nun sauber und die Lücken sind gestopft.

Was nun eher zu empfehlen ist, darf der geneigte Leser selbst entscheiden.


@Huschi:
[X] Du hast Nichts von dem was ich schrieb verstanden.
Analysen macht man offline per Image und nicht online per Glaskugel.
Und ja, eine Reinitialisierung ist immer Pflicht, egal wie harmlos der Einbruch war.
Man lässt schliesslich auch aufgehebelte Türen nach einem Wohnungseinbruch vollständig auswechseln, statt sie mit MDF-Platten zu fixen.
Und selbstverständlich erfolgen die Analysen bevor das neue System online geht, eben um die Lücke nicht wieder unbewusst zu öffnen.

So und nun darf sich darf sich der Huschi in die letzte Reihe setzen und das Schuljahr wiederholen. Die Aufzählung seiner einzelnen Sechsen erspare ich dem Rest der Leser...



BTW: Ja, auch die anderen erwähnten "harmlosen" Attacken untersucht man offline im Image, nicht online.

 

[d4f]

Analysen macht man offline per Image und nicht online per Glaskugel.
Und ja, eine Reinitialisierung ist immer Pflicht, egal wie harmlos der Einbruch war.

Huschi's Beispiel ging von einer Kompromittierung des Webspaces aus. Willst du also sagen dass Strato die ganze Serverfarm runter fährt, mit einem neuen Image bespielt und alle Kundendaten aus Backups wiederherstellt weil die FTP-Daten eines Kunden entwendet wurden?

Da die NYT aber nach meiner Empfehlung, nämlich dem seit Jahrzehnten gültigen Best-Practise, vorging

Nach eigenen Aussagen hat die NYT im laufenden Betrieb die Hacker verfolgt und die Schwachstellen so aufgefunden und blockiert (Note: es wird von blockiert, nicht gefixt geredet!). Nicht wie von dir empfohlen offline im Image analyisert (wobei das evtl dazu kam)
Des weiteren wurde die Lücke nur blockiert, nicht aber das ganze System neu aufgesetzt. Ich bezweifele auch dass es überhaupt machbar wäre alle privaten und Firmen-Rechner aller Mitarbeiter sowie die ganze interne Infrastruktur zeitgleich platt zu machen und neu auf zu setzen.

Quelle: http://www.nytimes.com/2013/01/31/t...mputers.html?pagewanted=3&pagewanted=all&_r=0

So und nun darf sich darf sich der Huschi in die letzte Reihe setzen und das Schuljahr wiederholen.

Imho war das definitiv unnötig.

 

[Joe User]

Huschi's Beispiel ging von einer Kompromittierung des Webspaces aus. Willst du also sagen dass Strato die ganze Serverfarm runter fährt, mit einem neuen Image bespielt und alle Kundendaten aus Backups wiederherstellt weil die FTP-Daten eines Kunden entwendet wurden?

Hat der OP, oder andere hier aufschlagende User mit kompromittierten Systemen, auch nur ansatzweise vergleichbare Sicherheitsstruktur in seinem System? Weisst Du wieviele Securitylayer bei Strato existieren? Wie weit kommt ein Angreifer beim OP und bei Strato mit dem gleichen Exploit für Rubys YAML-Lücke? Richtig, bei Strato nichtmal aus dem Homedirectory, beim OP hingegen erheblich weiter und wenns dumm läuft so gar bis root.
Und ja, sollte es bei Strato doch mal weiter gehen, dann werden dort die kompromittierten Systeme ebenfalls neu aufgesetzt/ausgetauscht.

Nach eigenen Aussagen hat die NYT im laufenden Betrieb die Hacker verfolgt

Das FBI und die externen Sicherheitsspezialisten, nicht die NYT.

und die Schwachstellen so aufgefunden und blockiert (Note: es wird von blockiert, nicht gefixt geredet!).

Zunächst blockiert, dann gefixt. Das übliche und sinnvolle vorgehen des FBI, schliesslich will man die Angreifer dingfest machen. Unsere Sicherheitsbehörden gehen ebenso vor.
Davon spricht aber weder Huschi, noch hat der OP die Behörden informiert, womit dieser Schritt schlicht wegfällt.

Nicht wie von dir empfohlen offline im Image analyisert (wobei das evtl dazu kam)

Das haben die Sicherheitsexperten und das FBI schon allein zur Beweissicherung getan. Die Analyse der Malware selbst, läuft auch dort nur per Image.

Des weiteren wurde die Lücke nur blockiert, nicht aber das ganze System neu aufgesetzt.

Lesen hilft, im von Dir verlinkten Artikel steht "It then replaced every compromised computer".

 

[Huschi]

Da Joe eh schon "EOD" geschrieben hat, gehe ich auf seinen trolligen Posts auch nicht weiter ein.

Der nächste Schritt wäre dann alle Daten zu sichern, die Lücke zu finden (wenn er das selbst nicht kann, jemanden dafür bezahlen)

Genau der Punkt ist es was in den ersten Posts fehlte. Niemand hat sich für die Lücke interessiert. Niemand hat dem OT Anweisungen gegeben was er als nächstes zu tun hat um die Lücke zu finden. Dabei war es genau das, wonach der OT (teils indirekt) fragte.
Der Server war doch schon vom Netz. Von daher war die Möglichkeit gegeben die Sache in Ruhe in die Hand zu nehmen.
Es ging also nie um unterschiedliche Meinungen (die hat lediglich Joe), sondern um das Auslassen eines wesentlichen Punktes.

huschi.

 

[infinitnet]

Genau der Punkt ist es was in den ersten Posts fehlte. Niemand hat sich für die Lücke interessiert. Niemand hat dem OT Anweisungen gegeben was er als nächstes zu tun hat um die Lücke zu finden. Dabei war es genau das, wonach der OT (teils indirekt) fragte.
Der Server war doch schon vom Netz. Von daher war die Möglichkeit gegeben die Sache in Ruhe in die Hand zu nehmen.
Es ging also nie um unterschiedliche Meinungen (die hat lediglich Joe), sondern um das Auslassen eines wesentlichen Punktes.

huschi.

Genau genommen habe ich ihm schon in der zweiten Antwort gesagt, dass er herausfinden muss, wie es zu dem Eindringen des Angreifers kommen konnte. Da wird nicht mal wissen, welches CMS er verwenden oder wie seine Server-Konfiguration aussieht, kann man ihm nur schlecht dabei helfen die Lücke zu finden, sofern er nicht über entsprechende Kenntnisse verfügt. Falls er die hat, sollte er es auch selbst schaffen. Naja, ich möchte hier keine zweite OT-Disskusion starten.

 

[Joe User]

Philosophie mit Praxis verwechselt. Setzen Sechs!

In der von Dir zitierten Frage und deren Bezug ging es ausschlisslich und unmissverständlich um die Praxis. Aber dass Du die Frage nicht beantworten wirst, war irgendwie abzusehen, da Du Dir dann selbst widersprechen müsstest.

Und nein, die SSF-Philosophie "verlangt" dass man dem Newbie hilft die Einbruchs-Lücke zu finden.
Also nochmal: Setzen Sechs!

Na dann mach das doch bitte, statt hier mit Sechsen um Dich zu werfen. Von Dir kam bisher lediglich die Frage nach Informationen, welche bereits im Topic-Title und dem ersten Post enthalten sind.

Dein gelöschter Beitrag war lediglich Offtopic-Blabla mit persönlichen Angriffen und damit ein Verstoß gegen die Nutzungsbedingung.

Persönlicher Angriff? Wenn Du Dich davon schon persönlich angegriffen fühlst, dann tust Du mir echt leid.

Mein Ansatz besagt nicht ausschließlich, dass nur das betroffene Web bereinigt werden soll. Sondern dass es wichtig ist die Lücke zu finden um diese im Falle einer Wiederherstellung schließen zu können.

Richtig, aber offline, nicht online. Solltest Du als Forensic-Dienstleister wissen.

Und wer hier weiter Diskutieren will, sollte genau zu diesem essentiellen Punkt Stellung nehmen: Ist es wichtig die Lücke zu finden oder nicht? Und ist die Lücke auf einem sauberen System zu finden oder auf einem befallenen?

Liest Du überhaupt was hier geschrieben wird?
Du traust dem OP also eine forensische Analyse seines Systems zu? Wenn er das könnte, warum ist er dann hier aufgeschlagen und hat das nicht längst selbst erledigt? Wenn er wenigstens wüsste, dass dies notwendig ist, warum hat er sich nicht längst an einen Forensic-Dienstleister wie Dich gewand?


Und eine abschliessende Frage habe ich noch:
Sollte sich irgendwann herausstellen, dass Papabaer, sbr2d2, tomasini und ich völlig unerwartet doch recht hatten, wirst Du dann zu Deiner Fehleinschätzung stehen und Dich hier öffentlich entschuldigen?
Ich werde es im umgekehrten Fall definitiv tun, sofern der OP nachweisen kann, dass ausschliesslich das Finden und Schliessen des Einfallstors und das Entfernen des DoSenden Scripts ausgereicht haben, um sein System genauso sicher zu machen, wie es ein vergleichbar neu aufgesetztes System ist.
Ich setze so gar noch einen realen Kasten Bier oben drauf.

 

[TerraX]

Nun, nach dem dieser Thread so "galant" ins Abseits geschossen wurde, wird sich der TE wohl kaum nochmal mit nützlichen Informationen zurückmelden. Schade drum, dass es wohl einigen wichtiger war, sich untereinander zu beschäftigen als einfach Feedback vom TE abzuwarten.