Tausende remote ROOT anmeldeversuche über SSH auf Webserver
Hallo zusammen,
betreibe meinen eigenen Debian 6 Webserver.
Ich bekomme alle paar Sekunden Meldungen von Remotehosts die sich versuchen per SSH mit dem user root anzumelden:
Das ganze hab ich x 1000 in meinem Auth.log
Habe versucht dem ganzen per Fail2ban irgendwie entgegen zu wirken.
Leider zeigt das nicht wirklich Wirkung oder meine Einstellungen sind zu lasch.
Ich möchte login per root offen lassen, kann leider in der Firewall keine spezielle IP für den Login einstellen, da ich eventuell weltweit per ssh auf meinen server möchte ;)
Oder sollte ich den "root" per ssh sperren und mit nem normalen Benutzer einloggen und dann "su - root" ? Jedoch würde es nicht lange dauern und man würde versuchen den lokalen Benutzer + passwort zu erspähen.
Ich würde mich wirklich freuen, wenn der ein oder andere eine Idee oder Lösung für mich hätte, das ganze ist bis jetzt gut gegangen, dank sehr starkem Passwort etc ;)
Viele Grüße
itproject
betreibe meinen eigenen Debian 6 Webserver.
Ich bekomme alle paar Sekunden Meldungen von Remotehosts die sich versuchen per SSH mit dem user root anzumelden:
May 17 08:27:26 myhostname sshd[28906]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.tmt-pcb.com.cn user=root
May 17 08:27:28 myhostname sshd[28906]: Failed password for root from 61.160.76.123 port 53572 ssh2
Das ganze hab ich x 1000 in meinem Auth.log
Habe versucht dem ganzen per Fail2ban irgendwie entgegen zu wirken.
Leider zeigt das nicht wirklich Wirkung oder meine Einstellungen sind zu lasch.
Ich möchte login per root offen lassen, kann leider in der Firewall keine spezielle IP für den Login einstellen, da ich eventuell weltweit per ssh auf meinen server möchte ;)
Oder sollte ich den "root" per ssh sperren und mit nem normalen Benutzer einloggen und dann "su - root" ? Jedoch würde es nicht lange dauern und man würde versuchen den lokalen Benutzer + passwort zu erspähen.
Ich würde mich wirklich freuen, wenn der ein oder andere eine Idee oder Lösung für mich hätte, das ganze ist bis jetzt gut gegangen, dank sehr starkem Passwort etc ;)
Viele Grüße
itproject
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 206611
Url: https://administrator.de/contentid/206611
Ausgedruckt am: 24.11.2024 um 18:11 Uhr
13 Kommentare
Neuester Kommentar
Ist der HerkunftsIP immer gleich? 61.160.76.123?
inetnum: 61.160.76.120 - 61.160.76.127
netname: WUXI-TONGMENG-ELECTRONIC-CORP
descr: wuxi tongmeng dianzi co.,ltd
descr: Wuxi City
descr: Jiangsu Province
country: CN
admin-c: DUMY-RIPE
tech-c: DUMY-RIPE
changed: unread@ripe.net 20000101
status: ASSIGNED NON-PORTABLE
mnt-by: MAINT-CHINANET-JS
mnt-lower: MAINT-CHINANET-JS-WX
source: APNIC-GRS
remarks:
remarks: * THIS OBJECT IS MODIFIED
remarks: * Please note that all data that is generally regarded as personal
remarks: * data has been removed from this object.
remarks: * To view the original object, please query the RIPE Database at:
remarks: * http://www.ripe.net/whois
remarks:
Kannst du diese IP sperren?
LG,
ticuta1
inetnum: 61.160.76.120 - 61.160.76.127
netname: WUXI-TONGMENG-ELECTRONIC-CORP
descr: wuxi tongmeng dianzi co.,ltd
descr: Wuxi City
descr: Jiangsu Province
country: CN
admin-c: DUMY-RIPE
tech-c: DUMY-RIPE
changed: unread@ripe.net 20000101
status: ASSIGNED NON-PORTABLE
mnt-by: MAINT-CHINANET-JS
mnt-lower: MAINT-CHINANET-JS-WX
source: APNIC-GRS
remarks:
remarks: * THIS OBJECT IS MODIFIED
remarks: * Please note that all data that is generally regarded as personal
remarks: * data has been removed from this object.
remarks: * To view the original object, please query the RIPE Database at:
remarks: * http://www.ripe.net/whois
remarks:
Kannst du diese IP sperren?
LG,
ticuta1
Hallo @itproject,
drei Sachen würde ich machen:
1) Denyhosts installieren, damit kannst du die Anzahl der Verbindungen zum SSH Dienst kontrollieren und ggf. blocken
Siehe dazu auch http://www.cyberciti.biz/faq/block-ssh-attacks-with-denyhosts/
2) Den Root-Zugriff per Remote komplett verbieten und nur mit dem User einloggen (alternativ wie SlainteMhath empfohlen hat, nur über einen private Keys reingehen). Am Besten du benutzt statt "su -" generell den "sudo command" Befehl.
3) Du änderst den Standard SSH-Port von 22 auf irgendwas über 4000 (z.B. 4267). Damit wird der Rechner in der Regel nicht mehr/kaum noch gescannt.
Der Login dazu wäre dann: "ssh -p 4267 username@host".
Damit du dich jetzt aber wieder ganz normal ohne Portangabe per "ssh user@host" anmelden kannst legst du einfach in Dein Home Verzeichnis unterhalb von .ssh/ die Datei "config" mit folgenden Inhalt an:
Damit sollte Dein SSH recht gut abgesichert sein:
Gruß
Frank
drei Sachen würde ich machen:
1) Denyhosts installieren, damit kannst du die Anzahl der Verbindungen zum SSH Dienst kontrollieren und ggf. blocken
apt-get install denyhosts
2) Den Root-Zugriff per Remote komplett verbieten und nur mit dem User einloggen (alternativ wie SlainteMhath empfohlen hat, nur über einen private Keys reingehen). Am Besten du benutzt statt "su -" generell den "sudo command" Befehl.
In der Datei "/etc/ssh/sshd_config":
PermitRootLogin no
3) Du änderst den Standard SSH-Port von 22 auf irgendwas über 4000 (z.B. 4267). Damit wird der Rechner in der Regel nicht mehr/kaum noch gescannt.
In der Datei "/etc/ssh/sshd_config":
Port 4267
Damit du dich jetzt aber wieder ganz normal ohne Portangabe per "ssh user@host" anmelden kannst legst du einfach in Dein Home Verzeichnis unterhalb von .ssh/ die Datei "config" mit folgenden Inhalt an:
Host xyz1
Port 4267
User namexyz
Host xyz2
Port 4267
User namexyz
Damit sollte Dein SSH recht gut abgesichert sein:
- durch den "anderen Port" ist der SSH nur schwer zu finden
- durch "PermitRootLogin no" gibts keine Root-Logins mehr
- durch "DenyHosts" können die Angreifer nur noch wenige Versuche starten
Gruß
Frank
Zitat von @Frank:
2) Den Root-Zugriff per Remote komplett verbieten und nur mit dem User einloggen (alternativ wie SlainteMhath empfohlen hat,
nur über einen private Keys reingehen).
2) Den Root-Zugriff per Remote komplett verbieten und nur mit dem User einloggen (alternativ wie SlainteMhath empfohlen hat,
nur über einen private Keys reingehen).
Ich würde das nicht als "alternativ" bezeichnen.
Meiner Meinung nach sollten SSH-Server grundsätzlich weder root-Zugriff noch Passwort-Anmeldung zulassen.
Also immer nur normaler User mit Keyfile.
3) Du änderst den Standard SSH-Port von 22 auf irgendwas über 4000 (z.B. 4267). Damit wird der Rechner in der Regel
nicht mehr/kaum noch gescannt.
nicht mehr/kaum noch gescannt.
Naja, wenn er "eventuell weltweit" auf seinen Server zugreifen möchte, dann könnte das evtl. Probleme machen. Mir ist noch nie eine Firewall begegnet, die den SSH-Port (zumindest nach draußen) blockt, während ich so einige kenne, die Zugriffe auf "beliebige" nicht-well-known Ports unterbinden. (In dem Fall benutze ich z.B. einen SSH-Tunnel/Portweiterleitung)
Das heißt er könnte bei einem zufälligen Port Gefahr laufen mal irgendwo nicht an seinen Server zu kommen.
Moin,
Die Tipps von Frank (und den anderen) reichen id.R. vollkommen um etwas Ruhe zu bekommen. Das wichtigste ist aber, root-login und password-authentifikation zu verbieten. Sofern das passiert ist und der private Schlüssel gut gewählt ist sollten einen die anmeldeversuche unkritisch sein, außer daß sie halt nerven und die logfiles vollmüllen.
Sofern man wirklich von "überallher" auf per ssh verbinden muß, sollte man den Standardport auf 22 lassen, weil das eben die wenigsten Probleme mit fremden Firewalls macht.
lks
Die Tipps von Frank (und den anderen) reichen id.R. vollkommen um etwas Ruhe zu bekommen. Das wichtigste ist aber, root-login und password-authentifikation zu verbieten. Sofern das passiert ist und der private Schlüssel gut gewählt ist sollten einen die anmeldeversuche unkritisch sein, außer daß sie halt nerven und die logfiles vollmüllen.
Sofern man wirklich von "überallher" auf per ssh verbinden muß, sollte man den Standardport auf 22 lassen, weil das eben die wenigsten Probleme mit fremden Firewalls macht.
lks
Zitat von @Frank:
3) Du änderst den Standard SSH-Port von 22 auf irgendwas über 4000 (z.B. 4267). Damit wird der Rechner in der Regel
nicht mehr/kaum noch gescannt.
3) Du änderst den Standard SSH-Port von 22 auf irgendwas über 4000 (z.B. 4267). Damit wird der Rechner in der Regel
nicht mehr/kaum noch gescannt.
Aber nur von den Skript-kiddies nicht mehr. Die Profis und Auftragshacker sind da gründlicher. Die lassen keinen Port aus und distributed scans sind ja heutzutage kein Problem mehr mit dem richtigen Botnetz.
Ist wie mit dem bildschirmschoner mit paßwortschutz. Das hält zwar die Putzfrau davon ab, mal schnell "die emails zu checken", aber den Datendieb, der es auf die Firmeninterna abgesehen hat, hält es nicht auf. (Der istalliert einen keylogger oder einen hdd-sniffer/duplizierer).
lks
Hallo @itproject,
Ich empfehle dir zusätzlich auch noch "Denyhosts" zu installieren (wie oben beschrieben, dauert ca. 2 Minuten). Damit kannst du die SSH Zugriffe auf deinem Server kontrollieren. Denyhosts sollte auf keinem System fehlen!
Gruß
Frank
Ich empfehle dir zusätzlich auch noch "Denyhosts" zu installieren (wie oben beschrieben, dauert ca. 2 Minuten). Damit kannst du die SSH Zugriffe auf deinem Server kontrollieren. Denyhosts sollte auf keinem System fehlen!
Gruß
Frank
Zitat von @dog:
> Die Profis und Auftragshacker sind da gründlicher. Die lassen keinen Port aus
Vielleicht sollten wir dann TCPv6 einführen.
Mit 128-Bit Portnummern
> Die Profis und Auftragshacker sind da gründlicher. Die lassen keinen Port aus
Vielleicht sollten wir dann TCPv6 einführen.
Mit 128-Bit Portnummern
Jepp.
wenn man denn endlich native-IPv6 am DSL-Anschluß und bei den Hostern bekommen würde und nicht über sixx o.ä tunneln müßte. Es werden zwar immer mehr Anbieter, aber das nützt nichts, wenn es nicht der ist, an den man gebunden ist.
lks
PS. Oder man verwendet Klopfzeichen um Einlaß an den Ports zu bekommen.