staging.inyokaproject.org

Da chkrootkit nicht soviele Tests beinhalter wie rkhunter hab ich mir das mal angeschaut und einen Artikel dazu geschrieben: Baustelle/rkhunter

Achja und das hatte ich letztends schon gefragt, warum kann ich von mir erstellte Attachments nichtmehr löschen? Hier schon wieder. Wollte nen kleinen Screenshot einfügen, doch er lässt sich irgendwie nicht schön in den Artikel eingliedern und ich wollte ihn wieder löschen über Aktionen-->Revision-->del doch ich bekomme immer nur: You are not allowed to delete attachments on this page.

Im ersten Hinweis ist erst die Rede vom "known-good"-Test, dann von dem genannten "known-bad"-Test... Ist das ein Fehler oder habe ich es nur falsch verstanden?

Anhänge löschen können nur die Wiki-Moderatoren, über den Sinn (den auch ich nicht sehe) können wir gerne streiten - aber bitte in einem extra Thread.

cornix hat geschrieben:

Im ersten Hinweis ist erst die Rede vom "known-good"-Test, dann von dem genannten "known-bad"-Test... Ist das ein Fehler oder habe ich es nur falsch verstanden?

Nein das war nur ein kleiner Fehler, der sich eingeschlichen hat. Es sollte beidemale im Hinweistext known-good heissen 😉

known good = es werden vorhandene Dateien mit den Hashes von unkomprimitierten verglichen
known bad = es werden vorhandene Dateien mit den Signaturen von rootkits verglichen

Known good klappt bei dem rkhunter aus den repos leider nicht.

Fein, habe ich doch mal was richtig verstanden. ☺

Am Schluss sollte vielleicht noch ein Hinweis hin, wie ihn die Ubuntu-Package-Search gibt:

Please note that rkhunter does *not* guarantee your system has not been compromised! You should also run additional tests, e.g. using chkrootkit and other measures.

Alles klar, hab einen Warnhinweis hinzugefügt, genauso wie im chkrootkit-Artikel:

Alleine durch die Benutzung von rkhunter kann nicht garantieren werden, dass sich nicht doch ein Rootkit auf dem System befindet. Die Anwendung von nur einem einzigen Tool ist nicht sehr effekiv, da ein Rootkit-Autor sein Rootkit dagegen immun gemacht haben könnte. Es sollten immer noch weitere Tests durchgeführt werden, wie zum Beispiel mit chkrootkit bzw. andere Maßnahmen vorgenommen werden.

Danke. Mein "english" ist bescheiden und ich war mir nicht sicher, ob ich es richtig verstanden habe. Ausführlich ist immer besser!

Guter Artikel - wir warten die üblichen zwei bis drei Tage mit dem Verschieben, falls noch Fragen oder Anregungen auftauchen.

Was sagen denn unsere Sicherheitsspezis und Paranoia-Freaks?

rkhunter ist verschoben und unter Sicherheit verlinkt..

Danke Adna rim!

Sollte vielleicht noch rein, dass man Tools wie rkhunter oder chkrootkit sicherheitshalber von einem 100% unkompromittierten System (z.B. Live-CD) starten sollte - zumindest wenn es wirklich Anzeichen eines Einbruchs gibt.

Sorry, hab den Thread erst jetzt gesehen.

Ja stimmt sowas steht im chkrootkit Artikel ebenfalls..Werd ich morgen im Laufe des Tages einfügen, hab heute leider keine Zeit mehr.

Warnung im rkhunter und chkrootkit-Artikel diesbezüglich erweitert:

Alleine durch die Benutzung von rkhunter kann nicht garantiert werden, dass sich nicht doch ein Rootkit auf dem System befindet. Die Anwendung von nur einem einzigen Tool ist nicht sehr effektiv, da ein Autor sein Rootkit dagegen immun gemacht haben könnte. Es sollten immer noch weitere Tests durchgeführt werden, wie zum Beispiel mit chkrootkit bzw. andere Maßnahmen vorgenommen werden. Desweiteren sollte rkhunter, um dessen Integrität und damit die Verlässlichkeit sicherzustellen, immer von einem 100%ig unkompromitierten System ausgeführt werden, wie zB einer Live-CD.

was tun bei folgender Ausgabe: (z.B.) ??

Checking /dev for suspicious file types [ Warning ] Checking for hidden files and directories [ Warning ]

Wer kann dazu was im Wiki ergänzen? Danke

frustschieber schrieb:

was tun bei folgender Ausgabe: (z.B.) ??

Das ist zwar eine typische frage, aber auch schwer zu beantworten. Denn man müsste, um einen hilfreichen Artikel zu haben, quasi tagesaktuell im Wiki halten, welche versteckten Verzeichnisse und Dateien in /dev/ normal sind und welche nicht. Und das ist nicht nur eine der Beurteilungen, die man nur mit großer Erfahrung treffen kann, sondern auch vermutlich eine Syspihosarbeit. Ich würde so etwas nicht im Wiki haben wollen, da man dazu bis auf drei Standardverzeichnisse wenig allgemeingültige Antworten geben kann.

rkhunter speichert das Ergebnis in /var/log/rkhunter.log.

Mit root-Rechten kann man sich die Datei ansehen und den Warnungen nachgehen. Oftmals entpuppen sie sich dann als harmlos.

Beispiel meines Durchlaufs von gestern:

[19:24:42]   Checking /dev for suspicious file types         [ Warning ]
[19:24:42] Warning: Suspicious file types found in /dev:
[19:24:42]          /dev/shm/network/ifstate: ASCII text
[19:24:43]   Checking for hidden files and directories       [ Warning ]
[19:24:43] Warning: Hidden directory found: /etc/.java
[19:24:43] Warning: Hidden directory found: /dev/.udev
[19:24:43] Warning: Hidden directory found: /dev/.initramfs

In der "verdächtigen" /dev/shm/network/ifstate findet sich die Zeile

lo=lo

Es wäre glaube ich hilfreich wenn man ins Wiki noch aufnimmt wie man mit WARNINGS umgeht.

Ein Hinweiß auf den Parameter

1

sudo rkhunter --check --pkgmgr dpkg

Habe aber selber gerade das Problem das "pkgmgr dpkg" nicht erkennt das eine Datei OK ist die durch ein update reingekommen ist.

Bekomme die Warning:

1
2
3
4
5
6

[17:22:07] /bin/ps                                           [ Warning ]
[17:22:07] Warning: The file properties have changed:
[17:22:07]          File: /bin/ps
[17:22:07]          Current inode: 90308627    Stored inode: 90308643
[17:22:07]          Current file modification time: 1324307913 (19-Dez-2011 16:18:33)
[17:22:07]          Stored file modification time : 1260992081 (16-Dez-2009 20:34:41)

Nun kann ich mit folgendem Befehl rausfinden in welchem deb Packet die Datei ist.

1

grep "/bin/ps$" /var/lib/dpkg/info/*.list

Damit finde ich raus das es in der procps drinnen ist

1

/var/lib/dpkg/info/procps.list:/bin/ps

Nun kann ich mir die passenden md5sum raus suchen:

1
2

patrick@server:~$ grep "bin/ps" /var/lib/dpkg/info/procps.md5sums 
8cca6945c0fc34ab1f941cd7cc8aa940  bin/ps

Diese md5sum kann ich dann mit meiner installierten Version vergleichen.

1
2

patrick@server:~$ md5sum /bin/ps
8cca6945c0fc34ab1f941cd7cc8aa940  /bin/ps

Das passt schon mal. Ist aber noch keine Sicherheit.

Nun kann ich noch das Datum überprüfen. Zum einen mit

1

ls -l  /var/lib/dpkg/info/procps.*

Und mit

1
2
3

zgrep procps /var/log/dpkg.log.*.gz
oder
grep procps /var/log/dpkg.log

Da kann ich sehen wann das deb file installiert wurde. In meinen Fall

1

/var/log/dpkg.log.2.gz:2012-03-16 10:17:12 upgrade procps 1:3.2.8-1ubuntu4 1:3.2.8-1ubuntu4.2

Leider ist das upgrade Datum mit dem "Current file modification time" nicht identisch. Warum weiß ich nicht.

Ich muss aber sagen das ich das auch von "--pkgmgr dpkg" erwarten würde.

ArpO schrieb: "moin,

hab gerade rkhunter auf meinem root eingerichtet. ubuntu 12.04.4 server. erst habe die ubuntu version installiert, die war aber mal wieder veraltet. also manuelles update wie im wiki beschrieben.

und zack hatte ich zwei versionen von rkhunter installiert.

die ubuntu version lag in /usr/bin, version 1.38, und die neue 1.43 in /usr/local/bin

vielleicht sollte das wiki da mal nachgearbeitet werden. ich habe jetzt erstmal /usr/bin/rkhunter manuell gelöscht."

Kann das Jmd bitte überprüfen? Danke