8
Plötzlich bestehende TCP-Verbindung trotz Blacklist , FW-Regel und nicht bedienter Source-Adresse !
Hallo zusammen ...
... seit ein paar Tagen blinkt immer wieder ein "Phänomen"auf, welches ich mir mal erklären lassen möchte.Denn ich komm nicht drauf ... wie bzw warum.
Es geht um um eine stätig(dynamisch) wiederkehrende Verbindungen an eine unterschiedliche Dst.-IP-Adresse die zwar zu meiner meiner Netze gehört, aber nicht von meinem Server vergeben wird bzw. wurde oder sich hinter meinen WAN befindet mit einem Interface befindet.Ist also in keinem meiner Pools hinterlegt.
Mein Server macht kein NAT ... verteilt also Externe IP´s an das User-Endgeräte-WAN-Interface(über PPPOE-Server).Alle aktiven Verbindungen sind in einem anderen IP-Pool.Ich nutze auch ein Transfernetz.
Weiterhin filtere ich über mein WAN einiges ... welches ich entweder droppe oder zurückweise.
Trotzdem wird einen Verbindung aufgebaut (TCP established) an unterschiedlichsten Ports an die (dynamische)Dst.-Adresse obwohl diese nicht existieren "sollte". Die Scr-Adresse(124.65.231.98) befindet sich auch in der Blacklist. Die Dst- Adresse(n) ist/sind nicht "vorhanden" ... jedenfalls nicht hinter meinem WAN. Diese ist zwar in einem meiner beiden /24 - Netze ... wird aber nicht genutzt und ist auch gar nicht eingepflegt.
Auch wenn keine Daten gesendet bzw. empfangen werden ... dürfte doch die "Verbindung" gar nicht bestehen oder irre ich da?
In diesem Fall verwerfe ich die Weiterleitung durch mein WAN-Interface und zusätzlich auch noch ein Drop an Input an das WAN-Interface direkt.
Aber trotzdem steht die Verbindung ! Warum ... oder wo liegt das "Problem" . Liegt es an der Zuordnung zum GW ... da ja im Transfernetz diese IP aus diesem Bereich ... meinem GW zu geordnet ist?
Wenn noch nähere Infos benötigt werden ... arbeite ich gern zu.
Vielleicht auch Quatsch sich damit zu befassen.Da ja nichts versendet wird! Sollte das so sein ... einfach euren Eindruck zuwerfen!
Danke
... seit ein paar Tagen blinkt immer wieder ein "Phänomen"auf, welches ich mir mal erklären lassen möchte.Denn ich komm nicht drauf ... wie bzw warum.
Es geht um um eine stätig(dynamisch) wiederkehrende Verbindungen an eine unterschiedliche Dst.-IP-Adresse die zwar zu meiner meiner Netze gehört, aber nicht von meinem Server vergeben wird bzw. wurde oder sich hinter meinen WAN befindet mit einem Interface befindet.Ist also in keinem meiner Pools hinterlegt.
Mein Server macht kein NAT ... verteilt also Externe IP´s an das User-Endgeräte-WAN-Interface(über PPPOE-Server).Alle aktiven Verbindungen sind in einem anderen IP-Pool.Ich nutze auch ein Transfernetz.
Weiterhin filtere ich über mein WAN einiges ... welches ich entweder droppe oder zurückweise.
Trotzdem wird einen Verbindung aufgebaut (TCP established) an unterschiedlichsten Ports an die (dynamische)Dst.-Adresse obwohl diese nicht existieren "sollte". Die Scr-Adresse(124.65.231.98) befindet sich auch in der Blacklist. Die Dst- Adresse(n) ist/sind nicht "vorhanden" ... jedenfalls nicht hinter meinem WAN. Diese ist zwar in einem meiner beiden /24 - Netze ... wird aber nicht genutzt und ist auch gar nicht eingepflegt.
Auch wenn keine Daten gesendet bzw. empfangen werden ... dürfte doch die "Verbindung" gar nicht bestehen oder irre ich da?
In diesem Fall verwerfe ich die Weiterleitung durch mein WAN-Interface und zusätzlich auch noch ein Drop an Input an das WAN-Interface direkt.
Aber trotzdem steht die Verbindung ! Warum ... oder wo liegt das "Problem" . Liegt es an der Zuordnung zum GW ... da ja im Transfernetz diese IP aus diesem Bereich ... meinem GW zu geordnet ist?
Wenn noch nähere Infos benötigt werden ... arbeite ich gern zu.
Vielleicht auch Quatsch sich damit zu befassen.Da ja nichts versendet wird! Sollte das so sein ... einfach euren Eindruck zuwerfen!
Danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 359914
Url: https://administrator.de/forum/ploetzlich-bestehende-tcp-verbindung-trotz-blacklist-fw-regel-und-nicht-bedienter-source-adresse-359914.html
Ausgedruckt am: 23.12.2024 um 01:12 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
Eigentlich gehoert die IP 124.65.231.98 nach China(CHINA169-BJ China Unicom Beijing Province Network, CN).
Was Du aus dieser Information machst, ist Dein Ding. Ich persoenlich wuerde die "wilde Hilde" auf alle Geraete im Netzwerk loslassen, wenn nicht zufaellig die IP oder das Netz von mir selbst vergeben wurde.
BFF
Eigentlich gehoert die IP 124.65.231.98 nach China(CHINA169-BJ China Unicom Beijing Province Network, CN).
Was Du aus dieser Information machst, ist Dein Ding. Ich persoenlich wuerde die "wilde Hilde" auf alle Geraete im Netzwerk loslassen, wenn nicht zufaellig die IP oder das Netz von mir selbst vergeben wurde.
BFF
...woher bzw. wohin die IP gehört ist schon klar. Aber warum kann sie eine Verbindung aufbauen, obwohl diese in einer Blacklist ist!
Und an deinem persönlichen "loslassen" würdest du nicht mehr festhalten, wenn du Funkstrecken hättest, wo jedes Paket ,welches eh nicht gewollt
ist, als Last zu erkennen ist. Warum soll ich bitte Port Anfragen "durchbringen" ... die eh nicht bedient werden, weil das Userinterface den Port nicht
hat bzw. die gleiche Scr-Adresse alles "anlabert" ... egal ob UP oder Down ..., was ihm vor das Interface kommt. Darum gehen diese Adressen ja auch in die Blackliste ! Denn dafür gibt es diese ja. Sonst könnte ich das komplette Netz nicht so schnell betreiben.
Hier sollte man vielleicht unterscheiden ... LAN oder LAN über WLAN .
Aber Danke trotzdem!
Und an deinem persönlichen "loslassen" würdest du nicht mehr festhalten, wenn du Funkstrecken hättest, wo jedes Paket ,welches eh nicht gewollt
ist, als Last zu erkennen ist. Warum soll ich bitte Port Anfragen "durchbringen" ... die eh nicht bedient werden, weil das Userinterface den Port nicht
hat bzw. die gleiche Scr-Adresse alles "anlabert" ... egal ob UP oder Down ..., was ihm vor das Interface kommt. Darum gehen diese Adressen ja auch in die Blackliste ! Denn dafür gibt es diese ja. Sonst könnte ich das komplette Netz nicht so schnell betreiben.
Hier sollte man vielleicht unterscheiden ... LAN oder LAN über WLAN .
Aber Danke trotzdem!
Aber Danke trotzdem!
Bitte!
Und an deinem persönliches "loslassen" würdest du nicht mehr festhalten, wenn du Funkstrecken hättest, wo jedes Paket ,welches eh nicht gewollt
Hast Du das irgendwo in Deiner Frage erwaehnt?
Und irgendwo da oben schreibst Du:
Es geht um um eine stätig(dynamisch) wiederkehrende Verbindung an eine IP-Adresse die zwar zu meiner meiner Netze gehört, aber nicht von meinem Server vergeben wird bzw. wurde oder sich hinter meinen WAN befindet mit einem Interface befindet.Ist also in keinem meiner Pools hinterlegt.
Deswegen die "wilde Hilde". Und damit meine ich nicht einen profanen Scan irgendwelcher HDD mit Drittanbieter-Software.
BFF
DANKE ... mein Fehler. Ganz klar! Ich hätte "Verbindungen" schreiben sollen UND , das es nicht nur eine SCR-Adresse gibt. Sorry nochmal.
Zeigt ja eigentlich klar das die Blacklist und die Firewall NICHT funktioniert.
Über das Warum kann man nur wild im freien Fall spekulieren ohne Details zu kennen.
Einen Eintrag in die Sessiontable zu bekommen bei entsprechenden korrekten Filterlisten ist unmöglich.
Jetzt mal einen Bug der Firewall/Router Firmware und Bedienungs- bzw. Konfig Fehler komplett ausgeschlossen.
Über das Warum kann man nur wild im freien Fall spekulieren ohne Details zu kennen.
Einen Eintrag in die Sessiontable zu bekommen bei entsprechenden korrekten Filterlisten ist unmöglich.
Jetzt mal einen Bug der Firewall/Router Firmware und Bedienungs- bzw. Konfig Fehler komplett ausgeschlossen.
... sehe ich auch so. Folgendes ist hinterlegt :
add action=drop chain=forward comment="Dropt IP aus Blacklist" in-interface=sfp1 src-address-list=Blacklist
´
Aufkommen momentan 2.3Gb (70Tage)
Aufgenommen werden diese über :
add action=add-src-to-address-list address-list=Blacklist address-list-timeout=30m chain=forward dst-address-list=ExternesNetz-DROP in-interface=sfp1 src-address-list="Blacklist-Versuch 3"
add action=add-src-to-address-list address-list="Blacklist-Versuch 3" address-list-timeout=30s chain=forward dst-address-list=ExternesNetz-DROP in-interface=sfp1 src-address-list="Blacklist-Versuch 2"
add action=add-src-to-address-list address-list="Blacklist-Versuch 2" address-list-timeout=20s chain=forward dst-address-list=ExternesNetz-DROP in-interface=sfp1 src-address-list="Blacklist-Versuch 1"
add action=add-src-to-address-list address-list="Blacklist-Versuch 1" address-list-timeout=10s chain=forward dst-address-list=ExternesNetz-DROP in-interface=sfp1 src-address-list=!Blacklist
Interface Sfp1 ist WAN. Alle anderen Sfp - Interface sind in einer Bridge. Welche vom Radius bedient wird.
Und genau die IP-Adresse die ich nicht bediene, nicht nutze oder eingepflegt habe ... befinden sich in der Liste "ExternesNetz-Drop.
Also alle SCR-Adressen , die sich an IP-Adresse wenden... die es eh nicht gibt(weil nicht verwendet) ... werde weitergereicht.
Je öffter sie sich "melden" ... desto weiter geht es nach oben ... bis sie schließlich in der Blacklist für 30min landen.
Wo könnte ich noch suchen ... denn an einem 2. Server (anderer Standort) läuft es sehr sauber und das über ein Jahr schon.
add action=drop chain=forward comment="Dropt IP aus Blacklist" in-interface=sfp1 src-address-list=Blacklist
´
Aufkommen momentan 2.3Gb (70Tage)
Aufgenommen werden diese über :
add action=add-src-to-address-list address-list=Blacklist address-list-timeout=30m chain=forward dst-address-list=ExternesNetz-DROP in-interface=sfp1 src-address-list="Blacklist-Versuch 3"
add action=add-src-to-address-list address-list="Blacklist-Versuch 3" address-list-timeout=30s chain=forward dst-address-list=ExternesNetz-DROP in-interface=sfp1 src-address-list="Blacklist-Versuch 2"
add action=add-src-to-address-list address-list="Blacklist-Versuch 2" address-list-timeout=20s chain=forward dst-address-list=ExternesNetz-DROP in-interface=sfp1 src-address-list="Blacklist-Versuch 1"
add action=add-src-to-address-list address-list="Blacklist-Versuch 1" address-list-timeout=10s chain=forward dst-address-list=ExternesNetz-DROP in-interface=sfp1 src-address-list=!Blacklist
Interface Sfp1 ist WAN. Alle anderen Sfp - Interface sind in einer Bridge. Welche vom Radius bedient wird.
Und genau die IP-Adresse die ich nicht bediene, nicht nutze oder eingepflegt habe ... befinden sich in der Liste "ExternesNetz-Drop.
Also alle SCR-Adressen , die sich an IP-Adresse wenden... die es eh nicht gibt(weil nicht verwendet) ... werde weitergereicht.
Je öffter sie sich "melden" ... desto weiter geht es nach oben ... bis sie schließlich in der Blacklist für 30min landen.
Wo könnte ich noch suchen ... denn an einem 2. Server (anderer Standort) läuft es sehr sauber und das über ein Jahr schon.
Hi!
Jetzt mal völlig ins Blaue... Einen Reboot der Firewall (welche überhaupt) hast du gemacht?
Aber schon mit einer standardmässigen default- Regel, die alles droppt, was nicht angefragt ist, sollten diese States nicht existieren, soweit mein Halbwissen reicht... Mit der Blacklist erst recht.
Bist du evtl. hinter einer dynamischen öffentlichen IP? Könnte es von daher sein, dass die Source-Adresse einfach nur nach einem IP-Wechsel versucht, ihren Counterpart noch bei dir zu erreichen, da ein Update im DNS fehlt?
Trotzdem: Ich verstehe dein Problem. Deine Firewall hat einen State zu einer IP die nicht existiert. Seltsam...
Buc
Jetzt mal völlig ins Blaue... Einen Reboot der Firewall (welche überhaupt) hast du gemacht?
Aber schon mit einer standardmässigen default- Regel, die alles droppt, was nicht angefragt ist, sollten diese States nicht existieren, soweit mein Halbwissen reicht... Mit der Blacklist erst recht.
Bist du evtl. hinter einer dynamischen öffentlichen IP? Könnte es von daher sein, dass die Source-Adresse einfach nur nach einem IP-Wechsel versucht, ihren Counterpart noch bei dir zu erreichen, da ein Update im DNS fehlt?
Trotzdem: Ich verstehe dein Problem. Deine Firewall hat einen State zu einer IP die nicht existiert. Seltsam...
Buc
... Guten Morgen Buc ...
ein klares "Nein". Die Server-IP am SFP1 ist statisch. Im Pool, zur Verteilung über den Radius liegt eine externes /23 Netz.
Aus diesem /23 Netz sind aber nicht alle vergeben ... vor allem nicht die, die ein Connect aufzeigt. Dst-Adresse ist xx.xxx.125.xx
und vergeben sind bisl mehr al 230 IPs aus mit xx.xxx.124.xxx. Mehr nicht !Bin also nicht im 125er !
Und ... die Scr-Adresse steht auch in der Blacklist!
ein klares "Nein". Die Server-IP am SFP1 ist statisch. Im Pool, zur Verteilung über den Radius liegt eine externes /23 Netz.
Aus diesem /23 Netz sind aber nicht alle vergeben ... vor allem nicht die, die ein Connect aufzeigt. Dst-Adresse ist xx.xxx.125.xx
und vergeben sind bisl mehr al 230 IPs aus mit xx.xxx.124.xxx. Mehr nicht !Bin also nicht im 125er !
Und ... die Scr-Adresse steht auch in der Blacklist!
