[gelöst] sshd_conf über Script änderbar?

[Piepnase]

Hallo zusammen,
habe festgestellt, dass sich jemand an der sshd_conf zuschaffen gemacht hat. Der Zeitpunkt der Änderungen, lässt sich recht genau eingrenzen. Habe die auth.log und die access.log durchgeschaut, aber nichts gefunden. Lässt sich die sshd z.B. mittels Script ändern?

[DeletedUserReAsG]

Jede Datei lässt sich mit ’nem Script ändern, solange es nur ausreichende Rechte hat.

[Piepnase]

Wie kann ich feststellen, ob die Datei mit Script geändert wurde oder ob sich eine ansich autorisierte Person daran zu schaffen gemacht hat? Wie gesagt, kann den zeitpunkt ziemlich eng eingrenzen, wann die Änderung durchgeführt wurde, finde ich den Log-Files aber nichts Ungewöhnliches.

[DeletedUserReAsG]

Am einfachsten/sichersten, indem du’s mit ’nem Backup vergleichst. Die FS-eigenen Attribute (atime, mtime, …) sind manipulierbar.

[The Hit-Man]

mich würde jetzt mal interessieren, was da geändert wurde?

[Piepnase]

@The Hit-Man:
u.a. wurde die ListenAddress auskommentiert und noch 2 andere Parameter deaktiviert, die ich so aber nicht mehr im Kopf habe und nachschauen müsste.
Ich weiß also, dass und welche Änderungen stattgefunden haben, zumal ich mit dem Spiegelsystem verglichen habe. Aber natürlich möchte ich herausfinden, auf welchem Weg das passiert ist, um das Leck abzudichten. Habe vorsorglich PW vom User und Root geändert.

@ niemand
Mit "solange es nur ausreichende Rechte hat", was im Detail meinst Du damit? Das die Logindaten (User+PW) bekannt sind? Die sshd_config darf vom User nicht bearbeitet werden, sondern nur vom Root. Aber wenn jemand die Zugangsdaten kennt, müsste der Zugriff doch trotzdem in der Access.log zu finden sein
.

[DeletedUserReAsG]

Wenn jemand UID0 hat, hindert ihn im Normalfall¹ nichts daran, die Logs nach Belieben zu manipulieren. Wenn die Maschine mit ’nem Livesystem gestartet wird, sind Änderungen im Normalfall² eh ohne weitere Spuren möglich.

¹ Abhilfe können so Sachen wie SELinux und Co. schaffen
² Abhilfe kann Systemverschlüsselung schaffen

[Piepnase]

Mit anderen Worten:
Hat die Person UID0 gehabt, kann ich nicht erkennen, auf welchem Wege die Änderungen, die ja ganz gezielt und nicht etwa rein zufällig waren, stattgefunden haben?

Da in den Logfiles nichts zu finden ist, muss ich davon ausgehen, dass diese manipuliert wurden, um die Spuren zu vertuschen. Das hatte ich mir schon gedacht, zumal ich durchaus einen Verdacht habe, wer es war. Aber es ist eben nur ein Verdacht.

Werde mich jetzt mal schlau machen bzgl. SELinux und wohl doch von PW Anmeldung auf Schlüssel umsteigen. Hatte das bisher vermieden, weil andere Personen, zu dem die verdächtige Person nicht gehört, per SFTP zugreifen müssen. Aber es ist doch glaube ich möglich, dass sich der User via PW und der Root via Schlüssel anmeldet, oder?

[Piepnase]

Wie es letztlich zu der Änderung gekommen ist, ist nicht mehr nachvollziehbar. Meine Vermutung: Es war ein anderer Admin, dem ich die Zugangsdaten mitteilen musste. Nach Änderung besagter Zugangsdaten und ohne diese dem anderen Admin mitzuteilen, läuft der Server problemlos.

[rendegast]

Code: Alles auswählen

last ...
w ...

Vielleicht hat der "Angreifer" seine Spuren nicht beseitigt?
ZBsp. welcher Benutzer sich von wo evtl. eingeloggt hat, um dann zu Root zu werden.

Erschwert werden solche nachträglichen Änderungen durch Senden der Logs auf ein gesondertes Remote-System.

[MSfree]

Wie es letztlich zu der Änderung gekommen ist, ist nicht mehr nachvollziehbar.

Ohne zusätzlich Software ist das bei einem Linux sowieso nicht nachvollziehbar. Bei einer normalen Installation wird nicht mitprotokolliert, welcher User wann welche Software ausgeführt hat. Lediglich Login- und Logoutzeiten werden protokolliert und das reicht bei weitem nicht aus, Angriffe zu analysieren.

Fest steht, daß es keine große Kunst ist, mit Werkzeugen wie sed oder awk, die man aus einem Skript ausführt, ASCII-Dateien zu manipulieren. Man kann also sshd_config genauso manipulieren wie die Logdateien. Einzige Voraussetzung hier ist, daß man ausreichend Rechte zum Schreiben der Dateien hat, aber die kann man sich durch ausnutzen von Sicherheitslücken und Privilge-Escalation letztlich beschaffen. So ein Verhalten ist ziemlich typisch für ein Rootkit.

Das perfide ist, daß, obwohl das System problemlos zu laufen scheint, ein Rootkit immer noch auf deinem System aktiv sein könnte. Ich würde dem System jedenfalls keinen Meter mehr über den Weg trauen und es neu aufsetzten. Zumindest aber solltest du den Netzwerkverkehr gründlich im Auge behalten und auf ungewöhnliche Aktivitäten überwachen (ein Webserver, der z.B. plötzlich Torrentpakete verschickt und empfängt, sollte zumindest stutzig machen).

Vielleicht solltest du dich mal mit dem Paket acct beschäftigen und remote-logging in Betracht ziehen, wie mein Vorposter vorgeschlagen hat.

[Piepnase]

Laut rkhunter ist das System sauber udn wie gesagt, ich habe einen konkreten Verdacht!

[DeletedUserReAsG]

rkhunter vom zu untersuchenden System aus gestartet? Das kann man sich auch sparen.