Leere Dateien unter /etc/init.d z.B. cron

[mkm]

Hallo,
ich verwalte seit vielen Jahren mehrer Debian Server.
Aktuell verwende ich die Version 7 (LTS).
Bei einem dieser Server habe ich heute, nachdem der Server am Sonntag neu gebootet wurde (Reboot erfolgt jeden Sonntag über cron), festgestellt, dass folgende Dateien unter /etc/init.d leer sind:

cron
nfs-kernel-server
rc.local
rmnologin

Alle tragen das Datum Jan 25 11:39.

Alle Log-Dateien unter /var/log habe ich bereits durchgesehen, keine Auffälligkeiten gesehen und zu dieser speziellen Zeit (Jan 25 11:39) keine EInträge gefunden.
Alle anderen Server sind nicht betroffen.

Kennt jemand soetwas?
Wie kann es passieren, dass diese Dateien leer sind?

Wenn ich beispielsweise die /etc/init.d/cron von einem anderen Server kopiere und starte, käuft cron ganz normal, die Installation ist demnach nicht betroffen.
Da ich die Server allein verwalte, weiss ich, dass weder Updates gelaufen sind (mache ich manuell), noch sonstige Änderungen durchgeführt wurden.
Da diese Server nahezu ohne Probleme laufen, mache ich nur alle paar Wochen die Security Updates.
Ansonsten laufen die Server einfach.
Gruß
Manfred

[rendegast]

Wurden denn Aktionen durch zBsp. rc.local ausgeführt? cron gestartet und seine Arbeit verrichtet?

Änderung durch rootkit?

Änderung durch Setup eines anderen init-Prozedere?
ZBsp. Start per inittab.

Da diese Server nahezu ohne Probleme laufen, mache ich nur alle paar Wochen die Security Updates.

Per Zusatzpaket wie unattended-upgrades oder cron-apt zeitnah einspielen lassen?
Das muß nicht den kernel einschließen (Reboots), dieser dürfte selten Angriffsopfer sein.
(zumindest sowas wie apticron zur Benachrichtigung)

checkrestart (debian-goodies) / needrestart als automatische Tests und mit Aktionen verbunden,
um wirklich alle eines Neustarts bedürftigen Dienste/Prozesse abzuhandeln.

Ansonsten laufen die Server einfach.

Ein rootkit würde außer Systemlast den Server nicht beeinträchtigen,
außer es will auf sich aufmerksam machen.


wheezy-LTS hat nur ein begrenztes Spektrum,
sind alle offenen Dienste davon abgedeckt?

[mkm]

Wurden denn Aktionen durch zBsp. rc.local ausgeführt? cron gestartet und seine Arbeit verrichtet?

Cron wurd nach dem Reboot nicht neu gestartet und hat demnach auch seine Arbeit nicht verrichtet. Das war es was mich heute aufmerksam machte.

rootkit

ist eine böse Vermutung die ich auch schon hatte, muß ich untersuchen.

Per Zusatzpaket wie Debianunattended-upgrades oder Debiancron-apt zeitnah einspielen lassen?
Das muß nicht den kernel einschließen (Reboots), dieser dürfte selten Angriffsopfer sein.
(zumindest sowas wie Debianapticron zur Benachrichtigung)

Ich mache meine Updates lieber per Hand.

wheezy-LTS hat nur ein begrenztes Spektrum,
sind alle offenen Dienste davon abgedeckt?

Ich denke schon, auf diesem Server läuft Samba (Fileserver), Qemu und KVM, sonst nichts.

[mkm]

Ich habe den Server jetzt mit chkrootkit (aus den Paketen) und Lynis (aktuelle Version) untersucht.
Keine Hinweise auf ein rootkit.
Hat noch jemand eine Idee?

[mkm]

Ich hatte am Montag die vier Dateien von einem idenstisch installierten Server wieder eingefügt (Datum der ursprünlichen Datei wurde beibehalten).
Gestern haben die drei Dateien

rc.local
rmnologin
nfs-kernel-server

wieder ein neues Datum bekommen. Ich habe den Inhalt mit den Ursprungsdateien verglichen, dieser ist identisch geblieben.
Die Datei cron wurde nicht angefasst.
Wer bzw. welcher Prozess toucht eventuell diese drei Datein?
Bin für jede Information dankbar.

[rendegast]

Wer bzw. welcher Prozess toucht eventuell diese drei Datein?

Eigentlich nichts.
Eventuell ein Upgrade der Pakete initscripts und nfs-kernel-server,
dann aber höchstens mit Datum der von diesen mitgebrachten Dateien.

Code: Alles auswählen

$ apt-cache policy nfs-kernel-server initscripts
nfs-kernel-server:
  Installiert:           (keine)
  Installationskandidat: 1:1.2.8-9
  Versionstabelle:
     1:1.3.4-2 0
        100 http://ftp.de.debian.org/debian/ unstable/main i386 Packages
        101 http://ftp.de.debian.org/debian/ testing/main i386 Packages
     1:1.2.8-9 0
        500 http://ftp.de.debian.org/debian/ jessie/main i386 Packages
initscripts:
  Installiert:           2.88dsf-59
  Installationskandidat: 2.88dsf-59
  Versionstabelle:
     2.88dsf-59.8 0
        100 http://ftp.de.debian.org/debian/ unstable/main i386 Packages
        101 http://ftp.de.debian.org/debian/ testing/main i386 Packages
 *** 2.88dsf-59 0
        500 http://ftp.de.debian.org/debian/ jessie/main i386 Packages
        100 /var/lib/dpkg/status

<apt-get download   /   entpacken>

$ find */etc/init.d/ ! -type d -ls | egrep "rmnologin|nfs-kernel|rc.local"
2793894    4 -rwxr-xr-x   1 etchuser etchuser     1042 Jul 20  2016 initscripts_2.88dsf-59.8_i386/etc/init.d/rmnologin
2793892    4 -rwxr-xr-x   1 etchuser etchuser      820 Jul 20  2016 initscripts_2.88dsf-59.8_i386/etc/init.d/rc.local

2794038    4 -rwxr-xr-x   1 etchuser etchuser     1042 Apr  6  2015 initscripts_2.88dsf-59_i386/etc/init.d/rmnologin
2794023    4 -rwxr-xr-x   1 etchuser etchuser      820 Apr  6  2015 initscripts_2.88dsf-59_i386/etc/init.d/rc.local

2794135    8 -rwxr-xr-x   1 etchuser etchuser     4836 Aug 13  2014 nfs-kernel-server_1%3a1.2.8-9_i386/etc/init.d/nfs-kernel-server
2793951    8 -rwxr-xr-x   1 etchuser etchuser     4836 Dez 17 11:49 nfs-kernel-server_1%3a1.3.4-2_i386/etc/init.d/nfs-kernel-server

Diese sogenannten conffiles haben keine im Paket hinterlegt Checksumme,
siehe /var/lib/dpkg/info/
(den Dateien dort dürfte aber auch nicht mehr zu trauen zu sein).



Ein forensisches Image des Rechners,
Untersuchung auf mögliche Sicherheitslücken?
Ein Konstrukt aus dd/nc (zur Laufzeit) dürfte zwar länger dauern,
sollte aber auch gut versteckte Rootkitdateien mit übertragen.
(Wobei ich voraussetze, daß irgendwas des eventuellen Rootkit auch permanent auf Platte liegen sollte.)
Zum Vergleich dann auch Images des Server im heruntergefahrenen Zustand von einer Administrationskonsole/Rettungssystem aus.

Ich lasse dabei außer Acht, daß sich richtig gute malware vielleicht in bios/firmware der Geräte verstecken könnte,
auf den üblichen Datenträgern sich nichts substanzielles davon fände.

[Tintom]

Interessante Sache. Um zu erfahren, wer für die "getouchten" Dateien verantwortlich ist, vielleicht mal incron ausprobieren und das Beispiel von hier[1] auf den konreten Fall abändern?

[1] http://www.admin-magazin.de/Das-Heft/20 ... eberwachen

[mkm]

incron kannte ich bisher noch nicht.
Hast Du noch einen Tipp wie man "Wer toucht" damit ermitteln kann?
Ich sehe zwar die Möglichkeit ein Skript auszuführen wenn die Datei getoucht wurde , ich wüßte aber nicht wie ich dann noch ermitteln könnte wer das getan hat. Der Touch ist ja schon vorbei.
Ich werde incron aber mal auf setzten um zu schauen wann diese Dateien geändert werden.

[MSfree]

Es gibt für Linux Process Accounting, mit dem man jede Programmausfürung protokollieren lassen kann. Das ganze ist natürlich Big Brother hoch 4 und sollte im normalen Betrieb eher nicht genutzt werden. Aber in diesem Fall könnte es wertvolle Hinweise liefern:

http://www.tldp.org/HOWTO/text/Process-Accounting

[rendegast]

google: "touched file what process" >>

You can use auditd and add a rule for that file to be watched:

Code: Alles auswählen

auditctl -w /path/to/that/file -p wa

Then watch for entries to be written to /var/log/audit/audit.log.

Paket auditd

Voraussetzung,
die Änderung passiert unbeabsichtigt, unfallartig.
Ein richtig gutes rootkit sollte entsprechende Gegenmaßnahmen in Petto haben,
verhält sich zBsp. bei Gegenwart solcher Überwacher absolut passiv.

[mkm]

Ich möchte um Entschuldigung bitten!

Bei der Durchsicht der bash history fand ich folgende Zeilen:

308 lrwxrwxrwx 1 root root 14 Jun 22 2015 S15cron -> ../init.d/cron
309 lrwxrwxrwx 1 root root 27 Jun 22 2015 S15nfs-kernel-server -> ../init.d/nfs-kernel-server
310 lrwxrwxrwx 1 root root 18 Jun 22 2015 S16rc.local -> ../init.d/rc.local
311 lrwxrwxrwx 1 root root 19 Jun 22 2015 S16rmnologin -> ../init.d/rmnologin

offensichtlich ein copy/paste Fehler in einem putty Fenster, der dazu führte, das diese Zeilen als Befehl ausgeführt wurden.
Alles Einträge mit denen die Bash nichts anfangen kann, bis auf den letzten Teil, z. Bsp. > ../init.d/cron.
Dies führt dazu, dass die cron Datei geleert wird.

aus http://tldp.org/LDP/abs/html/io-redirection.html:

> filename
# The > truncates file "filename" to zero length.
# If file not present, creates zero-length file (same effect as 'touch').
# (Same result as ": >", above, but this does not work with some shells.)


Der touch kommt offensichtlich vom init Prozess, der beim Booten diese Dateien sucht und nicht findet.
Das die cron Datei nicht betroffen war, lag daran, dass ich diese bereits vor dem reboot von einem anderen Server kopiert hatte.
Nachdem ich alle Dateien wiederhergestellt hatte "toucht" auch ein reboot diese Dateien nicht mehr.

Mea Culpa!

(aber wenigstens habe ich eine Erklärung und es ist kein rootkit)

Lieben Dank an alle die mir helfen wollten, leider war mir nicht zu helfen
Gruß
Manfred