force attacken?

  • Hallo,

    eine Frage, sind eure Logs auf den 'Root-Server' auch voll mit brute force attacken bzw. Anmeldeversuchen?


    Bsp. /var/log/auth.log:

    ...

    Failed password for root from 182.100.67.201 port 59780 ssh2

    pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=182.100.67.201 user=root

    ...

    Address 46.172.197.236 maps to host-46-172-197-236.mirgiga.net, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!

    pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=46.172.197.236 user=root

    Failed password for root from 46.172.197.236 port 45630 ssh2

    Failed password for root from 46.172.197.236 port 45630 ssh2

    Disconnecting: Too many authentication failures for root from 46.172.197.236 port 45630 ssh2 [preauth]

    PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=46.172.197.236 user=root

    PAM service(sshd) ignoring max retries; 6 > 3

    ...


    und das zig mal pro Sekunde (unterschiedliche IPs und Ports)... oder liege ich da total daneben und sehe das falsch?


    Gruß

    Jojo

  • Solange ein Rechner global am Netz hängt ist das für mein Verständnis ziemlich normal. Möglichkeiten:

    • SSH auf einen anderen Port verlegen
    • fail2ban installieren (Sperrt IPs nach einer bestimmten Anzahl Fehlversuchen)
    • SSH per Firewall auf dein "Quellnetz" einschränken
    • In jedem Fall: Gute(!) Passwörter verwenden

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Das ist völlig normal. Ich habe schon viele IP(-Ranges) komplett geblacklisted auf all meinen Systemen (vor allem die, die auf SMTP, FTP etc. gehen und "klug" agieren, also Domain-Namen als Usernamen probieren, die auch auf die IP matchen).


    Just for the lulz mal aus den letzten sieben Tagen die TOP10 ausprobierten Usernamen (und Services) auf meinen Systemen:

    Bildschirmfoto 2018-01-09 um 13.09.56.png

    (MySQL ist schon viel raus, da seit auch ca. 1 Woche Whitelist)

  • Solange ein Rechner global am Netz hängt ist das für mein Verständnis ziemlich normal. Möglichkeiten:

    • SSH auf einen anderen Port verlegen
    • fail2ban installieren (Sperrt IPs nach einer bestimmten Anzahl Fehlversuchen)
    • SSH per Firewall auf dein "Quellnetz" einschränken
    • In jedem Fall: Gute(!) Passwörter verwenden

    ...

    • root per ssh unterbinden
    • auch bei den Benutzernamen etwas kreativer sein;)

    das wichtigste wurde schon genannt aber es gibt einiges was man machen kann und auch wirklich tun sollte. Ansonsten ist Fail2Ban mit IPtables schon eine Möglichkeit den Log etwas zu "entlasten", da allerdings die Source-IPs ständig wechseln bringt es auch nur bedingt etwas...


    P.S.: Um es auch nochmal zu bestätigen, sobald ein System frei im Netz verfügbar ist, ist es leider vollkommen normal, dass es diverse Login-Versuche gibt...

  • Da es noch keiner genannt hat:

    • SSH-Keys benutzen und Password-Login verbieten


    Den Port zu ändern ist erfahrungsgemäß eine gute Möglichkeit, die Anmeldeversuche um 100% zu reduzieren und die Logs clean zu halten. (Mache ich aber nicht mehr, stattdessen SSH-Keys only, root sowieso verboten, Fail2Ban.)

  • Hay,


    ja, ist so. fail2ban benutzen!


    Auf einem Honeypot (nicht hier natürlich grins) habe ich 26.000 ssh-Angriffsversuche pro Woche.


    P.S.: Und ringelnatz Tipps beherzigen: ssh nur mit normalen Nutzer, root verbieten, mit Keys und su.


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Hi,

    vielen Dank für die Antworten!


    Da ich in dem Thema noch neu bin und gerade hierbei nichts falsch machen möchte, gibt es eine (einfache) Anleitung, wie

    a) das zu realisieren ist, dass nur SSH-Keys für den Login verwendet werden

    b) der root user verboten ist (wobei mit einem eigenen User sudo auf root nutzbar bleibt).

    Ich möchte mich nur ungern selbst aussperren ;)


    fail2ban habe ich bereits installiert und funktioniert soweit.


    Danke

    Jojo

  • Welches Betriebssystem verwendest Du lokal? (Davon hängt ab, wie Du SSH-Keys generierst.)


    Für Grundabsicherung und best practices gibt es im Netz diverse Artikel, z.B. diesen hier (-> Google). Muss/kann man natürlich nicht immer 100% genau so machen, z.B. ist unattended-upgrades bei Debian Stretch schon dabei. Da geht es aber zumindest auch um die beiden von Dir genannten Punkte.


    Generell: Aussperren kannst Du Dich eigentlich nicht, weil Du im Notfall einfach ins Rettungssystem booten und die Konfigurationsänderungen rückgängig machen kannst.

  • Eigentlich nutze ich Windows (jaja Schande, Schande) um die Verbindung aufzubauen.


    Habe natürlich auch Google bemüht, nur geht es mir bei dem Thema so, dass je mehr ich dazu bei den diversen Seiten lese, desto verwirrender wird es... (entweder sind es zu viele Abhängigkeiten oder ich bin für das Thema heute einfach nicht aufnahmefähig).

    Ich denk ich muss das nochmals vom 'Beginn' versuchen...


    Rettungssystem!?! finde ich das im CPS von netcup?

  • Unter Windows nutzt Du dann sicher PuTTY für Deine SSH-Verbindungen. PuTTY kann Dir irgendwie auch SSH-Keys generieren, da ich das aber noch nie gemacht habe bin ich hier raus. (Alternative unter Windows 10: Die Ubuntu-Sandbox benutzen)


    Rettungssystem!?! finde ich das im CPS von netcup?

    Was ist denn das CPS? Im ServerControlPanel kannst Du ins Rettungssystem booten, Deine Festplatte mounten und kaputte Configs reparieren.

  • Danke euch!

    Ich denke ich hab's jetzt verstanden und mach mich an die Umsetzung.


    Viele Grüße

    Jojo


    P.S. Ups sorry, ich meinte natürlich das SCP und hab den Punkt jetzt auch dank Ringelnatz gefunden.