Unbekannten Traffic v. WebCams blockieren
-
Der Alias steht für DNS (53) und SMTP (25).
Edit1: Habe die Regeln zum Blocken des SamsungTV´s entfernt, damit die Übersicht besser gegeben ist und den Screenshot neu hochgeladen. Die Counter funktionieren, waren auf dem 1. ursprünglichen Screenshots durch Reboot erst resettet worden.
EDIT2: Bei mir läuft 2.3.4-RELEASE-p1 (amd64) auf einer apu2c4.
-
Hier nochmal der Traffic mit höherem Loglevel:
19:42:03.511933 7c:XX:XX:XX:7b:5d > 00:XX:b9:XX:XX:18, ethertype IPv4 (0x0800), length 73: (tos 0x0, ttl 64, id 3506, offset 0, flags [DF], proto UDP (17), length 59)
192.168.XX.XXX.2050 > 192.168.55.1.53: [udp sum ok] 2+ A? www.nwsvr.com. (31)
19:42:04.252381 00:XX:b9:XX:XX:18 > 7c:XX:XX:XX:7b:5d, ethertype IPv4 (0x0800), length 89: (tos 0x0, ttl 64, id 46837, offset 0, flags [none], proto UDP (17), length 75)
192.168.XX.1.53 > 192.168.XX.XXX.2050: [bad udp cksum 0xf07b -> 0x8a8d!] 2 q: A? www.nwsvr.com. 1/0/0 www.nwsvr.com. A 54.219.236.25 (47)
19:42:04.256923 7c:XX:XX:XX:7b:5d > 00:XX:b9:XX:XX:18, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 3653, offset 0, flags, proto TCP (6), length 60)
192.168.XX.XXX.2048 > 54.219.236.25.80: Flags, cksum 0x09dc (correct), seq 49284027, win 1460, options [mss 1460,sackOK,TS val 3582 ecr 0,nop,wscale 0], length 0
19:42:04.257077 00:XX:b9:XX:XX:18 > 7c:XX:XX:XX:7b:5d, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 54243, offset 0, flags [DF], proto TCP (6), length 60)
54.219.236.25.80 > 192.168.XX.XXX.2048: Flags [S.], cksum 0x1bad (incorrect -> 0x3bee), seq 2302559599, ack 49284028, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 2918340636 ecr 3582], length 0
19:42:04.259769 7c:XX:XX:XX:7b:5d > 00:XX:b9:XX:XX:18, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 3654, offset 0, flags [DF], proto TCP (6), length 52)
192.168.XX.XXX.2048 > 54.219.236.25.80: Flags [.], cksum 0x63d3 (correct), seq 1, ack 1, win 1460, options [nop,nop,TS val 3582 ecr 2918340636], length 0
19:42:04.261833 7c:XX:XX:XX:7b:5d > 00:XX:b9:XX:XX:18, ethertype IPv4 (0x0800), length 196: (tos 0x0, ttl 63, id 3655, offset 0, flags [DF], proto TCP (6), length 182)
192.168.XX.XXX.2048 > 54.219.236.25.80: Flags [P.], cksum 0x859a (correct), seq 1:131, ack 1, win 1460, options [nop,nop,TS val 3582 ecr 2918340636], length 130
19:42:04.261933 00:XX:b9:XX:XX:18 > 7c:XX:XX:XX:7b:5d, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 42695, offset 0, flags [DF], proto TCP (6), length 52)
54.219.236.25.80 > 192.168.XX.XXX.2048: Flags [.], cksum 0x1ba5 (incorrect -> 0x66f9), seq 1, ack 131, win 519, options [nop,nop,TS val 2918340641 ecr 3582], length 0
19:42:04.296477 00:XX:b9:XX:XX:18 > 7c:XX:XX:XX:7b:5d, ethertype IPv4 (0x0800), length 297: (tos 0x0, ttl 64, id 8051, offset 0, flags [DF], proto TCP (6), length 283)
54.219.236.25.80 > 192.168.XX.XXX.2048: Flags [P.], cksum 0x1c8c (incorrect -> 0xf95e), seq 1:232, ack 131, win 520, options [nop,nop,TS val 2918340676 ecr 3582], length 231
19:42:04.296593 00:XX:b9:XX:XX:18 > 7c:XX:XX:XX:7b:5d, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 60195, offset 0, flags [DF], proto TCP (6), length 84)
54.219.236.25.80 > 192.168.XX.XXX.2048: Flags [P.], cksum 0x1bc5 (incorrect -> 0x7e5e), seq 232:264, ack 131, win 520, options [nop,nop,TS val 2918340676 ecr 3582], length 32
19:42:04.297005 00:XX:b9:XX:XX:18 > 7c:XX:XX:XX:7b:5d, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 28381, offset 0, flags [DF], proto TCP (6), length 52)
54.219.236.25.80 > 192.168.XX.XXX.2048: Flags [F.], cksum 0x1ba5 (incorrect -> 0x65cd), seq 264, ack 131, win 520, options [nop,nop,TS val 2918340676 ecr 3582], length 0
19:42:04.299499 7c:XX:XX:XX:7b:5d > 00:XX:b9:XX:XX:18, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 3656, offset 0, flags [DF], proto TCP (6), length 52)
192.168.XX.XXX.2048 > 54.219.236.25.80: Flags [.], cksum 0x623e (correct), seq 131, ack 232, win 1460, options [nop,nop,TS val 3586 ecr 2918340676], length 0
19:42:04.301701 XX:XX:XX:07:7b:XX > 00:XX:b9:XX:XX:18, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 3657, offset 0, flags [DF], proto TCP (6), length 52)
192.168.XX.XXX.2048 > 54.219.236.25.80: Flags [R.], cksum 0x6219 (correct), seq 131, ack 265, win 1460, options [nop,nop,TS val 3586 ecr 2918340676], length 0
19:42:04.308975 XX:XX:XX:07:7b:XX > 00:XX:b9:XX:XX:18, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 64, id 3587, offset 0, flags [DF], proto UDP (17), length 76)
192.168.XX.XXX.2050 > 192.168.XX.1.123: [udp sum ok] NTPv3, length 48
Client, Leap indicator: (0), Stratum 0 (unspecified), poll 4 (16s), precision -6
Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 2208988835.870000004 (1970/01/01 01:00:35)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 2208988835.870000004 (1970/01/01 01:00:35)
19:42:04.309376 00:XX:b9:XX:XX:18 > XX:XX:XX:07:7b:XX, ethertype IPv4 (0x0800), length 90: (tos 0xb8, ttl 64, id 26535, offset 0, flags [none], proto UDP (17), length 76)
192.168.XX.1.123 > 192.168.XX.XXX.2050: [bad udp cksum 0xf07c -> 0x3043!] NTPv3, length 48
Server, Leap indicator: (0), Stratum 2 (secondary reference), poll 4 (16s), precision -22
Root Delay: 0.027709, Root dispersion: 0.029968, Reference-ID: 131.188.3.221
Reference Timestamp: 3716731523.875041961 (2017/10/11 19:25:23)
Originator Timestamp: 2208988835.870000004 (1970/01/01 01:00:35)
Receive Timestamp: 3716732524.309091806 (2017/10/11 19:42:04)
Transmit Timestamp: 3716732524.309249043 (2017/10/11 19:42:04)
Originator - Receive Timestamp: +1507743688.439091801
Originator - Transmit Timestamp: +1507743688.439249038 -
Nabend @all,
mittlerweile habe ich weitere Versuche gestartet eine funktionierende Blockregel im LAN-Interface und auch alternativ per Floating auf diese IP zu legen. Leider weiterhin ohne Erfolg. Gibt es denn keine Möglichkeiten sämtlichen Netzwerkverkehr auf diese externe IP zu verhindern. Auch eine globale Regel, welchen allen meinen Netzwerkgeräten die Kommunikation mit dieser IP verhindert wäre ok. Nur leider komme ich hier nicht weiter…. Hat jemand eine Idee für mich parat?
Grüße M.
-
-
Guten Morgen
Was passiert denn wenn statt dem Alias in der "Block unknown Traffic rule" einfach allen (*) statt nur den "Webcams" der Traffic verboten wird?
Und nur um sicherzugehen. Wie sieht der Alias für "Webcams" aus?
-
Gibt es denn keine Möglichkeiten sämtlichen Netzwerkverkehr auf diese externe IP zu verhindern
Natürlich mit einer normalen Blockregel. Warum deine nicht greifen kann man aber leider nicht ohne weiteres sagen, wenn du zusätzlich auch noch Floating Regeln bastelst und die Aliase nicht einsehbar sind :)
-
Nabend @all,
danke für eure Antworten, war heut den ganzen Tag unterwegs daher erst jetzt die Antworten:
@flo: upnp ist deaktiviert
@hbauer: eine screenshot von dem alias webcams habe ich angehängt
@JeGr: Screenshot vom Alias habe ich beigefügt, Floating war nur ein Test, habe ich wieder entfernt / die aktuellen LAN-Rules habe ich per Screenshot ebenfalls angehängtIch habe direkt hinter der allgemeinen Blockregel für IPv6 eine weitere Regel erstellt, die von sämtlichen Quellen jeglichen Traffic auf die o.g. IP blockt.
Block: LAN-Schnittstelle - IPv4 - Protocol any - Source any –> Destination Host 54.219.236.25
Auch diese greift leider nicht. Scheinbar stellt die Kamera eine Verbindung zum Hersteller als DDNS Service her. In der WebConfig der Kamera ist alles deaktiviert, daher wollte ich die Verbindungen via pfsense verhindern.
-
Wenn diese Block Regel nicht zieht dann scheint es nicht an dem Alias liegen.
Gibt es vielleicht noch eine Interface Gruppe mit einer Regel?
-
Hallo hbauer,
es gibt auf OPT1 (ETH2) das VLAN1 und VLAN200. Hier sind aber keine Regeln bzgl. der WebCams angelegt, da diese nur via LAN angebunden sind. Floating-Rules habe ich keine definiert.
Mhmm, steh leider nachwievor völlig auf dem Schlauch und bin über jede Hilfe dankbar.
-
Die States hast du aber zurückgesetzt nachdem du die Regel aktiviert hast?
-
Nein, States habe ich bisher nicht zurückgesetzt. War bei allen anderen Regeln bisher auch nicht notwendig.
-
Nein, States habe ich bisher nicht zurückgesetzt. War bei allen anderen Regeln bisher auch nicht notwendig.
Na dann tu das mal, so lange ein State für die Verbindung besteht hat die Regel keine Auswirkungen, da die Regeln nur für das erstellen von States angewendet werden.
-
unter Diagnostics -> States -> Reset States, oder?
-
unter Diagnostics -> States -> Reset States, oder?
Ja. Wenn das nicht hilft beschreibe deinen Netzwerk mal ganz genau, inkl. aller Regeln die du erstellt hast. Sonst raten wir hier nur im Dunkeln weiter.
-
Habe die States zurückgesetzt, der Traffic per PacketCapture zeigt noch immer die Verbindung zur genannten IP an. Mein Netzwerk ist folgendermaßen aufgebaut:
VodafoneCable via FritzBox 6490 Cable –> pfsense WAN (eth0) -> LAN (eth1) + OPT1 (eth2)
OPT1 stellt 2 VLAN´s zur Verfügung, welche keinerlei Zugriff auf LAN/WAN haben. Habe der Einfachheit OPT1 vorrübergehend deaktiviert. An LAN (eth1) hängt eine fritzbox 7490 welche allen Geräten per Ethernet/WLAN den Zugang zum LAN-Netzwerk ermöglicht. Squid läuft zudem als transparenter Proxy.
Die besagten WebCams sind 2 Wansview Kameras, weiterhin sind im LAN ne handvoll Notebooks, Handy´s, raspberry pi´s ....
auf WAN Seite gibt es nur 1 Regel für die PortWeiterleitung f. den OpenVPN Server, welcher auf einem meiner pi´s läuft.
Die LAN-Regeln habe ich im vorletzten Post per Screenshot angehongen. Falls du weitere Infos benötigst stelle ich die gern zur Verfügung.
EDIT: Ich habe testweise die u.g. IP mal mit einer anderen getauscht. Vorher konnte ich das Ziel anpingen, nach dem Ändern der IP und dem Reset der States konnte die Test-IP nicht mehr angepingt werden. Ansich scheint die Regel daher zu funktionieren, die Frage ist nur warum die Cam nachwievor mit dieser u.g. IP kommunizieren kann...
-
Schau dir mal die States der Cam an, ist da einer für die Ziel IP dabei? Wenn machst du das PacketCapture, wenn am LAN Interface dann überprüfe bitte auch ob es am WAN Interface weitergeht. Die Fritzbox am LAN macht aber hoffentlich kein NAT.
-
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 BWenn 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 -
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 BWenn 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.
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 REDIRECTMach 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.
-
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.
-
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.
