15
Tool für Filekonsistenz gesucht (Um Veränderungen durch Hacker vorzubeugen)
hi@all,
Wir hatten kürzlich Korrupte PHP-Files, ein bösartiges Tool hat in sämtliche Files Schadcode hinein kopiert. Damit das nicht mehr passiert, suche ich ein Tool, dass die Files auf ihre Echtheit überprüft. Habe noch absolut keine Erfahrungen, und ich möchte/darf kein Risiko eingehen. Hat jemand schon Erfahrung mit solchen "Überwachungen"? Das Betriebsystem ist ein Suse (Suse Linux Enterprise Server 10).
Es gibt anscheinend Tools, die irgend über eine Checksumme schauen, ob das File noch gültig ist, habe ich aber nur mal so am Rande gehört. Für ein paar "Einsteiger-Inputs" wäre ich dankbar.
Es gibt anscheinend Tools, die irgend über eine Checksumme schauen, ob das File noch gültig ist, habe ich aber nur mal so am Rande gehört. Für ein paar "Einsteiger-Inputs" wäre ich dankbar.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 109285
Url: https://administrator.de/contentid/109285
Printed on: April 20, 2024 at 05:04 o'clock
15 Comments
Latest comment
Jop, gibts.
MD5-Hash
Kuck mal nach md5sum - Anleitungen gibts wie Sand am Meer - aber die Manualpage sollte reichen.
LG Florian http://www.lagg.at/
MD5-Hash
Kuck mal nach md5sum - Anleitungen gibts wie Sand am Meer - aber die Manualpage sollte reichen.
LG Florian http://www.lagg.at/
hi miteinander
Da MD5 heutzutage leider nicht mehr sicher ist würde ich sie zusätzlich mit SHA-2(512) prüfen.
Wen du ein "klick" Tool möchtest empfehle ich dir HashCalc von Slavasoft.
http://www.slavasoft.com/hashcalc/index.htm
Und Befehlszeilen Tools findest du wie Sand am Meer.
Da du ja H0cker vorbeugen möchtest , noch ein paar Zeilen aus dem bescheidenen Wiki, zur Sicherheit von MD5.
lowbyte
Da MD5 heutzutage leider nicht mehr sicher ist würde ich sie zusätzlich mit SHA-2(512) prüfen.
Wen du ein "klick" Tool möchtest empfehle ich dir HashCalc von Slavasoft.
http://www.slavasoft.com/hashcalc/index.htm
Und Befehlszeilen Tools findest du wie Sand am Meer.
Da du ja H0cker vorbeugen möchtest , noch ein paar Zeilen aus dem bescheidenen Wiki, zur Sicherheit von MD5.
Im August 2004 fand ein chinesisches Wissenschaftlerteam die erste Kollision in der vollständigen MD5-Funktion.Auf einem IBM-P690-Cluster benötigte ihr erster Angriff eine Stunde, davon ausgehend ließen sich weitere >Kollisionen innerhalb von maximal fünf Minuten finden. Der Angriff der chinesischen Forscher basierte auf Analysen. Kurz nach der Veröffentlichung der Arbeit der Chinesen wurde MD5CRK eingestellt.
Ein Eingabeblock (512 Bit) wird modifiziert, wobei versucht wird, eine bestimmte Differenz zum Original im Ausgang zu erzeugen. Durch eine aufwändige Analyse des Algorithmus kann die Anzahl der unbekannten Bits so weit >verringert werden, dass dies rechnerisch gelingt. Im nächsten 512-Bit-Block wird mit den gleichen Methoden versucht, die Differenz wieder aufzuheben. Die Fälschung beschränkt sich also auf einen zusammenhängenden >Datenblock von 1.024 Bit = 128 Byte, was den Einsatz stark einschränkt.
Kollisionen finden heißt, man kennt ein M (Text) und sucht ein M' (Kollision), so dass hash(M) = hash(M') (dies wäre eine Fälschung). Wenn man nur den Hashwert hat, ist es weiterhin schwierig, eine Kollision für den Hash zu >finden (dies wäre eine zufällige Kollision). Die Kollisionsfreiheit von Algorithmen ist daher eine schwächere Forderung als die Fälschungssicherheit eines Hashwertes.
Ein Eingabeblock (512 Bit) wird modifiziert, wobei versucht wird, eine bestimmte Differenz zum Original im Ausgang zu erzeugen. Durch eine aufwändige Analyse des Algorithmus kann die Anzahl der unbekannten Bits so weit >verringert werden, dass dies rechnerisch gelingt. Im nächsten 512-Bit-Block wird mit den gleichen Methoden versucht, die Differenz wieder aufzuheben. Die Fälschung beschränkt sich also auf einen zusammenhängenden >Datenblock von 1.024 Bit = 128 Byte, was den Einsatz stark einschränkt.
Kollisionen finden heißt, man kennt ein M (Text) und sucht ein M' (Kollision), so dass hash(M) = hash(M') (dies wäre eine Fälschung). Wenn man nur den Hashwert hat, ist es weiterhin schwierig, eine Kollision für den Hash zu >finden (dies wäre eine zufällige Kollision). Die Kollisionsfreiheit von Algorithmen ist daher eine schwächere Forderung als die Fälschungssicherheit eines Hashwertes.
Deswegen besteht keine akute Gefahr für Passwörter, die als MD5-Hash gespeichert wurden, diese Kollisionen sind eher eine Gefahr für ##red | digitale Signaturen##.
lowbyte
Hallo,
um zur Frage zurückzukommen.
Der Angreifer müßte die Datei verändern, dabei die Größe beibehalten und solange den Inhalt modifizieren bis am Ende die gleiche Prüfsumme wie vorher rauskommt.
Das ist so aufwendig, dass sogar ein crc32 zur überprüfung völlig ausreicht. Häufig wird sogar eine Prüfung der Größe schon ausreichen.
Stefan
um zur Frage zurückzukommen.
Der Angreifer müßte die Datei verändern, dabei die Größe beibehalten und solange den Inhalt modifizieren bis am Ende die gleiche Prüfsumme wie vorher rauskommt.
Das ist so aufwendig, dass sogar ein crc32 zur überprüfung völlig ausreicht. Häufig wird sogar eine Prüfung der Größe schon ausreichen.
Stefan
Das ist so aufwendig, dass sogar ein crc32 zur überprüfung
völlig ausreicht. Häufig wird sogar eine Prüfung der
Größe schon ausreichen.
Seh ich auch so...völlig ausreicht. Häufig wird sogar eine Prüfung der
Größe schon ausreichen.
Für md5sum hab ich mir's gerade auf meinem ubuntu angesehen:
1. Checksummen erstellen (rekursiv in Verzeichnisse):
find . ! -type d -print0 | xargs -0 md5sum >files.md5
2. Vergleichen
md5sum -c files.md5
Wenn irgendetwas nicht passt kommt dann zum Schluss:
md5sum: WARNING: 1 of 3381 computed checksums did NOT match
--> in meinem Fall das files.md5 für das es natürlich keinen Hash gibt
Ein Manko gibts: md5sum testet so alle Files die in files.md5 drinstehen - nicht aber files die zusätzlich dazukommen. Ich weiß nicht ob das mit md5sum direkt geht.
LG
Florian http://www.lagg.at/
Wow, cool, ich werd das Ausprobieren. Ich Suche kein Klick Tool, da ich vorallem via Konsole auf den Server zugreife. Hoffe da kann man nicht all zu viel falschmachen
Nicht das der Webserver am Ende nicht mehr funktioniert. Das Tool sollte free sein, ich teste mal das von Slavasoft, sofern es nicht nur in GUI-Form existiert. Neu angelegte Files müssen nicht zwangsläufig automatisch "gesichert" sein, dass kann dann der Admin vor zu machen. Danke mal für die Beiträge, weitere sind jederzeit willkommen.
Nicht das der Webserver am Ende nicht mehr funktioniert. Das Tool sollte free sein, ich teste mal das von Slavasoft, sofern es nicht nur in GUI-Form existiert. Neu angelegte Files müssen nicht zwangsläufig automatisch "gesichert" sein, dass kann dann der Admin vor zu machen. Danke mal für die Beiträge, weitere sind jederzeit willkommen.
Habe jetzt md5sum getestet und es ist noch eine tolle Sache. Wie du aber schon gesagt hast, nimmt es neue Files nicht auf. Und wenn ich dann einen neuen "find" mache um die neuen Files aufzunehmen, woher weiss ich dass das neue File nicht ein bösartiges Script ist? Wie lösen denn andere Sysadmins dieses Problem?
Zitat von @gijoe:
Habe jetzt md5sum getestet und es ist noch eine tolle Sache. Wie du
aber schon gesagt hast, nimmt es neue Files nicht auf. Und wenn ich
dann einen neuen "find" mache um die neuen Files
aufzunehmen, woher weiss ich dass das neue File nicht ein
bösartiges Script ist? Wie lösen denn andere Sysadmins
dieses Problem?
Wie ist denn das "böse" Skript auf deinen Rechner gekommen? Ich würd schon mal da ansetzen:Habe jetzt md5sum getestet und es ist noch eine tolle Sache. Wie du
aber schon gesagt hast, nimmt es neue Files nicht auf. Und wenn ich
dann einen neuen "find" mache um die neuen Files
aufzunehmen, woher weiss ich dass das neue File nicht ein
bösartiges Script ist? Wie lösen denn andere Sysadmins
dieses Problem?
- Firewall prüfen
- Apache/PHP chrooted ausführen (nicht als root-User)
- dem Benutzer für Apache/PHP KEINE Schreibrechte auf die Ordner geben
- gute Passwörter verwenden und
- Brute-Force-Angriffe mit fail2ban blocken
Ich denke das reicht. LG Florian.
Ja, diese Masnahmen wurden in etwa ergriffen, es fehlt nur noch die "Überwachung" oder ein Frühwarnsystem
Und wie gesagt, neue Files müssen ja auch als Vertrauenswürdig gelten und zum checken "freigegeben" werden. Wie machst denn du das auf euren Webservern?
Und wie gesagt, neue Files müssen ja auch als Vertrauenswürdig gelten und zum checken "freigegeben" werden. Wie machst denn du das auf euren Webservern?
Ja, diese Masnahmen wurden in etwa ergriffen, es fehlt nur noch die "Überwachung" oder ein Frühwarnsystem
installier mal fail2ban - du wirst begeistert sein.Das einzige was du einstellen musst ist die Mail-Adresse für die Benachrichtigungen.
Ach ja - kurze Beschreibung:
fail2ban überwacht die sicherheitsrelevanten Logfiles (zB SSH) und zählt bei Fehlversuchen mit. Standardmäßig bei mehr als 6 Fehlversuchen wird die Angreifer-IP gesperrt (für eine bestimmte Zeit) und du bekommst ein Email mit den Log-Einträgen und einen Whois-Eintrag der IP.
Beim ersten Mal mach ich meistens nichts, wenn dies öfter passiert schreib ich an die Abuse@-Adresse des Providers - diese sperren den User in der Regel.
Und wie gesagt, neue Files müssen ja auch als
Vertrauenswürdig gelten und zum checken "freigegeben"
werden. Wie machst denn du das auf euren Webservern?
Ehrlichgesagt - gar nicht. Mit einer Ausnahme: Meine Eigenentwicklungen verwalte ich in einem SVN-Repository auf einem anderen Server - somit könnte ich dieses Auschecken und vergleichen.Vertrauenswürdig gelten und zum checken "freigegeben"
werden. Wie machst denn du das auf euren Webservern?
Der Web-User hat keine Schreibberechtigung, ich verwende keine dubiosen CMS-Systeme bei denen offene Sicherheitslücken bekannt sind oder welche, die vielleicht sogar noch REGISTER_GLOBALS brauchen.
Außerdem habe ich sehr wenig PHP, ich verwende größtenteils Plone/Zope (Python-basiert) oder/und TurboGears, beide mit Objekt-relationaler Datenbank (also nicht anfällig für SQL-Injection) und bei Eigenprogrammierungen achte ich auf die Sicherheit.
Natürlich bin ich ständig am Updaten, lese in Security-Foren mit lass nur diejenigen auf mein System die das wirklich dürfen - ohne Ausnahme mit starken Passwörtern und nur dorthin wo sie was zu suchen haben.
Damit hab ich bisher jeglichen Angriff abgewehrt.
Bei einem Kunden (und natürlich anderem Hoster
) hatte ich bisher einen Angriff - das Problem war hier dass der Hoster eine uralte Version eines CMS-Systems hatte - und dieses war Angreifbar. Mit 5 min Internetrecherche konnte ich den Angriff nachvollziehen.Anhand dieses Threads werd ich mir überlegen je Kunde regelmäßig ein Änderungsprotokoll mit diff jeder Datei zu erstellen (und auf Wunsch regelmäßig zuzusenden).
Weitere Vorschläge sind herzlich willkommen.
Ich hoffe dass hilft dir.
LG Florian.
Was ich noch vergessen habe...
1x wöchentlich läuft bei mir ClamAV (Up2date mit FreshClam) über sämtliche Web- und Mailverzeichnisse. Das einzige was dieser in der Regel findet sind jedoch Mails die von Kunden per IMAP hochgeladen wurden (SMTP wird vor Annahme gescannt).
1x wöchentlich läuft bei mir ClamAV (Up2date mit FreshClam) über sämtliche Web- und Mailverzeichnisse. Das einzige was dieser in der Regel findet sind jedoch Mails die von Kunden per IMAP hochgeladen wurden (SMTP wird vor Annahme gescannt).
Auf dem Server läuft keine Firewall, somit bringt mir file2ban wohl nicht wircklich etwas, oder?
Zitat von @gijoe:
Auf dem Server läuft keine Firewall, somit bringt mir file2ban
wohl nicht wircklich etwas, oder?
Auf dem Server läuft keine Firewall, somit bringt mir file2ban
wohl nicht wircklich etwas, oder?
1. sollte sie aber. Ne einfache iptables firewall auf der nur die ports offen sind die wirklich benötigt werden. Besser noch: Vor dem Rechner eine Firewall, so:
Internet <--> Firewall <--> Server
Wenn du dich mit iptables nicht auskennst hilft dir fwbuilder weiter (aber bitte nicht am Live-System testen
) Ein bisschen einlesen wirst dich trotzdem müssenLink: http://www.fwbuilder.org/
Unter freien Betriebssystemen ist fwbuilder Open Source *gg*
Ach ja: wenn nicht explizit ausgeschalten sollte dein Linux-Rechner standardmässig eine iptables (oder UFW was prinzipiell nichts anderes ist) haben. Bin zwar kein SuSE-Spezi aber das sollte Standard sein.
2. Firewall und fail2ban:
Fail2ban überwacht logfiles. Wenn zuviele Fehlversuche zusammenkommen wird per iptables-Firewall der Client denied.
Um deine Frage noch zu beantworten:
Server ohne simple Firewall = Headshot --> Frag.
Fail2Ban ohne Firewall = geht nicht
Linux ohne Firewall = noch nicht gesehen.
LG Florian.
Nun, wir haben eine Accesslist aufnem Router im Einsatz, die (anscheinend) eine FW erübrigt. Und im nachhinein eine FW einbauen ist schon etwas gewagt, da dieser Server praktisch rund um die Uhr im Einsatz sein muss. Einen Ausfall können wir uns da nicht leisten.
Einen Ausfall können wir uns da nicht leisten.
Ein einzelner Server mit Anbindung über einen Router ist nie komplett ausfallssicher.Wenn das sein muß, braucht man...
- redundante Anbindung
- zweiter Server (fehlertolerant)
- ...
Das kann teuer werden. Meistens ist die Frage nicht - können wir uns einen Ausfall von X Stunden leisten - sondern - können wir uns die Geräte und erhöhte Wartung leisten wenn wir das System ausfallssicher auslegen...
Hat aber mit dem Thema nix zu tun.
Mit einem hast du recht - im laufenden System eine Firewall einführen kann direkt zu Ausfällen führen (auch wenn vorher am Testsystem getestet) und benötigt daher ein Wartungsfenster mit entsprechenden Reserven. Vorher benötigt man evtl. noch ein Ersatzgerät für das Arbeiten in dieser Zeit.
Ich schweife schon wieder aus.
Conclusio: Alles oben sind nur Anregungen für ein gut abgesichertes System. Es liegt im ermessen des Systembetreibers was wirklich notwendig ist und was nicht.
LG
Florian http://www.lagg.at/
