Möglichkeiten zu prüfen ob der Server Infiziert ist

  • Hallo,


    ich möchte das mal auslagern. Begonnen hat das Thema etwas hier:
    https://forum.netcup.de/admini…nnerung-benutzt-ssh-keys/


    Da mich das Thema aber sehr interessiert, möchte ich es explizit im eigenen Thema nochmal besprechen.


    Die Fragen sind im Allgemeinen:

    • Wie kann man einen infizierten Server erkennen
    • Womit kann man einen Infizierten Server erkennen
    • Welche Hilfsmittel gibt es einen Infizierten Server zu erkennen
    • Wie kann man dem effektiv Vorbeugen (Spezielle Rechtevergabe etc.)



    ThomasChr hatte ja schon ein Tool genannt zu 3. Welche Hilfsmittel gibt es einen Infizierten Server zu erkennen:

    • tripwire


    Man kann natürlich auch die Logs Analysieren und dazu Logwatch nutzen. Außerdem sollte man wohl nach versteckten Dateien suchen und unbekannte oder neue Systemprozesse aufspüren.


    Zur Vorbeugung im Allgemeinen wurde ja auch hier schon was gesagt:
    https://forum.netcup.de/admini…nnerung-benutzt-ssh-keys/


    Im Allgemeinen also:

    • root Benutzer deaktivieren / SSH Keys nutzen
    • SSH Port ändern
    • Software aktuell halten
    • Applikationen im allgemeinen aktuell halten
    • Sichere Passwörter verwenden (min. 8 Zeichen - Alls was die Tastatur hergibt dazu nutzen.)
    • Fail2Ban benutzen und richtig einrichten.


    Aber so ein Feedback was ihr noch wichtig findet wäre für mich sehr von Interesse. auch wie andere das Umsetzen und ob oder welche Hilfsmittel dazu genutzt werden .Auch welches OS präferiert wird und ggf. kurz warum.

    Der oben geschriebene Beitrag ist meine persönliche Meinung/Interpretation!
    Im übrigen verweise ich auf §675 Abs. 2 BGB .

  • Wobei das alles nutzlos sein könnte, wenn der Angreifer root-Rechte erlangt hat. Dann kann er sich sehr gut verstecken, ohne dass Du im laufenden System Spuren davon findest! ;)


    Dann sollte man doch aber hier z.B. in der Rechtevergabe Spuren finden können, oder?


    Angenommen er erlangt Rootrechte, agiert er dann mit "root" als root oder als unbekannter Benutzer z.B. "sddfg" mit Rootrechen?

    Der oben geschriebene Beitrag ist meine persönliche Meinung/Interpretation!
    Im übrigen verweise ich auf §675 Abs. 2 BGB .

  • Wenn der Angreifer Root-Rechte erlangt hat, kann er das gesamte System manipulieren. Jede Log-Datei kann von ihm bearbeitet werden, jeder Virenscanner kann mit einer Version ersetzt werden, die seine Scripte nicht erkennt. Ein solches System ist nicht mehr verlaesslich ueberpruefbar..

  • Nur, wenn die Log-Datei durch root noch bearbeitbar ist...


    root darf alles, immer! (von SELinux und anderen Spielereien mal abgesehen) Da hilft auch kein "chmod 0" o.ä. ;)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich denke rsyslogd kann seine Logs auch standardmäßig woanders hinsenden.


    Natürlich kann es das.


    Außerdem kann ich die Logs vor Modifikationen sichern. Dann sehe ich zwar nicht mehr, wie der Original-Eintrag war, kann aber nachweisen, ob und welche Einträge später modifiziert wurden. Möglichkeiten über Möglichkeiten... Daher, bevor Ihr über technische Lösungen diskutiert, stellt erst mal Eure Policy gescheit auf.

  • Das ging aus dem ursprünglichen Beitrag nicht ganz hervor, daran habe ich leider nicht gedacht. (obwohl ich das selbst einsetze… :rolleyes: )



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Die Fragen sind im Allgemeinen:

    • Wie kann man einen infizierten Server erkennen
    • Womit kann man einen Infizierten Server erkennen
    • Welche Hilfsmittel gibt es einen Infizierten Server zu erkennen

    Ich habe prinzipiell mind alle 2 Tage einen clamscan laufen, logwatch ist essentiell (scrollt man einmal morgens beim Morgenkaffee durch) mit E-Mail Benachrichtigung. Natürlich sollte man fail2ban Regeln einstellen für möglichst alle Dienste mit User/Passwort Authentifizierung (Webservices, dovecot, postfix, proftpd, wordpress, ssh, etc...)


    Wenn man viel Webseiten und CMS hostet ist mod_security keine schlechte Idee.

    Wenn man FTP Zugänge vergibt dann möglichst nur SFTP und FTP an sich blockieren.


    Ich plane aber demnächst noch mindestens auf tripwire und RKHunter zu setzen, denn clamAV ist schon langsam und ressourcenlastig.

  • ClanAV macht eigentlich nur für EMail oder für Dateiserver Sinn, wobei die Erkennungsrate doch echt mies ist. Ich habe hierfür immer ein Mix aus AVG und Sophos genutzt und auch nur OnDemand und hier auch täglich wechselnd. RKHunter kann man nutzen aber kann dies aber auch umgehen. Viel viel wichtiger ist es meiner Meinung nach auf passende Dateiberechtigungen achten, z.B.

    chmod 000 /etc/shadow

  • Ich plane aber demnächst noch mindestens auf tripwire und RKHunter zu setzen, denn clamAV ist schon langsam und ressourcenlastig.

    maldetect hat mir immer ganz gut beim Analysieren von (fremden) infizierten Servern geholfen.

    Es kann mit clamAV zusammenarbeiten und in mod_security2 integriert werden, um den eigenen Server zu schützen.

    Wenn es Befall gibt, dann meist innerhalb von einzelnen vhosts - vorausgesetzt diese sind z.B. mit suexec sauber getrennt. Wenn ein Eindringling bereits root Zugriff hatte, muss man den Server sowieso neu aufsetzen.

    Um unbefugte Änderungen an vhosts schnell zu erkennen/zu beheben, nutze ich je nach Arbeitsweise des Nutzers gern git - ein einfaches "git status" zeigt dann, was sich (ggf. unerwünscht) geändert hat und kann mit "git stash" behoben werden; natürlich erspart das nicht die Suche nach dem Einfallstor bzw. der Sicherheitslücke etc. Das macht natürlich nur Sinn, wenn der Nutzer bei erwünschten Änderungen immer zeitnah commits macht - und wenn die .gitignore sinnvoll eingestellt ist. Weil oben WordPress erwähnt wurde: VersionPress ist dein Freund.

    Systemseitig finde ich btrfs snapshots ganz sinnvoll - a) backups lassen sich mit btrfs send/receive beschleunigen, b) ein Vergleich zwischen zwei Snapshots ist ohne großen Aufwand möglich, c) zurück auf einen vorherigen Stand geht relativ schnell. Voraussetzung ist, dass man sinnvoll subvolumes anlegt, also von System und Nutzdaten/Cache/vhosts entsprechend einzeln copy-on-write Snapshots anlegen (und wieder aufräumen) kann.

    Ungewöhnliche Aktivitäten lassen sich natürlich auch mit entsprechendem Monitoring erkennen, nagios/icinga2/zabbix z.B. Aber auch einfache scripts können helfen zu erkennen, wenn z.B. smtp logins aus ungewöhnlichen ip-Bereichen kommen bzw. plötzlich viele Mails über einen Account verschickt werden. Nicht immer muss ein Server-Einbruch dahinter stehn, es genügen zu einfache Passwörter oder per lokalem Befall bei einem Benutzer ergaunerte Mail-/Ftp-Zugangsdaten. Ssh sollte eh nur per key ... wurde ja oben schon genannt.