Netcup Server derzeit verstärkt Ziel von Angriffen?

  • Nur ein paar Stunden nachdem der Server bereitgestellt wurde (war vorher noch gar nicht eingeloggt) lese ich beim ersten Login schon das hier:


    Quote

    Last failed login: Thu Jun 15 14:03:05 CEST 2017 from 58.218.198.xxx on ssh:notty


    Infobyip.com sagt mir die IP ist aus Chinanet. Sind die Netcup Server derzeit verstärkt Ziel von Angriffen?

  • Solche Login-Versuche sind normal. Das ist weder ein aktuelles Problem noch betrifft es nur netcup.

    Habe das bei meinen anderen Providern nicht gehabt bisher aber okay^^ Dachte nur dass Netcup evtl derzeit Bruteforce zum Opfer gefallen ist :P

    Werde wohl erstmal ssh root login deaktivieren.

  • per iptables die ssh logins per Minute reduzieren

    In Ergänzung zu MaxAuthTries 2 in /etc/ssh/sshd_config (wirkt nach Restart des Dienstes)

    ein dynamischerer Vorschlag (nach Lektüre u.g. Dokumentation und auf eigene Gefahr):

    Shell-Script
    1. # cf. http://forum.doozan.com/read.php?2,20609,20799#msg-20799 et seq.
    2. iptables -N SSHbrute
    3. iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m recent --update --seconds 7200 --reap --name SSHbrute --rsource -j DROP
    4. iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSHknown --rsource
    5. iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 30 --hitcount 2 --name SSHknown --rsource -j SSHbrute
    6. iptables -A SSHbrute -m recent --set --name SSHbrute --rsource -j LOG --log-prefix "SSHbrute "

    Wer bzw. wieviel erkannt und ggf. greylisted wird, lässt sich z.B. verfolgen per:

    cat /proc/net/xt_recent/SSHknown

    cat /proc/net/xt_recent/SSHbrute

    watch -d -n 2 iptables -nvL -x


    Verdächtige IP-Adressen werden damit für 2 Stunden kaltgestellt - gleichzeitig sperrt man sich auch bei Bedienfehlern selbst nicht länger aus.


    Für veränderte Angriffsmuster lassen sich wie unter obiger URL m.w.N. diskutiert verschärfte Filter nachlegen.

  • Hay,


    jedenfalls bei ssh den root abklemmen und nur mit Keys & sicherer Passphrase arbeiten.


    Ergänzend - so läuft es bei mir - fail2ban installieren.


    Das ist ein Logfile-Beobachter, den man mit regulären Ausdrücken auf Einbruchsversuche trimmen kann und man kann auch die Sensitivität einstellen. Wenn jemand sich z.B. innerhalb von 10 Minuten 5x erfolglos per ssh einloggen wird, wird die IP gesperrt und zwar für eine ganze Woche (ist gusto, wie lange). Man kann auch Einträge whitelisten (zum Beispiel indem man einen bestimmten User whitelistet - sollte natürlich nicht ausgerechnet root sein), so dass man sich selbst eine Lücke offen lässt. fail2ban läuft bei mir auf ssh, postfix und asterisk-Logfiles (plus andere empfindliche Dienste). Wenn man schon bei ssh-Hackversuchen wach wird... Ihr könnt Euch gar nicht vorstellen, was abgeht, wenn jemand da draußen im wilden weiten Netz einen offenen SIP-Port findet, da gibt es mehr Angriffsvektoren als nur ein Login 8o


    Nachteil von fail2ban... wenn jemand mit großer Bandbreite angreift (deswegen vielleicht in Kombination mit dem obigem Vorschlag), sind schon 200 Loginversuche durchgelaufen, bis fail2ban die IP sperrt...


    CU, Peter

  • Nachteil von fail2ban... wenn jemand mit großer Bandbreite angreift (deswegen vielleicht in Kombination mit dem obigem Vorschlag), sind schon 200 Loginversuche durchgelaufen, bis fail2ban die IP sperrt...

    Reicht aber trotzdem mit allerhöchster Wahrscheinlichkeit nicht, wenn man Pubkey-Auth benutzt :-)

  • [...] Nachteil von fail2ban... wenn jemand mit großer Bandbreite angreift (deswegen vielleicht in Kombination mit dem obigem Vorschlag), sind schon 200 Loginversuche durchgelaufen, bis fail2ban die IP sperrt... [...]

    Ein weiteres Problem, sofern man einen Zugriff via IPv6-Adresse(n) erlaubt, ist die Tatsache, daß der derzeit für die meisten Linux-Distributionen verfügbare Versionszweig 0.9x von fail2ban keine IPv6-Adressen sperren kann... ("Meta-Fail"? 8o)

    (Das ist hier dokumentiert.)

  • Hay,

    fail2ban keine IPv6-Adressen sperren kann... ("Meta-Fail"? 8o)


    ja, so ist es, habe ich nicht erwähnt - weil ich auf dem Auge leicht blind bin :P


    Zum einen sind die meisten meiner Dienste nur per IPv4 erreichbar (den Bug umgehe ich aktiv, indem ich meine RegEx nur auf IPv4 getrimmt habe) und zum anderen hatte ich bei denen, die für IPv6 offen sind, bislang noch keinen einzigen Angriff...sollte man sich mal drauf vorbreiten und ich bin voll der guten Hoffnung, dass die Leute von fail2ban das in den Griff bekommen :thumbup::thumbup:toitoitoi.


    CU, Peter