Unbekannten Traffic v. WebCams blockieren

Micky008

Hallo Grimson,

erstmal vielen Dank für deine Geduld und Unterstützung. Die o.g. Logs aus dem PacketCapture habe ich auf der LAN-Schnittstelle gemacht.

Sobald die Kamera gestartet wird erscheint folgender Eintrag bei den States:


LANSCHNITTSTELLE 	tcp 	192.168.XX.225:2048 -> 127.0.0.1:3128 (54.219.236.25:80) 	TIME_WAIT:TIME_WAIT 	5 / 5 	398 B / 531 B

Wenn ich die Kamera vom Strom nehme, wird der States Eintrag sofort wieder entfernt.

Die Fritzbox an der LAN-Schnittstelle macht kein NAT, wird nur als LAN + WLAN-Accesspoint genutzt, sollte also hier nicht dazwischen funken können.

Ich habe zudem nochmal ein PacketCapture auf der WAN-Schnittstelle ausgeführt. Das Log ist leer, egal ob ich nach der IP Adresse der Kamera oder nach der o.g. 54.219.236.25 filtere….

Ich guck mir nochmal Squid an, vielleicht gibt es hier die Möglichkeit die IP zu blockieren. Hast du sonst noch eine Idee?

Grüße M.

EDIT: Squid-Logs (bestätigt meinen Verdacht bzgl. dem ungewollten DDNS Service)


14.10.2017 18:04:21	192.168.XX.225/192.168.XX.225	http://54.219.236.25/api/userip.asp?username=XXXXXXX&userpwd=XXXXXXXX&vertype=910&language=0&dtype=0&tcpport=80&lanip=192.168.XX.225	Request(default/in-addr/-) - GET REDIRECT

Grimson

@Micky008:

Hallo Grimson,

erstmal vielen Dank für deine Geduld und Unterstützung. Die o.g. Logs aus dem PacketCapture habe ich auf der LAN-Schnittstelle gemacht.

Sobald die Kamera gestartet wird erscheint folgender Eintrag bei den States:
LANSCHNITTSTELLE 	tcp 	192.168.XX.225:2048 -> 127.0.0.1:3128 (54.219.236.25:80) 	TIME_WAIT:TIME_WAIT 	5 / 5 	398 B / 531 B
Wenn ich die Kamera vom Strom nehme, wird der States Eintrag sofort wieder entfernt.

Die Fritzbox an der LAN-Schnittstelle macht kein NAT, wird nur als LAN + WLAN-Accesspoint genutzt, sollte also hier nicht dazwischen funken können.

Ich habe zudem nochmal ein PacketCapture auf der WAN-Schnittstelle ausgeführt. Das Log ist leer, egal ob ich nach der IP Adresse der Kamera oder nach der o.g. 54.219.236.25 filtere….

Das sieht doch schon mal gut aus, dann verlässt der Traffic anscheinend die pfSense nicht. Ich habe noch nicht mit squid gearbeitet, aber ich könnte mir vorstellen dass das Antwort Packet auf der LAN Schnittstelle von squid kommt und nur eine entsprechende Fehlermeldung ist, schau dir doch einmal den Inhalt des Packetes an.

@Micky008:


14.10.2017 18:04:21	192.168.XX.225/192.168.XX.225	http://54.219.236.25/api/userip.asp?username=XXXXXXX&userpwd=XXXXXXXX&vertype=910&language=0&dtype=0&tcpport=80&lanip=192.168.XX.225	Request(default/in-addr/-) - GET REDIRECT

Mach doch einfach mal einen simplen Test pack einen deiner PCs in den Webcams Alias mit rein (nicht vergessen die States nach dem Neuladen der Filter zurück zu setzen), versuche die obige URL zu erreichen und schau was dabei raus kommt.

Was ich mir noch vorstellen könnte, mit einem Proxy auf der Firewall, ist das durch die Anti-Lockout Regel Zugriffe auf Port 80 später nicht mehr geblockt werden können. Da diese Regel die Zugriffe ja schon zulässt. Solltest du also mit obigem Test auf die Webseite durchkommen kannst du ja mal probieren die WebUI von der pfSense auf z.B. Port 88 oder 8080 zu legen, das müsste die Regel mit anpassen.

Micky008

Mhmm, ich denke schon dass der Traffic raus geht… lt. PacketCapture kommt ja auch was von der uminösen IP zurück. Das mit dem zusätzlichen Client in den Alias werde ich morgen ausprobieren, heut schaff ich es leider nicht mehr.

Grimson

Du kannst auch mal die pf Regeln im ganzen posten, bitte auf pastebin o.ä. und dann nen Link, nicht direkt hier ins Forum: https://doc.pfsense.org/index.php/How_can_I_see_the_full_PF_ruleset

Eigentlich sollten die Umleitungsregeln für squid erst nach den Benutzer Regeln auftauchen, wenn sie davor auftauchen ist das ein Bug.

Micky008

Hallo Grimson,

hatte in den letzten Tagen aus familiären Gründen leider "Land Unter". Sorry, dass ich erst jetzt antworte. Ich habe mir die Rules angeschaut, soweit ich das erkennen kann stehen auch die Squid Regeln unter den Nutzer Regeln.

Diese stehen hier am Ende:


...
block drop in quick on igb0 inet from any to 54.219.236.25 label "USER_RULE: Traffic auf WansView DDNS verhindern"
...
pass in quick on igb0 proto tcp from any to (igb0) port = 3128 flags S/SA keep state
pass in quick on igb2_vlan200 proto tcp from any to (igb2_vlan200) port = 3128 flags S/SA keep state
pass in quick on lo0 proto tcp from any to (lo0) port = 3128 flags S/SA keep state
pass in quick on igb0 proto tcp from any to (igb0) port = 3129 flags S/SA keep state
pass in quick on igb2_vlan200 proto tcp from any to (igb2_vlan200) port = 3129 flags S/SA keep state
pass in quick on lo0 proto tcp from any to (lo0) port = 3129 flags S/SA keep state

Unter States finde ich nur den folgenden Eintrag, welche einen Bezug auf die WebCam haben:


igb0 tcp 127.0.0.1:3128 (54.219.236.25:80) <- 192.168.XX.225:2054       TIME_WAIT:TIME_WAIT

Die Blockregel auf die ominöse IP habe ich ich via any von allen Geräten aus LAN net versucht. Dennoch kann ich die IP erreichen.

Hab auch unter Squid keine Möglichkeit gefunden diese IP zu blockieren.

LG Micky

Grimson

Die ganzen Regeln wären hilfreich, nicht nur ein Ausschnitt davon.

Micky008

Kann ich dir die Rules auch anderweitig zur Verfügung stellen?

Grimson

Nope, I halte Security through obscurity für absoluten Schwachsinn und unterstütze es in keiner Form.

Mit den lokalen IP Adressen kann von außen keiner was anfangen, und wenn jemand an der Firewall vorbei ist hast du so oder so verloren.

Micky008

ok, trotzdem Danke für deine Hilfe.

Grüße M.

Micky008

Hallo und Guten Morgen,

habe nun einen funktionierenden Weg gefunden den unerwünschten Traffic zu verhindern. Und zwar nutze ich Domain Overrides des DNS Resolvers um die Domän nwsvr.com auf 127.0.0.1 umzulenken.

Somit können die WebCams nun nicht mehr den WansView DDNS Server erreichen. Ganz lieben Dank an alle die mit nach einer Lösung gesucht haben.

Grüße M.