SSH / Openvpn Problem

[honigmaus]

Servus,

ich habe ein für mich sehr seltsames Problem mit genau einem SSH Client und genau einem SSHD:

Client 192.168.2.50:

Code: Alles auswählen

$ ssh -v 192.168.88.7
OpenSSH_9.2p1 Debian-2, OpenSSL 3.0.8 7 Feb 2023
debug1: Reading configuration data /home/honigmaus/.ssh/config
debug1: Connecting to 192.168.88.7 [192.168.88.7] port 22.
debug1: connect to address 192.168.88.7 port 22: Connection refused
ssh: connect to host 192.168.88.7 port 22: Connection refused

Router eno1 192.168.2.1 / tun0 192.168.88.2:

Code: Alles auswählen

# tcpdump -i tun0 host 192.168.2.50
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
19:16:19.778822 IP 192.168.2.50.54056 > 192.168.88.7.ssh: Flags [S], seq 978934151, win 64240, options [mss 1460,sackOK,TS val 2788336026 ecr 0,nop,wscale 7], length 0
19:16:19.854039 IP 192.168.88.7 > 192.168.2.50: ICMP 192.168.88.7 tcp port ssh unreachable, length 68

SSH Server mit Public IP und tun0 192.168.88.7 (neu installiert mit meinem normalen IaaS/Ansible code den ich sonst auch verwende):

Code: Alles auswählen

# tcpdump -i tun0 host 192.168.2.50
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
19:16:19.835026 IP 192.168.2.50.54056 > 192.168.88.7.ssh: Flags [S], seq 978934151, win 64240, options [mss 1345,sackOK,TS val 2788336026 ecr 0,nop,wscale 7], length 0
19:16:19.835165 IP 192.168.88.7 > 192.168.2.50: ICMP 192.168.88.7 tcp port ssh unreachable, length 68

Dasselbe auch in die andere Richtung.
Alle anderen Clients haben kein Problem mit dem SSHD von 192.168.88.7.

Was ich geprüft habe:

• Ohne Openvpn, also vom Client auf die Public IP gehts.

• Ping über VPN geht

• SSH Verbindung von/zu anderen IPs über das VPN, geht

• Routing, ist OK

• Firewalls ausgeschalten, selbes Problem

• mssfix auf dem Client mit versch. Werten, auch 1345

• Jeder Client hat ein eigenes Zertifikat

• SSH auf dem Client deinstalliert (dpkg -P) und neu installiert

• known_hosts gelöscht

• neue id_rsa

• Zeit ist synchron

Hab ich was übersehen?
Was könnte ich noch prüfen?

Danke <3

[MSfree]

SSH-Login als root ist in der Standardeinstellung nicht erlaubt.
Log dich als "normaler" Benutzer ein, das sollte gehen.

[honigmaus]

Danke, ich verwend root nicht für Logins.
# == root
$ == user

[heisenberg]

Was sagt nmap -p22 192.168.88.7 von der 192.168.2.50 aus?

Zeig/Kontrollier mal die FW-Regeln auf beiden Systemen, wenn die FW "ausgeschaltet" ist.

Dasselbe auch in die andere Richtung

D. h. Du kommst von der .7 nicht auf die .2.50 ?

(Ich tippe auf FW-Regeln auf der .7)

Mal doch mal einen kleinen ASCII Netzwerk Plan, damit wir deinen Aufbau sehen.

[honigmaus]

Servus & Danke!

192.168.2.50:

$ nmap -p22 192.168.88.7
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-04 22:36 CEST
Nmap scan report for 192.168.88.7
Host is up (0.073s latency).

PORT STATE SERVICE
22/tcp closed ssh

Nmap done: 1 IP address (1 host up) scanned in 0.35 seconds

Kiste daneben (192.168.2.51):

$ nmap -p22 192.168.88.7
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-04 22:38 CEST
Nmap scan report for 192.168.88.7
Host is up (0.082s latency).

PORT STATE SERVICE
22/tcp open ssh

Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds

Ja genau, in die andere Richtung (192.168.88.7 > 192.168.2.50/51) ist es genauso.

Die relevanten ufw Regeln auf .7:

# ufw status verbose numbered
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To Action From
-- ------ ----
22/tcp ALLOW IN Anywhere # ufw allow ssh
1194/udp ALLOW IN Anywhere # ufw allow openvpn

Hab das Problem aber genau so wenn ufw disabled ist.

ASCII-Diagramm-Tool geh ich mal suchen ...

PS: ich hab grad einen Verdacht, aber Name Resolution kanns doch nicht sein, oder?

[heisenberg]

Mit FW-Ausgabe wünsche ich mir

iptables-save

Ich mal meine ASCII-Diagramme mit der Hand.

[mat6937]

Hab das Problem aber genau so wenn ufw disabled ist.

PS: ich hab grad einen Verdacht, aber Name Resolution kanns doch nicht sein, oder?

Lauscht der sshd auf allen Interfaces? Wenn nicht, hast Du MASQUERADE (source-NAT) auch konfiguriert?

[honigmaus]

So, erster Versuch sowas zu zeichnen:


Bitte nicht fragen warum die Architektur nicht einheitlich ist, manchem werden die Ranges der Router bekannt vorkommen
Auf 88.2 war ein mssfix notwendig, das kanns aber nicht sein weil ja alle anderen Systeme in 192.168.2.0/24 problemlos 192.168.88.7 erreichen.

Zur Erinnerung: 192.168.2.50 kann 192.168.88.7 pingen und umgekehrt. SSH, SMTP, HTTP, ... 192.168.2.50 <> 192.168.88.7 gehen nicht.

Zu den Fragen: ja, sshd lauscht auf alles:

# netstat -tnelp | grep sshd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 16481 863/sshd: /usr/sbin

zur Erinnerung: _alle_ anderen Systeme im VPN können 192.168.88.7 problemlos erreichen

NAT in der before.rules von 192.168.2.1:

# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Forward traffic through eno3 (Internet interface)
-A POSTROUTING -s 192.168.2.0/24 -o eno3 -j MASQUERADE
#-A POSTROUTING -o eno3 -j MASQUERADE
# don't delete the 'COMMIT' line or these nat table rules won't
# be processed
COMMIT
# end NAT rules

zur Erinnerung: alle System im Netz von 192.168.2.0/24 außer einem (.50) können 192.168.88.7 problemlos erreichen

iptables-save liefert 4710 Zeilen, das kann nicht dein Ernst sein? 192.168.88.7 hab ich erst gestern via seit Jahrem bei mir bewährten und immer weiter gepflegten Apiscript & Ansible aufgesetzt,
Die Firewall besteht nur aus einfachen ufw-Regeln nach dem Schema "ufw allow <servicename>" Ich kann mir nicht vorstellen, dass da irgendwelche Altreste sind die spezifisch auf dieses Problem wirken,
aber immerhin: den Code hab ich schon nach den beiden IPs und Hostnamen durchsucht ... nix.

[cosinus]

192.168.2.50:
$ nmap -p22 192.168.88.7
PORT STATE SERVICE
22/tcp closed ssh

Aus Sicht des Clients 192.168.2.50 ist der Port 22 auf 192.168.88.7 geschlossen. Geschlossen deutet auf eine Regel mit REJECT hin. Bei DROP würde nmap ein filtered auswerfen.
Ich würde mir also die Firewallregeln des zuständigen Gatewways anschauen, in deinem Fall ist das für den Client 192.168.2.50 der Host mit den Adresse 192.168.2.1.

[honigmaus]

Die Firewall von 192.168.2.1:

# ufw status numbered
Status: active

To Action From
-- ------ ----
[ 1] Anywhere ALLOW IN 192.168.2.0/24 # ufw allow from 192.168.2.0/24
[ 2] Anywhere ALLOW OUT Anywhere on eno3 (out) # ufw allow out on eno3/Internet
[ 3] 1194 ALLOW IN Anywhere # ufw allow openvpn

Wenn da was wäre dürften alle anderen in 192.168.2.0/24 auch nicht an 192.168.88.7 kommen, oder?
Tun sie aber (siehe posting weiter oben).
Abgesehen davon ist das Problem dasselbe wenn alle Firewalls ausgeschaltet (ufw disable) sind.

... und gleich die Routen von 192.168.2.1 dazu:

# ip r
default via 192.168.1.1 dev eno3
10.0.0.0/24 via 192.168.88.1 dev tun0
192.168.0.0/24 via 192.168.88.1 dev tun0
192.168.1.0/24 dev eno3 proto kernel scope link src 192.168.1.48
192.168.2.0/24 dev eno1 proto kernel scope link src 192.168.2.1
192.168.88.0/24 dev tun0 proto kernel scope link src 192.168.88.2
192.168.178.0/24 via 192.168.88.1 dev tun0

[cosinus]

Wenn da was wäre dürften alle anderen in 192.168.2.0/24 auch nicht an 192.168.88.7 kommen, oder?
Tun sie aber (siehe posting weiter oben).

Nein. Du kannst ja Regeln definieren bis der Arzt kommt. Und es spricht nichts dagegen, eine Regel zu definieren, die eine bestimmte IP-Adresse daran hindert, den Rest des Subnetzes aber durchlässt.
Wo hast du überall mit ufw und vllt iptables Filterregeln eingerichtet? Hast du das alles selbst gemacht oder ist das ein Erbe, das dir hinterlassen wurde?

Ausgaben von

Code: Alles auswählen

iptables -L -n -v

könnten auch helfen.

[honigmaus]

... mir fällt noch ein dass 192.168.2.50 einen VM Manager (https://virt-manager.org/) hat, d.h. es gibt da eine Bridge:

br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 42:29:82:86:ef:56 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.50/24 brd 192.168.2.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::4029:82ff:fe86:ef56/64 scope link
valid_lft forever preferred_lft forever

Ich kann mich zwar nicht erinnern da was Besonderes konfiguriert zu haben, aber ich schau mal ...

Routen schauen schonmal unauffällig aus, oder?

# ip r
default via 192.168.2.1 dev br0 onlink
192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.50

[cosinus]

Also ich versteh da noch nicht alles. Wozu hast du VPN? Doch nicht um die anderen Rechner zu erreichen?
Und ohne "die VPN-Verbindung" kannst du ganz normal auch mit 192.168.2.50 SSH machen?
Was ist denn wenn du testweise diesen Rechner abschaltest und eine Testkiste mit IP-Adresse 192.168.2.50 einrichtest und dann SSH versuchst, mit und ohne VPN?

[honigmaus]

aaaaaahrgh!

Ich hab fail2ban auf 192.168.88.7 vergessen & ihr hattet alle recht:

# iptables-save | grep 192.168.2.50
-A f2b-ufw -s 192.168.2.50/32 -j REJECT --reject-with icmp-port-unreachable

Und das obwohl:

jail.local:ignoreip = 127.0.0.1/8 ::1 192.168.2.0/24

Erklärungsversuch:
192.168.2.50 war der Controlhost beim Deployment von 192.168.88.7.
Vielleicht hat er ein paar fails in logs geschrieben die fail2ban dann gefunden hat (Setting auf 600 Minuten) bevor die ignoreips aktuell waren,
oder so.

Problemlösung:

# fail2ban-client unban 192.168.2.50
1

*honigmaus happy*

Danke euch!

[cosinus]

Schön, dass wir gemeinsam den Fehler fanden

BTW: ich hab früher denyhosts genutzt. Mach ich nicht mehr. Ich schränke lieber mittlerweile manuell per iptables ein und/oder

-- SSH auf einen anderen Port
-- root Login verboten
-- Login nur mit Key und nur mit einem speziellen Loginuser

Für interne Kisten muss man diese Zügel natürlich nicht ziehen

[honigmaus]

Hast du das alles selbst gemacht oder ist das ein Erbe, das dir hinterlassen wurde?

Alles selber verbrochen und von mir selber geerbt, teilweise aus den frühen 1990ern.
Kalk rieselt schon, sorry.

[honigmaus]

Schön, dass wir gemeinsam den Fehler fanden

BTW: ich hab früher denyhosts genutzt. Mach ich nicht mehr. Ich schränke lieber mittlerweile manuell per iptables ein und/oder

-- SSH auf einen anderen Port
-- root Login verboten
-- Login nur mit Key und nur mit einem speziellen Loginuser

Für interne Kisten muss man diese Zügel natürlich nicht ziehen

Naja, ich hab User mit, sagen wir: "Tendenzen zu unsicheren Kennwörtern" und einer ausgeprägten Antipathie was MFA betrifft.
Hat bereits mehrmals dazu geführt dass in Systeme eingebrochen wurde, Mailserver sind scheints besonders beliebt.
Daher Fail2ban.

[cosinus]

Macht doch nichts. Jeder hat mal ein Brett vorm Kopf, besonders ich
Wir hatten letztens einen Einbrecher aus China. Der hatte es auf unsere Sophos UTM abgesehen. Die kann man eigentlich komplett per HTTPS administrieren, ich lass mir aber gerne die SSH-Option offen. Natürlich dann nicht über den Standardport, damit der aus der Schusslonie ist. Nun hatte es dieser Chinese aber geschafft, den Port zu erraten. Und brachte da ca. 3000 Loginversuche. Geschafft hatte er es nicht. Dazu hätte er aber nichtmal nen Key benötigt, nur den richtigen User+Passwort, aber den richtigen User konnte er nicht erraten, geschweige denn das Passwort dazu. Nun lauscht SSHD wieder auf nen anderen Port und es herrscht Ruhe

[honigmaus]

Wenn du mir die Länge und Anzahl der verwendeten Zeichen für Usernamen/Passwort verrätst dann sag ich dir wie lange ich brauche um die herauszufinden,
eine unlimitierte Anzahl Versuche vorausgesetzt

Spoiler: ab > 20 Zeichen wirds fad, da würd ich dann schon mehr als einen Server einsetzen.

[cosinus]

Naja, unsere UTM regelt das schon ab. Unendlich viele Versuche in beliebiger Zeit gibt es nicht. Das macht SSHD abe auch schon an sich, oder?
Wieso soll ich dir was verraten? Finde es selber raus. Mein Passwort ist sehr einfach. Wenn man es kennt

Erstmal müsstest du auch Adresse und den (neuen) Port erraten!

[MSfree]

-- SSH auf einen anderen Port
-- root Login verboten
-- Login nur mit Key und nur mit einem speziellen Loginuser

Ich habe mir nach dem Vorbild von Portknocking einen Pingknocking Server und Client gebaut. Die Serverseite wartet auf eingehende Pings und untersucht dann die Payload im Pingpaket. Bei passender Payload wird eine Aktion ausgeführt, z.B. wird Port 22 für eine Minute für eingehende SSH-Verbindungen von der IP-Adresse des Senders des Pingpakets aufgemacht, der Rest der Welt bleibt also trotzdem darußen. Genauso gut könnte man auch UDP-Port 1194 (OpenVPN) für eine Minute öffnen, oder auch ein Shellskript ausführen, das ein Backup anstößt...

Das hat den Vorteil, daß ich nach aussen keinen einzigen Port öffnen muß und SSH auf Port 22 belassen kann.

Clientseitig habe ich ein Pingprogramm, das die nötige Payload in das Pingpaket einsetzt und dann verschickt. Die Payload selbst ist ein SHA256 Hash, der sich zeitabhängig ändert, so wie es auch bei TOTP gemacht wird.

Der Nachteil ist, daß das natürlich Software ist, die nicht auf fertigen Netzwerkdevices nutzbar ist. Clientseitig bekommt man das Pingprogramm recht einfach für unterschiedliche Betriebssysteme gebaut, Windows, Linux, MacOS sind kein Problem. Serverseitig ist aber unbedingt iptables nötig. Eine Portierung auf nftables habe ich noch nicht in Angriff genommen, sollte aber auch machbar sein.

Wenn jemand versucht, sich mit meiner Kiste per SSH zu verbinden, ohne vorher den Port per Pingknocking aufzumachen, gibt es eine entsprechende Meldung im Syslog. Siehe auch hier: viewtopic.php?t=186814

Warum Ping? Portknocking ist aus vielen Netzen heraus nicht möglich, weil Firewalls die teilweise exotischen Portnummern blockieren. Ping bekommt man aber fast immer durch. Ausserdem verläßt sich Portknocking auf eine feste Sequenz von Ports, die man durch belauschen der Netzwerkpakete leicht herausfinden kann.

[MSfree]

Unendlich viele Versuche in beliebiger Zeit gibt es nicht.

Einerseits wird das schon durch die gegebene Netzwerkbandbreite eingeschränkt. Man kann halt nur soundsoviele Netzwerkpakete pro Sekunde durch die Leitung schicken. Andererseits limitiert die CPU, die beim Aufbau der Verschlüssleung auch arbeiten muß. Irgendwann sind halt Netz und/oder CPU gesättigt und man hat ein DoS.

[cosinus]

Ich hab gestern übrigens maßlos übertrieben. Es waren nicht 3000 Loginversuche, sondern nur 1500.
Jedenfalls hatte ich etwa so viele Mails bekommen, die UTM schickt mir bei jedem gescheiterten oder erfolgreichen Login eine Mail. Ich find nur komisch wie der chinese diesen Port erraten konnte. Schnell mit nmap abscannen geht nicht, die UTM verlangsamt alles wenn sie Portscans erkennt.

[heisenberg]

Ich find nur komisch wie der chinese diesen Port erraten konnte. Schnell mit nmap abscannen geht nicht, die UTM verlangsamt alles wenn sie Portscans erkennt.

Es gibt da mittlerweile sogar Dienstleister, das ganze Internet nach Servern und deren offenen Ports abscannen und die Ergebnisse zur Verfügung stellen.

Das Verschleiern des SSH Ports bringt nur bedingt etwas, nach zwei Tagen ist es öffentlich bei Shodan und Censys einsehbar, da der Port gefunden wurde.

Siehe:
https://linuxnews.de/linux-sicherheit-in-der-cloud/

Ich muss aber ehrlicherweise gestehen, dass ich die SSH-Ports von meinen Servern damit noch nicht gefunden habe. Bin ich einfach zu doof das zu benutzen, oder geht das nur mit kostenpflichtigem Account?

Was ähnliches gibt's u. a. für SSL-Zertifikate. Einen Dienst, der im Blick hat welche SSL-Zertifikate auf welchen Public IPs eingesetzt werden. Wenn Du da auf einem Server mit unsicherer SSL-Version einsetzt, dann sind alle anderen Server, die das gleiche Zertifikat benutzen (-> Wildcard-Zertifikate!) auch als gehackt zu betrachten. Qualys nutzt das u. a. in seinem SSL-Check.

[cosinus]

Der Port den der Chinese gefunden hat, hatten wir aber schon seit locker 5 Jahren so. Da kamen keine Einbruchsversuche rein, jedenfalls hat die UTM mir keine Mails dazu geschickt.
Seitdem ich den Port umgelegt habe ist Ruhe. Das mit den 2 Tagen kann ich also nicht nachvollziehen.