crontab & named ändern passwörter - Einbruchversuche ??

ms-networker

ms-networker

Registered User
Morgen zusammen,

irgendiwe bin ich in den letzten Tagen sher angefressen, meine /var/log/messages wird von tag zu tag immer größer...

Nun zu meinem anliegen: Heute morgen ist mir aufgefallen das meine "/var/log/messages" komische Sachen da auf dem Bildschrm postet, habe es etwas abgekürzt.

Code: 
Jul  9 07:34:14 s1xxxxx crontab[6140]: (root) LIST (user1)
Jul  9 07:34:15 s1xxxxx crontab[6143]: (root) LIST (user2)
Jul  9 07:34:15 s1xxxxx crontab[6146]: (root) LIST (user3)
Jul  9 07:34:16 s1xxxxx crontab[6154]: (root) LIST (user4)
Jul  9 07:34:16 s1xxxxx crontab[6155]: (root) REPLACE (user4)
Jul  9 07:34:16 s1xxxxx passwd[6157]: password changed - account=user4, uid=10004, by=0
Jul  9 07:34:16 s1xxxxx crontab[6159]: (root) LIST (user1)
Jul  9 07:34:16 s1xxxxx crontab[6160]: (root) REPLACE (user1)
Jul  9 07:34:16 s1xxxxx passwd[6162]: password changed - account=user1, uid=10005, by=0
Jul  9 07:34:16 s1xxxxx crontab[6164]: (root) LIST (user2)
Jul  9 07:34:16 s1xxxxx crontab[6165]: (root) REPLACE (user2)
Jul  9 07:34:16 s1xxxxx passwd[6167]: password changed - account=user2, uid=10016, by=0
Jul  9 07:34:19 s1xxxxx named[3877]: loading configuration from '/etc/named.conf'
Jul  9 07:34:19 s1xxxxx named[3877]: no IPv6 interfaces found
Jul  9 07:34:19 s1xxxxx named[3877]: none:0: open: /etc/rndc.key: permission denied
Jul  9 07:34:19 s1xxxxx named[3877]: couldn't add command channel 127.0.0.1#953: permission denied
Jul  9 07:34:19 s1xxxxx named[3877]: zone xxx.xxx.xxx.in-addr.arpa/IN: loaded serial 1247117659
Jul  9 07:34:19 s1xxxxx named[3877]: zone domain.tld/IN: zone serial unchanged
Jul  9 07:34:19 s1xxxxx named[3877]: zone domain.tld/IN: loaded serial 1227103180

Dementsprechend konntei ich auch (wenn auch nur wirklich kurzzeitig) keine Mails verschicken bz.w empfangen "Login Failed"

Sofort habe ich mir die "messages" per ssh an meine Mail geschickt um Sie genauer zu Untersuchen, habe aber keinen Hinweis auf was verdächtiges gefunden.
Hat jemand eine Idee woher das kommen könnte ??? Wäre für jeden Hinweis dankbar.

// EDIT:

Ist es möglich das es mit Plesk & Greylist zusammen gehangen haben könnte? Ich hatte kurze Zeit vorher im Plesk 9.2.1 / Einstellungen / Spamfilter / die Option Greylisting aktivieren gefunden, natürlich auch sofort dann angeklickt. Plesk gab irgendwie kurz n Fehler dazu aus, lies aber die Option angehackt. Nachdem ganzen schreck jetzt habe ich das erstmal ausgeschaltet (wieder Fehler) und den Server neusgestartet, jetzt ist erstmal alles ruhig, ka. ob das damit zusammenhängen kann??

Gruß
ms-networker
 
Last edited by a moderator:
Läuft bei Dir eine Admin-Oberfläche, cpanel oder so?

crontab ist eigentlich das Programm zum Ändern von Cron-Einträgen (siehe man 1 crontab) - nicht der cron daemon selbst.
Falls nicht absichtlich gestartet, war es wohl mehr als ein Einbruchsversuch - da ist was mit Root-Rechten gelaufen (in 2 Sekunden - vermutlich ein Script).

Die Meldungen beim named sehen mir nach Rechteproblemen aus. rndc.key sollte (nur) von der UID des Nameservers gelesen werden können.
 
Mist, ich habe schon sowas befürchtet ....

erstmal danke für die Antwort, Ich habe soeben doch bemerkt das es nicht mit Greylisting/styling zusammen hängt da es erneut wieder auftritt. Ich werde sofort mal sehen was Crontab eingetragen hat.

Es hat definitiv keine besonderen Änderungen zuletzt gegeben die sowas rechtfertigen würden, wie gesagt, erst seit heut morgen....

Danke schonmal
ms-networker
 
Folgendes bekomme ich ausgegeben bei "crontab -l"

Code: 
s1xxxxx:~ # crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Mon Dec  8 20:54:17 2008)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Wed Oct 22 10:24:56 2008)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.keepup2date installed on Fri Sep 19 11:51:24 2008)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/usr/local/psa/tmp/crontabaQRDhD installed on Tue Sep  2 23:44:04 2008)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
[email protected]
##check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
*/15    *       *       *       *       test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1
14      5       *       *       *       /usr/local/psa/bin/mysqldump.sh >/dev/null 2>&1
7       4       *       *       *       /usr/local/psa/admin/sbin/statistics >/dev/null 2>&1
30      *       *       *       *       /usr/local/psa/admin/sbin/backupmng >/dev/null 2>&1
17      7       *       *       *       /usr/local/psa/admin/bin/php /usr/local/psa/admin/plib/report/autoreport.php --auto daily >/dev/null 2>&1
17      7       *       *       1       /usr/local/psa/admin/bin/php /usr/local/psa/admin/plib/report/autoreport.php --auto weekly >/dev/null 2>&1
17      7       1       *       *       /usr/local/psa/admin/bin/php /usr/local/psa/admin/plib/report/autoreport.php --auto monthly >/dev/null 2>&1
19      0       *       *       *       /usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.daily
9       5       *       *       7       /usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.weekly
18      5       1       *       *       /usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.monthly
0       1       *       *       1       /usr/local/psa/libexec/modules/watchdog/cp/send-report weekly
10      1       *       *       *       /usr/local/psa/libexec/modules/watchdog/cp/clean-sysstats
15      1       *       *       *       /usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats day
15      1       *       *       1       /usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats week
15      1       1       *       *       /usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats month
15      1       1       *       *       /usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats year
20      1       *       *       *       /usr/local/psa/libexec/modules/watchdog/cp/clean-events
0       3       *       *       7       /usr/local/psa/libexec/modules/watchdog/cp/clean-reports

Keine Ahnung was davon vll. nicht ok ist, ich geh die erstmal nacheinander durch.
 
Oben sind auch die Crontabs von user1, user2 und user4 geändert worden - bei SuSE liegen die unter /var/spool/cron/tabs.

Falls Du alle crontabs durchgehen willst - denke auch an /etc/cron.(daily|weekly|monthly|d).

Falls das System wirklich kompromittiert wurde, würde ich vor weiteren Aktionen einen (forensischen) Dump machen - z.B. auf den FTP-Backupspace.
 
Ich glaube ich den Fehler gefunden....

Login in Plesk hat mit geholfen. Dort habe ich gesehen das diverse Domains gesperrt sind, per Hand in Plesk entsperren will Plesk nicht weil wohl gerade Backups dort läuft. Ich habe zwar überall dieses Backup beendet kann aber immer noch diese Sperre nicht aufheben selbst nach Neustart tut sich dort nix.

Den verantwortlichen Crontab habe ich erstmal auch direkt deaktiviert, aber leider immer noch kein entsperren möglich, da Plesk der Meinung ist er müsse immer noch die Backups machen obwohl Sie nicht laufen. Hat jemand eine Idee wie ich das wieder hinbekomme, derzeit sind 3 Domänen davon betroffen -.-

// EDIT :

Habe eine zuvor gesicherte Server-Config ohne Webinahlte per Backupmanager eingespielt und damit habe ich das lösen können.

Wüsste eigentlich nur gerne warum der ein Komplett-Backup um diese Zeit macht und dabei die Daomains abschaltet???

Vielen Dank
ms-networker
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top