Firewall-Logs gehen über

Es gibt 20 Antworten in diesem Thema, welches 2.634 mal aufgerufen wurde. Der letzte Beitrag () ist von swag.

    Hallo,


    ich habe eine UDM (UniFi OS 3.1.16, Network 8.0.7) mit 4 VLANs und entsprechende Firewall-Regeln.


    Die wichtigsten davon für mein "Problem" sind folgende:


    TypeNameActionSourceDestinationMatch State
    LAN InAllow Established and Related
    		AcceptAnyAnyEstablished, Related
    LAN In
    		Drop invalid stateDropAnyAnyInvalid
    LAN InBlock inter-VLAN routingDropRFC1918RFC1918
    LAN LocalBlock IoT to GatewaysDropIoTAll Gateways except IoT
    LAN Local
    		Block IoT to UDM interfaceDropIoTIoT Gateway (80, 443, 22)


    Wenn ich mir unter System Log -> Triggers die Einträge ansehe, kommen dort minütlich welche dazu.


    Mein Raspberry Pi, die Google Nest Geräte und mein Wall Tablet (Amazon Fire) treffen ganze Zeit die zweite Firewall-Regel:


    Zudem ist mir aufgefallen, dass mein LG Fernseher regelmäßig versucht, auf das VLAN Gateway und die IP-Adresse 192.168.1.82 zuzugreifen. Ich habe allerdings kein Subnetz 192.168.1.x deklariert.


    Sind diese Einträge "normal" und haben die irgendwelche Auswirkungen auf Performance/Geschwindigkeit?


    Danke!

    Zum LG TV.

    Na ja Gateway erreichen will ja nun jeder. Die 192.168.1.82 zu erreichen will der LG weil er da was erwartet.

    Hattest du vorher mal 192.168.1.9/xx beim TV im Einsatz ? Ich denk da so an Remote, Soundbars, Streaming boxe,

    DNLA server von anderen Rechnern / NAs Boxen. Villeicht aber auch irgendeine default IP von LG bei der eine Config gezogen werden kann

    (für Hotel Mode, Whitebord, etc)


    Zu den Drop by Invalid:

    Invalid ist eigentlich wenn ein Packet nicht NEU, Relatet oder Establish ist. Das kann bei Laufenden Verbindungen vorkommen

    die dann „Gefiltert“ werden. In der Contrack Tabelle fehlt der Eintrag und dein Client versucht noch die Verbidung aufrecht zu erhalten.

    Der Spuck sollte von alleine sich legen kann aber je nach IP / TCP Dauer (ei default Wert sind da 30 min)

    Neustart ist da meist schneller...


    Ansonsten zeig her die Regeln, weil du kannst dich ja auch Verknackt haben...

    Zitat

    Hattest du vorher mal 192.168.1.9/xx beim TV im Einsatz ? Ich denk da so an Remote, Soundbars, Streaming boxe,

    DNLA server von anderen Rechnern / NAs Boxen. Villeicht aber auch irgendeine default IP von LG bei der eine Config gezogen werden kann

    (für Hotel Mode, Whitebord, etc)

    Ich hatte eigentlich nie ein 192.168.1.x Subnetz. Mein Default (trusted) ist 192.168.86.0/24.

    Vielleicht hilft die Information, dass während dieser Log-Einträge die Sky Q-App auf dem Fernseher lief.


    Übersicht


    Allow Established and Related



    Drop invalid state



    Block inter-VLAN routing



    Block IoT to gateways



    Block IoT to UDM interface




    Profile




    Einmal editiert, zuletzt von thebogeyman ()

    Habe die vor 2-3 Stunden auch mal bei mir eingefügt um zu sehen ob das ding sauber in die Iptables eingebaut wird.

    In den Letzen zwei Stunde habe ich dann auch 5 Einträge für „Invalide" Pakete. Alle mit dem ziel von typischen CDN Netzwerken

    wie Amazon, Akamai und Google Cloud. Alle an Port 443 also wahrscheinlich HTTPS.


    Der Rotz scheint mittlerweile normales Grundrauchen zu sein (ich werde alt) evt. Retrasmissions, die aber schon in der

    Contrack Tabelle weg sind. Altes aufgefahren einer SSL Webseite die noch nen altes Paket verschicken will.

    oder Mehrfach verschickt ( in den log sehe ich mindestens 2 Versuche fast zeitgleich)


    Würde (für mich eh unsinnig weilLAN) regeln rauswerfen oder zumindestens Stumm Schalten.

    Im Lan würde ich fast sagen beide sind unnötig, oder denkst du das HACKER Geräte bei dir im LAN ?

    Zumindestens die DROP würde ich ganz Rauschmeißen.


    Bin in den letzen Minuten schlauer geworden:


    Zwei Pakete, gleiche Sequenznummer, gleicher Absender, gleicher ziel Port.

    Das erste ging durch und enthält ein „FIN/ACK“ um die Verbindung zu beenden.

    Offensichtlich ist es grade bei Webroswer / Servern und CO gang und gebe da gleich ein RST

    hinunterzuschicken. Damit werden ein wenig Zeit gesparrt und stammt noch aus jüngeren tagen.


    Sprich in Grunde kann es nur Helfen diese Paket ausgehend zu erlauben.



    Ok, danke schon mal für die Hilfe und Erklärung!

    Das "Drop invalid state" hab ich jetzt mal rausgenommen.


    Bliebe für mich nur mehr die Frage, warum mein Fernseher so oft das Gateway ansteuern will und was es mit der 192.168.1.82 auf sich hat.

    Was mir aber gerade aufgefallen ist: Die "Block IoT to UDM interface" Regel sollte ja nur für die Ports 80, 443 und 22 gelten, da ich nicht will, dass ein Gerät innerhalb des Netzwerkes auf das Router-Interface kommt. Im Log stehen bei den Port-Infos unterschiedliche 5-stellige Nummern, die mit 3 beginnen (36604, 36696, 36804, ...). Sollte das überhaupt geblockt werden?


    Und warum macht das nur der Fernseher und keine anderes Gerät im IoT Netzwerk?


    BTW, ich habe mich beim Einrichten der Firewall-Regeln an diesem Guide orientiert, wo alle meine Regeln dabei sind (auch das "Drop invalid state"): https://lazyadmin.nl/home-network/unifi-vlan-configuration

    Die Erklärung zu der "Drop invalid state" Regel vom Autor ist folgende:

    Zitat

    The firewall not only blocks strange or messed-up packets but also rejects any packets that don’t belong to an ongoing conversation. Think of it like this: if you were getting a file, and the transfer finished, the connection would close. So, if the server sends more data after that, the firewall sees it as odd because there’s no active talk going on. To be safe, it’s smart to have these rules to stop any weird attempts from a compromised device.

    2 Mal editiert, zuletzt von thebogeyman ()

    Zitat von thebogeyman

    . Im Log stehen bei den Port-Infos unterschiedliche 5-stellige Nummern, die mit 3 beginnen (36604, 36696, 36804, ...). Sollte das überhaupt geblockt werden?

    Die Logs sind „doof", das sind die QuellPorts drinnen. Die sind bei tcp immer zufällig von 1024-65535

    auf der UDM-SE (3.2.x, 8.0.x) gibt es in

    /var/log/ulog/syslogemu.log da stehen alle Infomationen drinnen. Hier ein Beispiel mit Farbigen Ports


    cat syslogemu.log | grep 2582215435

    Nov 30 11:43:44 Lisa [LAN_IN-D-20000] DESCR="Block" IN=br50 OUT=ppp0 MAC=d4:XX:f9:XX:XX:e5:00:1c:c2:48:XX:53:XX:00 SRC=10.0.50.156 DST=104.21.7x.xx LEN=40 TOS=00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=62806 DPT=443 SEQ=2582215435 ACK=0 WINDOW=0 RST URGP=0 MARK=0


    Zitat von thebogeyman

    warum mein Fernseher so oft das Gateway ansteuern will u

    Na ja Gateway is klar. Will woanders hin aus dem eignen Netz/ Ipkreis und das geht nur über ein Gateway.

    die 192.168.1.82 die er versucht zu erreichen ist dann aber seltsam, das stimmt.


    Irgendwas auf dem TC wird schon sein, und wenns wie gesagt irgendein ein ein default kram ist.

    Du könntest in die Log schauen zu welchen Port das Paket will. Oder nen Trace machen und reinschauen

    was das genau sein könnte.

    Ok, danke, ich werde das mal verfolgen und bei Gelegenheit versuchen, mitzuloggen.

    Außerdem würde mich selbst auch interessieren, ob das nur bei Verwendung der Sky Q App auftritt, oder generell wenn der Fernseher läuft.

    Kann ich leider erst am Abend prüfen.

    Zitat von thebogeyman

    Ok, danke, ich werde das mal verfolgen und bei Gelegenheit versuchen, mitzuloggen.

    Außerdem würde mich selbst auch interessieren, ob das nur bei Verwendung der Sky Q App auftritt, oder generell wenn der Fernseher läuft.

    Kann ich leider erst am Abend prüfen.

    LIegt nicht nur an Sky Q. Habe gestern die Meldungen auch ohne die App bekommen und habe dann versucht, alles mögliche, was potentiell nach außen kommunizieren könnte, am Fernseher abzudrehen (ein IOT Gerät war tatsächlich im Dashboard eingetragen). Hat aber nichts gebracht.

    Einmal editiert, zuletzt von razor () aus folgendem Grund: Ein Beitrag von thebogeyman mit diesem Beitrag zusammengefügt.

    So, ich hab das jetzt mit den Logs hinbekommen. Man muss das Logging explizit bei den entsprechenden Regeln aktivieren, damit sie ins Syslog kommen:



    Zunächst mal zum "Block IoT to UDM interface":

    Source ist immer mein Fernseher, jedoch jedes zweite Mal ein anderer 5-stelliger Port (58494, 58498, 58592).

    Ziel ist das IoT Interface 192.168.20.1 auf Port 80


    Beim "Block inter-VLAN routing" siehts so aus:

    Source sind meistens mein Fernseher oder noch häufiger mein Google Nest Hub, wieder jedes zweite Mal ein anderer 5-stelliger Port.

    Ziel sind mein Nvidia Shield (welches im Trusted Network läuft) auf Port 9000 und diverse IP-Adressen im 192.168.1.x und 192.168.0.x Subnetz auf Port 80 (wobei ich nicht einmal ein 192.168.1.x bzw. 192.168.0.x Subnetz habe!?).

    Keine Ahnung was die kommunizieren wollen.

    Ich versuche mal rauszufinden, was Port 9000 auf dem Nvidia Shield ist.


    Außerdem frage ich mich gerade, warum ich das Nvidia Shield überhaupt ins Trusted Network habe und nicht ins IoT, aber ich denke, ich konnte damals auf mein NAS (im Trusted) nicht zugreifen. Vielleicht sollte ich das wieder ändern und eine entsprechende Firewall Regel anlegen.

    Nächstes Update!

    Ich hab jetzt das Nvidia Shield in mein IoT Netzwerk gehängt und ich weiß jetzt auch, warum ich es damals ins Trusted getan habe: Der Zugriff aufs NAS im Trusted ist ... sehr eigenartig. Das NAS wird als Netzwerkspeicher im Shield nicht gefunden, weil es in einem anderen Subnetz ist und ein manuelles hinzufügen funktioniert zwar, jedoch ist der Speicher nach einem Neustart wieder weg und ich muss es händisch neu verbinden.

    Aber egal, ich lasse das jetzt erst mal so bis es mir zu blöd wird.

    Damit können mein Google Nest und der TV mit dem Nvidia Shield kommunizieren. Ich habe zwar keinen Plan, was die miteinander reden, aber stört mich jetzt auch nicht sonderlich, somit sind diese Meldungen mal weg.


    Übrig bleiben damit nur mehr 2 Meldungen:

    TV was blocked from accessing 192.168.1.82 by firewall rule: Block inter-VLAN routing
    TV was blocked from accessing 192.168.20.1 by firewall rule: Block IoT to UDM interface


    Beim ersten sind wir uns einig: Keine Ahnung, warum der TV auf diese IP zugreifen will, obwohl es das Gerät nicht gibt.


    Aber der zweite erschließt sich mir auch nicht ganz: Warum will der TV auf die Gateway IP auf Port 80? Kein anderes Gerät will das! Und genau das will ich ja verhindern: Ein IoT Gerät soll nicht auf die Website des Gateways (was übrigens mein Router Interface ist) kommen.

    Kanns sein, dass der TV tatsächlich dubiose Sachen versucht? Ich muss dazu sagen, dass der gerootet und webOS Homebrew installiert ist.

    Zitat von thebogeyman

    Aber der zweite erschließt sich mir auch nicht ganz: Warum will der TV auf die Gateway IP auf Port 80? Kein anderes Gerät will das! Und genau das will ich ja verhindern: Ein IoT Gerät soll nicht auf die Website des Gateways (was übrigens mein Router Interface ist) kommen.

    Kanns sein, dass der TV tatsächlich dubiose Sachen versucht? Ich muss dazu sagen, dass der gerootet und webOS Homebrew installiert ist.


    Selber gebaut oder „Dubiose Quellen“, also was genau hast du dir draufgespielt ?

    Villeicht was Dubioses, villeicht nur ein „AHHH der Router ist da weil ich erreiche Port 80“ (was wenig sinnt macht)

    oder ein Oh wenn das Router y ist dann können wir Statistiken dafür holen.

    Gefühlt fällt das dann auch in die gleiche kerbe wie "192.168.1.82„


    sont halt mit tcpdump nen trace von TV machen und mit wierscahrk auswerten...Port80 klingt erstmal

    unverschlüsselt, da würde man das GET sehen und was der TV genau zu erreichen..


    also sowas wie tcpdump -i br0 host xxx.xx.xxx.xx -w meintrace.pcap


    (xx = IP von TC, das br0 = VLAN1 das ggf auftauchen gegen das brxx interface fürs richtige VLAN)

    Puh, das war jetzt kompliziert (für mich zumindest), aber ich hab mal einen Dump, den ich in Wireshark ansehen kann.

    Leider kenn ich mich damit überhaupt nicht aus. Es fallen mir aber zumindest mal folgende Einträge ins Auge (solche ähnlichen gibts noch mehrere):





    Kannst du damit schon was anfangen oder würdest du eher die ganzen Paket-Details benötigen?

    Ich würde ja am liebsten den kompletten Dump posten bzw. dir schicken, allerdings ist mir das relativ unsicher, weil ich nicht weiß, was da alles drinnen steht und nicht für die Öffentlichkeit bestimmt ist.

    Zitat von swag

    Nur eine mögliche Variante aber falls Du ein Gerät mit dieser ip im Netz hast könnte die Adresse per multicast DNS an Deinen LG bekannt gemacht werden (auch wenn er sie gar nicht erreichen kann) ZeroConfig sei Dank

    Die eine Adresse (192.168.20.1), die ständig gepingt wird, ist ja das Gateway vom entsprechenden VLAN und die andere Adresse (192.168.1.82) gibt es nicht ... nicht einmal das Subnetz dazu