5
suche Rat fuer Analyse der Datei auth.log
Ich habe den Verdacht, dass ein Angriff auf meinen Server gemacht wird.
Da aber durch Verschaerfung der Sicherheitsmassnahmen keine Aenderung aufgetreten ist, bin ich verunsichert, ob ich Recht habe.
Daher bitte ich um Analyse der Datei /var/log/auth.log von einem Fachkundigen.
Ich habe vor ein paar Wochen einen automatischen Hinweis von meinem SSH-Server bekommen, dass moeglicherweise ein Man-In-The-Middle-Attack beim Einloggen ueber SSH stattfinden koennte.
Daraufhin habe ich die oben genannte Datei ueberprueft und staendige Login-Versuche mit eventl. positiven Ausgang beobachtet.
Daher habe ich meine SSH-Sicherheit von Name/Passwort auf Oeffentlichen/Privaten-Key gewechselt. Der private Key ist noch zusaetzlich mit eine Passwort gfeschuetzt.
Root-Zugriff will ich nicht sperren.
Heute habe ich die log-Datei wieder ueberprueft und das gleiche Verhalten beobachtet.
Nun bin ich unsicher, ob ich ueberhaupt die Datei richtig verstanden habe und poste hier sie, damit ein Fachkundiger unter Euch mir sagen kann, was der log genau bedeutet.
Danke fuer Eure Hilfe, LennyB.
Auszug aus der Datei /var/log/auth.log
Mar 10 04:39:01 noname CRON[16568]: (pam_unix) session opened for user root by (uid=0)
Mar 10 04:39:02 noname CRON[16568]: (pam_unix) session closed for user root
Mar 10 05:09:01 noname CRON[16578]: (pam_unix) session opened for user root by (uid=0)
Mar 10 05:09:01 noname CRON[16578]: (pam_unix) session closed for user root
Mar 10 05:17:01 noname CRON[16588]: (pam_unix) session opened for user root by (uid=0)
Mar 10 05:17:01 noname CRON[16588]: (pam_unix) session closed for user root
Mar 10 05:39:01 noname CRON[16591]: (pam_unix) session opened for user root by (uid=0)
Mar 10 05:39:01 noname CRON[16591]: (pam_unix) session closed for user root
Mar 10 06:09:01 noname CRON[16601]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:09:02 noname CRON[16601]: (pam_unix) session closed for user root
Mar 10 06:10:01 noname CRON[16611]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:11:01 noname CRON[16618]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:17:02 noname CRON[16625]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:17:02 noname CRON[16625]: (pam_unix) session closed for user root
Mar 10 06:25:01 noname CRON[16628]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:25:03 noname su[16659]: Successful su for nobody by root
Mar 10 06:25:03 noname su[16659]: + ??? root:nobody
Mar 10 06:25:03 noname su[16659]: (pam_unix) session opened for user nobody by (uid=0)
Mar 10 06:25:03 noname su[16659]: (pam_unix) session closed for user nobody
Mar 10 06:25:03 noname su[16661]: Successful su for nobody by root
Mar 10 06:25:03 noname su[16661]: + ??? root:nobody
Mar 10 06:25:03 noname su[16661]: (pam_unix) session opened for user nobody by (uid=0)
Mar 10 06:25:03 noname su[16661]: (pam_unix) session closed for user nobody
Mar 10 06:25:03 noname su[16663]: Successful su for nobody by root
Mar 10 06:25:03 noname su[16663]: + ??? root:nobody
Mar 10 06:25:03 noname su[16663]: (pam_unix) session opened for user nobody by (uid=0)
Mar 10 06:27:18 noname su[16663]: (pam_unix) session closed for user nobody
Mar 10 06:39:01 noname CRON[16737]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:39:01 noname CRON[16737]: (pam_unix) session closed for user root
Mar 10 07:09:01 noname CRON[16747]: (pam_unix) session opened for user root by (uid=0)
Mar 10 07:09:01 noname CRON[16747]: (pam_unix) session closed for user root
Mar 10 07:17:01 noname CRON[16757]: (pam_unix) session opened for user root by (uid=0)
Mar 10 07:17:01 noname CRON[16757]: (pam_unix) session closed for user root
Mar 10 07:39:01 noname CRON[16760]: (pam_unix) session opened for user root by (uid=0)
Mar 10 07:39:02 noname CRON[16760]: (pam_unix) session closed for user root
Mar 10 08:09:01 noname CRON[16770]: (pam_unix) session opened for user root by (uid=0)
Mar 10 08:09:01 noname CRON[16770]: (pam_unix) session closed for user root
Mar 10 08:17:01 noname CRON[16788]: (pam_unix) session opened for user root by (uid=0)
Mar 10 08:17:02 noname CRON[16788]: (pam_unix) session closed for user root
Mar 10 08:39:01 noname CRON[16791]: (pam_unix) session opened for user root by (uid=0)
Da aber durch Verschaerfung der Sicherheitsmassnahmen keine Aenderung aufgetreten ist, bin ich verunsichert, ob ich Recht habe.
Daher bitte ich um Analyse der Datei /var/log/auth.log von einem Fachkundigen.
Ich habe vor ein paar Wochen einen automatischen Hinweis von meinem SSH-Server bekommen, dass moeglicherweise ein Man-In-The-Middle-Attack beim Einloggen ueber SSH stattfinden koennte.
Daraufhin habe ich die oben genannte Datei ueberprueft und staendige Login-Versuche mit eventl. positiven Ausgang beobachtet.
Daher habe ich meine SSH-Sicherheit von Name/Passwort auf Oeffentlichen/Privaten-Key gewechselt. Der private Key ist noch zusaetzlich mit eine Passwort gfeschuetzt.
Root-Zugriff will ich nicht sperren.
Heute habe ich die log-Datei wieder ueberprueft und das gleiche Verhalten beobachtet.
Nun bin ich unsicher, ob ich ueberhaupt die Datei richtig verstanden habe und poste hier sie, damit ein Fachkundiger unter Euch mir sagen kann, was der log genau bedeutet.
Danke fuer Eure Hilfe, LennyB.
Auszug aus der Datei /var/log/auth.log
Mar 10 04:39:01 noname CRON[16568]: (pam_unix) session opened for user root by (uid=0)
Mar 10 04:39:02 noname CRON[16568]: (pam_unix) session closed for user root
Mar 10 05:09:01 noname CRON[16578]: (pam_unix) session opened for user root by (uid=0)
Mar 10 05:09:01 noname CRON[16578]: (pam_unix) session closed for user root
Mar 10 05:17:01 noname CRON[16588]: (pam_unix) session opened for user root by (uid=0)
Mar 10 05:17:01 noname CRON[16588]: (pam_unix) session closed for user root
Mar 10 05:39:01 noname CRON[16591]: (pam_unix) session opened for user root by (uid=0)
Mar 10 05:39:01 noname CRON[16591]: (pam_unix) session closed for user root
Mar 10 06:09:01 noname CRON[16601]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:09:02 noname CRON[16601]: (pam_unix) session closed for user root
Mar 10 06:10:01 noname CRON[16611]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:11:01 noname CRON[16618]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:17:02 noname CRON[16625]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:17:02 noname CRON[16625]: (pam_unix) session closed for user root
Mar 10 06:25:01 noname CRON[16628]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:25:03 noname su[16659]: Successful su for nobody by root
Mar 10 06:25:03 noname su[16659]: + ??? root:nobody
Mar 10 06:25:03 noname su[16659]: (pam_unix) session opened for user nobody by (uid=0)
Mar 10 06:25:03 noname su[16659]: (pam_unix) session closed for user nobody
Mar 10 06:25:03 noname su[16661]: Successful su for nobody by root
Mar 10 06:25:03 noname su[16661]: + ??? root:nobody
Mar 10 06:25:03 noname su[16661]: (pam_unix) session opened for user nobody by (uid=0)
Mar 10 06:25:03 noname su[16661]: (pam_unix) session closed for user nobody
Mar 10 06:25:03 noname su[16663]: Successful su for nobody by root
Mar 10 06:25:03 noname su[16663]: + ??? root:nobody
Mar 10 06:25:03 noname su[16663]: (pam_unix) session opened for user nobody by (uid=0)
Mar 10 06:27:18 noname su[16663]: (pam_unix) session closed for user nobody
Mar 10 06:39:01 noname CRON[16737]: (pam_unix) session opened for user root by (uid=0)
Mar 10 06:39:01 noname CRON[16737]: (pam_unix) session closed for user root
Mar 10 07:09:01 noname CRON[16747]: (pam_unix) session opened for user root by (uid=0)
Mar 10 07:09:01 noname CRON[16747]: (pam_unix) session closed for user root
Mar 10 07:17:01 noname CRON[16757]: (pam_unix) session opened for user root by (uid=0)
Mar 10 07:17:01 noname CRON[16757]: (pam_unix) session closed for user root
Mar 10 07:39:01 noname CRON[16760]: (pam_unix) session opened for user root by (uid=0)
Mar 10 07:39:02 noname CRON[16760]: (pam_unix) session closed for user root
Mar 10 08:09:01 noname CRON[16770]: (pam_unix) session opened for user root by (uid=0)
Mar 10 08:09:01 noname CRON[16770]: (pam_unix) session closed for user root
Mar 10 08:17:01 noname CRON[16788]: (pam_unix) session opened for user root by (uid=0)
Mar 10 08:17:02 noname CRON[16788]: (pam_unix) session closed for user root
Mar 10 08:39:01 noname CRON[16791]: (pam_unix) session opened for user root by (uid=0)
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 82761
Url: https://administrator.de/forum/suche-rat-fuer-analyse-der-datei-auth-log-82761.html
Ausgedruckt am: 15.04.2025 um 10:04 Uhr
5 Kommentare
Neuester Kommentar
Die Sessions werden offenbar durch den Cron-Daemon geöffnet. Sorgen solltest du dir vor allem über die Ausgabe
'Mar 10 06:25:03 noname su[16661]: + ??? root:nobody'
machen. Ähnliches hatte ich auch vor kurzem auf einem Server gesehen und dort wurde der SSH-Server durch einen anderen bei einem Angriff ausgetauscht. Schau mal nach, ob du in /dev eine seltsame Datei hast, die sich 'saux' oder ähnlich nennt und keine Device-Datei ist (enthält meist Benutzernamen und Passwörter des Servers im Klartext, sofern sich User via SSH mit Passwort eingeloggt haben. Schau ausserdem, ob als SSH-Server wirklich der /usr/sbin/sshd läuft und nicht etwa /usr/local/sbin/sshd (/usr/local wäre nur bei einem BSD-System, nicht aber bei einem Linux korrekt, sofern der SSH-Server der Distro verwendet wird). Ausserdem war auffällig, dass ein Prozess lief, der in der Prozessliste als '???' auftauchte. (vermutlich der, der bei dir die SUIDs macht). Dieser startete beim Restart des SSH-Servers automatisch den Fake-Server und killte das Original. Und überprüfe natürlich, ob der SSH-Server immernoch den korrekten Fingerprint zurückgibt, den er auch bei der Einrichtung des Servers hatte. Geänderte Fingerprints weisen immer auf ein anderes Zertifikat hin, das nicht das ursprüngliche ist.
Solltest du diese Phänomene bei deinem Server beobachten, setze ihn am besten komplett neu auf, lege dann den SSH-Port auf einen anderen Port und mache den Default-Port 22 zusätzlich via Firewall dicht. Ausserdem root-Login via SSH verbieten und Passwort-Authentifizierung komplett abschalten. Und zu guter Letzt natürlich Programme wie ftp, wget, lynx u.ä., womit man Sachen aus dem Netz nachladen kann, komplett deinstallieren oder umbenennen. Leider konnte ich bisher noch nicht rausbekommen welche Lücke da genutzt wurde. Es ist jedenfalls kein mir bekannter Rootkit und auch rkhunter und chkrootkit finden nur die Nicht-Device-Datei in /dev, sonst aber keine Spuren.
'Mar 10 06:25:03 noname su[16661]: + ??? root:nobody'
machen. Ähnliches hatte ich auch vor kurzem auf einem Server gesehen und dort wurde der SSH-Server durch einen anderen bei einem Angriff ausgetauscht. Schau mal nach, ob du in /dev eine seltsame Datei hast, die sich 'saux' oder ähnlich nennt und keine Device-Datei ist (enthält meist Benutzernamen und Passwörter des Servers im Klartext, sofern sich User via SSH mit Passwort eingeloggt haben. Schau ausserdem, ob als SSH-Server wirklich der /usr/sbin/sshd läuft und nicht etwa /usr/local/sbin/sshd (/usr/local wäre nur bei einem BSD-System, nicht aber bei einem Linux korrekt, sofern der SSH-Server der Distro verwendet wird). Ausserdem war auffällig, dass ein Prozess lief, der in der Prozessliste als '???' auftauchte. (vermutlich der, der bei dir die SUIDs macht). Dieser startete beim Restart des SSH-Servers automatisch den Fake-Server und killte das Original. Und überprüfe natürlich, ob der SSH-Server immernoch den korrekten Fingerprint zurückgibt, den er auch bei der Einrichtung des Servers hatte. Geänderte Fingerprints weisen immer auf ein anderes Zertifikat hin, das nicht das ursprüngliche ist.
Solltest du diese Phänomene bei deinem Server beobachten, setze ihn am besten komplett neu auf, lege dann den SSH-Port auf einen anderen Port und mache den Default-Port 22 zusätzlich via Firewall dicht. Ausserdem root-Login via SSH verbieten und Passwort-Authentifizierung komplett abschalten. Und zu guter Letzt natürlich Programme wie ftp, wget, lynx u.ä., womit man Sachen aus dem Netz nachladen kann, komplett deinstallieren oder umbenennen. Leider konnte ich bisher noch nicht rausbekommen welche Lücke da genutzt wurde. Es ist jedenfalls kein mir bekannter Rootkit und auch rkhunter und chkrootkit finden nur die Nicht-Device-Datei in /dev, sonst aber keine Spuren.
Ich habe nur eine psaux.
Ansonsten laeuft die sshd unter /usr/sbin/
Das mit dem Fingerprint kann ich wohl nicht ueberpruefen, da ich ihn beim aufsetzen des servers haette speichern muessen, oder?
Was mich davon abhaelt, an eine Attacke zu denken, ist, dass der SSH-Server schon unter einem anderen Port liegt und der Server an sich nicht oeffentlich ist. (http-server ist nicht auffindbar mit google z.B.)
Die einzige Moeglichkeit ist die, dass man ueber dyndns oder ip-Massensuche auf meinen Server gestossen ist. Dass man aber auch noch den Port findet, erachte ich als sehr unwahrscheinlich.
Was ich auch nicht verstehe, ist, was der cron-daemon da zu suchen hat. Hm, habe gerade nachgeschaut. Da ich erst auf Debian gewechselt bin, ist mir im crontab der Fehler unterlaufen, den Benutzer nicht hinzuzufuegen. Vielleicht liegt es daran.
Unten hab ich meine /dev aufgelistet. psaux ist nicht als Datei oeffenbar, also anscheinend ist da alles korrekt.
audio mtd1 ptyp2 ram5 tty12 tty35 tty58 ttypf
bus mtd1ro ptyp3 ram6 tty13 tty36 tty59 ttyS0
console mtd2 ptyp4 ram7 tty14 tty37 tty6 ttyS1
core mtd2ro ptyp5 ram8 tty15 tty38 tty60 urandom
disk mtd3 ptyp6 ram9 tty16 tty39 tty61 usbdev1.1_ep00
dsp mtd3ro ptyp7 random tty17 tty4 tty62 usbdev1.1_ep81
fb0 mtd4 ptyp8 rtc tty18 tty40 tty63 usbdev1.3_ep00
fd mtd4ro ptyp9 rtc0 tty19 tty41 tty7 usbdev1.3_ep83
full mtd5 ptypa sda tty2 tty42 tty8 usbdev2.1_ep00
fuse mtd5ro ptypb sda1 tty20 tty43 tty9 usbdev2.1_ep81
hwrng mtdblock0 ptypc sda2 tty21 tty44 ttyp0 usbdev3.1_ep00
i2c-0 mtdblock1 ptypd sda5 tty22 tty45 ttyp1 usbdev3.1_ep81
initctl mtdblock2 ptype sdb tty23 tty46 ttyp2 usbdev3.3_ep00
input mtdblock3 ptypf sdb1 tty24 tty47 ttyp3 usbdev3.3_ep81
ixp4xx_ucode mtdblock4 ram0 shm tty25 tty48 ttyp4 usbdev3.4_ep00
kmem mtdblock5 ram1 snd tty26 tty49 ttyp5 usbdev3.4_ep02
kmsg net ram10 sndstat tty27 tty5 ttyp6 usbdev3.4_ep81
log null ram11 stderr tty28 tty50 ttyp7 usbdev3.5_ep00
loop port ram12 stdin tty29 tty51 ttyp8 usbdev3.5_ep02
MAKEDEV ppp ram13 stdout tty3 tty52 ttyp9 usbdev3.5_ep81
mapper psaux ram14 tty tty30 tty53 ttypa vcs
mem ptmx ram15 tty0 tty31 tty54 ttypb vcsa
mixer pts ram2 tty1 tty32 tty55 ttypc watchdog
mtd0 ptyp0 ram3 tty10 tty33 tty56 ttypd xconsole
mtd0ro ptyp1 ram4 tty11 tty34 tty57 ttype zero
Ansonsten laeuft die sshd unter /usr/sbin/
Das mit dem Fingerprint kann ich wohl nicht ueberpruefen, da ich ihn beim aufsetzen des servers haette speichern muessen, oder?
Was mich davon abhaelt, an eine Attacke zu denken, ist, dass der SSH-Server schon unter einem anderen Port liegt und der Server an sich nicht oeffentlich ist. (http-server ist nicht auffindbar mit google z.B.)
Die einzige Moeglichkeit ist die, dass man ueber dyndns oder ip-Massensuche auf meinen Server gestossen ist. Dass man aber auch noch den Port findet, erachte ich als sehr unwahrscheinlich.
Was ich auch nicht verstehe, ist, was der cron-daemon da zu suchen hat. Hm, habe gerade nachgeschaut. Da ich erst auf Debian gewechselt bin, ist mir im crontab der Fehler unterlaufen, den Benutzer nicht hinzuzufuegen. Vielleicht liegt es daran.
Unten hab ich meine /dev aufgelistet. psaux ist nicht als Datei oeffenbar, also anscheinend ist da alles korrekt.
audio mtd1 ptyp2 ram5 tty12 tty35 tty58 ttypf
bus mtd1ro ptyp3 ram6 tty13 tty36 tty59 ttyS0
console mtd2 ptyp4 ram7 tty14 tty37 tty6 ttyS1
core mtd2ro ptyp5 ram8 tty15 tty38 tty60 urandom
disk mtd3 ptyp6 ram9 tty16 tty39 tty61 usbdev1.1_ep00
dsp mtd3ro ptyp7 random tty17 tty4 tty62 usbdev1.1_ep81
fb0 mtd4 ptyp8 rtc tty18 tty40 tty63 usbdev1.3_ep00
fd mtd4ro ptyp9 rtc0 tty19 tty41 tty7 usbdev1.3_ep83
full mtd5 ptypa sda tty2 tty42 tty8 usbdev2.1_ep00
fuse mtd5ro ptypb sda1 tty20 tty43 tty9 usbdev2.1_ep81
hwrng mtdblock0 ptypc sda2 tty21 tty44 ttyp0 usbdev3.1_ep00
i2c-0 mtdblock1 ptypd sda5 tty22 tty45 ttyp1 usbdev3.1_ep81
initctl mtdblock2 ptype sdb tty23 tty46 ttyp2 usbdev3.3_ep00
input mtdblock3 ptypf sdb1 tty24 tty47 ttyp3 usbdev3.3_ep81
ixp4xx_ucode mtdblock4 ram0 shm tty25 tty48 ttyp4 usbdev3.4_ep00
kmem mtdblock5 ram1 snd tty26 tty49 ttyp5 usbdev3.4_ep02
kmsg net ram10 sndstat tty27 tty5 ttyp6 usbdev3.4_ep81
log null ram11 stderr tty28 tty50 ttyp7 usbdev3.5_ep00
loop port ram12 stdin tty29 tty51 ttyp8 usbdev3.5_ep02
MAKEDEV ppp ram13 stdout tty3 tty52 ttyp9 usbdev3.5_ep81
mapper psaux ram14 tty tty30 tty53 ttypa vcs
mem ptmx ram15 tty0 tty31 tty54 ttypb vcsa
mixer pts ram2 tty1 tty32 tty55 ttypc watchdog
mtd0 ptyp0 ram3 tty10 tty33 tty56 ttypd xconsole
mtd0ro ptyp1 ram4 tty11 tty34 tty57 ttype zero
Wenn ein Prozess über den Cron-Daemon ohne Benutzer-Eintrag läuft, kann es natürlich auch zu solchen Meldungen kommen. Crons laufen bei Debian regelmässig um z.B. Log-Dateien zu rotieren Manpage-Datenbanken zu aktualisieren usw. Das ist also nichts ungewöhnliches.
Die Meldung mit der Man-in-the-middle-attacke kommt vor allem dann,wenn der ssh key ausgetauscht wurde, z. B. wenn man noch einen alten ssh key von diesem ssh server in seinem lokalen client speicher hat (known_hosts?) , und der ssh server wird neu aufgesetzt, dann merkt der client dass der öffentliche Schlüssel nicht passt und frägt nach ob das ok ist.
Sorgen solltest du
dir vor allem über die Ausgabe
'Mar 10 06:25:03 noname su[16661]: +
??? root:nobody'
Zur Erhellung der Beitrag: "Successful su for nobody by root?"
Ansonsten kann ich Deinem Log nichts Erheiterndes, Besorgniserregendes oder Auffälliges entnehmen.
saludos
gnarff
