Sonstiges

Hau wech den Hack: Alarmanlage für Blog-Hacks!

Johannes Oppermann, der Autor der exzellenten BlogDesk-Software, hat mich angemailt und auf eines seiner weiteren Tools hingewiesen. Diesmal etwas aus der Waffenkammer: HackDetect (Windows 95, 98, NT, 2000, ME, XP und Vista, leider kein Mac noch Linux). Das Tool ist so simpel und einfach, wie nur möglich, let a pic speak:
HackDetect
Es scanned die Verzeichnisse auf dem Webserver und meldet, was verändert wurde. Was ich also bisher immer nur manuell gemacht habe (Anzahl Files und Größe der Files, das Tool kann aber noch mehr Parameter checken), kann ich automatisch und noch umfangreicher erledigen lassen. Way cool. Installieren auf dem PC, Serveradresse wie beim FTP angeben (IP/Domain, User+PW), Verzeichnisse auswählen, Scanvorgang regelmäßig anstoßen und verdächtige Änderungen anzeigen lassen. Dat wars. Ideal für das zeitige Bemerken von Blog-Hackereien, die letzte Zeit immens zugenommen haben. Ausgenommen Hacks, die direkt Einträge in die Datenbank schreiben, da kann HackDetect auch nix mehr machen. Es überwacht „nur“ die Verzeichnisse und Dateien des Blogs, wenn man es jetzt auf Blog-User bezieht (für diesen speziellen Fall gibt es für WordPress-Blogger auch etwas: DigoWatchWP)

Sinn? So wie in meinem Fall heute verändert ein Angreifer bestimmte Dateien auf dem Webserver, um sein Werk anzurichten. Das können bestehende Dateien sein (bei mir war es eine Datei im wpinclude-Ordner), das können natürlich auch frische Dateien sein, die der Angreifer hochlädt. So bleibt aber der Hack über den Detector nicht unbemerkt, denn ein Verzeichnis ändert damit umgehend seine Größe. Werde es gleich installieren und testhalber laufen lassen. Mehr später.

About zum Prinzip dieser Alarmanlage:

Das Prinzip ist ganz simpel: HackDetect macht sich beim Scannen eine Liste aller Dateien und merkt sich deren Eigenschaften (Soll-Zustand). Bei jeder Kontrolle wird dann überprüft, ob der aktuelle Ist-Zustand weiterhin dem Soll-Zustand entspricht. Werden Abweichungen entdeckt, erhalten Sie einen detaillierten Report mit allen neuen, fehlenden oder veränderten Dateien.

Update:
Installation ging super glatt. Kurz den Zielserver angegeben und HackDetect scanned momentan die Verzeichnisse. Bei der Installation sieht man auch bereits am Optionsmenue, welche Parameter überwacht werden:
hack1

hack2

Johannes, kurze Frage: Das Limit von 1.000 Verzeichnissen habe ich beim ersten Komplettscan erreicht. Habe nun eher unwichtige Verzeichnisse ausgenommen, so dass ich unter das Limit komme. Gabs ein KByte-Limit im Programm bei den Variablen bzw. Arrays oder wie kommt die Grenze von 1.000 Verzeichnissen zu Stande? Wäre imho einer Verbesserung, wenn man kurz vor dem ersten Scan ein Programm drüberlaufen lässt, das die Anzahl der Verzeichnisse durchzählt und dem User angibt, dass er beim Scan das Limit erreichen wird. So war / ist mir unklar, welche Verzeichnisse bzw. Unterverzeichnisse das Tool nicht erfasst hat, die ich aber gerne überwachen lassen würde. Es stand auch nirgens was von 1.000er Limit, einfach beim Konfigurieren im Server-Menue darauf hinweisen;) Zentralproblem ist beim Erreichen des Limits nochmals kurz zusammengefasst: Welche Verzeichnisse sind außen vor geblieben und wie bemerkt das Tool das unerlaubte Anlegen neuer Verzeichnisse, sobald Limit wieder erreicht wurde? Was für einen Blogger an sich kein Probblem darstellen sollte, da mW kein Blog-System auch nur annähernd an die 1.000 Ordner anlegt. Kommt nur dann vor, wenn man mehr auf dem Server laufen hat bzw. mehrere Blogs angelegt hat.

Hack3

Und Frank verweist btw auf spezielle WordPress-Lösungen, einfach mal in diesen Sicherheits-Thread reinschauen (aber Obacht, einige Plugins sind nix für schnelle Finger;)


Vernetze dich mit uns!

Like uns auf Facebook oder folge uns bei Twitter


Über den Autor

Robert Basic

Robert Basic ist Namensgeber und Gründer von BASIC thinking und hat die Seite 2009 abgegeben. Von 2004 bis 2009 hat er über 12.000 Artikel hier veröffentlicht.

31 Kommentare

  • Bei Tools, die meine Zugangsdaten benötigen, damit sie funktionieren, bekomme ich immer Bauchschmerzen.
    Nichts gegen Johannes Oppermann, aber wenn ich das Tool eh auf Windows installieren muss, kann ich gleich meine Dateien per FTP runterladen und lokal auf meinem Rechner vergleichen.
    Zum einen habe ich dann gleich eine Datensicherung.
    Zum anderen minimiere ich so die Tools, denen ich meine Zugangsdaten anvertrauen muss.

  • Hm, stimmt….
    … müssen wir uns vielleicht doch mal anschauen.
    Dachte schon, das wäre wieder was für die Faulen, die keine Datensicherungen machen.
    Wir checken das mal. 🙂

  • 1000 Verzeichnisse oder Files? Unter Linux ja im Prinzip dasselbe. Files wären recht wenig. Da kannste doch kein etwas umfangreicheres CMS mit testen. TYPO3 braucht allein für das System schon ein Vielfaches davon.

  • … solche Lösungen gibt es auch als Plugin, du liest schon wieder nicht die News zu deinem System 😉
    Es gibt Plugins in WP, die das machen, wenig Aufwand.

  • So war es auch nicht gemeint, aber du nutzt wp, wirst viel gelesen und bist eine optimale Zielgruppe für Hacker. Da vermutet man, dass du Blogs liest die dir diese Info geben und umsetzt. Sie knnten dir das Leben erleichtern.
    Nichts gegen das Tool, es ging mir lediglich um dein aktuelles Problem. Klar das auch andere Seiten sowas benötigen können.

  • ja und nein, denn es löst das Problem von vielen anderen Blog-USern nicht. Es muss einen Weg geben, allen gerecht zu werden. Da sehe ich HackDetect allen voran, denn viel simpler und einfacher geht es für Normalos kaum noch (auch wenn das Tool nicht mehr das jüngste ist). Gibt mit Sicherheit auch andere Tools, so hoffe ich, die man für den Mac und Linux analog nutzen kann, ohne Kommandozeilenfetischist zu sein oder Corefiles ändern zu müssen, wovon ich nix halte. One tool for all wäre natürlich am besten, aber leider wohl nicht machbar zZt.

  • Ganz klar, die Idee ist klasse. Trotzdem mag ich online-anwendungen, bin viel unterwegs, viele Clients, Desktoptools stehen bei mir hinten an und ich gebe einem Plugin, wofür auch immer, den Vorrang.

  • darüber habe ich vorhin auch nachgedacht, wie es wäre, dass die Filestruktur inkl. der Infos online abgelegt werden kann, um darauf von verschiedenen Rechnereinheiten aus zugreifen zu können. Onlinezugriff aber, um Filechecks zu machen ist heikel:)

    Bin mir sicher, dass so ein Tool in Kombination Online (Fileinfos) und local (Check) einige zahlende Subscriber finden würde…

  • @Frank: Ein Plugin mit dem Check der Dateien zu beauftragen macht doch wenig Sinn.
    Wenn jemand das WordPress kompromitiert, dann kommt er evtl. auch an das Plugin und dann taugt das nix mehr.
    Oder es kommt eine neue WP Version raus und du kannst nicht updaten, weil dein Sicherheitsplugin vom Entwickler noch nicht aktualisiert ist.
    Je mehr Plugins du hast, desto höher ist die Wahrscheinlichkeit, dass eines Dich beim Update deines WP ausbremst.
    Und jedes weitere Plugin erhöht das Risiko, dass man sich eine Sicherheitslücke einfängt.

  • eine weitere Lösung:

    Einfach bei google.com/webmaster anmelden. Laut Matt Cutts, Head of Google’s Webspam team, wird man dann von Google informiert, ob die Seite gehacked ist.

    Mindestens eine Option für unterwegs….

    Des Weiteren noch eine Vorhersage von Matt Cutts für dieses Jahr:

    2008 will be the year that hacking and search engine optimization (SEO) collide in a major way. By the end of the year, a nontrivial fraction of blackhat SEO will involve illegally hacking sites for links or landing pages.

  • @C.J. Sobald nur ein Teil verändert wird, kann man eine Nachricht erhalten. Klar, wenn er an alles ran kommt, dann hackt man auch das Plugin. Aber die Kette wird damit länger und erschwert es. Entscheidend ist aber, man muss es erst mal merken.
    Eine ganze Reihe von Beiträgen bekommen von Hackern unsichtbare Links in alte Beiträge gelegt und die merkt man nur schwer.

    Def. richtig – mit jedem Plugin steigt das Risiko einer weiteren Sicherheitslücke. Auch richtig, mehr Plugin können für Update-Probleme sorgen.

    Trotzdem empfinde ich das Prüfen per Desktop-Tool weniger gut, weil mit einfach die Zugriffe auf einem Client fehlen.

  • Wer soetwas unter Linux braucht, kann sich mal Tripwire in der OpenSource Version anschauen: http://en.wikipedia.org/wiki/Tripwire_(software). Tripwire ist in so ziemlich jeder Linux Distribution enthalten.

    Ein Tool zur Erkennung von Veränderungen sollte aber nur eine Sekundärlösung sein, um den Fall der Fälle einfacher zu erkennen. Primär sollte man darauf achten, Einbrüche von vornherein zu verhindern.

  • Wie wäre es, das ganze CMS einfach in ein Versionskontrollsystem zu packen und darüber zu schauen, ob Veränderungen erfolgt sind? Also z.B. mit GIT kann man sich ja auch eine lokale Kopie anlegen (und damit auch recht einfach Backups machen). Vorteil gegenüber nur Überwachung ist auch, dass man die Änderungen auch gleich rückgängig machen kann. Damit der Angreifer das Versionskontrollsystem nicht verändern kann, kann man es ja außerhalb des basedirs (von PHP) platzieren.

  • bloggen kann mehr als ein Hobby sein…

    […] schließlich könnte er gehackt werden etc. Kürzlich hat er ein Tool empfohlen, dass ich euch nicht vorenthalten […]…

  • @Michael: seh ich ähnlich. Hatte zuerst an ein einfaches rsync via cron gedacht (wobei man hier das cms auch aus svn/git auschecken könnte – hookscript foo) oder, oder, oder… Scheinbar bleibt hier die Begeisterung für win32gui-zeug und manuelles checken jedoch ungebrochen. Naja, wer’s mag – bitteschön.

  • @Robert
    Hatte gerade wieder Kontakt, aber dieses Mal hat jemand versucht einen Link einzuschleusen nach kvantservice[.]com zu verlinken und hat mir dabei den Artikel nach dem More-tag gelöscht. Habe nun aus einem DB-Backup den Artikel wieder herausgekrammt.
    Ich würde ja zu gerne deren Seite mal Arbeit machen, aber ich habe diese kriminelle Energie nicht!
    Ich werde mir wohl mein gesamtes Blog vornehmen müssen hinsichtlich Sicherheit. Grummel!
    @all
    Wie soll man bloß kontrollieren, ob auch die Artikel nicht verändert wurden?

  • Ich denke das kommt auf das System an, im Prinzip kann man bei Datenbankbasierten Systemen ja einfach regelmäßige Backups der Datenbank machen (nicht komprimiert) und vergleichen. Da könnten aber auch Logs, Cache (und natürlich Kommentare) drin sein, also eventuell muss man da mit ein paar Filtern etwas nachhelfen…

    Fein raus sind natürlich mal wieder die Datenbanklosen Systeme (wie DokuWiki mit BlogSuite), wobei man natürlich auch da gewisse Dateien/Pfade ausschließen um den Überblick nicht zu verlieren.

Kommentieren