Fehler: Handshake failed with Client-ID 1

[Hendrik2020]

Währe halt doof jetzt deswegen das gesamte „Thread Management“ oder wie die das nennen ausschalten zu müssen....

[vento66]

Warum auch immer man im internen Netzwerk nach offenen Ports scannen muss....

[Hendrik2020]

man kann ja nicht nur die "Portscan Funktion" abschalten oder halt das Gerät also EDOMI rausnehmen... man kann ja leider nur das gesamte "Thread Management" abschalten... soweit ich das weis.

[DerSeppel]

Ja ist ziemlich nervig. Hatte neulich schon nen Anruf der IT meines Arbeitgebers. Weil die IDS auf meinen Laptop angesprungen ist sobald ich den Rechner im Home-Office auf die UDM gepacht habe.

Edit: Endpoint Scanning kann man unabhängig vom Threat Management ausschalten, glaube ich.

[vento66]

Ist ja auch völliger Nonsens sowas.

[DerSeppel]

Ja ist es. soll wohl proaktiv unsichere Hosts im Netzwerk finden.
Interessant sind die Berichte wo nachts der Drucker anspringt und Müll ausdruckt.
Spricht allerdings auch nicht wirklich für den Drucker...

Unter Security > Network Scanners > Threat Scanner lässt sich das abschalten.

[saegefisch]

Just heute Nacht wieder 5x "Handshake failed with Client-ID 1" in rascher Folge (insgesamt 10s). Dieses Mal habe ich von meiner FW (MikroTik zwischen DMZ und LAN) mitschneiden lassen. Tatsächlich gab es Zugriffe meines RevProxy (DMZ hinter FritzBox) auf edomi (LAN). Für eine PortScan spricht, dass die 15 Log-Einträge fast eine Reihe bilden: 46316, 46318, 46320, 46324, 46326. Jeweils ein 3er-Paket eine TCP-Handshakes: (SYN), (ACK), (ACK,FIN).

Aber...erstaunlicherweise habe ich die diese Ports ganz sicher nicht exponiert?! -> vielleicht bringt das ja neue Erkenntnisse...
Kann es sein, dass ein RevProxy (NGINX; sehr regelmäßige Updates und keinerlei weitere SW dort am laufen) sowas macht? An der Stelle fehlt mir tieferes Wissen...

exemplarisch: 1. der 5 Fälle

02:23:14 firewall,info edomi Port 8080 Websocket: for: in:ether06-WAN out:bridge-vlanxxx, proto TCP (SYN), 192.168.aaa.bbb:46316->192.168.xxx.yyy:8080, len 60
02:23:14 firewall,info edomi Port 8080 Websocket: for: in:ether06-WAN out:bridge-vlanxxx, proto TCP (ACK), 192.168.aaa.bbb:46316->192.168.xxx.yyy:8080, len 52
02:23:14 firewall,info edomi Port 8080 Websocket: for: in:ether06-WAN out:bridge-vlanxxx, proto TCP (ACK,FIN), 192.168.aaa.bbb:46316->192.168.xxx.yyy:8080, len 52

Bin dankbar für jede Vermutung, wie
A) das weiter analysiert und
B) vermieden werden kann und
C) ob das ein Grund zur Sorgen geben sollte oder
D) irgendwie gehärtet werden kann.
Ich schätze den VPN-freien Zugriff von außen, aber nicht um jeden Preis; mit wireguard ist VPN heute auch schon viel geschmeidiger als früher.

In dem Zusammenhang sind meine damaligen Fragen auch noch immer aktuell.

[saegefisch]

Die Client-ID ist eine interne fortlaufende ID des Clients (quasi ein Array-Index).

Kann man daraus etwas sinnvolles ableiten, wenn es bei mir immer nur ID 1 ist?

[jonofe]

Die ID1 wird wohl immer gewählt wenn keine weitere VISU Verbindung aktiv ist.
Das kann man sehen, wenn man die VISU im Browser aufmacht und dann ein

telnet <EDOMI-IP> 8080

macht. Dann taucht der Fehler mit ID 2 auf. Ansonsten mit ID 1.

Wirklich vermeiden ist schwierig, wenn der Port 8080 via ReverseProxy ohne weitere Sicherheitsmechnismen (ClientCertificates) zum Internet exposed ist.
Denn dann geht jeder WS-Connect bis zum EDOMI Server durch und erzeugt den Fehler.

Meine Vermutung: Die hohen Ports, die du siehst sind nicht nach außen exponierte Ports, sondern die hohen Ports, die dein ReverseProxy verwendet um auf Port 8080 des EDOMI Servers zuzugreifen. Dazu müsste dann aaa.bbb dein ReverseProxy und xxx.yyy dein EDOMI Server sein. Richtig?

VPN ist natürlich die beste Möglichkeit diese Fehler zu verhindern.

Ansonsten würde mir nur einfallen, eine intelligente Logik in den Mikrotik oder ReverseProxy zu integrieren, d.h. entweder über L7Protocols (Mikrotik), um den Inhalt der ankommenden Pakete auf Port 8080 irgendwie zu verifizieren, bevor diese weitergeleitet werden oder aber den Port 8080 dynamisch weiterzuleiten, nachdem eine Verbindung auf 443 aufgebaut wurde. Beides ist aber wohl nicht trivial.

Wenn Mikrotik mal Wireguard in einer Stable Version von RouterOS drin hat, dann wäre das aus meiner Sicht ein guter Ansatz.

[saegefisch]

Danke für Deine Einschätzungen. Und ja, aaa.bbb ist ReverseProxy und xxx.yyy der EDOMI Server. Bei so viel Input muss ich aber noch mal nachfassen... kleiner Finger, ganze Hand.. wie das so ist...

>> Denkst Du (unverbindlich!), dass dies nur störend ist oder ist das ein Risiko, weil ein denkbarer Angriffsverktor?

>> Ist aus Deiner Sicht technisch eine Lösung mit ClientCertificates für Websocket überhaupt denkbar/möglich?
Das wäre die schönste Lösung, weil alle anderen Dienste ja bereits per CC abgesichert sind. Ich habe vor einiger Zeit schon mal dazu recherchiert, aber nichts gefunden. Wenn es technisch undenkbar ist, kann ich mir jeden Gedanken daran ersparen.

>> Der RevProxy würde so eine Art Port-NAT machen... Ist Dir bekannt, ob man derlei konfigurieren kann, welche Ports z.B. NGINX dafür nutzt?
In meinen conf-Dateien habe die obigen Ports nicht gefunden. Dann könnte man diese Vermutung prüfen. Aber es ist für mich auch die einzige logische Erklärung (mit meinem Halbwissen).

>> L7-FW-Regeln ist sicher eine neue Herausforderung... aber vielleicht auch gar nicht. Die Frage spannende wäre, welchen Inhalt der Portscan hat und welchen eine edomi-Verbindung. Ich habe technisch zu wenig Vorstellung, wie Pakete einer validen Websockets-Verbindung aussehen, aber es dürfte sehr sicher erheblich abweichen von einem Paket eines Portscans. Wenn es da klare Marker gäbe (enthält nicht den String "edomi" oder andere spezifischen Dinge (css, php, html)) - dann könnte das vielleicht sogar einfach sein.
> Die Frage wäre: Eher ein RevProxy-Thema (kann der in Pakete schauen?) oder ist das definitiv L7 auf dem MT?
> Oder auch die Frage der subdomain, die die 443-Anfrage nutzt - nutzt die auch der Websocket? Ist Dir bekannt, ob man den UPSTREAM/websocket auf eine bestimmte subdomain begrenzen kann? Damit würde die Wahrscheinlichkeit für derlei bereits rapide fallen. Dazu werde ich auch mal forschen - das wäre vermutlich die simpelste Lösung.

Ich habe wireguard ohnehin auf einem Server schon sehr lange am laufen, weil damit meine Kinder sich gefahrlos und sorgenlos in jedes "Drecks-WLAN" einwählen können (und was sie auch fleißig tun, um Ihr Kontingent zu schonen). Aber derzeit nutze ich wireguard nicht im Mobilfunknetz, weil ich dem Provider hinreichend traue. Da ist der ReverseProxy schon charmant und ich brauche auch keine interne und externe Link auf edomi, sonder nutze auf dem Smartphone immer nur den externen.
Wenn MT wirguard (mit ROS7?) endlich implementiert, wäre das aber schon schön.

[saegefisch]

Nachtrag: Blick ins NGINX-error.log -> vielleicht kann man daraus eine bessere/einfache Abwehr-Strategie ableiten

2021/04/15 02:22:34 [crit] 32029#32029: *49720 SSL_do_handshake() failed (SSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsup ported protocol) while SSL handshaking, client: 80.82.70.118, server: 0.0.0.0:8080
2021/04/15 02:23:14 [error] 32030#32030: *49725 upstream prematurely closed connection while reading response header from upstream, client: 5.8.10.202, server: , request: "GET / HTTP/1.1", upstream: "http://192.168.xxx.yyy:8080/", host: "<meinedyn.IPderTelekom>:8080"
2021/04/15 02:23:14 [error] 32030#32030: *49727 upstream prematurely closed connection while reading response header from upstream, client: 5.8.10.202, server: , request: "GET /aaa9 HTTP/1.1", upstream: "http://192.168.xxx.yyy:8080/aaa9", host: "<meinedyn.IPderTelekom>:8080"
2021/04/15 02:23:14 [error] 32029#32029: *49731 upstream prematurely closed connection while reading response header from upstream, client: 5.8.10.202, server: , request: "GET /aab9 HTTP/1.1", upstream: "http://192.168.xxx.yyy:8080/aab9", host: "<meinedyn.IPderTelekom>:8080"
2021/04/15 02:23:24 [error] 32029#32029: *49736 upstream prematurely closed connection while reading response header from upstream, client: 5.8.10.202, server: , request: "GET /aaa9 HTTP/1.1", upstream: "http://192.168.xxx.yyy:8080/aaa9", host: "<meinedyn.IPderTelekom>:8080"
2021/04/15 02:23:24 [error] 32029#32029: *49739 upstream prematurely closed connection while reading response header from upstream, client: 5.8.10.202, server: , request: "GET /aab9 HTTP/1.1", upstream: "http://192.168.xxx.yyy:8080/aab9", host: "<meinedyn.IPderTelekom>:8080"

und access-log:

5.8.10.202 - - [15/Apr/2021:02:23:24 +0200] "GET /aaa9 HTTP/1.1" 502 568 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36"
5.8.10.202 - - [15/Apr/2021:02:23:24 +0200] "GET /aaa9 HTTP/1.1" 400 666 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36"
5.8.10.202 - - [15/Apr/2021:02:23:24 +0200] "GET /aab9 HTTP/1.1" 502 568 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36"
5.8.10.202 - - [15/Apr/2021:02:23:25 +0200] "GET /aab9 HTTP/1.1" 400 666 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36"

Was mich zu meiner Frage im letzten Post bringt: Kann man nicht vielleicht schon am Pfad "leichtfüßig" erkennen, ob eine websocket-Anfrage valide ist (hier "/" und "/aaa9" und "/aab9") und nicht /visu oder /admin und damit im NGINX oder MT raus zu filtern?

80.82.70.118 -> Datacenter in NL https://www.abuseipdb.com/check/80.82.70.118
5.8.10.202 -> Datacenter in RUS https://www.abuseipdb.com/check/5.8.10.202

Vielleicht könnte man den Websocket-Verkehr auf deutsche IPs begrenzen? Dann bräuchte ich VPN nur,wenn ich im Ausland bin. Oder gibt es blacklists für derlei? Werde mal forschen gehen... gab es da nicht mal was mit fail2ban...oder geoip?

[saegefisch]

Habe dem RevProxy jetzt mal GeoIP beigebracht. Erstmal ganz strikt alles verbieten außer IP aus DE. - mal schauen, ob das heute Nacht der letzte handshake failed war...

Was dafür nötig ist: geoip-Modul in nginx aktivieren, sofern noch nicht aktiv. Aktuelle maxmind-GeoDaten von alternativer Quelle https://dl.miyuru.lk herunter laden, weil maxmind nur noch sein neues Format anbietet. in nginx.conf im Abschnitt http:

geoip_country /usr/share/GeoIP/GeoIP.dat;
map $geoip_country_code $allowed_country {
default no;
DE yes;
}

und zu jedem relevanten Server die nun bereitstehende Variable auch anwenden

if ($allowed_country = no) {
return 444;
}

vor allem aber für das aktuelle Thema zum edomi-websocket-Port 8080. Reload und schon sollte jeglicher Zugriff von IP-Adressen außerhalb Deutschlands abprallen. Alternativ kann man statt 444 auch einen anderen Status setzen. (Test: "DE yes;" auskommentieren). Natürlich hilft das nicht gegen Portscans aus DE, aber es sollte stiller werden.

---

Für den verbleibenden Rest aus DE wäre es ja spannend, ob man nicht per URL auf valide edomi-Zugriffe rückschließen kann. Damit geht es schon lange prima (und auch mit dem neuen GeoIP-Filter):

server {
listen 8080 ssl http2;
listen [::]:8080 ssl http2;

if ($allowed_country = no) {        #+20200415: GeoIP-Filter
return 444;
}

location / {
proxy_pass http://websocket;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}

Allerdings schlägt der Aufruf der edomi-Visu fehl, wenn man z.B: hinzufügt

[...]
location = / {
 return 444;
}
[...]

oder "location / {" ersetzt durch

location ~* \.*(visu|admin).*$ {

oder das selbe mit

location ~* \.(ws|js|php)$ {

In allen drei Fällen klappte der Zugriff nicht mehr. Entweder nutze ich NGINX hier falsch oder die URL einer validen Websocket-Verbindung sieht nicht so aus, wie erwartet ".../visu/...", sondern offenbar lautet die Websocket-URL abweichend wohl "= /".

Nachtrag: In den Entwicklerwerkzeugen wird man schlauer... der websocket geht offenbar tatsächlich auf /, aber mit: "wss://<domain>:8080/" und z.B. main.js - da ist nichts mehr mit /visu/ oder /admin/.

Ganz konkret: Wie kann man in nginx erreichen, dass der proxy_pass nur mit einem validen edomi-websocket Aufruf ausgeführt und nicht mehr mit einem non-websocket Aufruf? --> alles außer wss:// auf Port 8080 mit return 444 bentworten (und damit nie edomi erreicht)

Das dürfte die grundlegende Lösung für das gesamte Problem hier sein...

[saegefisch]

Es ließ mir keine Ruhe... aber dafür etwas dazu gelernt und nun die finale Lösung...

Mit den gestrigen Erkenntnissen, die aus der Vermutung nun die klare Ursache aufzeigten (Portscans unbekannter URL), funktioniert folgende Lösung nun nachweislich für einen NGINX ReverseProxy:

• Einbau gestern beschriebener GeoIP-Filterung auf IP aus Positiv-Länderliste ist sicher grundsätzlich sinnvoll, aber optional. Ich belasse den Filter weiter aktiv.
• In der nginx-conf im server-Abschnitt in dieser Reihenfolge(!)

[...]
server {
listen 8080 ssl http2;
listen [::]:8080 ssl http2;
server_name "" "_";
return 444;
}

server {
listen 8080 ssl http2;
listen [::]:8080 ssl http2;

if ($allowed_country = no) {
return 444;
}

server_name <deine domain oder subdomain>;

location / {
proxy_pass http://websocket;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
[...]

Damit werden alle Zugriff auf Port 8080 ohne host-Namen per return 444 abgeblockt. Nur die Requests mit korrekter Domain kommen zum websocket und damit zu edomi durch. Einzig, wenn jemand edomi-Domain + Port kennt, käme er da noch (soweit wie bisher) durch - eher unwahrscheinlich für Wald&Wiesen-Portscans "ins Blaue".

Test per nmap.

ACHTUNG: nmap ist KEIN Spielzeug und darf nur auf IP-Adressen angewendet werden, die man selber kontrolliert oder dafür eine Erlaubnis hat! Alles andere ist mindestens im Graubereich oder gar illegal. Auch nicht "mal aus Neugier", sondern nur auf eigenen IPs zum Zwecke der Sicherheit!

Per ping oder dem DSL-Modem/FritzBox/whatever die aktuelle eigenen IP ermitteln. Dann damit

nmap -Pn -sV -p8080 <DEINEIP>

Vor obiger Änderung des RevProxy führt der Scann reproduzierbar zu den hier thematisierten Fehlern im edomi-Error-Log. Nach Einbau (und reload!) werden diese Zugriffe vom RevProxy zuverlässig abgeblockt, der reguläre Zugriff auf edomi über den RevProxy funktioniert dennoch weiter.