[gelöst] Beunruhigende Einträge in security run output!

[hok]

Hallo,

ich habe in den letzten Tagen von meinem Freenas-Server security-run-output Mails bekommen - mit sehr merkwürdigen Sicherheitsmeldungen. Ich vermutete, daß sind fehlgeschlagene Loginversuche von außen.
Das allein beunruhigte mich erst gar nicht so sehr, bis mir auffiel, daß ich exakt vor einem Jahr, exakt gleichlautende Mails bekommen habe (ich hebe die Mails alle auf). Das empfinde ich nun als gespenstisch. Noch mehr irritiert mich auch die eine Zeile jeweils vom 18.11.: „Failed password for tobias from 192.168.2.123…“ - Das ist mein Laptop. Ich weiß sicher, daß der Laptop zwar lief, ich aber gar nicht zu Hause war!

Kann mir jemand helfen, dieses Phänomen zu deuten?
Auch kenne ich nicht den Unterschied der Meldungen „Failed password“ und „Authentication refused“

Hier die Logmeldungen (sie beginnen jeweils am 16.11. und gingen 2014 bis zum 22., ich habe folgend nur die vom 16., 18., und 20. ausgewählt)

Code:

16.11.15
freenas.local login failures:
Nov 15 02:16:34 freenas sshd[22595]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 15 11:29:19 freenas sshd[82139]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 15 12:46:45 freenas sshd[85276]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys


16.11.14 (!)
freenas.local login failures:
Nov 15 02:16:34 freenas sshd[22595]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 15 11:29:19 freenas sshd[82139]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 15 12:46:45 freenas sshd[85276]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys

(...)

18.11.2015
freenas.local login failures:
Nov 17 12:26:50 freenas sshd[4053]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 17 12:26:57 freenas sshd[4053]: Failed password for tobias from 192.168.2.123 port 59033 ssh2
Nov 17 13:19:17 freenas sshd[3959]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 17 13:43:57 freenas sshd[3983]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys


18.11.2014 (!)
freenas.local login failures:
Nov 17 12:26:50 freenas sshd[4053]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 17 12:26:57 freenas sshd[4053]: Failed password for tobias from 192.168.2.123 port 59033 ssh2
Nov 17 13:19:17 freenas sshd[3959]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 17 13:43:57 freenas sshd[3983]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys

(...)

20.11.2015
freenas.local login failures:
Nov 19 01:52:38 freenas sshd[17888]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 11:12:16 freenas sshd[4458]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 15:20:36 freenas sshd[13811]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 15:49:07 freenas sshd[12235]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 16:49:13 freenas sshd[5698]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 17:12:16 freenas sshd[9628]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 21:55:07 freenas sshd[79152]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 21:59:51 freenas sshd[80036]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 22:44:33 freenas sshd[82289]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys



20.11.2014
freenas.local login failures:
Nov 19 01:52:38 freenas sshd[17888]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 11:12:16 freenas sshd[4458]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 15:20:36 freenas sshd[13811]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 15:49:07 freenas sshd[12235]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 16:49:13 freenas sshd[5698]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 17:12:16 freenas sshd[9628]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 21:55:07 freenas sshd[79152]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 21:59:51 freenas sshd[80036]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys
Nov 19 22:44:33 freenas sshd[82289]: Authentication refused: bad ownership or modes for file /mnt/dp1/User/tobias/.ssh/authorized_keys

Grüße aus der Ratlosigkeit
Seb.

 

[xaibex]

nutzt du zufällig ein backupprogramm über fts/sftp von deinem laptop aus?

was sagt "ls- la /mnt/dp1/User/tobias/.ssh/" ?
authorized_keys sollte Berechtigungen 600 haben und .ssh 700.
ändern kannst du es mit:

Code:

chmod 700 /home/your_user/.ssh
chmod 600 /home/your_user/.ssh/authorized_keys

 

[hok]

Hallo xaibex,

Danke erstmal.
Nein, kein Backup mit dem Laptop. Backup geht täglich vom Server auf einen (Freenas-)Backupserver.

Code:

tobias@freenas:~ % ls -la /mnt/dp1/User/tobias/.ssh/
total 74
drwx------  2 tobias  tobias    3 Nov 15  2014 ./
drwxr-----  3 tobias  tobias   14 May  3  2015 ../
-rw-r-----  1 tobias  tobias  797 Dec  6  2014 authorized_keys

Aber berührt das überhaupt das Problem, daß vor einem Jahr auf die Sekunde dieselben Zugriffsversuche (?) stattfanden - und dieses falsche Passwort von meinem Laptop - ohne daß ich zu Hause war?


EDIT/
Beim Einloggen via ssh mit dem Terminal, um die ls -la Abfrage zu machen, wunderte ich mich, daß der Laptop angeblich den Server noch nicht gelistet hat:

Code:

MacBook-WLAN:~ tobias$ ssh freenas-server
The authenticity of host 'freenas-server (#IP#)' can't be established.
RSA key fingerprint is ##fingerprint##.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'freenas-server' (RSA) to the list of known hosts.

Last login: Wed Dec 31 00:35:42 2014 from ##IP##
FreeBSD 9.2-RELEASE-p12 (FREENAS.amd64) #0 r262572+b043649: Sun Sep 28 23:03:31 PDT 2014

hok

 

[gottestod]

Hallo hok!

Die gute Nachricht: Das sind die gleichen Logs. Selbst die PIDs sind gleich. Alles andere wäre schon sehr unwahrscheinlich.
Die Schlechte: Es gibt wohl ein Problem beim Parsen der Logdateien (müsste auth.log sein). Da das Jahr nicht vorkommt und die Datei nur beim Neustart angelegt wird kann es bei Uptime > 1 Jahr zu diesen Problemen kommen.
Abhilfe: Neustart ... ist schlecht.
Alternative 1: Datei von Hand archivieren und leer neu anlegen (auf Besitzer und Rechte achten).
Alternative2: Anpassen des Eintrags für auth.log in /etc/newsyslog.conf, so dass die Datei jedes Jahr einmal archiviert wird.

Die Fehlermeldungen sagen doch recht deutlich, wo das Problem lag: Einmal war das Passwort nicht das richtige und sonst sind die Berechtigungen falsch. Siehe #2 (xaibex).

 

[hok]

Hallo gottestod,

vielen Dank für deine aufschlußreichen Infos! Eine Paranoia habe ich noch nicht bekommen, war aber kurz davor. Aber wer kommt auf sowas? Ich nicht ;)
Da in den (alten) Log-Mails auch noch andere, sich unterscheidende Einträge waren (aber nicht von sshd und ich habe sie nicht mitgepostet), war mir das nicht unbedingt offensichtlich.
Zur Abhilfe:
Alternative 1 und 2 traue ich mir nicht zu. Ich bin froh, das die Server seit 352 Tagen ohne jedes Problem laufen und arbeiten. Das hat mich hektoliterweise Kaffee in unzähligen Nächten gekostet.
Warum ist ein Neustart schlecht? Weil ein reboot das Problem nur auf das nächste Jahr verschiebt?

Ich hatte mich vor einem Jahr viel mit dem ssh rumgeplagt. Daher die alten Meldungen... das ergibt Sinn.
Jetzt sind doch aber die Rechte richtig? (Siehe ls -la Ausgabe oben)

Nochmals: vielen Dank (euch beiden) für die schnelle Hilfe!

EDIT/
Hm... Uptime ist ja kürzer als 1 Jahr! 352 Tage. Ändert das jetzt was an den Ursachen?

hok

 

[gottestod]

Hallo hok!

Beim Neustart und bei Alternative 1 hast du das Problem natürlich in einem Jahr wieder.
Ob die Rechte jetzt richtig sind sagt dir deine tägliche Mail, zumindest ab morgen wieder.
xaibex ist da etwas restritiver ( 600 gegenüber 640 von dir ).

Es hat dich hektoliterweise Kaffee gekostet den Server ein Jahr in Betrieb zu halten
und du fragst mich, warum es schlecht ist den,
wegen einer Kleinigkeit, außer Betrieb zu nehmen?
Nein, außer der Nichtverfügbarkeit ist an einem Neustart nichts schlecht.

 

[hok]

Hallo gottestod,

die Rechte haben jetzt fast ein Jahr keine Probleme gemacht, das scheint dann ok zu sein. Fehlermeldungen in den LOGs habe ich keine.

Ich hatte vorhin noch ein EDIT zugesetzt. Ändert die Tatsache, daß der letzte Neustart erst 352 Tage her ist (ist ja gar kein ganzes Jahr...!) etwas an dem Lösungsprozedere? Werden die Logs dann wirklich gelöscht?
Die "Kleinigkeit" ist leider für mich eine Hürde. Ich weiß nicht, wo man da wo etwas konfiguriert - ich habe wirklich nur sehr rudimentär Ahnung davon. Ein Reboot ist für mich kein Problem - die 5 min trinke ich einen Kaffee ;)

Kaffee und Nächtelanges basteln waren erforderlich um ihn Fehlerfrei zum Laufen zu bekommen. Seit dem war ich nicht ein einziges Mal auf der Konsole unterwegs. Er tut und tut (und hat nicht wenig zu tun). Das hat den Nachteil, daß ich alles was ich dabei an Wissen gewonnen habe, nun schon vergessen habe.... (ich bin ja Fotograf). Ich mußte vorhin erst nachschlagen, wie ich mich mit ssh einlogge... ;/

hok

 

[hok]

Hallo,

ein Reboot hat das Log nicht gelöscht.

In newsyslog.conf ist auth.log folgend konfiguriert:

Code:

/var/log/auth.log       600  7  100  *  JC

Ich müsste also statt dem * einen Eintrag vornehmen, der auth.log nach einem Jahr rotieren lässt.

Kann mir da jemand helfen, wie ich das machen kann?
Bei Mac OS X ginge das vermutlich so:

Code:

pico /etc/newsyslog.conf /var/log/auth.log 600 7 100 [Zeitangabe] JC

Geht sowas in Freenas auch mit einer Befehlszeile?

hok

 

[gottestod]

Hallo hok!

Wegen des Editors:
https://www.freebsd.org/doc/handbook/editors.html
Ich bevorzuge den vi , ee geht aber auch.

Versuch mal das hier:

Code:

newsyslog -F auth.log
/etc/rc.d/syslogd restart

Das sollte auth.log archivieren und neu anlegen und dann den syslogd neu starten.

Die /etc/newsyslog.conf wird wohl bei dir auch bei jedem Neustart überschrieben.
Du musst dann /conf/base/etc/newsyslog.conf editieren.
Diese ist allerdings auf einem Dateisystem, das nur lesen eingehängt wird.
Dazu vorher:

Code:

mount -w / 

und nach dem ändern (wichtig):

Code:

mount -r / 

Ich hab mich für ein monatliche Intervall entschieden und das benutzt:

Code:

$M1D0

 

[hok]

Hallo Gottestod (wirklich gottestod und nicht gottisttod?)

hab vielen Dank für die Hilfe!

1. newsyslog -F auth.log
2. /etc/rc.d/syslogd restart

das hat auth.log nicht archviert und keine neu angelegt.
/EDIT: doch, das tut es, wenn man die Befehle schön nacheinander ins Terminal eingibt! Folgendes Prozedere also überflüssig!
Deshalb habe ich auth.log manuell umbenannt (weil ich nicht weiß, wie man die archiviert) und eine neue auth.log angelegt - mit gleichen Rechten (600).
Seltsamerweise wird dann in meine Umbenannte weiter geschrieben und nicht in die neue. Also alle gelöscht und
erneut:

1. newsyslog -F auth.log
2. /etc/rc.d/syslogd restart

Das hat dann eine neue auth.log angelegt und hier wird jetzt auch rein geschrieben!

Die newsyslog.conf editieren hebe ich mir für das WoE auf...

Nochmals: vielen Dank für die Hilfe!

Beste Grüße
hok

 

[hok]

Kleiner Nachtrag, falls jemand anderes mal auf so ein Problem stößt:
Da ich nun auch von meinem Backupserver Meldungen von vor einem Jahr bekomme, habe ich auch hier das händische Prozedere durchgeführt:
Und: natürlich archiviert und erstellt "newsyslog -F auth.log" eine neue auth.log. Nur darf ich nicht, wie ich es letztens gemacht habe, den Befehl zusammen mit "/etc/rc.d/syslogd restart" eingeben, sondern schön nacheinander ;) Kann man mal sehen, woran ein unbedarfter User wie ich, trotz guter Anleitung schon scheitern kann...

hok