Server Angriff auf SSH trotz NoRootPermit sowie OSSEC rootcheck

[sTaN]

Hallo,

ich habe soeben eine Mail Alert Level 10 von OSSEC erhalten das ein mehrfacher fehlerhafter Versuch auf SSH erfolgte, obwohl der root Login deaktiviert wurde. Wie ist das möglich???

Hier ein Auszug des gesendeten Logs aus auth.log:

Jul 31 05:55:53 Servername sshd[26405]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=netcircuit-monitoring.de  user=root
Jul 31 05:55:50 Servername sshd[26393]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=netcircuit-monitoring.de  user=root

u.s.w so wie noch der falsche Loginversuch:

Jul 31 05:55:55 Servername sshd[26405]: Failed password for root from 81.169.138.50 port 57018 ssh2
Jul 31 05:55:52 Servername sshd[26393]: Failed password for root from 81.169.138.50 port 56623 ssh2

und noch weitere Versuche.
Eine weite Mail mit Alert Level 7 beinhaltet einige komische Einträge, was bedeuten diese?

Received From: Servername->rootcheck
Rule: 510 fired (level 7) -> "Host-based anomaly detection event (rootcheck)."
Portion of the log(s):

Process '2975' hidden from /proc. Possible kernel level rootkit.

Received From: Servername->rootcheck
Rule: 510 fired (level 7) -> "Host-based anomaly detection event (rootcheck)."
Portion of the log(s):

Process '6558' hidden from /proc. Possible kernel level rootkit.

und davon noch ein paar mit unterschiedlichen Prozessnummern. Wie es abzuschalten geht wird hier beschrieben, aber keine Info über die eigentlich Meldung.

Bitte um Hilfe!

Gruß
sTaN

 

[Roger Wilco]

Wie ist das möglich???

Vermutlich indem jemand versucht, sich mit der Benutzerkennung root anzumelden und deine Konfiguration nicht dicht ist...

Eine weite Mail mit Alert Level 7 beinhaltet einige komische Einträge, was bedeuten diese?

Wie die Meldungen, sollte dir doch einfache Übersetzung klar sein. Der Grund für die Meldungen können unterschiedlich sein. Von kaputtem HIDS, über komische Virtualisierungslösung bis hin zur Kompromittierung deines Systems. Letzteres solltest du gründlich prüfen.

 

[sTaN]

Vermutlich indem jemand versucht, sich mit der Benutzerkennung root anzumelden und deine Konfiguration nicht dicht ist...

Wie kann sich aber jemand mit root anmelden, wenn dieser in der SSH Konfig deaktiviert wurde.
Es ist nur möglich, sich mittels User einzuloggen und dann per su zum root zu werden.

Wie die Meldungen, sollte dir doch einfache Übersetzung klar sein. Der Grund für die Meldungen können unterschiedlich sein. Von kaputtem HIDS, über komische Virtualisierungslösung bis hin zur Kompromittierung deines Systems. Letzteres solltest du gründlich prüfen.

Einen gelungenen Angriff würde ich ja ebenfalls von OSSEC erhalten bzw. ist mir nichts unaufälliges aufgefallen.
Das mein HIDS defekt ist konnte ich auch nicht feststellen (wie am besten?) Was meinst du mit komische Virtualisierungslösung?

Gruß

 

[Roger Wilco]

Wie kann sich aber jemand mit root anmelden, wenn dieser in der SSH Konfig deaktiviert wurde.

Wo konnte sich denn jemand mit der Benutzerkennung root anmelden? Ich sehe nur Meldungen in deinen Logs, dass dies genau nicht möglich war.

Einen gelungenen Angriff würde ich ja ebenfalls von OSSEC erhalten

Haha! Genau, und der Pilot dreht um und fliegt zurück.

Was meinst du mit komische Virtualisierungslösung

Eben eine OS-level Virtualisierung, welche die Meldungen erklären könnte.

 

[sTaN]

Wo konnte sich denn jemand mit der Benutzerkennung root anmelden? Ich sehe nur Meldungen in deinen Logs, dass dies genau nicht möglich war.

Sorry nicht anmelden, meinte identifizieren. Sprich er wurde nach dem root Passwort gefragt. Soweit dürfte es ja schon gar nicht kommen meinte ich!

Haha! Genau, und der Pilot dreht um und fliegt zurück.

Damit meinte ich, dass alle Logfiles durchstöbert worden sind und ich keinerlei Spuren finden konnte die auf einen gelungenen Angriff hindeuten.

Eben eine OS-level Virtualisierung, welche die Meldungen erklären könnte.

Heißt Meldungen kommen aufgrund des virtuellen Servers und können ignoriert werden?

Gruß
sTaN

 

[Roger Wilco]

Soweit dürfte es ja schon gar nicht kommen meinte ich!

Da meinst du falsch.

Damit meinte ich, dass alle Logfiles durchstöbert worden sind und ich keinerlei Spuren finden konnte die auf einen gelungenen Angriff hindeuten.

Wäre ja auch noch schöner, wenn geglückte Angriffe noch in den Logdateien zu finden wären. Den Fehler machen nur Anfänger. Oder hast du deine Logs etwa permanent an einen speziell abgesicherten Log-Host geschickt?

Heißt Meldungen kommen aufgrund des virtuellen Servers und können ignoriert werden?

Das würde ich so pauschal nicht sagen, aber es ist immerhin mal ein Ansatz, dem du nachgehen könntest.

 

[sTaN]

Da meinst du falsch.

Nimm mir bitte nicht übel wenn ich mit deinen Aussagen nicht viel anfangen kann. Wieso meine ich da falsch? Wie ist es denn möglich sich als root zu identifizieren wenn NoRootPermit auf No steht???

Wäre ja auch noch schöner, wenn geglückte Angriffe noch in den Logdateien zu finden wären. Den Fehler machen nur Anfänger. Oder hast du deine Logs etwa permanent an einen speziell abgesicherten Log-Host geschickt?

Wie sonst soll ich noch einen Angriff identifizieren? Es ist ja nichts auffälliges.

Das würde ich so pauschal nicht sagen, aber es ist immerhin mal ein Ansatz, dem du nachgehen könntest.

Wie kann ich am besten wo anfangen das Problem zu lösen?

 

[Roger Wilco]

Wieso meine ich da falsch? Wie ist es denn möglich sich als root zu identifizieren wenn NoRootPermit auf No steht???

Weil OpenSSH eben so implementiert ist.

Die Option heißt eben nicht PreventRootLogin sondern eben PermitRootLogin und ein Login zu verhindern ist nicht dasselbe, wie ein Login komplett zu vermeiden.

Wie sonst soll ich noch einen Angriff identifizieren? Es ist ja nichts auffälliges.

Ungewöhnliche Trafficmuster, eingehende Beschwerden, ungewöhnliches Verhalten von Anwendungen (was natürlich voraussetzt, dass du das normale Verhalten der von dir eingesetzten Anwendungen kennst).

Die Meldungen von OSSEC würde ich mal dazuzählen, sofern die Meldungen vorher noch nie aufgetreten sind.

 

[Lord Gurke]

Nunja, wenn ich den root-Login per SSH verbiete, ist der Daemon ja nicht so doof und teilt es der Welt mit
Der fragt bei jedem angegebenen Benutzernamen (und sei es "root", "admin", "thermoskanne" oder "runkelrübe") auch nach einem Passwort, damit ein Angreifer keine vorhandenen Benutzernamen dadurch erfragen kann

EDIT:
Verdammt, zu langsam

 

[michael-08]

Weil OpenSSH eben so implementiert ist.

Die Option heißt eben nicht PreventRootLogin sondern eben PermitRootLogin und ein Login zu verhindern ist nicht dasselbe, wie ein Login komplett zu vermeiden.

Hi Roger Wilco, also das interessiert mich nun auch.

Permit = erlauben
Prevent = verhindern

nicht erlaubt = nicht möglich 0 0
verhindern = eventuell möglich 0 1


Wenn Permit auf No steht, bedeutet dass, das es nicht erlaubt ist und somit auch nicht versucht werden kann sich dennoch anzumelden.

Prevent bedeutet verhindern, und wenn man etwas verhindern muss, bedeutet es auch, dass es versucht werden kann.

Wenn ich nun PermitRootLoging auf No stelle, sollte doch wie bei Public Key und beispielsweise UsePAM: no erst gar nicht die möglichkeit bestehen!??!?

Sobald der nutzername root fällt sollte ssh doch dann zu machen!!!

Ich vermute, dass versucht wurde sich mit root anzumelden, aber aufgrund eines nicht zugelassenen usernamen die sitzung verhindert wurde und kein passwort abgefragt worden ist!


Andernfalls verstehe ich das auch nicht richtig

 

[LinuxAdmin]

Lies nochmal den Beitrag von Lord Gurke! Damit will man verhindern, dass (ganz generell) Benutzernamen erraten werden können...

 

[sTaN]

Okay, dass klingt auch einleuchtend von Lord Gurke.
Nur erhalte ich bei Eingabe von root eine Meldung das dieser Login verboten ist und werde gar nicht erst nach meinem Passwort gefragt.
Wenn es für einen Außenstehenden aber nicht der Fall ist und sich die Anmeldemaske wie bei jedem anderen Loginversuch verhält, verstehe ich es!
Für mich war dies vorher nicht klar u ich habe es auch so verstanden das ein root Login generell permitted wird!

Grüße