Securepoint Support Forum

Wenn ich da vielleicht noch einen kleinen Wunsch äußern dürfte: Eine große Hilfe wäre es, wenn im Log stehen würde durch welchen Länder-Eintrag (Länder-Code) die IP geblockt wurde.

Dafuer waere unsere Securepoint Wunschbox angedacht. Ich bin mir recht sicher, das so etwas bereits bei uns im Raum steht. Aber bitte solche Dinge in der Wunschbox hinterlegen. So haben dann auch andere Reseller die Moeglichkeit, sich dazu zu aeußern.

Ja, ich habe danach auch gesehen das so ein Wunsch in der Wunschbox bereits eingetragen ist. Hier im Forum bekommt aber immerhin von dir eine Rückmeldung (vielen Dank dafür).
In der Wunschbox muss man auf Securepoint-Feedback teilweise sehr lange warten oder es kommt gar nichts.

Was nicht bedeutet, das das nicht gelesen wird. Alternativ waere noch ueber Facebook ein Kommunikationskanal da. Ich nutze jedoch kein facebook mehr, kann nicht verlinken.

Hallo,

ist zwar ein Portfilter-Problem, aber passt zur aktuellen GeoIP-Thematik. Wir haben eine DMZ, über die unsere ADFS-Authentifizerung läuft, dort wird der Port 443 über DN an den Server in der DMZ geleitet. Nun habe ich eine GEO-IP-Block-Gruppe erstellt und diese Regel davor geschaltet, das sieht so aus:

• GeoBlocking-Deny external-interface https DROP
• internet-vdsl interneServerIPDMZ https DN ACCEPT

Egal ob ich bei der DROP-Regel  als Ziel external-interface, external-interfacevdsl, internet-vdsl, die DMZ oder direkt die Server-DMZ-IP wähle, wird im Log die untere Regel mit Accept genommen, sobald ich über einen Proxy aus einem der gesperrten Länder komme (in dem Fall: 217.107.34.191)

• Habe die IP manuell mit in die Gruppe aufgenommen -> immer noch aufrufbar
• https beim DROP durch any ersetzt -> gleiches Ergebnis

Habe ich hier einen Denkfehler? Oder ist meine Überprüfungsmethode falsch? Prüfe mit dem folgenden Proxy: irlandec ru

Was auch richtig ist.

Ersetzen Sie internet-vdsl durch eine Geo-IP Whitelist. Die andere Regel kann weg. Vorrausgesetzt das ist das gleiche Interface

Mario hat geschrieben: Vorrausgesetzt das ist das gleiche Interface

Danke, sofern die Quelle "internet" ist, geht das, bei dem genannten Dienst wird jedoch unsere Zweitleitung (eth3) benutzt, hier klappts dann leider nicht (Seite ist dann nirgends mehr erreichbar)

Haben Sie das GEO-IP Objekt fuer die korrekte Zone erstellt und verwendet?

Vielen Dank, das wars!

Hallo zusammen,

steh ich auf dem Schlauch? Wenn ja schubbst mich bitte runter.
Folgende Ausgangslage:
UTM Version 12.2.2.3
Wir haben beim Kunden nur die Implizierten Regeln Aktiv was den geo Filter betrifft.
Hier ist unter anderem CN (Volksrepublik China) für eingehend blockiert.

Wieso bekomme ich dann über das Alertingcenter einen Alarm dass die IP 183.136.225.42 versucht hat zuzugreifen und dann vom IDS/IPS abgelehnt wurde

INPUT - Potenziell gefährliche Verbindung blockiert: Eingehendes Interface wan0, ausgehendes Interface , Quelladresse 183.136.225.42, Zieladresse xx.xx.xx.xx, Protokoll TCP, Quellport 5764, Zielport 444

Über findip-address.com wenn ich die IP suche stammt diese aus China. Somit sollte diese IP Adresse doch nicht erst vom IDS abgelehnt werden.

Danke für Hinweise..

Michael

Bitte ein Ticket bei uns eroeffnen

Kann sein das die Liste fuer China nicht geladen wurde.

Hallo,
Das gleiche hab ich mit Honk Kong, GeoBlock dafür aktiv, trotzdem die Meldung im Alert-Center.

Wie gesagt, gerne ein Ticket bei uns eroeffnen. Villeicht hat sich die Firewall die Listen nicht komplett ziehen koennen

ist halt nicht recht zuverlässig, woher weiß ich, das die FW alle Listen, bzw. die anderen Länder hat?

Das werden wir alsbald sicher stellen. Das Script wird noch mal angepasst werden.

Doofe Frage:
Klappt bei Euch produktiv der GeoIP Filter?

Sobald ich global den GeoIP-Filter aktiviere unter implizite Regeln,
und dann zB granulare Regeln via Portfilter verwende als Whitelist (z.B. eingehend für HTTPs), dann greift die Whitelist nicht!

Den Test mache ich via VPN-Client und entsprechenden HTTPs-Zugriffen aus den Whitelist-Ländern.
Im Log sehe ich auch nichts von etwaigen DROPs, obwohl Logging je auf "short" steht.

Achtung, in meiner UTM hieß die externe Zone früher nicht "external", sondern "external-eth0", was ich korrigiert habe nun auf "external"
Habe daraufhin via CLI quasi die GeoIP-Objekte angelegt für zB mit dem Präfix "geo_" , weil sonst die GeoIP-Objekte nicht aufgetaucht sind...

Habe anhand dieser Anleitung gearbeitet:
https://wiki.securepoint.de/UTM/GeoIP

ein Reboot der UTM mit dem Fw-Update auf Build 12.2.2.8 hat noch nicht abgeholfen.

Soll:
Granulare Whitelist von GeoIP-Ländern für bestimmte eingehende Dienste (zB SMTP oder HTTPs).

1. Implizit > GeoIP aktiviert für je source und target (keine Host eingetragen, da ich dies im Portfilter granular mache)
2. Netzwerkobjek-Gruppe angelet "geo_whitelist_https" mit entsprechenden Ländern gefüttert
3. Portfilter > eingehende Regel: Quelle anstelle von "internet" nun die "geo_whitelist_https" eingetragen --> tut nicht... trotzdem werden die Whitelist-Länder blockiert (Test via VPN-Client)....

Was mache ich falsch?

Vielen Dank

Also iwas klappt ganz und gar nicht;
So kurz mal einrichten und beruhigt sein, ist nicht. don't trust, verify!
an den IPs liegts nicht, die werden sauber erkannt, ich vermute, meine UTM hat iwo Stress und blockt nicht;

Habe testhalber mal die impliziten Regeln ausprobiert; Systemweiter abgelehnte Quellen:
<diverse Ländern> anhand einer Blacklist -> geht nicht.
im Log taucht schön der Eintrag "ACCEPT" auf....

Merkwürdig:

• wenn ich nach einem Land suche, taucht der Vorschlag je drei Mal auf für dasselbe Land (kann man das via CLI korrigieren)

Das liegt an vorhandenen Zonen.

Und implizierte Regeln greifen vor Portfilterregeln.