Hallo zusammen,
Ich stehe mal wieder vor einem kniffligen Problem und brauche eure Hilfe. Meine Securepoint-Firewall rejectet Pakete mit der Meldung "REJECT: IPBlockingList_Rejec", wie dieser Log-Eintrag zeigt:
Jun 10 11:30:21 firewall.wenzel-elektronik.com ulogd[9631] REJECT: IPBlockingList_Rejec IN=B1 OUT=wan0 MAC=00:07:32:7e:11:96:9c:05:d6:37:bb:d8:08:00 SRC=192.168.53.2 DST=9.9.9.9 LEN=61 TOS=00 PREC=0x00 TTL=62 ID=65466 PROTO=UDP SPT=53839 DPT=53 LEN=41 MARK=0
Das perfide daran: Dieses Verhalten betrifft alle Pakete, die auf dem B1-Adapter ankommen, was große Teile unseres WLANs lahmlegt.
Dieses Problem hatte ich bereits vor ein paar Wochen. Damals konnten wir es auch mit unserem Händler nicht lösen, und es verschwand nach etwa einer Woche von selbst. Da die Meldung explizit auf "IPBlockingList_Rejec" hinweist, schließe ich eigene Paketfilter so gut wie aus – unser Regelwerk ist überschaubar, und ein solcher Filter würde anders aussehen.
Mir fallen spontan zwei mögliche Ursachen ein: die "Systemweiten Sperrungen" oder Fail2Ban (beides unter "Anwendungen -> IDS/IPS"). Allerdings ist die betreffende IP-Adresse (192.168.53.2 in diesem Beispiel) in keiner dieser Listen enthalten. Ich gehe davon aus, dass Fail2Ban gesperrte IPs dort ebenfalls anzeigen würde.
Da dieser Fehler nun zum wiederholten Mal auftritt und den WLAN-Betrieb massiv stört, ist er extrem nervig. Hat jemand eine Idee, wo ich noch suchen könnte?
Danke, Kai
REJECT: IPBlockingList_Rejec
Moderator: Securepoint
Zur Ergänzung:
Die allmächtige KI ;-) gibt mir folgenden Hinweis auf das Problem
----
Cyber Defense Cloud (CDC) / Threat Intelligence Filter
Dies ist die wahrscheinlichste Ursache, wenn die IP nicht manuell gesperrt oder von Fail2Ban gebannt wurde. Die Securepoint-Firewall nutzt eine Cloud-basierte Datenbank bekannter Bedrohungen.
Wenn eine IP-Adresse, ob Quell- oder Ziel-IP, als bösartig (z.B. Botnet, Malware-Server, Spam-Quelle) eingestuft wird, blockiert die Securepoint die Verbindung.
----
Dieses halte ich für absolut wahrscheinlich. In meiner Verzweiflung habe ich jetzt (Firmware 14.x) in Anwendungen -> IDS/IPS -> Sperrungen -> Allgemein die IP 192.168.53.2 (als Test auch 192.168.53.0/24) eingetragen.
Jedoch hat es keinerlei Auswirkungen darauf das eingehende Verbindungen auf der B1 Schnittstelle blockiert werden. Völlig unerheblich was dort ankommt. Es wird DNS geblockt, ICMP wird geblockt und alles unter den Deckmantel: REJECT: IPBlockingList_Rejec
Wo in aller Welt kann ich bei Securepoint denn mal Anfragen ob es ein Problem in der Securepoint Cyber Defence Cloud gibt? Es kann doch nicht sein das sich ein Hersteller hinter Reseller versteckt und dadurch riskiert das der Endkunde unnatürlich lange auf
ein Problem sitzen bleibt, wenn dieser Reseller träge reagiert oder das Problem nicht richtig erfassen kann/will?
Gruß
Kai
Die allmächtige KI ;-) gibt mir folgenden Hinweis auf das Problem
----
Cyber Defense Cloud (CDC) / Threat Intelligence Filter
Dies ist die wahrscheinlichste Ursache, wenn die IP nicht manuell gesperrt oder von Fail2Ban gebannt wurde. Die Securepoint-Firewall nutzt eine Cloud-basierte Datenbank bekannter Bedrohungen.
Wenn eine IP-Adresse, ob Quell- oder Ziel-IP, als bösartig (z.B. Botnet, Malware-Server, Spam-Quelle) eingestuft wird, blockiert die Securepoint die Verbindung.
----
Dieses halte ich für absolut wahrscheinlich. In meiner Verzweiflung habe ich jetzt (Firmware 14.x) in Anwendungen -> IDS/IPS -> Sperrungen -> Allgemein die IP 192.168.53.2 (als Test auch 192.168.53.0/24) eingetragen.
Jedoch hat es keinerlei Auswirkungen darauf das eingehende Verbindungen auf der B1 Schnittstelle blockiert werden. Völlig unerheblich was dort ankommt. Es wird DNS geblockt, ICMP wird geblockt und alles unter den Deckmantel: REJECT: IPBlockingList_Rejec
Wo in aller Welt kann ich bei Securepoint denn mal Anfragen ob es ein Problem in der Securepoint Cyber Defence Cloud gibt? Es kann doch nicht sein das sich ein Hersteller hinter Reseller versteckt und dadurch riskiert das der Endkunde unnatürlich lange auf
ein Problem sitzen bleibt, wenn dieser Reseller träge reagiert oder das Problem nicht richtig erfassen kann/will?
Gruß
Kai
Moin,
ist auf der betroffenen UTM das GeoBlocking aktiviert? Das könnte auch eine Ursache sein.
Zum einen gibt es die status.secureoint.de wo Störungen reported werden.
Ansonsten gilt: Sind Sie mit dem Reseller nicht zufrieden können Sie wechseln.
Gruß
PS: Evtl. sollten Sie einmal den ersten Beitrag editieren und dort den Firewallnamen aus dem Log entfernen.....
ist auf der betroffenen UTM das GeoBlocking aktiviert? Das könnte auch eine Ursache sein.
Wo in aller Welt kann ich bei Securepoint denn mal Anfragen ob es ein Problem in der Securepoint Cyber Defence Cloud gibt? Es kann doch nicht sein das sich ein Hersteller hinter Reseller versteckt und dadurch riskiert das der Endkunde unnatürlich lange auf
ein Problem sitzen bleibt, wenn dieser Reseller träge reagiert oder das Problem nicht richtig erfassen kann/will?
Zum einen gibt es die status.secureoint.de wo Störungen reported werden.
Ansonsten gilt: Sind Sie mit dem Reseller nicht zufrieden können Sie wechseln.
Gruß
PS: Evtl. sollten Sie einmal den ersten Beitrag editieren und dort den Firewallnamen aus dem Log entfernen.....
Hallo und danke für den Input. Das deaktivieren von GeoBlocking war leider nicht erfolgreich. Im Grunde dürften bei einer PrivateIP ja auch gar keine Geo-Informationen enthalten sein.kennethj hat geschrieben: Moin,
ist auf der betroffenen UTM das GeoBlocking aktiviert? Das könnte auch eine Ursache sein.
Zum einen gibt es die status.secureoint.de wo Störungen reported werden.
Ansonsten gilt: Sind Sie mit dem Reseller nicht zufrieden können Sie wechseln.
Gruß
PS: Evtl. sollten Sie einmal den ersten Beitrag editieren und dort den Firewallnamen aus dem Log entfernen.....
Danke für den Hinweis mit dem Firewall Namen. Grrrr da habe ich nicht aufgepasst. Leider finde ich im Moment noch nicht die Edit-Funktion für den Beitrag.
Da das Problem, aus dem ersten Vorfall, ja temporär auftritt, habe ich nur 2 Möglichkeiten. Entweder eben [font="Lucida Grande", "Trebuchet MS", Verdana, Helvetica, Arial, sans-serif]Securepoint Cyber Defence Cloud oder aber auch Fail2ban.[/font]
Ich habe daher doch noch mal fail2ban versucht zu schauen
1. Ich gehe davon aus das der entsprechende Dienst in Securepoint sp2fd lautet. Ist das richtig?
2. Dieser Dienst scheint zu laufen:
sv status spf2bd
run: spf2bd: (pid 21577) 692s
3. Im Webfrontend unter Anwendungen -> IDS/IPS -> Sperrungen -> Allgemein -> Aktuelle Sperrungen sind keine Einträge vorhanden (Ist das der richtige Ort wo fail2ban dieses Anzeigen würde?)
4. Auf einer rootshell habe ich den Befehl: spf2bd ip list eingegeben. Ich habe mir davon erwartet das dort dann die gesperrten IPs aufgelistet werden.
Allerdings wird dieser Befehl nur mit einer Ausgabe von (process:21596): GLib-GIO-WARNING **: 08:41:54.988: Unexpected reply 3 when releasing name de.securepoint.Spf2bd1 quitiert. Diese Ausgabe wartet dann scheinbar bis in alle Ewigkeit, es sei den man beendet sie mit STRG-C
5. Ich habe inzwischen im Webfrontend unter Firewall -> Implizite Regeln Blockchain (Fail2Ban) alles deaktiviert.
Es nützt aber alles nicht, alles was auf B1 reinkommt wird geblockt. Nur das ich nicht prüfen kann ob fail2ban das Problem verursacht.
Kai
Ergänzung:
Ich habe jetzt mal einfach mittels
sv stop spf2bd
ok: down: spf2bd: 0s, normally up
den Dienst spf2d gestoppt, ohne mir da bewusst zu sein, welche Seiteneffekte ich evtl. damit auslöse. Eigentlich sollten dadurch ja IPs aus der BAN-Liste gelöscht werden
Der Staus ist:
sv status spf2bd
down: spf2bd: 5s, normally up
Aber auch das führt leider nicht zu dem gewüntschen Erfolg.
Moin,
Ich hatte eher die Ziel IP als Blockursache im Verdacht.
Irgendwas stört jedenfalls dem Threat Filter an der Verbindung (Ziel IP, Quell/Ziel Port).
Der fail2ban Sperrt nur den Zugriff auf einen Dienst der UTM (ssh/WebUI/SMTP etc). - der fällt in dieser Thematik also raus.
Man könnte testweise unter IDS/IPS -> Cyber Defense Cloud das verhalten von Sperren auf nur Protokollieren setzen - wenn das "Problem" dann nicht mehr auftritt, liegt es zu 100% am Threat Intelligence Filter.
Normalerweise sollen oben Rechts im AdminUI aber auch Meldungen erscheinen (oder im Alerting Center) wenn was vom Threat Filter blockiert wird:
INPUT - Potenziell gefährliche Verbindung blockiert: Eingehendes Interface wan0, ausgehendes Interface <kein Wert verfügbar>, Quelladresse x.x.x., Zieladresse x.x.x, Protokoll TCP, Quellport 9017, Zielport 443
Ich hatte eher die Ziel IP als Blockursache im Verdacht.
Irgendwas stört jedenfalls dem Threat Filter an der Verbindung (Ziel IP, Quell/Ziel Port).
Der fail2ban Sperrt nur den Zugriff auf einen Dienst der UTM (ssh/WebUI/SMTP etc). - der fällt in dieser Thematik also raus.
Man könnte testweise unter IDS/IPS -> Cyber Defense Cloud das verhalten von Sperren auf nur Protokollieren setzen - wenn das "Problem" dann nicht mehr auftritt, liegt es zu 100% am Threat Intelligence Filter.
Normalerweise sollen oben Rechts im AdminUI aber auch Meldungen erscheinen (oder im Alerting Center) wenn was vom Threat Filter blockiert wird:
INPUT - Potenziell gefährliche Verbindung blockiert: Eingehendes Interface wan0, ausgehendes Interface <kein Wert verfügbar>, Quelladresse x.x.x., Zieladresse x.x.x, Protokoll TCP, Quellport 9017, Zielport 443
So Problem gelöst. Ich hatte unter Anwendungen -> IDS/IPS alles disabled was nur ging und schon funktionierte es. Das Problem war, das in der Liste der systemweiten Sperre eben genau die IP enthalten war.
Leider war das aber nicht so zu sehen im Webfrontend. Erst nach einer Abfrage auf der CLI mittel spcli extc global get { variable GLOB_BLOCK_ADDRESSES } | grep 192.168 wurde das sichtbar.
Skurril aber für die Zukunft zwischen den Ohren gespeichert. Vielen Dank für die Hilfe.
Kai
Leider war das aber nicht so zu sehen im Webfrontend. Erst nach einer Abfrage auf der CLI mittel spcli extc global get { variable GLOB_BLOCK_ADDRESSES } | grep 192.168 wurde das sichtbar.
Skurril aber für die Zukunft zwischen den Ohren gespeichert. Vielen Dank für die Hilfe.
Kai