Wie Hacking erkennen?

[webpilot]

Ich habe eine kleine Seite von mir entdeckt, welche vor einigen Wochen gehackt wurde. Dabei wurde die htaccess-Datei verändert, ein PHP-File hochgeladen und Schadcode geladen. Da ich die Seite so gut wie nie besuche und eig. genauso gut hätte deaktivieren können, habe ich das lange nicht bemerkt. Zum Glück gibt es so gut wie keine Besucher.

Meine Frage deshalb. Wie schützt ihr eure Seiten vor solchen Attacken (abgesehen von Prävention durch aktuelle Software, etc.)? Gibt es eine Möglichkeit ganze Projekte auf Veränderungen prüfen zu lassen? Beispielweise ein Script das einmal täglich prüft, ob Dateien verändert wurden? Bei einem gehackten FTP-Account wäre es doch sinnvoll, würde man beispielweise per Mail über einen erfolgreichen FTP-Zugriff informiert. Wenn ich selbst nicht gerade per FTP zugreife, wäre das möglicherweise ein gehackter Account.

Wie geht ihr vor?

[Malte Landwehr]

Überwachung:
Viele Leute nutzen Google-Alerts der Form "site:example.com viagra", wobei example.com deine Domain ist und viagra durch andere Begriffe ersetzt werden kann, die von Craphats gerne auf gehackten Seiten platziert werden.

Meine Präventivmaßnahme:
So viele Sachen wie möglich durch einfache HTML-Datein lösen. PHP und DB nur wenn es sein muss.

Wenn du Systeme wie Wordpress nutzt kannst du dich nicht zuverlässig schützen und musst regelmäßig Backups erstellen und patchen.

[Ice Man]

kannst auch per FTP schauen, wann zuletzt eine Datei verändert wurde.
Oder baust dir ein Script was das Datum der letzten Änderung ausließt und dich 1x täglich informiert

[seonewbie]

Das Problem war doch nicht der Angriff sondern das deine
htaccess Schreibrecht für den Apache User hatte.
Setze einfach alles auf nur lesen und das Problem wäre
gar nicht entstanden.

Ein Problem haben nur Leute die Spider Trap nutzten denn
für den vollen Funktionsumfang benötigt die htaccess hier
schreibrechte.

Jeder andere soll doch seine htaccess auf 444 setzen und
dann kann auch niemand schreiben nicht mal root.
Wenn die Datei geändert werden soll muß root sich erst selber
schreibrechte geben und kann dann erst ändern.

Wer einen Windows Server nutzt - nun gut dem ist eh nicht
zu helfen ...

Alle anderen wie gesagt htaccess auf nur lesen setzen und gut ist.

[webpilot]

Danke für Eure Antworten.

Überwachung:
Viele Leute nutzen Google-Alerts der Form "site:example.com viagra", wobei example.com deine Domain ist und viagra durch andere Begriffe ersetzt werden kann, die von Craphats gerne auf gehackten Seiten platziert werden.

Das ist zwar gut und Recht, aber dann auch sichtlich spät. Mir wäre eine Lösung auf dem Server lieber. Bis Google die Seite indexiert hat und anzeigt, können ja auch schon Besucher geschädigt sein...

Meine Präventivmaßnahme:
So viele Sachen wie möglich durch einfache HTML-Datein lösen. PHP und DB nur wenn es sein muss.

So mache ich das ähnlich. Kleiner Webseiten bestehen soweit nur aus HTML und gelegentlich etwas PHP und dann meistens nur als PHP-Include für ein Header, footer, etc.

Das Problem war doch nicht der Angriff sondern das deine
htaccess Schreibrecht für den Apache User hatte.
Setze einfach alles auf nur lesen und das Problem wäre
gar nicht entstanden.

Ich glaube eher, dass es sich bei dem konkreten Fall um einen gehackten FTP-Account handelt, da PHP-Dateien auf dem Server gespeichert wurden - bin mir aber natürlich nicht zu 100% sicher.

[SeriousBadMan]

Doofe Frage, aber:

1. Kann man denn in HTML keinen Schadcode platzieren, z.B. per Javascript??
2. Wenn der FTP Account gehackt wird, hilft HTML statt PHP ja auch nicht?

Kenne mich mit Programmierung leider kaum aus, daher meine etwas dummen Fragen.

[800XE]

Doofe Frage, aber:

1. Kann man denn in HTML keinen Schadcode platzieren, z.B. per Javascript??

JavaScript wird im Browser ausgeführt, also keine Gefahr für den WebServer

Oder baust dir ein Script was das Datum der letzten Änderung ausließt und dich 1x täglich informiert

@webpilot

Das war mein Gedanke als ich anfing deinen Post zu lesen


mal sehen .... Heute oder Morgen ..... vielleicht was zusammenbauen

am besten in der index.php verstecken ....
.... sonst merken die Häcker gleich das was da ist (wenn es mehrere nutzen)

[Malte Landwehr]

Doofe Frage, aber:

1. Kann man denn in HTML keinen Schadcode platzieren, z.B. per Javascript??
2. Wenn der FTP Account gehackt wird, hilft HTML statt PHP ja auch nicht?

Kenne mich mit Programmierung leider kaum aus, daher meine etwas dummen Fragen.

Das stimmt. Bei einem gehackten FTP-Account kann der Hacker natürlich alles machen.
Aber in den meisten Fällen von Website-Hacks werden SQL-Injections oder ähnliches verwendet. Und sowas geht bei reinem HTML nicht.

[tmyp]

Wenn die Seiten nicht zu groß sind (=Millionen von Dateien) würde ich zur Kontrolle lieber auf hashing setzen als auf's Änderungsdatum der Datei, denn das lässt sich ja leicht manipulieren (allerdings keine Ahnung, ob das jemand macht wenn er Code reinbastelt, aber ich würde es machen).
Wenn FTP-Zugriff besteht, besteht meist auch Code-Zugriff, denn oft wird, auch wenn kein PHP verwendet wird, dem Vhost ja nicht die Fähigkeit zu PHP entzogen, d.h. einfach ne test.php hochladen und da alles mögliche drin machen. Wenn ich das richtig erinnere gibt's auch fertige PHP-Shells für eben den Zweck.
Auf einem normalen Webhosting-Server eines Providers hat man ja oft nur FTP-Zugriff, da ist dann in der Tat ein Timestamp und Größen-Vergleich wohl das beste. Am besten auch mit einer lokalen Kopie vergleichen, so wird's einfach(er) zu erkennen, ob die Änderung von dir stammt, Du willst ja nicht jedes mal einen Alarm um 0400 der dich aus dem Bett wirft, nur weil Du mal was irgendeiner Datei auf'm Webspace getan hast.
Wenn ssh-Zugriff besteht: hashs vergleichen, das ist ziemlich sicher.
Wenn's auf dem eigenen Server ist, gibt's einiges. SFTP oder FTPS nutzen. Fail2ban nutzen, um bruteforce an sich schon mal schwer bis unmöglich zu machen. Wer's hart mag: Portknocking drauf, dann erübrigt sich die Sache mit den Angriffen auf nicht benötigte Dienste (SSH, FTP...) schon mal.
mod_security für den Apache. PHP mit suhosin härten, allow-url-fopen aus, nicht als apache-modul, sondern als CGI mit suexec laufen lassen. Wenn man fremde Anwendungen einsetzt: immer aktuell halten, am besten auf die Mailinglisten mit Releases und Exploits setzen. Bei eigenen Apps halt den Standardkram: Usereingaben sind immer böse und werden niemals direkt in systemcalls oder zum öffnen von Dateien verwendet. Datenbankwerte werden immer escaped.
Der eigene Server ist da oft sicherer als Shared Space bei einem Provider: so bist Du nur für deine Scripte verantwortlich, aber wenn beim webhoster der Nachbar ein Tor aufmacht und php als modul läuft und die Zugriffsrechte nicht ganz sauber gesetzt sind, hast Du auch gleich ein Problem.

[nerd]

Doofe Frage, aber:

1. Kann man denn in HTML keinen Schadcode platzieren, z.B. per Javascript??

javascript kann keine dateien auf dem rechner lesen oder schreiben (ausser cookies), und die meisten (alle?) browser lassen auch nicht zu das javascript, welches auf meineheimseite.de laeuft auf code von eineandereseite.de zugreift, oder irgendwelche daten dorthin postet.
was anderes ist es allerdings mit adobe flash, adobe reader und dergleichen pest; was sich ja ebenfalls in html einbinden laesst, imho auch von anderen domains ...

[Cujo]

Wenn du Systeme wie Wordpress nutzt kannst du dich nicht zuverlässig schützen und musst regelmäßig Backups erstellen und patchen.

Ist nicht ganz richtig Das Plugin Antivirus kontrolliert regelmäßig, ob Veränderungen an den Dateien vorgenommen wurden und schickt gegebenfalls eine E-Mail.

[Malte Landwehr]

Ist nicht ganz richtig

Doch, ist richtig. Das Plugin kann dir auch nur helfen etwas zu erkennen aber es kann es nicht verhindern.

[AngelOfDark]

Doofe Frage, aber:

1. Kann man denn in HTML keinen Schadcode platzieren, z.B. per Javascript??

javascript kann keine dateien auf dem rechner lesen oder schreiben (ausser cookies), und die meisten (alle?) browser lassen auch nicht zu das javascript, welches auf meineheimseite.de laeuft auf code von eineandereseite.de zugreift, oder irgendwelche daten dorthin postet.
was anderes ist es allerdings mit adobe flash, adobe reader und dergleichen pest; was sich ja ebenfalls in html einbinden laesst, imho auch von anderen domains ...

...und solange nicht Java wieder eine Lücke als Feature deklariert, letztes Jahr gab es mal eine Java-Version, die irgendwelchen Fremdcode nachladen durfte - das konnte per JavaScript ausgelöst werden und zack, hatte man den Salat - respektive Virus.

[rapidcc]

Es gibt sogenannte Intrusion Detection Systems (kurz IDS) deren einziger Zweck es ist, die Payload, also die schadhafte sequenz, zu erkennen.

Das bekannteste IDS ist wohl SNORT, es ist OpenSource und es gibt sehr viele Regeln für snort.

Allerdings muss man sich immer fragen, ob man sowas braucht. Es ist so, dass SNORT jedes Paket filtert und begutachtet, das merkt man dann schon in der Performance, wenn man das im großen Stil macht.

Solange man nur statische webseiten (html) hostet, braucht man sich nur um den Server selbst Sorgen zu machen, denn es gibt weder php noch irgendeine Datenbank etc..

Man kann sehr leicht erkennen, wer sich in den Server eingeloggt hat, indem man die logdatei vom ssh daemon durch grep schickt und nach "accepted" sucht. Ist dort eine fremde IP zu finden, würde ich mir Sorgen machen.

Aber all diese "good practice" hier zu erklären würde den Rahmen sprengen. Das sage ich auch immer wieder den Kunden:
Risk Assessment lohnt sich nur dann, wenn es viel "Risk" gibt. Ansonsten reicht es, wenn man täglich die updates checkt, starke passwörter verwendet und ab und zu mal die logs anguckt. Und genau das wird oft unterschätzt.

Außerdem darf man Java nicht mit JavaScript verwechseln. Es gibt so genannte Java Drive-Bys, das sind kleine Applets, die vom Client ausgeführt werden, um Schadsoftware runterzuladen und zu starten.
Aber sowas merkt man eh. Und JavaScript selbst kann auch gefährlich sein, Stichwort Cross Site Scripting (führt zu Session Stealing etc..) aber ganz ohne dynamische seiten geht auch das nicht
Input checking ftw

Vor Flash braucht man als Host auch keine Angst zu haben.

mfg

[rayman]

Hi,


ich hatte vor kurzen auch einen "Hacker-Agriff"
https://www.abakus-internet-marketing.d ... 03044.html
ich vermute er hat die PHP-Shell genutzt
(schau dir mal im Web Videos an, wie "einfach" es gehen kann "php-shell site hacken")
... ich war schockiert, dass man es den Leuten so einfach macht


darauf hin habe ich einige Sachen am Server geändert,
zum beispiel in der "disable_functions" die Shells zugriffe blockieren
hier weitere Infos zu meine Fall
https://www.webmasterpark.net/forum/rec ... lizei.html


Herausgefunden habe ich es auch recht spät,
erst als mich jemand angesprochen hat, dass er einen Viren/SPAM Warung bekommt,
wenn er auf die Seite gehen will.



Ich habe übrigens auch eine Anzeige bei der Polizei gemacht
(da ich auch einen sehr konkreten verdacht habe)
und schauen wie nun mal, was dabei herraus kommt

grüße
Rayman