Hackversuch

[pixkart]

Hallöchen,

ich habe 4 Roots und bei einem davon bekam ich heute früh mal wieder einen Schock. Ich loggte mich ein, weil die Kiste lahmte (habe SSH nur per Private-Key laufen). Es waren 2 User (inkl. mir) eingeloggt. Ich als root und einer als admin (Debian-User) und es lief "ssh-scan". Zuerst war ich baff wie der das geschafft hat. Ich schaute - wie üblich - ins /tmp, wo sich ein Ordner .a befand, der admin gehört(e). Den löschte ich sofort, vergab ein neues PW für admin und rebootete die Kiste. Da war er weg.

Ein Blick in die Logs zeigte dann das:

Code: Select all

Jun  6 08:07:11 athen21 sshd[6820]: Failed password for illegal user info from 66.218.54.46 port 46268 s$
Jun  6 08:07:12 athen21 sshd[6822]: Failed password for root from 66.218.54.46 port 56408 ssh2
Jun  6 08:07:12 athen21 sshd[6824]: Illegal user test from 66.218.54.46
Jun  6 08:07:12 athen21 sshd[6824]: error: Could not get shadow information for NOUSER
Jun  6 08:07:12 athen21 sshd[6824]: Failed password for illegal user test from 66.218.54.46 port 55936 s$
Jun  6 08:07:14 athen21 sshd[6826]: Illegal user network from 66.218.54.46
Jun  6 08:07:14 athen21 sshd[6826]: error: Could not get shadow information for NOUSER
Jun  6 08:07:14 athen21 sshd[6826]: Failed password for illegal user network from 66.218.54.46 port 5987$
Jun  6 08:07:14 athen21 sshd[6830]: Failed password for admin from 66.218.54.46 port 56452 ssh2
Jun  6 08:07:15 athen21 sshd[6831]: Illegal user webmaster from 66.218.54.46
Jun  6 08:07:15 athen21 sshd[6831]: error: Could not get shadow information for NOUSER
Jun  6 08:07:15 athen21 sshd[6831]: Failed password for illegal user webmaster from 66.218.54.46 port 55$
Jun  6 08:07:15 athen21 sshd[6834]: Illegal user word from 66.218.54.46
Jun  6 08:15:59 athen21 sshd[8428]: Failed password for admin from 66.218.54.46 port 35920 ssh2
Jun  6 08:16:00 athen21 sshd[8434]: Failed password for admin from 66.218.54.46 port 35934 ssh2
Jun  6 08:16:01 athen21 sshd[8438]: Failed password for admin from 66.218.54.46 port 35941 ssh2
Jun  6 08:16:03 athen21 sshd[8440]: Failed password for admin from 66.218.54.46 port 35954 ssh2
Jun  6 08:16:04 athen21 sshd[8444]: Failed password for admin from 66.218.54.46 port 35969 ssh2
Jun  6 08:16:05 athen21 sshd[8447]: Failed password for admin from 66.218.54.46 port 35978 ssh2
Jun  6 08:16:06 athen21 sshd[8452]: Failed password for admin from 66.218.54.46 port 35989 ssh2
Jun  6 08:16:07 athen21 sshd[8456]: Failed password for admin from 66.218.54.46 port 36003 ssh2
Jun  6 08:16:08 athen21 sshd[8460]: Failed password for admin from 66.218.54.46 port 36013 ssh2
Jun  6 08:16:09 athen21 sshd[8464]: Failed password for admin from 66.218.54.46 port 36025 ssh2
Jun  6 08:16:11 athen21 sshd[8466]: Failed password for admin from 66.218.54.46 port 36039 ssh2
Jun  6 08:16:12 athen21 sshd[8470]: Failed password for admin from 66.218.54.46 port 36047 ssh2
Jun  6 08:16:13 athen21 sshd[8474]: Failed password for admin from 66.218.54.46 port 36060 ssh2

usw.

Nur kam dann:

Code: Select all

Jun  6 11:01:53 athen21 sshd[8022]: Accepted password for admin from 89.136.64.140 port 4589 ssh2
Jun  6 11:01:54 athen21 sshd[8069]: (pam_unix) session opened for user admin by (uid=0)
Jun  6 11:02:25 athen21 passwd[8108]: (pam_unix) authentication failure; logname=admin uid=1000 euid=0 t$
Jun  6 11:02:38 athen21 passwd[8121]: (pam_unix) password changed for admin
Jun  6 11:02:38 athen21 passwd[8121]: (pam_unix) Password for admin was changed
Jun  6 11:03:49 athen21 sshd[8230]: Accepted password for admin from 89.136.64.140 port 4592 ssh2

Was mich pers. schockte, da wir ÜBERALL 9-stellige, alphanumerische Passwörter nutzen. Ich schaute dann direkt in die sshd_config, denn das darf normal ja nicht sein bei aktiviertem Private-Key Login. Hier die "alte" Datei

Code: Select all

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes

RSAAuthentication no
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication yes

# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Subsystem       sftp    /usr/lib/sftp-server

UsePAM yes

Das Problem war - denke ich - "PasswordAuthentication yes", die mein damaliger Admin wohl falsch gesetzt hatte. Ich habe es dann gegen 13 Uhr auf "PasswordAuthentication no" geändert und per "/etc/init.d/ssh restart" neu gestartet. Seit dem ist Ruhe im Karton.

Habt ihr weitere Sicherheitstipps? Bzw. gibt es eine Möglichkeit, ALLEN Usern des Servers ssh zu "verbieten" bis auf root mit dem Key?

Grüße

[Joe User]

http://www.rootforum.org/wiki/howto/gen ... figurieren

UsePAM muss Off sein, siehe "man sshd_config", desweiteren kennt Dein OpenSSH noch kein "AddressFamily".

[pixkart]

Danke für den Tipp. Kannst du mir etwas zu den Auswirkungen von usePAM no sagen? Leider mag der Link nicht bei mir funktionieren, die Site ist zerschossen.

[flo]

Danke für den Tipp. Kannst du mir etwas zu den Auswirkungen von usePAM no sagen? Leider mag der Link nicht bei mir funktionieren, die Site ist zerschossen.

Die Debian-Config sieht ja so aus:

Code: Select all

# PAM configuration for the Secure Shell service

# Disallow non-root logins when /etc/nologin exists.
auth       required     pam_nologin.so

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth       required     pam_env.so # [1]

# Standard Un*x authentication.
@include common-auth

# Standard Un*x authorization.
@include common-account

# Standard Un*x session setup and teardown.
@include common-session

# Print the message of the day upon successful login.
session    optional     pam_motd.so # [1]

# Print the status of the user's mailbox upon successful login.
session    optional     pam_mail.so standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session    required     pam_limits.so

# Standard Un*x password updating.
@include common-password

Ich denke, daß das wohl die Einstellungen in der sshd-config überschreibt, weil man ja PAM als Authentifizierungsmethode angegeben hat!?

flo.

[Joe User]

Ich denke, daß das wohl die Einstellungen in der sshd-config überschreibt, weil man ja PAM als Authentifizierungsmethode angegeben hat!?

So ist es.

[pixkart]

Danke für die Antworten. Also UsePam auf no. Habe ich jetzt mal gemacht. Dadurch sollte es aber keine Probleme beim Login per Key geben, richtig? Muss mich mit dem PAM mal mehr auseinandersetzen.

[khark]

Habt ihr weitere Sicherheitstipps?

Ja.

Code: Select all

PermitRootLogin no
AllowUsers uuser1

Man meldet sich nicht direkt als Root an seinem System an, auch wenn man Keys benutzt.
Die 2. Zeile erlaubt es nur den aufgeführten User "uuser1" sich per SSH einloggen.
Den Usernamen kannst du ja beliebig anpassen, sollte einer sein, der von den SSH-Bruteforce-Skripten nicht ausprobiert wird. (Also kein Name eines Systemdienstes (gopher, irc, init, etc.) oder Standardbenutzers (root!!!!).

Bzw. gibt es eine Möglichkeit, ALLEN Usern des Servers ssh zu "verbieten" bis auf root mit dem Key?

Wenn du es wie folgt änderst, sollte es so gehen.

Code: Select all

PermitRootLogin yes
AllowUsers root

(NICHT EMPFOHLEN!!)

Ich verwende aber Password Authentication und keine Keys. Daher weiß ich nicht, ob bei der Verwendungen von Keys der Effekt der selbe ist, oder ob dir PAM dazwischenschießt.

Ansonsten hätte ich noch eine kleine, nette SSH-Motd (auch /etc/issue.net genannt) anzubieten: http://www.kharkerlake.net/ssh-banner.txt :twisted:

Hast du noch den Exploit, der sich in /tmp/.a befand?? Ich sehe die Bruteforces ja sonst nur als Logzeileneinträge und mich würde mal interessieren, wie die Skripte aussehen.
(Bin grad zu faul bei PacketStorm & Co. zu suchen :-) )


MfG Khark

[oxygen]

Man meldet sich nicht direkt als Root an seinem System an, auch wenn man Keys benutzt.

Warum nicht? Wenn man soweiso Keys benutzt, macht das keinen Unterschied.

[lord_pinhead]

Sperr Port 22 mit ein Portknocker, leg dir wie die anderen schon gesagt haben ein Loginuser an und schalte den Rootlogin ab. Allerdings denke ich nicht das da jemand per SSH drauf kam, ich tippe da eher wieder auf ein Webexploit. Schonmal durch deine access_log gegreppt?

Wenn du es noch ganz "tight" haben willst kannst du auch nur Logins von dem Netzbereich deines Providers zulassen bei der SSH. Allerdings bringt dir die am härtesten abgesicherte SSH nichts wenn andere Dienste offen sind ;)

ps. Schonmal die Flatfiles durchsucht ob ein User angelegt wurde?

[mattiass]

ps. Schonmal die Flatfiles durchsucht ob ein User angelegt wurde?

In diesem Zusammenhang würde ich gerne darauf hinweisen, dass es nicht schaden kann, Listen mit MD5-Summen relevanter Dateien anzufertigen...

[lord_pinhead]

Wenn man davon ausgeht das der Angreifer das md5sum tool nicht ersetzt. Würde das Tool wenn schon statisch kompilieren und dann beim checken hochladen.

[mattiass]

Wenn man davon ausgeht das der Angreifer das md5sum tool nicht ersetzt. Würde das Tool wenn schon statisch kompilieren und dann beim checken hochladen.

Die Rettungssysteme des Providers sind meist sauber... Da kann man auch mal zehn Minuten Downtime eingehen.

Viele Grüße,
Mattias

[khark]

Man meldet sich nicht direkt als Root an seinem System an, auch wenn man Keys benutzt.

Warum nicht? Wenn man soweiso Keys benutzt, macht das keinen Unterschied.

Weil man nicht dauerhaft mit vollen Rechten arbeitet. Man gibt sich die Rootrechte wenn man sie benötigt (für Zugriff auf Logfiles, etc.) und wenn man sie nicht mehr braucht, dann ist gut.
Klar kann man über sudo -u Befehle als normaler User ausführen. Aber irgendwie widerspricht das meiner Auffassung.

Und nur mal so: Wenn er an einem wirklichen fiesen System sitzt, dann wird auch die Key-Datei kopiert, wenn er diese in den SSH-/PuTTy-Ordner legt.
Und dann hat der Angreifer auch gleich Rootrechte und muss nicht noch erst nach lokalen Exploits suchen.

Ist vielleicht so eine Gretchenfrage, aber ich habe den Rootlogin nur über die serielle Konsole erlaubt, damit ich im Notfall als Root draufkomme, wenn der Kernel mangels Speichers den SSHd abgeschossen hat.

Zudem wird man glaube ich eher dazu verleitet Prozesse als Root zu starten, die gar keine Rootrechte benötigen (IRC-Client *g*) oder nicht Imstande sind, ihren Benutzer nach dem Start zu ändern.

MfG Khark

[thorsten]

Komische Einstellung...

SSH Keys haben bei mir auch unter Windows ein Paßwort und werden beim Login per ssh-agent geladen. Ja, das geht auch mit Putty [1]

Wenn ich als root arbeite und ein X starte oder als root unter X in einen irc-Kanal beitreten will (warum sollte ich das tun?), dann über ssh $USER -c "Kommando zum Starten"

Der ssh-key, der auf deinem Linuxserver hinterlegt ist, kann genausogut auf deiner Homepage stehen. Nur in Verbindung mit dem privaten Teil des keys, der sich bei dir befindet (und mit einem PW geschützt ist!!!), kann sich der "Hacker" einloggen...


[1]Diese fürchterliche Seite habe ich mal vor 4 Jahren erstellt, der Umgang mit pagent stimmt aber noch: http://www.strus.ch/ssh/
Der key muß auf dem Server allerdings unter ~/.ssh/autorized_keys und nicht authorized_keys2 abgelegt werden. Das war damals bei einem RH7.1 oder 7.2 so.
Hier eine weitere Anleitung: http://www.strus.ch/ssh-anleitung

[codc]

[1]Diese fürchterliche Seite habe ich mal vor 4 Jahren erstellt,

Wenn du den Hintergrund ändern würdest sogar lesbar ^^

[thorsten]

[1]Diese fürchterliche Seite habe ich mal vor 4 Jahren erstellt,

Wenn du den Hintergrund ändern würdest sogar lesbar ^^

Die Seiten ziehen in wenigen Monaten komplett um, da fasse ich nichts mehr an - zumal ich die Zugangsdaten gerade nicht griffbereit habe ;)