Sichere sshd_config

Port ändern und gff. Fail2ban für SSH

Quote

PermitRootLogin yes

Warum nicht "without-password" oder ganz aus stellen und nur für einzelne IPs Key-Login zulassen?

Wieviele User/SSH-Keys hast du, dass du so viele Cihper aktiv haben musst? Mir reicht in der Regel genau 1 Cipher.

btw, per iptables / ipset den SSH-Bereich massiv einschränken. z.B. dein DSL-Provider + andere vServer (als Backup). Wenn du keine statische IP hast, dann einfach mal auf die letzten IPs aus dem Router-Log/etc ein whois machen und dort den Bereich von deinen DSL-Provider nehmen.

Port ändern bringt nur was wenn man auch Firewall Regeln gegen Portscan hat.

Fail2Ban würde ich auch bei No Password Auth nehmen, alleine um die Last und Log files kleiner zu halten.

PermitRootLogin no
PasswordAuthentication no
AllowGroups sshusers
AuthorizedKeysFile      %h/.ssh/authorized_keys /var/lib/ssh/user/%u/authorized_keys /var/lib/ssh/allusers

Die allusers Datei wird per puppet oder anderen tools beliefert.

so können die Admins auf alle User zugreifen direkt, falls notwendig.

eine "/etc/ssh/sshrc" ist auch noch anzuraten

#!/bin/bash

HOSTNAME=`hostname`
echo "Subject: SSH Login $IP at ${USER}@${HOSTNAME}\r\nUser $USER just logged in from $IP at Server $HOSTNAME" | /usr/sbin/sendmail root &

diese sendet beim Login einfach an den root, welcher bei uns in der alias Datei auf einer E-Mail Adresse weiterleitet.

So kann man auch Logins erkenne, falls es mal einen "Eingriff" geben sollte.

Ich habe keine Firewallregeln gegen Portscans (letztlich kann jeder ja trotzdem die Ports herausfinden, ist nur aufwändiger und erfordert z. B. ein VPN, oder tor, falls man das nicht geblockt hat...) und habe mal nachgesehen, wie viele "authentication failure" ich bei ssh in den logs finde:

zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
5

Also gerade einmal 5 Stück und wie viele davon stammen nicht von mir selber, eil ich mich vertippt habe? 0

Also Portänderung ist schon sehr effektiv. Die meisten Scriptkiddies machen sich gar nicht die Mühe den Port zu scannen. Dabei geht es mir vor allem darum, dass die Logs nicht so zugemüllt werden, fail2ban muss dadurch auch weniger Arbeiten. Als ich noch 22er Port hatte, waren meine Logs voll mit Angriffen...

Mich würde ja mal interessieren, welche Zahl mein obiger Befehl bei Leuten liefert, die noch den 22er Port verwenden.

Hier ein paar Zahlen bei Systemen mit konfiguriertem fail2ban (48h bantime):

root@w5-vm:~# zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
144620

root@daisy:~# zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
21555

root@kvm-root:~# zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
10451

root@home-server:~# zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
3874

Will gar nicht wissen wie das ohne fail2ban aussehen würde, bei mir sind meist auch immer 100+ IPs wegen fail2ban gesperrt

perryflynn

LogLevel VERBOSE

Damit Du u.a. weißt, über welchen Public Key der Login stattgefunden hat.

PermitRootLogin prohibit-password

Das ist mittlerweile der bevorzugte Wert.

Quote from julian-w

Hier ein paar Zahlen bei Systemen mit konfiguriertem fail2ban (48h bantime):

Code

root@w5-vm:~# zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
144620

root@daisy:~# zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
21555

root@kvm-root:~# zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
10451

root@home-server:~# zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
3874

Display More

Will gar nicht wissen wie das ohne fail2ban aussehen würde, bei mir sind meist auch immer 100+ IPs wegen fail2ban gesperrt

Ja so sah das bei mir auch mal aus, bevor ich den Port geändert habe. Bei mir ist derzeit keine einzige IP gebannt, weil fail2ban nicht aktiv werden muss.

Bei Paranoid denk ich direkt an Port-Knocking, ... ekelig im Alltag zu gebrauchen, gerade bei mobilen Clients, ... aber dafür Paranoid +1 haha

Quote from Cictani

Ich habe keine Firewallregeln gegen Portscans (letztlich kann jeder ja trotzdem die Ports herausfinden, ist nur aufwändiger und erfordert z. B. ein VPN, oder tor, falls man das nicht geblockt hat...) und habe mal nachgesehen, wie viele "authentication failure" ich bei ssh in den logs finde:

Code

zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
5

Also gerade einmal 5 Stück und wie viele davon stammen nicht von mir selber, eil ich mich vertippt habe? 0

Also Portänderung ist schon sehr effektiv. Die meisten Scriptkiddies machen sich gar nicht die Mühe den Port zu scannen. Dabei geht es mir vor allem darum, dass die Logs nicht so zugemüllt werden, fail2ban muss dadurch auch weniger Arbeiten. Als ich noch 22er Port hatte, waren meine Logs voll mit Angriffen...

Mich würde ja mal interessieren, welche Zahl mein obiger Befehl bei Leuten liefert, die noch den 22er Port verwenden.

Display More

Richtig, wenn der Angreifer erstmal im Dunkeln die Tür suchen muss, an der er den Schraubendreher ansetzen kann dann hat er in der Zeit eher zig andere Server mit Tür an bekanntem Ort gefunden.

Natürlich sollte die Tür im Dunkeln nicht offenstehen, das hat dann wirklich nichts mit Sicherheit zu tun. Aber um es dem Angreifer so schwer wie möglich zu machen bietet sich Portänderung als zusätzliches und einfaches Mittel an.

Ich habe die gleiche Erfahrung gemacht. Mit 22 volle Logs mit failed auths. Nach Änderung Ruhe. Schont halt auch das System, wenn die Angreifer nicht erst vom Dienst zurückgewiesen werden, sondern schon von der Firewall abprallen.

Quote from perryflynn

Port ändern hat nichts mit Sicherheit zu tun.

stimmt. Aber es reduziert die Anzahl Zeilen in Logfiles enorm und spart mir damit Zeit

Gruss

Quote

Zum Port Knocking und zum Ändern von Ports: Das ganze soll in einer Standard Umgebung funktionieren. Sprich auch, wenn ich mich in einer "Enterprise" Umgebung mit Proxy und Company Firewall befinde. Und das geht nun mal nur über Port 22.

Was haltet ihr von der Idee Port Knocking über den Umweg Webserver zu machen (wenn eh einer auf dem Server läuft).

Also Port Knocking wird von einem Skript, z.b. in PHP oder Pyhton, ausgeführt, das ganz normal über http oder https aufrufbar ist.

Evtl mit Passwort-Schutz, wenn man will.

Vorteile:

- Port ist nur offen, wenn er gebraucht wird, Port Knocking eben

- sollte auch mit erwähnter ""Enterprise" Umgebung mit Proxy und Company Firewall" funktionieren

- kann leicht automatisiert werden, indem besagte Webseite einfach vorher per curl aufgerufen wird

- Webserver-Skript benötigt, dank Port Knocking, keine root Rechte

Varianten

- Port Knocking nur auf localhost erlauben

- noch mehr security by obscurity, indem die Webseite ein ganz normale Seite mit einem Formular ist, und nur wenn z.B. bei Straße und Postleitzahl etwas bestimmtes steht, wird geknockt.

- Skript könnte auch auf einem anderen Server laufen, wenn man das für mehrere VMs verwenden will, aber dann geht Punkt 1 nicht mehr (localhost)

Sicherheit ist das Gegenteil von Bequemlichkeit

per iptables kann man noch nach treten

$IPT -A tcp_outbound -p TCP -s 0/0 -d $INET_ADDRESS --destination-port 22 -j ACCEPT
$IPT -A tcp_inbound -d $INET_ADDRESS -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
$IPT -A tcp_inbound -d $INET_ADDRESS -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --name DEFAULT --rsource -j DROP
$IPT -A tcp_inbound -d $INET_ADDRESS -p tcp -m tcp --dport 22 -j ACCEPT

INET_ADDRESS ist die Main IP des Servers.