SSH, Fail2Ban und TCP Wrapper

[wagnbeu0]

Hallo, ich habe aus diversen Gründen auf meinem Rechner mit Debian 11.6 SSH aus dem Internet zugänglich gemacht. Als Absicherung habe ich bislang Fail2ban aktiviert, und SSH blockiert nach 3 Fehlversuchen das Netz des "Attackers". Dazu nutze ich das Script https://github.com/WKnak/fail2ban-block ... p-range.py, das per Cronjob jede 5 Minuten ausgeführt wird. Trotztdem habe ich eine sehr große Menge an IPs, die abgewiesen werden. Jetzt habe ich mich mit dem THema /etc/hosts.allow und /etc/hosts.deny beschäftigt.
Meine beiden Dateien sehen so aus:

Code: Alles auswählen

# /etc/hosts.allow: list of hosts that are allowed to access the system.
sshd: 192.168.10.
sshd: localhost
sshd: doc.jz-roethenbach.de
sshd: fr4ygshxg1m8k1bb.myfritz.net
sshd: *.pool.telefonica.de

# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
sshd: ALL

Trotzdem bekomme ich angezeigt, dass sehr viele IPs zugelassen werden, die nicht in die erlaubten Kriterien passen. Habe ich da irgendwo einen Denkfehler?

[uname]

Leider kann ich zu deiner Konfiguration nichts sagen, da ich Fail2Ban nicht verwende.

Hallo, ich habe aus diversen Gründen auf meinem Rechner mit Debian 11.6 SSH aus dem Internet zugänglich gemacht.

Leider kenne ich deine Gründe nicht. Aber musst du unbedingt den Port 22 verwenden? Wenn du einen anderen, eher unbekannten Port verwendest, dann wird schnell Schluss sein mit den ganzen Anmeldeversuchen. Die Änderung des Ports erhöht nicht wirklich die Sicherheit (Security through Oobscurity), es minimiert aber den Ärger durch Script-Kiddies denn viel mehr ist das aktuelle Problem auch nicht (bei Verwendung von SSH-Keys und/oder hoch komplizierten Passwörtern wovon ich bei dir erst mal ausgehe).

[oln]

Moin,
ein paar Fragen:
- Hast du den sshd nach den Änderungen neu gestartet?
- Hast du nach den Zeilen einen Zeilenumbruch in der Datei?
- Wie sieht der Logeintrag genau aus?
Wenn da etwas kommt mit "Connection closed by remote host" dann zieht deine Einstellung. Geloggt wird aber trotzdem.

[wagnbeu0]

- Hast du den sshd nach den Änderungen neu gestartet?
--> Ja, schon mehrmals

- Hast du nach den Zeilen einen Zeilenumbruch in der Datei?
-->, Ja, habe ich gemacht

- Wie sieht der Logeintrag genau aus?

Code: Alles auswählen

cat /var/log/auth.log
Apr 17 11:45:36 nuc sshd[2448182]: refused connect from 156.236.70.135 (156.236.70.135)
Apr 17 11:45:36 nuc sshd[2448179]: refused connect from 156.236.70.135 (156.236.70.135)
Apr 17 11:46:16 nuc sshd[2423225]: exited MaxStartups throttling after 00:00:40, 11 connections dropped
Apr 17 11:46:16 nuc sshd[2448303]: refused connect from 187.251.18.226 (187.251.18.226)
Apr 17 11:46:16 nuc sshd[2448304]: refused connect from 187.251.18.226 (187.251.18.226)
Apr 17 11:46:17 nuc sshd[2448302]: refused connect from 187.251.18.226 (187.251.18.226)
Apr 17 11:47:10 nuc sshd[2423225]: Received signal 15; terminating.
Apr 17 11:47:10 nuc sshd[2448395]: Server listening on 0.0.0.0 port 22.
Apr 17 11:48:01 nuc sshd[2448395]: Received signal 15; terminating.
Apr 17 11:48:02 nuc sshd[2448510]: Server listening on 0.0.0.0 port 22.
Apr 17 11:48:08 nuc sshd[2448555]: Accepted password for benjamin from 192.168.10.119 port 65471 ssh2
Apr 17 11:48:08 nuc sshd[2448555]: pam_unix(sshd:session): session opened for user benjamin(uid=1010) by (uid=0)
Apr 17 11:48:08 nuc systemd-logind[596]: New session 41720 of user benjamin.

Er blockt also schon einiges, aber eben nicht alles, was durch hosts.allow und hosts.deny gesetzt wird. Der Fail2ban liest ja nur noch die Logfiles, und wenn mehr als 3 fehlerhafte Logins sind, verwendet er die IP zum blockieren via IPTables.

[cosinus]

Warum setzt du auf fail2ban? Ich würde auch wie @uname den SSH-Zugang anders absichern. Zuerst den SSH-Server aus der Schusslinie nehmen also den Port von 22 auf zB 2244 oder so setzen. Und für höchste Sicherheit grundsätzlich kein Login per Passwort mehr erlauben. Dann können dir irgendwelche Loginversuche von Scriptkiddies egal sein.

[wagnbeu0]

Es gibt gewisse technische Notwendigkeiten, warum ich den SSH Port auf Port 22 und per Username und Kennwort anbieten muss. Es geht mir ja jetzt darum, den bestehenden Zugang abzusichern. Das kann ich leider nicht abändern.

Was mich jetzt eben interessieren würde: Warum funktioniert hosts.allow und hosts.deny nicht wie erwartet? Fehler auf meiner Seite? Bug?

[cosinus]

Das hättest du aber auch kurz erwähnen können, dass du SSH auf Port 22 erreichbar haben musst und Logins mit Passwörtern auch sein müssen. Und wenn deine hosts.deny tatsächlich so aussieht

Code: Alles auswählen

# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
sshd: ALL

könnte sich keiner (bis auf die in hosts.allow definierten wenigen Ausnahmen) mit diesem Rechner per SSH verbinden.

[reox]

Wenn du einen anderen, eher unbekannten Port verwendest, dann wird schnell Schluss sein mit den ganzen Anmeldeversuchen. Die Änderung des Ports erhöht nicht wirklich die Sicherheit (Security through Oobscurity), es minimiert aber den Ärger durch Script-Kiddies denn viel mehr ist das aktuelle Problem auch nicht (bei Verwendung von SSH-Keys und/oder hoch komplizierten Passwörtern wovon ich bei dir erst mal ausgehe).

Ich bin mir nicht sicher ob das noch gilt. Ich sehe auch auf anderen Ports als 22 die Anmeldeversuche. Gut, es sind nicht so viele wie auf 22 aber dennoch. Ich glaube seit Portscannen billig geworden ist (Siehe auch https://fahrplan.events.ccc.de/congress ... /5533.html) kann man ja problemlos auch geziehlt nach SSH Servern Ausschau halten (shodan lässt grüßen).
Wenn man sonst nichts ändern will, schafft vermutlich nur noch Port-Knocking oder SSH in v6-only zu betreiben Abhilfe, weil man den gesamten v6 Adressraum viel langsamer durchforsten kann.
Ein weiteres Problem ist ja auch, dass Wörterbuchattacken heute parallelisiert werden können. So können sie sogar unter dem Radar von fail2ban fahren, weil kein einzelner Host so oft eine Anfrage sendet.

[wagnbeu0]

So, ich bin mit meinem Latein am Ende ...

Generell funktoniert der TCP Wrapper. Meine aktuelle Hosts-Daateien sehen so aus:

Code: Alles auswählen

root@nuc:~# cat /etc/hosts.*
sshd: 192.168.10. : allow
sshd: 127.0. : allow
sshd: fr4yrtzg1m8k1bb.myfritz.net : allow
sshd: .pool.telefonica.de : allow

# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
sshd: ALL \
: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
: deny

Im sshd.log tauchen auch folgende Meldungen auf:

Code: Alles auswählen

Mi 19. Apr 12:55:40 CEST 2023 access denied to 40.84.188.145

Und Fail2ban sagt mir auch fleißig:

Code: Alles auswählen

[Fail2Ban] sshd: banned 40.84.188.145
[Fail2Ban] sshd: banned 82.223.27.224

Meine Frage jetzt:
Warum scheint der TCP Wrapper zu funktionieren (er springt ja an), aber trotzdem IPs durchzulassen?

[wagnbeu0]

Nach vielen lesen und testen habe ich jetzt folgende Config am laufen:

Code: Alles auswählen

hosts.allow:
sshd: localhost, 127.0.0.1 : allow
sshd: 192.168.10.0/255.255.255.0: allow
sshd: 95.115.115.47: allow
sshd: 91.22.72.37: allow
sshd: ALL: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/banned-sshd.log: deny

hosts.deny:
sshd: ALL

Dann läuft noch ein Fail2ban, der in den erlaubten IP-Bereichen nach 3 fehlerhaften Logins via SSH die IP blockiert via IP-Tables.
Ich sehe aber weiterhin, dass fail2ban viele IPs blockiert, pro Tag knapp 50. Das sind 233.x.x.x.x, 161.xxx etc., also alles IPs, die eigentlich ja schon gar nicht durch den TCP Wrapper durchkommen sollten, oder?

Geblockte IPs sollen ja vom TCP Wrapper in einer Datei geloggt werden (banned-sshd.log). Da sind folgende Meldungen zu sehen:

Code: Alles auswählen

Mo 24. Apr 09:35:47 CEST 2023 access denied to 125.74.196.138
Mo 24. Apr 09:53:13 CEST 2023 access denied to 185.22.153.175
Mo 24. Apr 10:05:03 CEST 2023 access denied to 170.64.186.100
Mo 24. Apr 10:05:10 CEST 2023 access denied to 103.69.9.7
Mo 24. Apr 10:15:40 CEST 2023 access denied to 159.89.168.24
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:23:23 CEST 2023 access denied to 43.158.208.161
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37
Mo 24. Apr 10:29:02 CEST 2023 access denied to 149.202.74.37

Meine Frage also:
Geht der TCP Wrapper bei hohen Anfragen nicht (DDOS), also dass einfach IPs von ihm nicht mehr behandelt werden können? Das würde bei 15 Anfragen pro Sekunde aber das System insgesamt in Frage stellen.
Oder warum werden manche IPs erst nach drei Logins blockiert, wenn der tcpd Wrapper die ja gar nicht zulassen soll?

Ich hoffe, ihr könnt mir hier weiterhelfen.

[mat6937]

So, ich bin mit meinem Latein am Ende ...

BTW: Du kannst auch mit der service-unit (in der [Service]-Section), Zugriff blocken und erlauben. Z. B.:

Code: Alles auswählen

:~ $ systemctl cat ssh | grep -i address
IPAddressDeny=any
IPAddressAllow=192.168.178.0/24
IPAddressAllow=192.168.174.0/24

[wagnbeu0]

Schade. Habe so ein ähnliches Problem.
Meine beiden Files sehen so aus:

Code: Alles auswählen

hosts.allow:
sshd: 192.168.10.0/255.255.255.0: allow
sshd: 95.115.123.47: allow
sshd: 91.22.53.37: allow
sshd: ALL: spawn /bin/echo `/bin/date` access denied to %h>>/tmp/sshd.log: deny

hosts.deny
sshd: ALL: spawn /bin/echo `/bin/date` access denied to %h>>/tmp/sshd.log: deny

Eigentlich sollten also keine anderen IPs als die oben eingetragenen beim SSHD ankommen. Trortdem meldet mein fail2ban nun, dass immer wieder IPs wegen fehlerhater Logins geblockt werden. Ich verstehe nur nicht, wie IPs an der hosts.deny vorbeikommen, wenn ihre Regeln nicht gelten...

Beispiel:
eben wurde die IP 112.20.185.169 vom fail2ban geblockt. Die sollte aber gar nicht durchkommen ...

Code: Alles auswählen

root@nuc:~# tcpdmatch sshd 112.20.185.169
client:   address  112.20.185.169
server:   process  sshd
access:   denied

Mein Logfile sagt:

Code: Alles auswählen

Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194
Mo 24. Apr 14:49:10 CEST 2023 access denied to 23.224.98.194

Wird also der TCP Wrapper durch zu viele Anfragen außer gefecht gesetzt?


Edit JTH: Hierher verschoben aus ollem, erledigtem Thema „hosts.allow und host.deny scheren sich nicht um ssh!“.

[mat6937]

... Trortdem meldet mein fail2ban nun, dass immer wieder IPs wegen fehlerhater Logins geblockt werden.

Wird also der TCP Wrapper durch zu viele Anfragen außer gefecht gesetzt?

BTW: Auf welcher Ebene "arbeitet" fail2ban und auf welcher Ebene "arbeitet" der TCP Wrapper?

[schorsch_76]

Bist du dir sicher das der TCP Wrapper für ssh aktiv ist und nicht als Dienst läuft? Das würde erklären warum der ssh diese Dateien ignoriert....

[mat6937]

Bist du dir sicher das der TCP Wrapper für ssh aktiv ist ...

Lt. seiner Ausgabe:

Code: Alles auswählen

:~# tcpdmatch sshd 112.20.185.169
client:   address  112.20.185.169
server:   process  sshd
access:   denied

ist er aktiv.

[wagnbeu0]

So, kurzes Update. Ich vermute mal, dass der sshd einfach die Dateien nicht sauber abarbeitet. Interessanterweise habe ich einen Info gefunden, die RHEL8 betrifft:
https://zedt.eu/tech/linux/how-to-filte ... y-linux-8/

Ich habe das jetzt mal in meiner Debianinstallation gemacht, also den SSHD auf socket umgestellt, und im Startscript folgendes geändert:

Code: Alles auswählen

cp /lib/systemd/system/ssh@.service /etc/systemd/system/
vi /etc/systemd/system/ssh@.service 
--> ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $SSHD_OPTS
systemctl start ssh.socket

root@nuc:/usr/lib/systemd# systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Mon 2023-04-24 16:09:11 CEST; 10min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 604593 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
    Process: 604594 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=0/SUCCESS)
   Main PID: 604594 (code=exited, status=0/SUCCESS)
        CPU: 59ms

Apr 24 16:04:29 nuc systemd[1]: Starting OpenBSD Secure Shell server...
Apr 24 16:04:29 nuc sshd[604594]: Server listening on 0.0.0.0 port 22.
Apr 24 16:04:29 nuc systemd[1]: Started OpenBSD Secure Shell server.
Apr 24 16:05:31 nuc sshd[604703]: refused connect from 143.198.128.123 (143.198.128.123)
Apr 24 16:09:11 nuc sshd[604594]: Received signal 15; terminating.
Apr 24 16:09:11 nuc systemd[1]: Stopping OpenBSD Secure Shell server...
Apr 24 16:09:11 nuc systemd[1]: ssh.service: Succeeded.
Apr 24 16:09:11 nuc systemd[1]: Stopped OpenBSD Secure Shell server.

root@nuc:/usr/lib/systemd# systemctl status ssh.socket
● ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/lib/systemd/system/ssh.socket; disabled; vendor preset: enabled)
     Active: active (listening) since Mon 2023-04-24 16:09:11 CEST; 11min ago
   Triggers: ● ssh@0-192.168.10.7:22-192.168.10.119:59278.service
     Listen: [::]:22 (Stream)
   Accepted: 43; Connected: 1;
      Tasks: 0 (limit: 9247)
     Memory: 16.0K
        CPU: 57ms
     CGroup: /system.slice/ssh.socket

Apr 24 16:09:11 nuc systemd[1]: Listening on OpenBSD Secure Shell server socket.

Jetzt mal schauen, ob damit die Dateien besser genutzt werden

[heisenberg]

The TCP Wrappers package has been deprecated in RHEL 7 and therefore it will not be available in RHEL 8 or later RHEL releases.

https://access.redhat.com/solutions/3906701

Red Hat hat sich vom tcpd bewusst verabschiedet. Deswegen arbeitet der sshd auch dort sehr sauber, ist aber einfach nicht mehr gegen libwrap gelinkt und bietet diese Funktionaltität schlicht nicht mehr an.

Ansonsten hat der OpenSSH-Server auch eigene Möglichkeiten IP-basierende Sperren umzusetzen.

Ohne grosse Überprüfung würde ich das mal so vermuten:

Code: Alles auswählen

# globale Konfig-Ebene: Authentifizierung komplett abschalten.

PubKeyAuthentication No
PasswordAuthentication No
ChallengeResponseAuthentication No

# Match-Blocks für einzelne Quell-Objekte:

Match Address 127.0.0.*
    PubkeyAuthentication Yes
    PasswordAuthentication Yes
    ChallengeResponseAuthentication Yes

Match Address 1.2.3.*
    PubkeyAuthentication Yes
    PasswordAuthentication Yes
    ChallengeResponseAuthentication Yes

Der verlinkte Workaround frickelt den TCP-Wrapper ja wieder einfach so um den sshd drumherum.

Damit gibt es jetzt also ad-hoc 4 Möglichkeiten, wie man das umsetzen kann:

• Firewallregeln
• sshd-service explizit mit tcp-wrapper gewrappt konfigurieren
• Match-Blöcke von sshd verwenden
• systemd IP-Zugriffslisten

[wagnbeu0]

So, ich habe das jetzt seit gestern am laufen, und was soll ich sagen, es funktioniert einwandfrei. Es kommen beim fail2ban keine IPs mehr an, außer wenn sie laut /etc/hosts.allow erlaubt sind.

In den Logfiles ist mir folgendes aufgefallen:

Code: Alles auswählen

root@nuc:~# tail -f /tmp/sshd.log
Di 25. Apr 05:48:31 CEST 2023 access denied to ::ffff:124.238.252.52
Di 25. Apr 05:48:46 CEST 2023 access denied to ::ffff:124.238.252.52
Di 25. Apr 05:49:02 CEST 2023 access denied to ::ffff:124.238.252.52
Di 25. Apr 05:49:02 CEST 2023 access denied to ::ffff:124.238.252.52
Di 25. Apr 05:49:02 CEST 2023 access denied to ::ffff:124.238.252.52
Di 25. Apr 05:49:02 CEST 2023 access denied to ::ffff:124.238.252.52
Di 25. Apr 05:49:02 CEST 2023 access denied to ::ffff:124.238.252.52
Di 25. Apr 06:14:28 CEST 2023 access denied to ::ffff:116.235.95.221
Di 25. Apr 06:19:43 CEST 2023 access denied to ::ffff:220.71.135.19
Di 25. Apr 06:36:42 CEST 2023 access denied to ::ffff:183.107.47.119

Die IPs, die der sshd selbst noch zugelassen zugelassen hat, der tcpd aber ordnungsgemäß abweist, sind alles ipv6 notierte ipv4 Adressen. die lässt der sshd in der Defaultconfig einfach durch.