RootForum Community

Resources for System-Administrators
https://www.rootforum.org/forum/

SSH-Zugriffsversuch

https://www.rootforum.org/forum/viewtopic.php?t=45035

Page 1 of 1

SSH-Zugriffsversuch

Posted: 2007-03-09 17:53
by Anonymous
Hallo,

ich verfolge seit einiger Zeit meine /var/log/login und bemerke dabei des öfteren solche Zeilen:

Code: Select all

Dec 20 00:28:18 Arktur sshd[12363]: Invalid user test from 216.153.128.159
Dec 20 00:28:18 Arktur sshd[12363]: reverse mapping checking getaddrinfo for mail1.nytas.com failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 20 00:28:18 Arktur sshd[12363]: input_userauth_request: invalid user test
Dec 20 00:28:18 Arktur sshd[12363]: Failed password for invalid user test from 216.153.128.159 port 33277 ssh2
Dec 20 00:28:18 Arktur sshd[12363]: Received disconnect from 216.153.128.159: 11: Bye Bye
Dec 20 00:28:20 Arktur sshd[12364]: User guest not allowed because shell /dev/null is not executable
Dec 20 00:28:20 Arktur sshd[12364]: input_userauth_request: invalid user guest
Dec 20 00:28:20 Arktur sshd[12364]: reverse mapping checking getaddrinfo for mail1.nytas.com failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 20 00:28:20 Arktur sshd[12364]: Failed password for invalid user guest from 216.153.128.159 port 33334 ssh2
Dec 20 00:28:20 Arktur sshd[12364]: Received disconnect from 216.153.128.159: 11: Bye Bye
Dec 20 00:28:21 Arktur sshd[12365]: Invalid user admin from 216.153.128.159
Dec 20 00:28:21 Arktur sshd[12365]: reverse mapping checking getaddrinfo for mail1.nytas.com failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 20 00:28:21 Arktur sshd[12365]: input_userauth_request: invalid user admin
Dec 20 00:28:21 Arktur sshd[12365]: Failed password for invalid user admin from 216.153.128.159 port 33387 ssh2
Dec 20 00:28:21 Arktur sshd[12365]: Received disconnect from 216.153.128.159: 11: Bye Bye
Dec 20 00:28:22 Arktur sshd[12372]: Invalid user admin from 216.153.128.159
Dec 20 00:28:22 Arktur sshd[12372]: reverse mapping checking getaddrinfo for mail1.nytas.com failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 20 00:28:22 Arktur sshd[12372]: input_userauth_request: invalid user admin
Dec 20 00:28:22 Arktur sshd[12372]: Failed password for invalid user admin from 216.153.128.159 port 33448 ssh2
Dec 20 00:28:23 Arktur sshd[12372]: Received disconnect from 216.153.128.159: 11: Bye Bye
Dec 20 00:28:24 Arktur sshd[12373]: Invalid user user from 216.153.128.159
Dec 20 00:28:24 Arktur sshd[12373]: reverse mapping checking getaddrinfo for mail1.nytas.com failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 20 00:28:24 Arktur sshd[12373]: input_userauth_request: invalid user user
Dec 20 00:28:24 Arktur sshd[12373]: Failed password for invalid user user from 216.153.128.159 port 33503 ssh2
Dec 20 00:28:24 Arktur sshd[12373]: Received disconnect from 216.153.128.159: 11: Bye Bye
Dec 20 00:28:25 Arktur sshd[12374]: reverse mapping checking getaddrinfo for mail1.nytas.com failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 20 00:28:25 Arktur sshd[12374]: Failed password for root from 216.153.128.159 port 33555 ssh2
Dec 20 00:28:25 Arktur sshd[12374]: Received disconnect from 216.153.128.159: 11: Bye Bye
Dec 20 00:28:26 Arktur sshd[12381]: reverse mapping checking getaddrinfo for mail1.nytas.com failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 20 00:28:26 Arktur sshd[12381]: Failed password for root from 216.153.128.159 port 33612 ssh2
Dec 20 00:28:27 Arktur sshd[12381]: Received disconnect from 216.153.128.159: 11: Bye Bye
Dec 20 00:28:28 Arktur sshd[12382]: reverse mapping checking getaddrinfo for mail1.nytas.com failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 20 00:28:28 Arktur sshd[12382]: Failed password for root from 216.153.128.159 port 33658 ssh2
Dec 20 00:28:28 Arktur sshd[12382]: Received disconnect from 216.153.128.159: 11: Bye Bye
Dec 20 00:28:29 Arktur sshd[12383]: Invalid user test from 216.153.128.159
Dec 20 00:28:29 Arktur sshd[12383]: reverse mapping checking getaddrinfo for mail1.nytas.com failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 20 00:28:29 Arktur sshd[12383]: input_userauth_request: invalid user test
Dec 20 00:28:29 Arktur sshd[12383]: Failed password for invalid user test from 216.153.128.159 port 33706 ssh2
Dec 20 00:28:29 Arktur sshd[12383]: Received disconnect from 216.153.128.159: 11: Bye Bye
Warum ich hier poste:
Ich war der Meinung, dass wenn ich über meine Firewall den Port 22 für SSH blocke, der Dienst dann auch nicht erreichbar ist von außen. Aber wieso spricht der Dienst z.B. auf Port 33706 an?

Und ist der Eindringling in mein System gekommen?

THX, für euere Hilfe.

Gruß

Re: SSH-Zugriffsversuch

Posted: 2007-03-09 18:45
by daemotron
Waterloo wrote:Ich war der Meinung, dass wenn ich über meine Firewall den Port 22 für SSH blocke, der Dienst dann auch nicht erreichbar ist von außen
Wenn Du das richtig gemacht hast, ist das auch so (aber Du selbst kommst auch nicht mehr per SSH an die Kiste ran).
Waterloo wrote:Aber wieso spricht der Dienst z.B. auf Port 33706 an?
Das ist der Port der Gegenstelle.
Waterloo wrote:Und ist der Eindringling in mein System gekommen?
Das weiß ich nicht, aber wenn's nur nach Deinem Log-Auszug geht, dann nicht.

Re: SSH-Zugriffsversuch

Posted: 2007-03-09 22:25
by kumpel2
HI,

gut für dich vielleicht fail2ban.

Oder hol dir eine DSL-Flat mit fester IP und geb den SSH Port nur für deine IP frei ;)

Oder verleg den SSH Port auf einen Hohen Port >50 000...

LG

Re: SSH-Zugriffsversuch

Posted: 2007-03-09 22:43
by daemotron
Auch wenn es wieder keiner hören will: zu allererst auf pubkey-Authentifizierung umsteigen und Auth per User/Passwort komplett verbieten. Damit wird keines dieser Passwort-Ratespielchen jemals zum Erfolg führen.

Wenn das erledigt ist, kann man solche Maßnahmen wie denyhosts, Portverlegung etc. in Betracht ziehen - die dienen aber in erster Linie dazu, Deine Logs sauber zu halten und den Kreis der Angreifer auf diejenigen einzuschränken, die es wirklich ernst meinen.

Re: SSH-Zugriffsversuch

Posted: 2007-03-10 13:52
by Joe User
Die Logs kann man auch durch Änderung des Loglevels sauber halten...

Re: SSH-Zugriffsversuch

Posted: 2007-03-10 14:14
by nyxus
Joe User wrote:Die Logs kann man auch durch Änderung des Loglevels sauber halten...
"LogLevel QUIET"? ;-) Es geht den meisten sicher eher darum, die automatisierten Fehlversuche nicht mehr im Log zu haben.

Re: SSH-Zugriffsversuch

Posted: 2007-03-11 22:10
by danu
und den Kreis der Angreifer auf diejenigen einzuschränken, die es wirklich ernst meinen
.. und dabei herausfinden, welche Attacke ernst ist ?
Die Flut der tälichen Logfiles durchzuchecken ist für mich ein Muss. Dabei ist mir denyhosts eine grosse Hilfe. Es ist sicher sinnvoll (Fehlersuche)soviel wie möglich zu loggen, aber das, was der Admin täglich sich ansehen muss, übersichtlich in /var/log/messages sichtbar ist. Die Prozessortemperatur ineressiert da recht wenig :P

Re: SSH-Zugriffsversuch

Posted: 2007-03-19 21:25
by buggy
also ich habe auch das oben genannte problem. leider macht ein gewisser Benutzer:

Code: Select all

Mar 19 21:00:54 h2964 sshd[10076]: Received disconnect from ::ffff:88.214.208.27: 11: Bye Bye
Mar 19 21:00:55 h2964 sshd[10077]: Failed password for root from ::ffff:88.214.208.27 port 55922 ssh2
Mar 19 21:00:55 h2964 sshd[10077]: Received disconnect from ::ffff:88.214.208.27: 11: Bye Bye
Mar 19 21:00:56 h2964 sshd[10078]: Failed password for root from ::ffff:88.214.208.27 port 56153 ssh2
Mar 19 21:00:57 h2964 sshd[10078]: Received disconnect from ::ffff:88.214.208.27: 11: Bye Bye
Mar 19 21:00:58 h2964 sshd[10080]: Failed password for root from ::ffff:88.214.208.27 port 56442 ssh2
Mar 19 21:00:58 h2964 sshd[10080]: Received disconnect from ::ffff:88.214.208.27: 11: Bye Bye
Mar 19 21:01:00 h2964 sshd[10083]: Failed password for root from ::ffff:88.214.208.27 port 56798 ssh2
Was ist nun wirklich die beste Möglichkeit dieses zu unterbinden, da ich zur zeit mehr downtime als uptime des Servers habe.
Ich brauche jedoch von überall access weiterhin drauf, meinetwegen nmit bissel umwege aber net zuviel

Re: SSH-Zugriffsversuch

Posted: 2007-03-19 23:30
by codc
@buggy - lesen:
jfreund wrote:Auch wenn es wieder keiner hören will: zu allererst auf pubkey-Authentifizierung umsteigen und Auth per User/Passwort komplett verbieten.

Re: SSH-Zugriffsversuch

Posted: 2007-03-20 02:21
by danu
denyhost bewirkt immerhin dass die Anzahl erfolgloser Loginversuche wirkungsvoll eingeschränkt wird, und somit die Chance, das richtige Passwort zu erraten. Ausserdem schreibt denyhost in die /etc/hosts.deny

Code: Select all

sshd: 219.80.34.78
sshd: 85.158.181.11
.
.
.
bei wiederholten Angriffswellen von derselben IP. Ich sehe darin einen wesentlichen Schutz. Dazu ist /var/log/messages von 2MB auf 1MB geschrumpft.

Re: SSH-Zugriffsversuch

Posted: 2007-03-20 16:22
by rootsvr
codc wrote:@buggy - lesen:
jfreund wrote:Auch wenn es wieder keiner hören will: zu allererst auf pubkey-Authentifizierung umsteigen und Auth per User/Passwort komplett verbieten.
wie war das im Hetznerforum mit demjenigen der alles per publickey eingerichtet hat und dann mit der Lara (kein PublicKey) sich nicht lokal an seinem Server anmelden konnte.

Generell sind die Tests auf hirnlose Passwörter ungefährlich, machen nur ein paar Logeinträge. Wenn Du allerdings Passwörter wie "password", "sex", "admin" oder "root" hast wäre dir eh nicht zu helfen.

Key ist toll, bei sicheren (langen) passwörtern würde ich mir allerdings keine übergroßen Sorgen machen.

Re: SSH-Zugriffsversuch

Posted: 2007-03-20 16:27
by Joe User
danu wrote:denyhost bewirkt immerhin dass die Anzahl erfolgloser Loginversuche wirkungsvoll eingeschränkt wird...
Und funktioniert nur, wenn der SSHd mit Unterstützung für tcp-wrapper kompiliert wurde...

Re: SSH-Zugriffsversuch

Posted: 2007-03-20 16:42
by blattlaus
Erwähnt schon jemand fail2ban?

Re: SSH-Zugriffsversuch

Posted: 2007-03-20 17:47
by Roger Wilco
Blattlaus wrote:Erwähnt schon jemand fail2ban?
KuMpEl2 wrote:gut für dich vielleicht fail2ban.

Re: SSH-Zugriffsversuch

Posted: 2007-03-20 18:27
by daemotron
matzewe01 wrote:Herje, immer diese Diskussionen.

Er hat nach gefragt... ist definitiv eine Methode, die die Sicherheit von SSH verbessert.
matzewe01 wrote:Mit Allowuser habe ich einen recht cryptischen Benutzername erlaubt.
Meine Erfahrung mit der sshd_config von Benutzern, die so etwas schreiben (nicht persönlich auf den Poster gemünzt, eher allgemein gesprochen, also nicht böse sein :wink:):
Ich war der Meinung, dass wenn ich über meine Firewall den Port 22 für SSH blocke
I. d. R. ist weder der Login als root verboten, noch der Zugriff auf eine Bestimmte Gruppe limitiert. Teilweise haben System-User /bin/bash als Shell eingetragen - von schwer zu erratenden Benutzernamen und kryptischen Passwörtern mal ganz zu schweigen... Die Praxis gibt mir leider immer wieder recht, wenn ich darauf poche, erst mal die Möglichkeiten von OpenSSH selbst auszuschöpfen, als auf Workarounds wie denyhosts & Co. auszuweichen. Mal davon abgesehen, dass die Code-Qualität bei OpenSSH um einiges höher sein dürfte als bei abenteuerlichen Perl- und Python-Skripten (nicht wegen der Programmiersprache, aber das ist quasi ein Markenzeichen der OpenBSD-Leute :wink: *SCNR*)

Re: SSH-Zugriffsversuch

Posted: 2007-03-21 00:47
by timeless2
matzewe01 wrote:Naja, und bei Deiner Erfahrung mit der Allgemeinheit, musst Du früher oder später damit rechnen, dass jemand hier aufschlägt und fragt, wie man auf einen Server kommt, wo man seinen ssh-key verloren hat. 8O
Oder den Super-kryptischen Benutzernamen oder/und Passwort 8O

Re: SSH-Zugriffsversuch

Posted: 2007-03-21 07:23
by captaincrunch
Um mal einen neuen Punkt in die "sichere Passwort"-Diskussion einzubringen: (aber Achtung,) Schleichwerbung ;)

Re: SSH-Zugriffsversuch

Posted: 2007-03-21 07:54
by daemotron
matzewe01 wrote:Und was man sich im Kopf merken kann, geht bei einem Plattencrash nicht einfach so verloren.
Das's ja mal ein Argument - wozu gibt es USB-Sticks und Backups? OK, ist wahrscheinlich nicht ganz so weit hergeholt, dass Leute ihren Key zu Hause auf einem RAID0 ohne jedes Backup speichern... *Autsch*
matzewe01 wrote:Ich erwähne hierbei nur mal nebenbei der Zugang per Remote Console, den viele Provider anbieten.
Diesen Service kann man in vielen Fällen per Webinterface aktivieren.
Wenn man eine solche Möglichkeit hat, kann man durchaus einen authkey einsetzen.
Kann man auch, wenn man keine Remote Console hat - einen Provider ohne Rettungssystem würde ich erst gar nicht in Betracht ziehen...

Mal abgesehen davon drehen wir uns im Kreis. Mein Standpunkt: Man kann einen sshd auch ohne pubkey-Authentifizierung einigermaßen sicher betreiben - Voraussetzung sind aber Restriktionen für den SSH-Zugriff auf Benutzer- oder Gruppenebene und entsprechend sicher gewählte Usernamen und Passwörter. In den meisten Fällen, wenn solche Themen hier auf die Tagsordnung gebracht werden, ist aber keine dieser Maßnahmen umgesetzt worden.

So, zu guter letzt hier noch ein Beispiel für eine sshd_config, die einem den meisten Ärger vom Hals halten dürfte (außer private Schlüssel ohne Backup auf einem gecrashten RAID0 zu Hause) - ich beschränke mich durchaus nicht auf pubkey-auth bei der Absicherung:

Code: Select all

#Optional: Port verlegen, um Logs klein zu halten
Port 9922
Protocol 2

#Funktioniert nicht mit älteren OpenSSH-Versionen:
AddressFamily inet

#Wer mehrere IPs hat, kann hier einschränken
#ListenAddress 0.0.0.0

PermitRootLogin forced-commands-only
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no

Subsystem sftp /usr/lib/misc/sftp-server

#Nur Mitglieder von wheel dürfen (und bei mir können auch nur die su ausführen)
AllowGroups wheel

Re: SSH-Zugriffsversuch

Posted: 2007-07-13 16:40
by Anonymous
Vielleicht bereits nicht mehr aktuell, trotzdem möcht ichs nicht versäumen, noch einen meiner Meinung nach viel zu wenig angesprochenen Lösungsansatz gegen Bruteforce Attacken zu nennen: iptables!
Ich halte mir die unliebsamen Bruteforcer so vom Hals:

Code: Select all

# SSH erlauben - aber vor bruteforce schützen
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 90 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 90 --hitcount 4 --rttl --name SSH -j DROP
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
Danebst sind sicherlich die root Logins generell auszuschalten, diesen Benutzernamen muss man gar nicht erst erraten, daher ist die Gefahr diesen zu "knacken" noch um einiges höher.
Obige Befehle (aus meinem Firewall script) bewerkstelligen, dass ein Verbindungsversuch auf den Port 22 von derselben IP aus bloss max. 3 Mal versucht werden kann, resp. genau genommen, dass maximal bis zu 3 Verbindungen innerhalb 90 sek. auf dem Port 22 von derselben IP aus erstellt werden können. Ab dem 4. Versuch werden die Pakete verworfen. Die Gegenstelle sitzt dann da und kriegt ein Timeout. Das schlimmste was passieren kann, ist dass man sich selbst 3 Mal vertippt und dann eineinhalb Minuten warten muss, um eine neue Verbindung aufzubauen...
Ich verzeichne damit einen nennenswerten Erfolg:

Code: Select all

Jul 13 06:20:01 [cron] (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Jul 13 06:23:19 [kernel] SSH_brute_force IN=eth4 OUT= MAC=00:40:95:30:a8:15:00:14:f1:1b:23:01:08:00 SRC=88.115.65.242 DST=80.218.194.96 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=14039 DF PROTO=TCP SPT=3669 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
Jul 13 06:23:22 [kernel] SSH_brute_force IN=eth4 OUT= MAC=00:40:95:30:a8:15:00:14:f1:1b:23:01:08:00 SRC=88.115.65.242 DST=80.218.194.96 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=14040 DF PROTO=TCP SPT=3669 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
Jul 13 06:23:28 [kernel] SSH_brute_force IN=eth4 OUT= MAC=00:40:95:30:a8:15:00:14:f1:1b:23:01:08:00 SRC=88.115.65.242 DST=80.218.194.96 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=14041 DF PROTO=TCP SPT=3669 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
Jul 13 06:30:01 [cron] (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Der "hacker" hat nach drei erfolgslosen Verbindungsversuchen abgebrochen. Bruteforce, bei welcher nach drei Versuchen bis zur nächsten Verbindung 90 sek. lang gewartet werden muss, lohnt sich nicht!
All times are UTC+01:00
Page 1 of 1