Seit der Einführung des GeoIP-Filters in den UTMs von Securepoint haben wir fleißig von diesem gebrauch gemacht. So konnten unerwünschte Zugriffe weiter unterbunden oder gewollte Zugriffe begrenzt werden. Manchmal erlangt man allerdings auch mitunter unerwartete Erkenntnisse.

Bekanntermaßen sind Filter auf Basis von GeoIP, unabhängig von Securepoint, relativ unscharf. Das soll heißen: Ein Provider, Peering- oder Backbone-Anbieter ist zwar in einem Land tätig, der Traffic wird allerdings über ein anderes Land geroutet.

Dennoch ist es eine gute Möglichkeit, etwas mehr Sicherheit rein zu bekommen. Generell haben wir beobachtet, das durch entsprechende Einschränkungen das IDS / IPS weniger zu tun hat und so auch die täglichen Alerting Center-Berichte wesentlich schlanker ausfallen können.

Ein Fall-Beispiel genau zu diesem Routing-Thema ergab sich nun: Bei einem Kunden wurde der Zugriff via SSL-VPN auf Deutschland beschränkt, das funktioniert für fast alle Außendienstler und Home Office-Mitarbeiter mit einer einzigen Ausnahme. Dieser Mitarbeiter verwendet einen Glasfaser-Internetanschluss des Darmstädter Unternehmens Entega. Dieses wiederum bietet in Südhessen FTTH-Anschlüsse in Zusammenarbeit mit der Deutschen Glasfaser an.

Ein Blick in das Log der UTM (gefiltert nach Port 1194 [OpenVPN]) zum Zeitpunkt des gescheiterten Verbindungsaufbau lieferte die IP-Adresse des “Home Office”-Anschlusses. Nach dieser mit der Suchmaschine der Wahl, ggf. mit einem vorangestellten “whois”, gesucht brachte relativ wenig Treffer.

Das Ergebnis bei SpeedGuide.net lieferte als ISP die ENTEGA Medianet GmbH, hier wird auch eine Lokation in Deutschland angegeben. Ein nslookup auf die IP-Adresse lieferte den Einwahlnamen nach dem Schema

 IP-1234567890.dynamic.medianet-world.de

Soweit erstmal stimmig und erwartet. Das Ergebnis bei IPSquads wiederum zeigt etwas anderes, hier wird zwar auch die Entega angegeben, aber als Lokation Tschechien. Unterschiedlich fällt das Ergebnis bei WhoIsRequest aus. Beispielsweise ergibt die Suche nach dem bei SpeedGuide ermittelten ASN das

"The country in which these IPs are located is Germany (DE)..."

Sucht man dort allerdings direkt mit der IP-Adresse ergibt sich als Land wieder Tschechien. Quasi das Gleiche mit der IP-Adresse kommt bei Ip-Whois-Lookup heraus.

Lange Rede, kurzer Sinn: Offenbar läuft (zumindest) ein Teil des Traffics über Tschechien, folglich wurde dieses Land im GeoIP-Netzwerkobjekt in der Securepoint UTM hinzugefügt und schon klappte der VPN-Zugang.

Update 12.05.2022

Leider trat dieses “Problem” nun erneut auf, wieder im Zusammenhang mit der Entega, was nicht bedeutet das es in deren Verantwortung liegt. Im Log der UTM konnte man wunderbar die DROP-Meldungen sehen, aber leider sieht man dort bislang noch nicht, aus welchen Land die IP stammt. Eine whois-Suche bzw. -Abfrage wie zuvor lieferte neben den bekannten Treffern, gemeint ist DE, dann auf Ip-Whois-Lookup statt CZ auf einmal RU. Letzteres ist aus aktuellem Anlass nicht unbedingt so positiv. Ein testweises Zulassen von RU half allerdings auch nicht, erst als wieder das Internet in Gänze für den Zugriff zugelassen wurde, konnte eine Verbindung aufgebaut werden. So war klar, das da etwas nicht ganz passt.

Vom Support kam dann die Info das man die Listen von IPdeny verwendet, diese sind hinlänglich bekannt und werden in vielen Anleitungen und Projekten verwendet. Auf der UTM selbst kann man via ssh als root mit

ipset list

die aktuellen Listen einsehen, diese werden wöchentlich von Securepoint aktualisiert. Mit

ipset list > ipset-list.txt

habe ich mir die Ausgabe umgeleitet, mit WinSCP die Datei dann auf meinen lokalen PC heruntergeladen und mit Notepad geöffnet. Dies erschien mir der einfachste Weg, um nach der IP bzw. dem Teilnetz zu suchen.

Das Teilnetz wurde dann unter

Name: ip4-GEOIP:AT

gefunden.