SSH server hardening / Bruteforce / Logging / Mail notifications

[theSplit]

Hallo,

ich benötige für ein System ein möglich hoch abgeschottetes SSH, dazu setze ich auf Key Authenthication. Passwortzugriff ist grundsätzlich deaktiviert.
Die Keys sind mittel ssh-copy-id hinterlegt von Clients, die darauf zugreifen sollen.

Auch sind X11Forwarding, TCPForwarding, AgentForwarding, GatewayPorts deaktiviert und alles außer TTY ausgeschaltet. Auch der Login als Root ist abgeschaltet.
Zusätzlich sind "Rhotsts" deaktivert.

Damit fühle ich mich schon relativ sicher, das war auch eigentlich das, was ich bisher so lesen konnte. Die Quellen dazu sind aber verstreut und gerade nicht zur Hand. Finden sich aber schnell.

Eine weitere Überlegung wäre ein Chroot Environment, aber ich brauche unter Umständen auch Zugriff auf andere Funktionen die ich nur als "SuperUser" bekommen kann, wie etwas zu updaten, das heißt ich brauche mindestens von einem Client vollen Zugriff, weiß aber nicht ob man irgend eine per KeyUser-Basis machen kann.
Was mir jetzt einfallen würde, einen anderen User für den SuperUser Zugriff anzulegen, der sich dann auch als SuperUser anmelden kann. Geht das mit Chroot auf per User Basis oder gilt das komplett für ssh(d), zum Beispiel um "su" ausführen zu können?

Zweiter Punkt - ich habe einmal eine statische und mehrere dynamische Clients, die alle auf den Server zugreifen können sollen.
Known Hosts scheint ja eine fixe IP zu registrieren, falls man eine Prüfung der Known_Hosts Datei von sshd zulässt, das würde aber dann vermutlich nur die statische IP covern. Wie wäre hier am schlausten vorzugehen wenn ich auch dynamische Clients habe?

Vielleicht kann jemand noch etwas ergänzen, wenn euch mehr einfällt, was man unbedingt machen sollte.
Fail2Ban zum Beispiel und andere hatte ich im UbuntuWiki gesehen, mit denen man SSH noch schützen kann vor BruteforceAttacken.
Was neben Logging, damit man nicht nur die Zugriffe in "auth.log" hat, auch gut wäre, wenn man bei Einbruchsversuchen per Email benachrichtigt werden könnte, zum Beispiel mittels Vorgabe eines MailAccounts mit fixem Benutzernamen + Password, welcher über SSL läuft. Keine Ahnung ob das irgend ein System neben dem Aussperrren auch anbietet oder was man damit in Kombination machen könnte.

Und vielleicht noch eine Frage am Rande die eigentlich nichts mit dem Absichern zu tun hat, gibt es außer Putty noch andere Clients für Windows die man verwenden könnte?

 

[Metal_Warrior]

@theSplit: Grundsätzlich erstmal alles deaktivieren, was du nicht brauchst. RHosts sind eh in der neusten Version deprecated, d. h. haben schon lang keine Funktion mehr (alles dazu kannst du rauslöschen).

Grundsätzlich hast du aber einen Denkfehler: Vor dem Zeitpunkt, an dem Forwarding, Gateway etc. überhaupt erst möglich werden, steht der Login. Wenn ein Angreifer sich einloggen kann, hat er alle Möglichkeiten eines Terminals mit allen eventuell vorhandenen Softwarefehlern des Servers (Remote Code Execution, Privilege Escalation etc.). Ergo sind die von dir deaktivierten Optionen eigentlich keine Sicherheitsrisiken, sondern nur Möglichkeiten für authentifizierte, angemeldete User.

Was du hingegen noch nutzen kannst, ist das AllowUsers-Statement (das den Zugriff auf SSH auf die von dir konfigurierten User einschränkt - alle anderen dürften trotz angelegtem User keine SSH-Session aufbauen). Ach, und den Port ändern (dann hast du keine nervigen China-Bots im Syslog aufschlagen, die dann letztendlich eh nix reißen). BruteForce-Attacken werden bei deaktiviertem Passwort-Login sowieso nicht gefahren, daher kannst du dir Fail2Ban sparen. Keys sind praktisch nicht anfällig dafür, und der Server nennt dem Client ja am Anfang die möglichen Authentifizierungs-Methoden. Ist Passwort nicht dabei, wird kein Bot das probieren (können).

Auch deine Superuser-Problematik ist eigentlich unabhängig von SSH - entweder der User darf sudo nutzen (ist also in der Gruppe sudo), oder eben nicht. Woher er kommt ist dafür völlig egal.

Die Known-Hosts-File hat mit sshd nix zu tun, das ist nur für ssh (den Client) relevant - dort speichert er die bereits bekannten SSH-Server ab.

Mail-Notification geht mit ssmtp und rsyslog. Lass rsyslog alle SSH-Loginversuche in ein extra Logfile schreiben und schreib ein kleines Script, das via Cronjob alle X Minuten nachprüft, ob die letzten Y Minuten irgendwelche IPs auffällig wurden (zum Beispiel mehr als 10 Versuche in den letzten 5 Minuten). Das verschickt dann einfach eine kurze Mail an den konfigurierten User (der via ssmtp alle lokalen Mails auf ein extern liegendes Mailkonto bekommt). Dann kannst du auch gleich nen iptables-Eintrag für die IP schreiben lassen, die sie blockt, aber das ist eigentlich alles Overkill und nicht wirklich nötig.

Und ja, es gibt neben PuTTY noch andere Clients, eine kurze Google-Suche sollte dir zig Möglichkeiten aufzeigen: https://www.google.de/search?safe=o...natives+windows&oq=putty+alternatives+windows

BTW: Was meinst du mit ssh-copy-id? Üblicherweise werden einfach die PubKeys in die jeweiligen ~/.ssh/authorized_keys geschmissen und gut ists.

 

[theSplit]

BTW: Was meinst du mit ssh-copy-id? Üblicherweise werden einfach die PubKeys in die jeweiligen ~/.ssh/authorized_keys geschmissen und gut ists.

Guten Morgen, nur kurz zu "ssh-copy-id". Es macht genau das was du sagst, es greift auf den Server zu und hinterlegt bzw. "lässt" (durch den Server) den public key des Clients in "authorized_keys" hinzufügen.
Das geht logischerweise nur so lange, wie man den Passwortzugriff aktiviert hat und sich darüber einloggen kann, noch bevor man die PubKeyAuthentication aktiviert und Passwortzugriff deaktiviert hat (weil ohne gültigen hinterlegten Key, ginge das ja dann nicht).

Ist quasi für faule Leute, die sich nicht die Arbeit machen wollen das Keyfile manuell zu editieren bzw. anzulegen. Das wird dann für den jeweiligen User in "~/.ssh/authorized_keys" direkt gemacht.

Hier kann man auch etwas mehr nachlesen:
Generell: https://www.ssh.com/ssh/copy-id
oder https://www.ssh.com/ssh/copy-id#sec-Copy-the-key-to-a-server (speziell wie das handzuhaben ist, gleiche Seite)

 

[musv]

Was du noch machen kannst:

Port ändern
>95% aller Bruteforce-Angriffe gehen auf Port 22. Als bei der Umstellung auf systemd fail2ban und denyhosts nicht mehr funktionierten, war das die effektivste Möglichkeit, die ganzen Script-Kiddie-Attacken zu vermeiden.

sshd_config

AllowUsers mein_user

Damit schaltest du explizit nur bestimmte User für den SSH-Zugriff frei. Hat den Sicherheitsgewinn, dass evtl. angelegte Testuser nicht automatisch SSH-Zugriff bekommen.

 

[theSplit]

@musv: Danke für den Tip mit dem Port, das hat Metal_Warrior auch erwähnt.

Mit dem "AllowUsers" hätte ich sowieso nochmal hinterfragen müssen, wo die Direktive hingehört - da der Hinweis mit sshd_config gar nicht so verkehrt.

Vielleicht wäre jetzt noch gut zu wissen, wie "AllowUsers" erweitert wird wenn ich zum Beispiel zwei Benutzer habe. (*Habs jetzt gegoogelt, aber ich wollte mich da auch noch weiter einlesen. )

Ich weiß das man die "Port" direktive so erweitern kann, um auf mehreren Ports zu lauschen:
"Port 22"
"Port 1234"

*AllowUsers Google Suche: https://linux.die.net/man/5/sshd_config
Also wäre "AllowUsers username_A username2 benutzer" anzugeben.

---
@Metal_Warrior

Im übrigen gibt es ja scheinbar wirklich doch einige Putty Ports/ähnliche Software, hab gedacht da gibt es nicht mehr viel Auswahl. Danke für den Hinweis zu "Google".

 

[drfuture]

Ich nehme https://www.bitvise.com/ssh-client - der ist sehr flexibel...
Ich fahre bei mir ein etwas anderes Setup, ob das nun Unsicherer ist oder nicht vermag ich nicht zu bewerten. Für mich ist es praktikabler.

Login per sshd nur für festgelegte User (kein root) (wie hier ja auch schon angegeben).
Login per Passwort + 2. Faktor Google Authenticator am Handy.
Nach 2 falschen Login-Versuchen wird der Login für glaube 30min gesperrt (Einstellung im sshd)

Ein Zertifikat muss ich immer dabei haben oder kann theo. entwendet werden; ob das Passwort dann geknackt werden kann keine Ahnung - aber das kann sich im Zweifel auch jedes Jahr ändern. Ich finde daher getrennte Orte für den Zugang besser.

 

[theSplit]

drfuture, die Software sieht in der Tat auch nicht schlecht aus. Das einzige was man bemängeln könnte, die Quelltexte sind nicht frei verfügbar
Den Client kann man aber so wie ich gelesen haben uneingeschränkt nutzen und scheint auch gängig kompatibel zu sein. Einzig Wermutstropfen, der SSH Server hat eine Trial Period von 30 Tagen und müsste dann erworben werden.

Und für die gekaufte Variante gibt es für 12 Monate Updates, danach nur gegen bares. Kann man sich streiten ob das Sinn macht.

----

Ich habe eben noch etwas recherchiert:

Was die Multi-Faktor Authentication angeht, hier noch etwas interessantes:
https://wiki.mozilla.org/Security/Guidelines/OpenSSH

Zwei für mich interessante Gedanken aus dem Artikel:

Für die Clients, folgender Hinweis:

Multi-factor bypass setup for machine keys

Machine keys do not play well with multi-factor authentication as there is no human interaction.

- All logins from machine accounts should be protected by an additional authentication layer (VPN, another machine, etc.).
- All logins from machine accounts are only allowed within the private IP-space, and if possible, only the relevant machine source IPs should be accessible.

File: /etc/ssh/sshd_config (OpenSSH 6.3+)

Und in diesem Zusammenhang das hier (steht unter der Quote), die Nutzung von "Match":

Match User machine_user Address 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12
PubkeyAuthentication yes
KbdInteractiveAuthentication no
AuthenticationMethods publickey

Wenn ich richtig lese, werden durch "Match User removeUser Adress" in diesem Fall nur bestimmte Adresseräume erlaubt sich mittels Publik Key zu authentifizieren - das wäre eigentlich genau das für die statische IP bzw. für die dynamischen, die aus bestimmen Räumen kommen würden. Hier könnte man wohl auch noch den "Host" mit unterbringen!

Und ich glaube auch den Hinweis rauslesen zu können, das eine reine "Key-Authentication" nicht unbedingt geeignet/empfohlen ist - auch das was @drfuture anspricht.

Und was zum Server dazu geschrieben wird:

Multi-Factor Authentication (OpenSSH 6.3+)

Recent versions of OpenSSH support MFA (Multi-Factor Authentication). Using MFA is recommended where possible.

It requires additional setup, such as using the OATH Toolkit or DuoSecurity.

DuoSecurity ist wohl ein Bezahldienst, aber "OATH Toolkit" - scheint einmalig ein Passwort zu generieren, hier müsste man überlegen wie dies transportiert wird, vielleicht auch auf einen Email Account?

Da gibt es aber auch folgende Hinweise:

In order to allow using one time passwords (OTPs) and any other text input, Keyboard-interactive is enabled in OpenSSH. This MAY allow for password authentication to work. It is therefore very important to check your PAM configuration so that PAM disallow password authentication for OpenSSH.

Und:

# IMPORTANT: you will have to ensure OpenSSH cannot authenticate with passwords with PAM in /etc/pam.d/sshd
# "PasswordAuthentication no" is not sufficient!
PubkeyAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactiveam
KbdInteractiveAuthentication yes
UsePAM yes
# Ensure /bin/login is not used so that it cannot bypass PAM settings for sshd.
UseLogin no

Jetzt wäre die Frage, wenn man einmal eine Identifizierung über den Public Key zulässt + ein dynamisch generiertes Passwort. Hätte man doppelte Sicherheit, selbst wenn aus irgend einem Grund ein Keyfile entwendet werden würde, auch wenn dieses mit einem Passwort abgesichert ist. Und so könnte man theoretisch auch die Legitimität eines Users erzwingen da, selbst im Falle ein Key ist kompromittiert, immer noch der Zugriff auf ein Passwort ausbleiben würde, auf das der Angreifer dann keinen Zugriff besitzt würde.

Mal eine Überlegung, hohe Sicherheit -> Admin Zugrif über sudo... nur Public Key authentication, Chroot(ed) und reiner SFTP Client, also vielleicht sogar ohne Terminal/tty Interface.
Hier ist auch noch etwas zu chroot
Spontan dieser Artikel hier, müsste man aber schauen wie das von statten geht in Verbindung mit einem Match "User"-Block.

Und einen der mittels anderem "Match User username" - nicht chrooted ist und auch Zugriff auf "sudo/su" hat, aber auch zwei/Multi-Faktor Authentifizierung.

Sorry falls die Informationen etwas unsauber zusammengetragen sind, ich lese hier 5-6 Seiten quer und ich finde das Thema spannend und dieses Match User/Group/Host sieht in der Tat mit DNS Lookups sehr gut aus!

 

[drfuture]

@bitvise, nutze nur den Client. Der Server ist glaube ich für Windows? Habe ich mir nicht angeschaut

 

[theSplit]

@drfuture: Ist in der Tat nur für Windows (der Server). Aber es ging dir vermutlich ja auch um den Client...
War doch aber klar das man als "Open Source User" darauf rumhacken muß.

Schaue ich mir aber auf jeden Fall mal an.

 

[X-Coder]

Kommt Portknocking in Frage?

 

[theSplit]

@X-Coder: Wenn die Frage an mich geht.... sagen wir so, was einmal installiert ist, soll so wenig "wartung" wie möglich benötigen, den Standardport 22 nehme ich nicht - aber davor sitzten ganz normale Router und keine Hardware Firewalls.

Wenn du das "Abklopfen" von Ports meinst.... es würden theoretisch nur ein Port für alles freigegeben werden. So der Plan. Also der explizite SSH Port den ich für den Remote-Zugriff brauche.

Ob das ein Problem werden kann, kann ich nur schwer einschätzen.

 

[musv]

Wenn du's mit der Sicherheit ins Extreme treiben willst, kannst du auch noch ein VPN davorschalten. D.h. die Clients können sich nur verbinden, wenn sie vorher einen VPN-Tunnel aufgebaut haben.

Warum willst du's eigentlich so derart auf die Spitze treiben mit der Absicherung? Irgendwann kommst du zwangsläufig an einen Punkt, wo die Sicherheit sich überproportional auf die Einschränkung der Freiheit (oder hier Benutzbarkeit) auswirkt. Ist genau wie in der Politik.

 

[theSplit]

@musv: Naja, deinen Einwand kann ich glaube auch verstehen - aber für mich sieht zum Beispiel das Matching in so fern gut aus, als das ich damit die statischen Clients abdecken kann, wie auch manche dynamischen - zum Beispiel die ungefähre Adressrange - das schränkt den Zugriff schon etwas ein, ohne großes zu tun.

Natürlich besteht die Gefahr das man sich aussperrt, sagen wir die statische IP(s) ändern sich, oder die dynamischen Wechseln den Anbieter und damit den IP Raum. Oder der Host verändert sich.

Aber das paradoxe ist ja, je mehr Zugriffe ich im Vorfeld erlaube, desto höher ist die Wahrscheinlichkeit, das reagiert werden kann - um das komplette Aussperren zu verhindern.
Aber gerade wenn die Orte physikalisch getrennt sind, besteht doch eine Chance, das immer ein "Zugang" offen bleibt - im besten Fall einer der Adminrechte erwirken kann.

Das Problem warum ich so erpicht bin, die Sicherheit zu steigern, es kann gut sein das ich dann rein von den Örtlichkeiten keinen Zugriff mehr auf bestimmte Geräte erlangen kann bzw. nur mit sehr hohem Aufwand, das heißt: Es muss sicher sein, so sicher, dass das Ding "unbeaufsichtigt" funktioniert - ich mich also darauf verlassen kann. Wenn es eine Lücke gibt, ist es dann auch nicht so das ich eben mal "schnell" updaten kann, eben durch die räumliche Trennung.

Das mag alles etwas Overkill sein ja, und bisher scheint es auch so zu sein, das die Angriffsfläche bei Keyfile-Authenthication de facto bei Null liegt, da man ein Keyfile nicht erraten kann.
Aber kann man sich 100% darauf verlassen?

Selbst wenn ich keine Multi-Factor-Authenthication einsetze und mich auf Keyfiles verlasse, das mit dem "Match User user Adress" scheint mir das mindeste zu sein, was ich machen sollte - da dies ein relativ "einfacher" Trick zu sein scheint, aber man die Angriffsfläche schon (drastisch) reduzieren kann. So liest sich das zumindest für mich gerade.

 

[BurnerR]

Aber kann man sich 100% darauf verlassen?

Seit wann bzw. wer sieht denn gut konfigurierten SSH-Zugang mit Keyfile nicht als sicher an?
Ich würde ja einfach hingehen und (falls möglich) alles außer Europa aussperren.

Das Problem warum ich so erpicht bin, die Sicherheit zu steigern, es kann gut sein das ich dann rein von den Örtlichkeiten keinen Zugriff mehr auf bestimmte Geräte erlangen kann bzw. nur mit sehr hohem Aufwand, das heißt: Es muss sicher sein, so sicher, dass das Ding "unbeaufsichtigt" funktioniert - ich mich also darauf verlassen kann. Wenn es eine Lücke gibt, ist es dann auch nicht so das ich eben mal "schnell" updaten kann, eben durch die räumliche Trennung.

Dann würde ich persönlich aber eher die Komplexität möglichst gering halten.
Aber irgendwie verstehe ich das ganze nicht. Du kannst dich doch per ssh einloggen, da spielt doch dann die räumliche Trennung keine Rolle.
Sich aussperren hat ja nichts mit der Sicherheit zu tun, das wird eher mal auftreten, wenn du ein komplexes Setup verwendest.

Aber das paradoxe ist ja, je mehr Zugriffe ich im Vorfeld erlaube, desto höher ist die Wahrscheinlichkeit, das reagiert werden kann - um das komplette Aussperren zu verhindern.

Ich würde ja genau einen zuverlässigen Zugang hernehmen. Per ssh zum Beispiel. Was willst du denn an weiteren 'Zugriffen'? Meinst du mehr ssh user? Warum?

 

[theSplit]

Aber irgendwie verstehe ich das ganze nicht. Du kannst dich doch per ssh einloggen, da spielt doch dann die räumliche Trennung keine Rolle.
Sich aussperren hat ja nichts mit der Sicherheit zu tun, das wird eher mal auftreten, wenn du ein komplexes Setup verwendest.

Was ich mit aussperren meine, wenn 3/4 aller Keyfiles (Zugänge), warum auch immer einbrechen weil Keys nicht mehr vorhanden sind oder der ISP wechselt (Host) oder aus irgendeinem Grund ein IP wechsel bei statischen IPs (warum auch immer) eintritt, aber keine alternativen Zugänge eingerichtet sind.

In dem Fall meine ich mit mehrere Zugänge nicht SSH-User, sondern hinterlegte Keyfiles von verteilten Standorten, falls ein Ecke wegbricht kann von anderer Stelle "nachgepflegt werden" Neue Keyfiles, neue Settings in sshd_config für IP Ranges oder ähnliches.

Ich würde ja genau einen zuverlässigen Zugang hernehmen. Per ssh zum Beispiel. Was willst du denn an weiteren 'Zugriffen'? Meinst du mehr ssh user? Warum?

Wie gesagt, "ein" Zugang, bei dem ich auf eine statische IP setze, könnte sich ändern, das heißt es müssten "Backup"zugriffe. Mehrere SSH User nicht zwingend, es würde ein Maschine-User vollkommen reichen, wichtig sollte dann nur sein, mehr Keyfiles von verteilten Standorten, so das man nicht ein einziges Keyfile hinterlegt.. gerade wenn der Rechner nicht ohne SSH mehr aktualisiert werden kann, von einer Stelle oder etwas aktualisiert werden muß.

So denke ich mir das jedenfalls. Ein Keyfile ist gut, aber was passiert wenn ich einen Anruf bekomme, hier geht etwas nicht, wir haben keinen Zugriff, ich aber nicht ein oder zwei Zugänge (über die Keyfiles) hinterlegt habe? Dann wäre ich ja aufgeschmissen.

Wird das etwas klarer was ich meine?

 

[nik]

Und genau das macht doch keinen Sinn. Wenn du weißt, dass sich der IP-Range ändern kann, mach dir einen "Administrationszugang" ohne IP-Einschränkungen. Genauso hebt man Keyfiles so auf, dass sie nicht verloren gehen (Backup?).
Wenn das dem Nutzer mal passiert, kann das ja über deinen Administrationszugang gefixt werden.
Trotzdem seh ich keinen Zusammenhang, inwiefern da mehrere Keyfiles mit IP-Range-Beschränkungen irgendeinen sinnvollen Nutzen haben sollten.

Genauso mit den Sicherheitslücken. Du hast extra nen ssh-Zugang damit du auch aus der ferne ein Update fahren kannst. Wozu also das Setup so kryptisch gestalten? Du blickst doch dann am Ende nur selbst nicht mehr durch, wo jetzt was war und wofür überhaupt eingerichtet wurde.

 

[BurnerR]

Private Key im KeePass Safe speichern und davon Backups haben.
Nicht einzelne IPs whitelisten sondern Asien blacklisten.

So denke ich mir das jedenfalls. Ein Keyfile ist gut, aber was passiert wenn ich einen Anruf bekomme, hier geht etwas nicht, wir haben keinen Zugriff, ich aber nicht ein oder zwei Zugänge (über die Keyfiles) hinterlegt habe? Dann wäre ich ja aufgeschmissen.

Ein Benutzer mit beschränkten Rechten kann ja deinen Zugang nicht beeinflussen.

Mehrere SSH User nicht zwingend, es würde ein Maschine-User vollkommen reichen, wichtig sollte dann nur sein, mehr Keyfiles von verteilten Standorten, so das man nicht ein einziges Keyfile hinterlegt.

Ein private Key = eine Identität. Jeder Standort verwendet einen eigenen private key.

 

[theSplit]

@Nik und @Burner: Also Backups sind zum Teil schon vorhanden, werde ich aber nochmal durchexerzieren und dafür sorgen das diese "möglichst" sicher, irgendwo abgelegt werden.

@BurnerR: Also mit "Keyfile" meine ich einen expliziten Eintrag in "authorized_keys" (hinterlegt).
KeePass Safe muß ich mir dafür man anschauen, evtl. wäre das etwas, so richtig habe ich mir darüber aber noch keine Gedanken gemacht, muß ich zu meiner Schande gestehen.... mal testen.

Wegen des Blacklistings, ich bin mir nicht 100% sicher wie umfangreich die IP Ranges da wären, evtl. wird eher umgekehrt ein Schuh daraus, wenn explizit etwas freigegeben und alles andere konkret ausgesperrt wird - das würde ich zumindest "spontan" als leichter ansehen. Wobei gut, damit würde man sich evtl. wieder aussperren, wenn etwas aber explizit geblacklistet ist, kann man ansonsten aber dennoch zugreifen aus anderen Ranges.

Gibt es da nicht ein "Prinzip" für? - Das man nicht sich einschränkt, sondern die "anderen" um (wirkungsvolle) Sicherheit zu erhalten?

 

[Metal_Warrior]

@theSplit: Ich kann dir auch nur raten, das Setup so einfach wie möglich zu halten: AllowUsers, nicht verwendete Optionen auskommentieren, KEINE IP-Beschränkungen in der sshd_config (das wird uferlos und unübersichtlich - also komplex und damit sicherheitsfeindlich). SSH gehört zu den sichersten Diensten am Server, da wird AFAIK mehr getestet als irgendwo sonst. Und wie gesagt: KeyAuth und da kommt kein BruteForce mehr. An meinen Servern brechen die Bots die Verbindung ab, sobald der Server ihnen nur KeyAuth zur Auswahl lässt.

IPs einschränken nur über Firewall (also iptables). Und auch das ist sehr umfangreich - die Whitelist für Österreich, Deutschland, Niederlande, Schweiz, Luxemburg und Belgien, die wir als Notfall-Option bei DDoS haben, ist 14k Einträge groß. Allein das Laden bei vollem iptables-Setup dauert mehrere Minuten. Ist für SSH völlig unnötig.

 

[rexcolo]

2FA braucht man nur, wenn man Geräte nutzt, die unsicher sind. Dann doch gleich einen Nitrokey nutzen!

MaxStartups 5:50:50 hilft gegen DDoS-Attacken und anderes Scriptkiddie-Gedöns, das vergessen die Leute oft.

Man kann allein in iptables einen Portknocking-Service erstellen. Zusammenfassung (importierbar):

[SRC=BASH]*filter
:knocking - [0:0]
:knock1 - [0:0]
:knock2 - [0:0]
:knock3 - [0:0]
:knockpassed - [0:0]

#This is from a ufw rule set, I place it first to make sure that it gets process before any ufw rules.
-I INPUT 1 -j knocking

#Keeps track of the knock state, i.e. what stage of the knock process the client is in
-A knocking -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A knocking -m recent --rcheck --seconds 30 --name KNOCK3 -j knockpassed
-A knocking -m recent --rcheck --name KNOCK2 -j knock3
-A knocking -m recent --rcheck --name KNOCK1 -j knock2
-A knocking -j knock1

#First knock chain
-A knock1 -j LOG --log-level 4 --log-prefix "In knock 1: "
-A knock1 -p tcp --dport 1111 -m recent --name KNOCK1 --set -j DROP
-A knock1 -j DROP

#Second knock chain
-A knock2 -m recent --name KNOCK1 --remove
-A knock2 -j LOG --log-level 4 --log-prefix "In knock 2: "
-A knock2 -p tcp --dport 2222 -m recent --name KNOCK2 --set -j DROP
-A knock2 -j knock1

#Third knock chain
-A knock3 -m recent --name KNOCK2 --remove
-A knock3 -j LOG --log-level 4 --log-prefix "In knock 3: "
-A knock3 -p tcp --dport 3333 -m recent --name KNOCK3 --set -j DROP
-A knock3 -j knock1

#After successful a successful know, allow the target to port 22
-A knockpassed -m recent --name AUTH3 --remove
-A knockpassed -j LOG --log-level 4 --log-prefix "Knock accepted!: "
#Port 10085 was my testing port. I used netcat -l -p 10085 to test the connection from my remote machine
-A knockpassed -p tcp --dport 10085 -j ACCEPT
-A knockpassed -j knock1

COMMIT[/SRC]

Ich würde natürlich statt solchen Ports lieber was im Bereich >>1024 verwenden, z.B. 65432, 17171 und 34241. Das dazugehörige Knocking-Script aus dem Artikel:

[SRC=BASH]#!/dev/zero

ports="1111 2222 3333"
host="your_server"

for x in $ports
do
nmap -Pn --host_timeout 201 --max-retries 0 -p $x $host
sleep 1
done
ssh user@${host}[/SRC]

Moxie Marlinspike hat das auch als Python-Anwendung umgesetzt: https://github.com/kchr/knack

---

Und vielleicht noch eine Frage am Rande die eigentlich nichts mit dem Absichern zu tun hat, gibt es außer Putty noch andere Clients für Windows die man verwenden könnte?

choco install -y msys2