Archiv verlassen und diese Seite im Standarddesign anzeigen : Da versucht jemand in mein System zu kommen?!?
Hallo,
seht euch mal die messages Log an. (im Anhang)
Da versucht doch jemand meinen Root Server zu knacken oder?
Was sollte ich alles unternehmen?
May 22 03:50:02 ***** sshd[27475]: Failed password for root from ::ffff:84.244.4.142 port 38999 ssh2
May 22 03:50:02 ***** sshd[27475]: Received disconnect from ::ffff:84.244.4.142: 11: Bye Bye
May 22 03:50:10 ***** sshd[27476]: Illegal user admin from ::ffff:84.244.4.142
May 22 03:50:10 ***** sshd[27476]: input_userauth_request: illegal user admin
May 22 03:50:10 ***** sshd[27476]: Failed password for illegal user admin from ::ffff:84.244.4.142 port 39299 ssh2
May 22 03:50:10 ***** sshd[27476]: Received disconnect from ::ffff:84.244.4.142: 11: Bye Bye
May 22 03:50:13 ***** sshd[27477]: Illegal user test from ::ffff:84.244.4.142
May 22 03:50:13 ***** sshd[27477]: input_userauth_request: illegal user test
May 22 03:50:13 ***** sshd[27477]: Failed password for illegal user test from ::ffff:84.244.4.142 port 43171 ssh2
May 22 03:50:13 ***** sshd[27477]: Received disconnect from ::ffff:84.244.4.142: 11: Bye Bye
May 22 03:50:20 ***** sshd[27478]: Illegal user guest from ::ffff:84.244.4.142
May 22 03:50:20 ***** sshd[27478]: input_userauth_request: illegal user guest
gruß
hobie
Das ist ein ganz normaler, aber unerwünschter Portscan mit Login-Versuch per zufällig gewählten User-Namen und Kennwort.
1. Lasse nur ssh Vers. 2 zu, untersage login-Versuche mit ssh Vers. 1
2. Verbiete User root login - Verbindungen per ssh
3. Wähle einen außergewöhnlichen User-Namen, nicht etwa admin, webman,
test etc. und ein gutes ausgefallenes Kennwort
Wenn Du das Obige korrekt umgesetzt hast, brauchst Du Dir eignetlich kaum Sorgen zu machen. Dann dann kennt der "Scanner" weder den User-Namen noch das Kennwort. :D
Diese "Scanner" sind auf zufällige schnelle Beute aus. Ich kenne einen Server der locker geknackt wurde, da der Benutzer den User-Namen und Kennwort af linux gesetzt hatte. Da braucht man sich über nichts zu wundern. :ugly:
ich denke nicht, dass man da viel machen kann. Vom Netz nehmen wär ja blödsinn... Es sieht auch nicht dannach aus, als wäre der Angreifer erfolgreich gewesen. :ugly:
Keine Sorge, solche Versuche habe ich täglich seitdem ich Port 22 für SSH geöffnet habe. Passiert ist in fast einem Jahr nichts. ;)
Verschoben ins Forum "Sicherheit".
Siehe dazu auch folgenden Thread: http://www.linuxforen.de/forums/showthread.php?t=166256
ich würde an deiner stelle die tipps von blade befolgen und zusätzlich noch den sshd auf einen anderen (unbekannten) port schalten, dann ist auch bei dir ruhe ;)
ciao
psy
chrisi1698
24.05.05, 22:11
hallo!
sowas kommt bei mir am SSHD auch dauernd vor, und auch wenn nicht wirklich was passiert, nervts gewaltig. :rolleyes:
@auf-anderen-port-umleiten: wenn der angreifer nen portscan macht, hat er das doch in 0,7sec?^^ wer sind eigentlich diese angreifer? scannen die just for fun einfach alle ssh-ports einer bestimmten ip-range und probieren dann ihre standard-usernamendatenbank aus? wenn man ein 'login incorrect' zurueckbekommt, kann man daraus ja nicht schliessen, ob das PW falsch war, oder ob es den user gar nicht gibt. also was soll das alles eigentlich? :confused: bzw, was macht der, wenn er wirklich drin ist? koennte ich mal per vmware ausprobieren.. .*fg* user linux, pw auch linux^^...
konkret noch ne frage: kann man eine IP, von der sich jemand zB 3mal ein 'login incorrect' eingefangen hat fuer 10min sperren? das wuerde die frequenz der versuche zumindest etwas senken, da sonst (ca alle 2sec ein versuch) schon eeeeetwas haeufig ist, meiner ansicht nach...
ich hab bei man sshd_config keine derartige option gefunden. leider. muss man das vllt machen, indem man sshd ueber den inetd startet, dass der inetd die verfeinerte zugriffskontrolle uebernimmt?
lg, christian
edit: hab grad im andern thread von einer ziemlich gleichen fragestellung wie meiner gelesen, loesung hatte trotzdem (noch) keiner wirklich, das mit logwatch, scripts, hosts.deny, ist mir auch schon eingefallen, aber 'native' vom sshd waere mir das lieber ;) also bitte um verstaendnis fuer meine doppelfrage ;)
die lösung könnte "authfail" sein - dieses programm
überprüft die /var/log/auth.log und sperrt dann nach
n missglückten logins den angreifer via iptables aus
EDIT: funktioniert bei dem server eines bekannten einwandfrei
- sein rechner litt auch an ssh-attacken
mfg mcfock
Ist es nicht möglich, via iptables die Verbindung auf Port 22 (oder wo sshd eben grad lauscht) auf bestimmte Zeitabstände zu begrenzen?
ein script könnte das realisieren (zeitpunkt 1: port dicht machen, zp 2: port öffnen usw)
Das Thema hatten wir schonmal - eine Lösung wurde präsentiert...
Bitte mal die SUFU benutzen...
mfg
cane
die gleichen Logs habe ich auch des öfteren. Wir haben dann zurück gescannt und der Angreifer hatte einen Rechner, offen wie ein Scheunentor. Telnet, HTTP dar war einfach alles offen.
Schön wäre eine Funktionen wie sie einige Hardware-Router bieten. Wenn ein und die selbe Quelle in einem kurzem Zeitabstand erfolglos zu verbinden wird der Port für Ihn geschlossen. Portscann's fallen dann sehr kurz aus.
Hi,
irgenwie hat irgendwo irgendwer das schon mal gepostet:
http://linux.newald.de/new_design/login_check.html
Ein Perlskript, das die IP nach einer bestimmten Anzahl Loginversuche für eine bestimmte Zeit sperrt (über iptables).
BTW: funktioniert sehr gut. :D
LKH
die gleichen Logs habe ich auch des öfteren. Wir haben dann zurück gescannt und der Angreifer hatte einen Rechner, offen wie ein Scheunentor. Telnet, HTTP dar war einfach alles offen.
Ich denke eher nicht, dass das der Rechner des tatsächlichen Angreifers war... wie du sagst, der Rechner war offen, also auch für indirekte Angriffe zu gebrauchen.
Ist es nicht möglich, via iptables die Verbindung auf Port 22 (oder wo sshd eben grad lauscht) auf bestimmte Zeitabstände zu begrenzen?
Doch: http://blog.hexagon.at/2005/03/25/ssh-brute-force-attacken-abwehren/
Generell würde ich auch den sshd-port auf irgendeinen >1024 legen.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.