Es ist nun eine Woche her das mir folgendes passiert ist:

Bei einem Kunden wurde ein LANCOM-Router der durch die Deutsche Telekom gestellt wurde durch eine Securepoint UTM RC300 ersetzt. Kurz nach dem Tausch kam dann das erste Feedback, dass das Telefon nicht mehr funktionieren würde. Dieser Kunde hat eine Avaya IP Office-PBX im Einsatz (nicht von aus, ich kenne mich damit nicht aus und habe mit dieser Anlage auch nichts zu tun).

Der erste Gedanke war natürlich das es am Portfilter liegen könnte, allerdings war zu diesem Zeitpunkt alles quasi noch auf Durchzug (Any-Regeln) gestellt, da im ersten Schritt der Kunde zunächst wieder online und erst im Nachgang Schritt-für-Schritt die Sicherheit hochgeschraubt werden sollte.

Dem Avaya-Admin fiel zunächst auf, das der SIP-Trunk bei der Deutschen Telekom nicht mehr registriert. Um der Sache auf den Grund zu gehen hatte ich mich mittlerweile per ssh als root mit der Securepoint UTM verbunden um mir mittels tcpdump anzusehen was da verkehrstechnisch passiert, nachdem im Log nichts zu finden war.

Hier zeigte sich schnell, das die Telefonanlage lediglich DNS-Abfragen gegenüber der UTM tätigte, sonst passierte nichts weiter:

tcpdump -i eth1 host 192.168.2.18
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:45:41.053710 IP 192.168.2.18.domain > 192.168.2.1.domain: 13705+ SRV? _sip._tcp.reg.sip-trunk.telekom.de. (52)
11:45:41.053843 IP 192.168.2.1.domain > 192.168.2.18.domain: 13705 3/4/6 SRV n-ipr-a01.edns.t-ipnet.de.:5060 20 0, SRV d-ipr-a02.edns.t-ipnet.de.:5060 30 0, SRV n-ipr-a02.edns.t-ipnet.de.:5060 10 0 (403)
11:46:11.073928 IP 192.168.2.18.domain > 192.168.2.1.domain: 13706+ SRV? _sip._tcp.reg.sip-trunk.telekom.de. (52)
11:46:11.074070 IP 192.168.2.1.domain > 192.168.2.18.domain: 13706 3/4/6 SRV d-ipr-a02.edns.t-ipnet.de.:5060 30 0, SRV n-ipr-a02.edns.t-ipnet.de.:5060 10 0, SRV n-ipr-a01.edns.t-ipnet.de.:5060 20 0 (403)

Wie man sieht fragt die Avaya nach den Service Records für den SIP-Trunk und bekommt sogar eine Antwort, das Ganze wiederholt sich dann endlos, es finden keine weiteren Anfragen statt. Man kann das Ganze zudem mit mehr Details beobachten, das Ergebnis sieht dann wie folgt aus:

tcpdump -i eth1 host 192.168.2.18 -vv

17:07:00.233245 IP (tos 0x0, ttl 99, id 26991, offset 0, flags [none], proto UDP (17), length 80)
192.168.2.18.domain > 192.168.2.1.domain: [udp sum ok] 13731+ SRV? _sip._tcp.reg.sip-trunk.telekom.de. (52)

17:07:00.233372 IP (tos 0x0, ttl 64, id 11121, offset 0, flags [none], proto UDP (17), length 431)
192.168.2.1.domain > 192.168.2.18.domain: [bad udp cksum 0x8710 -> 0xe118!] 13731 q: SRV? _sip._tcp.reg.sip-trunk.telekom.de.
3/4/6 _sip._tcp.reg.sip-trunk.telekom.de. SRV d-ipr-a02.edns.t-ipnet.de.:5060 30 0, _sip._tcp.reg.sip-trunk.telekom.de. SRV n-ipr-a02.edns.t-ipnet.de.:5060 10 0, _sip._tcp.reg.sip-trunk.telekom.de. SRV n-ipr-a01.edns.t-ipnet.de.:5060 20 0
ns: telekom.de. NS dns1.telekom.de., telekom.de. NS dns2.telekom.de., telekom.de. NS secondary006.dtag.net., telekom.de. NS pns.dtag.de.
ar: pns.dtag.de. A 194.25.0.125, dns1.telekom.de. A 194.25.225.19, dns2.telekom.de. A 194.25.225.3, secondary006.dtag.net. A 195.244.245.25, pns.dtag.de.

AAAA 2003:40:8000::100, secondary006.dtag.net. AAAA 2a00:fa8:3:0:100:0:6:1 (403)

Soweit wie ich es beurteilen kann ist alles da. Um sicher zu gehen, das in Sachen VoIP einem nichts durch die Lappen geht zusätzlich noch mit

tcpdump -i wan0 port 5060

geschaut. Das Ganze zusätzlich zudem mit dem eth1-Internface (LAN) wiederholt, bei beiden gähnende Leere. Die Avaya versucht noch nicht mal irgendetwas zu registrieren.

Per Zufall bzw. weil dies Teils des Projekts war fiel dann von einem neuen entfernten Standort (S2S) auf, das die Telefonanlage zudem nicht auf Ping-Anfragen (icmp-echo-request) reagiert. Im lokalen Netz klappt das noch, aber sobald irgendwie Routing ins Spiel kommt ist Feierabend.

Auch das lies sich wunderbar per tcpdump beobachten:

Ping-Test via VPN (keine Antwort von der PBX):

13:22:17.219406 IP 10.1.1.250 > 192.168.2.18: ICMP echo request, id 1, seq 150, length 40
13:22:22.173170 IP 10.1.1.250 > 192.168.2.18: ICMP echo request, id 1, seq 151, length 40
13:22:27.162525 IP 10.1.1.250 > 192.168.2.18: ICMP echo request, id 1, seq 152, length 40
13:22:32.166314 IP 10.1.1.250 > 192.168.2.18: ICMP echo request, id 1, seq 153, length 40

Ping-Test Lokal/LAN:

13:24:29.670160 IP 192.168.2.1 > 192.168.2.18: ICMP echo request, id 48401, seq 0, length 64
13:24:29.673185 IP 192.168.2.18 > 192.168.2.1: ICMP echo reply, id 48401, seq 0, length 64
13:24:30.670179 IP 192.168.2.1 > 192.168.2.18: ICMP echo request, id 48401, seq 1, length 64
13:24:30.673078 IP 192.168.2.18 > 192.168.2.1: ICMP echo reply, id 48401, seq 1, length 64
13:24:31.670202 IP 192.168.2.1 > 192.168.2.18: ICMP echo request, id 48401, seq 2, length 64
13:24:31.672980 IP 192.168.2.18 > 192.168.2.1: ICMP echo reply, id 48401, seq 2, length 64
13:24:32.670227 IP 192.168.2.1 > 192.168.2.18: ICMP echo request, id 48401, seq 3, length 64
13:24:32.671892 IP 192.168.2.18 > 192.168.2.1: ICMP echo reply, id 48401, seq 3, length 64
13:24:33.670250 IP 192.168.2.1 > 192.168.2.18: ICMP echo request, id 48401, seq 4, length 64
13:24:33.672798 IP 192.168.2.18 > 192.168.2.1: ICMP echo reply, id 48401, seq 4, length 64

Da machte sich dann Ratlosigkeit breit. Also mit dem Securepoint-Support in Verbindung gesetzt, dieser bestätigte dann den Verdacht bis hierhin das die Avaya

• a) nur DNS-Abfragen vornimmt und
• b) kein Routing mehr macht bzw. nicht mit dem Gateway kommuniziert.

Der Vollständigkeit halber sei erwähnt, das wir in der Zwischenzeit schon mehrfach alles neu gestartet hatten, ohne das sich irgendetwas geändert hat. Dem Avaya-Admin fiel zudem auf, das die Anlage versuchte den Trunk gegenüber „pns.dtag.de“ also der IP-Adresse „194.25.0.125“ und weiteren zu registrieren, also quasi alle möglichen Telekom-Server abklapperte außer die eigentlichen für den SIP-Trunk zuständigen. Interessanterweise sah man davon nichts via tcpdump. Das Klang dann danach, das diese Anfragen die Anlage schon gar nicht verlassen haben, folglich irgendetwas intern schon falsch abbiegt.

Ein Vorschlag von mir an den Avaya-Admin war dann, doch mal die IP-Konfiguration in der PBX neu einzutragen, in der Hoffnung das dies den wie auch immer gearteten Knoten löst. Durchgeführt wurde dies leider nicht. An dieser Stelle war ich dann zunächst raus, da wie bereits erwähnt ich mit Avaya nichts zu tun habe.

Gute 24 Stunden später meldete sich dann vom Telefonanlagen-Lieferanten der Support beim Kunden-eigenen Avaya-Admin. Der Erzählung nach schaute man sich das Ganze an und änderte letztlich den DNS-Eintrag in der Telefonanlage von der IP-Adresse der UTM auf den Google-DNS-Server „8.8.8.8“. Daraufhin registrierte die Anlage den SIP-Trunk und sie reagiert auch wieder auf Pings von außerhalb des LANs. Kurzum: Es läuft wieder.

Via tcpdump kann man zudem, wenn gerade ein Gespräch geführt wird, ebenfalls mehr „Leben“ sehen:

...
13:39:20.472452 IP <Hostname>.dip0.t-ipconnect.de.12892 > 192.168.2.18.46750: UDP, length 172
13:39:20.479478 IP 192.168.2.18.46750 > <Hostname>.dip0.t-ipconnect.de.12892: UDP, length 172
...

Für mich sieht das danach aus das die Änderung des DNS-Servers in der Avaya den IP-Stack wieder in die Spur gebracht hat, im Grunde also der Effekt den ich mit dem Vorschlag die IP-Konfiguration nochmal einzutragen erzielen wollte. Ich glaube nicht, das es an den DNS-Daten liegt. Da der jetzige Zustand, sprich DNS-Abfragen am Domänencontroller und der UTM vorbei, nicht bleiben soll haben wir vereinbart das wir dieses Thema nochmal in Ruhe angehen.

Ich habe ja schon so einige Router in meinem IT-Leben ausgetauscht, aber sowas ist mir bis dato noch nicht begegnet. Das man ggf. am Regelwerk etwas nachstellen muss ist klar, aber das ein Netzwerk-Gerät quasi ganz aussteigt und das über Neustarts hinweg ist mir neu.

Vielleicht gibt es ja hier Avaya-kundige Kollege*innen mit einer Idee dazu, was da passiert sein könnte.

Links:

Securepoint – Forum – Avaya PBX mit Telekom-SIP-Trunk registriert nicht (mehr)

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Neue (Firmware-)Updates für Securepoint UTMs werden nach deren Veröffentlichung Wellenweise an die Geräte verteilt bzw. von diesen automatisch heruntergeladen. Manchmal kommt allerdings vor, das selbst nach mehreren Tagen oder gar Wochen eine UTM das Update noch nicht zur Installation anbietet.

In der Regel wird man direkt nach der Anmeldung als „admin“ am Web-Interface über ein Update informiert und kann dieses entweder direkt installieren oder später über

Extras - Firmware Updates

Weiß man beispielsweise aufgrund des Changelogs das es eine oder gleich mehrere neuere Versionen gibt und keine davon wird im Web-Interface angeboten, kann man zunächst auf die CLI oder via ssh auf die Shell ausweichen. Am einfachsten geht dies über das Web-Interfaces unter

Extras - CLI

Nun kann man der Reihe nach folgende Befehle absetzen:

system upgrade update

Oder besser:

system upgrade forceupdate

Im Idealfall wird das Update im Hintergrund heruntergeladen, was je nach Umfang der Aktualisierung und der Internetgeschwindigkeit eine Weile dauern kann, und diese kann via

Extras - Firmware Updates

installiert werden.

Möglicherweise erhält man in der CLI oder Shell eine oder mehrere der folgenden Fehlermeldungen:

error: downloading VERSION: failed
parse error
empty answer from 'spupdater'

In diesem Fall einfach etwas warten und immer mal wieder in der GUI nachsehen, ob das Update mittlerweile zur Installation angeboten wird. Ggf. mal die UTM neu starten und die Befehle erneut absetzen. Im Log kann man zudem nach

spupdater

suchen. Wenn wirklich alle Stricke reißen bleibt nur der Weg mit einer Update-Installation via USB-Stick.

Quelle:

Securepoint – Support-Forum – Updates funktionieren nicht

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Da kann man Sonntags-Morgens schonmal Bluthochdruck bekommen, wenn man in seinem Postfach folgende Meldung von einer Securepoint UTM erhält: „Neue Lizenzinformationen konnten nicht runter geladen werden“.

Letztlich ist das allerdings gar nicht so schlimm, wie sich zeigen sollte: Bei einer Securepoint UTM die im Rahmen von Firewall as a Service (FWaaS) an einem Standort eines Kunden läuft, klappte über Nacht die Erneuerung der Lizenz nicht. Lizenz bei Securepoint bedeutet seit geraumer Zeit, das es sich um ein für den Zeitraum X gültiges Zertifikat handelt. Bei FWaaS sind diese immer drei Monate gültig und werden automatisiert vor deren Ablauf und sofern es ein gültiges Abo gibt heruntergeladen. Das Ganze geschieht transparent im Hintergrund und man bekommt davon in der Regel nichts mit.

Erstmals hatte ich nun die oben genannte Meldung, was an einem Wochenende und bei einem wichtigen Kunden dann durchaus für einen gewissen anfänglichen Stress sorgt, der zumindest diesmal völlig unnötig war. Aber erstmal der Reihe nach:

Die eigentliche E-Mail-Benachrichtigung sieht so aus:

Meldet man sich direkt am Web-Interface der UTM als „admin“ an, sieht die Welt schon ganz anders aus:

Also doch alles in Ordnung, Was war also geschehen? Hierzu hilft ein Blick ins Log und der Suche nach „license_restrictions“, was wiederum zu diesem Ergebnis führt:

Es wurde versucht eine neue Lizenz herunterzuladen, das klappte zunächst zwei Mal nicht, da die Gegenstelle (der Securepoint Lizenzserver) in beiden Fällen den Fehler 500 ausgegeben hat. Daraus ergibt sich, das es nicht an der UTM liegt und man erstmal schlicht nichts machen kann. Beim dritten (automatischen) Versuch hat es dann funktioniert und alles ist gut.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Mir ist es mittlerweile zwei Mal direkt nach dem Wechsel einer Securepoint UTM untergekommen, das die Graphen für z.B. „LOAD“, „CPU-x“, „SPEICHER“ usw. lediglich „no data available“ anzeigen.

Vorausgegangen ist immer die Inbetriebnahme der jeweiligen UTM ohne Internet und lediglich das Einspielen der Lizenz sowie der aktuellen Konfiguration vom Altgerät. Bei der ersten UTM hatte ich sogar noch die Uhrzeit manuell gesetzt. Letztlich findet wohl beim ersten Kontakt mit dem NTP-Zeitserver sozusagen ein Zeitsprung statt, der die Graphen durcheinander bringt. Zurücksetzen lassen diese sich via ssh als root mit folgenden Befehlen:

cd /rootdisk/collectd/rrd/localhost/
rm -rf *
sv restart collectd

Beim ersten Mal hat das noch der Support für mich erledigt, beim zweiten Mal schritt ich selbst zur Tat.

Quelle:

Securepoint – Support Forum – Graphen zeigen nichts mehr an – no data available

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Das die Securepoint UTM mehrere Subnetzte direkt, also mittels physischen Schnittstellen oder via VLAN kann, ist klar. Dieser Beitrag zielt auch gar nicht direkt auf die UTM bzw. Securepoint ab, vielmehr geht es diesmal um eine kleine Hilfestellung für Admins.

Folgendes Kunden-Szenario:

Bei Kunden gibt es zwei Internet-Zugänge und zwei bislang von einander getrennte Subnetze. An einem der Internet-Zugänge hängt eine Securepoint UTM, an dem Anderen eine AVM FRITZ!Box.

Nun soll von dem „UTM-LAN“ aus auch auf das andere Netz und vice versa zugegriffen werden. Dazu wurde aus dem „FRITZ!Box-LAN“ ein Kabel mit der UTM verbunden.

Während die Einrichtung der Schnittstelle und des Portfilters in der UTM soweit kein Thema ist, klappt der Zugriff aus dem „UTM-LAN“ auf die FRITZ!Box bzw. deren Web-Interface und weiteren Netzwerk-Geräten erstmal noch nicht, denn: Der Fritte fehlt schlicht noch eine Route zum „UTM-LAN“.

Hat man jetzt erstmal keinen Zugriff auf das „FRITZ!Box-LAN“ sei es direkt vor Ort, per pcvisit o.ä. kann man sich mit einem ssh-Tunnel aka ssh-Port-Forwarding (durch die UTM) behelfen. Der „Trick“ dabei ist einfach:

Statt mit einer IP-Adresse aus dem UTM-LAN „daherzukommen“, kommt die Verbindung direkt aus der UTM bzw. der Schnittstelle die mit deM „FRITZ!Box-LAN“ verbunden ist. Ergo aus dem Subnetz der Fritte und somit wird keine Route benötigt.

Unter Windows kann man beispielsweise PuTTY oder KiTTY verwenden, die Herangehensweise ist bei beiden identisch. Für auf die Schnelle bietet sich KiTTY Portable an.

• PuTTY/KiTTY starten.
• Bei „Session“ den „Host Name“ oder die IP-Adresse der UTM eintragen.
• Zu „Connection – SSH – Tunnels“ wechseln.
• Bei „Source Port“ den lokal zu verwendeten Port eintragen.
• Bei „Destination“ die IP-Adresse der FRITZ!Box samt Port (!) eintragen.
• Auf „Add“ klicken.
  
• Auf „Open“ klicken.
• Den ssh-Schlüssel der UTM bestätigen und an der UTM anmelden.
  Bemerkung: Das admin-Konto reicht völlig aus, es muss kein root-Konto angelegt bzw. verwendet werden!
• Im Browser „localhost:8080“ oder „127.0.0.1:8080“ eingeben.
  Bemerkung 1: Es kann passieren, das beim ersten Verbindungsaufbau der Tunnel nicht erstellt wird, dann PuTTY/KiTTY beenden und nochmal starten.
  Bemerkung 2: Bei der Nutzung von „localhost“ kann es passieren, das die FRITZ!Box die Verbindung wegen des DNS-Rebind-Schutzes ablehnt, in diesem Fall einfach „127.0.0.1“ benutzen.

So gelangt man auf das Web-Interface der FRITZ!Box, sobald die Route eingetragen ist kann man auf den ssh-Tunnel verzichten. Das Ganze funktioniert i.d.R. auch wenn keine FRITZ!Box, sondern ein LANCOM, Speedport, … auf der anderen Seite verwendet wird.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Der SSL VPN Client von Securepoint lässt sich wie viele Anwendungen gleichfalls automatisch installieren oder aktualisieren. Dazu ist es lediglich notwendig, den Installer mit entsprechenden Argumenten zu starten.

Grundsätzlich kann man die *.exe-Ausgabe des Installers verwenden, da dieser letztlich eine *.msi entpackt und die Argumente übergibt:

openvpn-client-installer-2.0.33.exe -qb

Allerdings kann nicht die Abfrage der Sprache zu Beginn des Setups unterbunden bzw. automatisiert werden:

Da es so oder so auf eine *.msi-Datei hinausläuft kann man gleich diese entweder aus dem Resellerportal oder bei Sourceforge herunterladen und nutzen. Bei Sourceforge findet man zudem passend zur jeweiligen Version Beispiele für die Automatisierung:

Windows 10 - German
msiexec /qn /i openvpn-client-installer-2.0.33.msi CWINVERSION=10

Windows 7 - German
msiexec /qn /i openvpn-client-installer-2.0.33.msi CWINVERSION=7

Windows 10 - English
msiexec /qn /i openvpn-client-installer-2.0.33.msi TRANSFORMS=":en-us.mst" CWINVERSION=10

Im Grunde reicht bereits ein

openvpn-client-installer-2.0.33.msi /qn

aus.

Hat man zuvor (manuell) den SSL VPN Client mit der entsprechenden *.exe-Datei installiert und möchte bzw. muss nun die *.msi-Datei verwenden, so stellt dies kein Problem dar. Es muss nichts vorher angepasst, beachtet oder gar deinstalliert werden!

Quellen:

Microsoft – Docs – msiexec

Securepoint Support Forum – Silent Installation SSL VPN Client

Securepoint Support Forum – gelöst: SSL VPN Client 2.x silent Installation

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Bislang gab es mit Securepoint Antivirus Pro bei uns und unseren Kunden herzlich wenig Überraschungen, ganz ohne blieb es allerdings leider auch nicht.

Ein wiederkehrendes Szenario ist, das plötzlich der Dienst streikt und sich nicht mehr starten lässt und in Folge der betroffene Computer nicht mehr geschützt ist sowie das Portal meldet, das dieser nicht mehr aktuell sei.

Reparatur-Installation oder Neustart helfen leider nicht. Es hilft nur De- und erneutes Installieren, dieses setzt allerdings einen Neustart voraus.

Beobachtet haben wir dies nun bei mehreren Windows Server 2012 R2 Standard. Nun sind das ohnehin Kandidaten zum Austauschen, dennoch und bis es soweit ist, muss der Virenschutz noch laufen. Da man einen Server eher selten während des Tages neu starten kann, musste eine Lösung her.

An dieser Stelle der Hinweis, das der nachfolgende Workaround nur als eine Art Notlösung gedacht ist! Ob dieser einen Neustart, beispielsweise wegen Windows Updates, übersteht, ist bislang nicht geklärt.

Vorbereitungen

• Das aktuelle Securepoint Antivirus Pro-Setup herunterladen und entpacken.
• Die aktuelle Version von NSudo herunterladen und entpacken.

Den Antivirus-Dienst löschen

Ein direktes Löschen des Antivirus-Dienstes ist mangels Rechte selbst als Administrator nicht möglich. Daher

• NSudo starten,
• bei “User” TrustedInstaller” auswählen,
• den Haken setzen bei “Enable All Privileges” kann man machen, muss man aber nicht,
• Bei “Open:” “cmd” eintragen und
• auf “Run” klicken.

In der sich öffnenden Eingabeaufforderung “sc delete GuardX” ausführen.

Nun das Securepoint Antivirus Pro-Setup starten und zunächst die alte Installation entfernen. Sobald dieser Schritt abgeschlossen ist, das Setup nochmals starten und diesmal den Schutz (wieder) installieren.

Sobald das Setup abgeschlossen ist, im Portal prüfen ob das entsprechende Gerät nun wieder aktuell ist. Ggf. die Konfiguration samt einem Kennwort (sofern genutzt) nochmals übertragen.

Tipp: Damit man früher mitbekommt, das der Dienst streikt, kann dieser mittels Monitoring überprüft werden. Läuft der Dienst nicht, sollte eine Alarmierung stattfinden!

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Manchmal ist es notwendig, herauszufinden wer oder was eine Datei erstellt. Dank eines Tools ist die Aufgabe schnell erledigt.

In diesem Beispiel meldete der Securepoint Antivirus Pro bei einem Kunden regelmäßig, sprich alle 10 Minuten, temporäre Dateien:

Nun Stand die Frage im Raum wie man herausfinden könnte, welche Anwendung oder welcher Prozess diese Dateien erzeugt. Anhand des Dateinamens konnte in diesem Fall schon mal nach einer knappen Recherche festgestellt werden, das die Anwendung bzw. der Prozess vermutlich in der Programmiersprache Delphi geschrieben ist.

Um nun schnell und einfach den Ursprung ermitteln zu können, wurde einfach der Process Monitor auf dem betroffenen System heruntergeladen und gestartet. Damit man nun die benötigten Treffer erhält wurde zuerst über die Symbolleiste lediglich die Anzeige von Dateisystem-Aktivitäten (“Show File System Activity”) aktiviert bzw. der Rest deaktiviert.

Als nächstes wurde ein Filter (Trichter-Symbol, sechstes Symbol von links) wie folgt gesetzt:

Path contains C:\Windows\Temp\Indy Include

Wie man sieht, kann man im Pfad einen Teil des Dateinamens einbauen, dies ist sehr hilfreich um die Zugriffe besser eingrenzen zu können. Beim nächsten Durchlauf sah man dann auch gleich den betroffenen Prozess:

Die “TMMS.exe” gehört zum Taifun MailServer, der Archivierungslösung die Teil der Taifun-Handwerker-Software ist.

Da Pfad-Ausnahmen in diesem Fall nicht ausreichten, wurde der Prozess als Ausnahme im Virenschutz definiert und die Meldungen hörten auf.

Umgekehrt, gemeint ist mit einem Filter auf den “Process Name” lässt sich feststellen, welche Zugriffe ein Programm vornimmt. Dies ist z.B. hilfreich bei Rechte-Problemen (Stichworte: Access denied, Zugriff verweigert).

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

• MDaemon: Mittels Inhaltsfilter bestimmte Nachrichten (nach extern) weiterleiten
• MDaemon: Mit der Protokollübersicht erfolgreiche und fehlgeschlagene Zustellungen einsehen
• MDaemon: Ausgehende Nachrichten direkt zustellen, wenn das nicht klappt dann via Smarthost

Set your Author Custom HTML Tab Content on your Profile page

Auf einem Windows Server 2016 Standard lastete der Virenschutz von Securepoint das System zu gut 50% und mehr aus. Im Dashboard wurde das System wahlweise mit 26 oder 129 erkannten Schädlingen angezeigt.

Vorausgegangen waren erfolgreiche Erkennungen von alten inaktiven Schädlingen die in archivierten Dateien vorhanden waren, sowie der eine oder andere Treffer beim Scannen des Mailserver-Verzeichnisses. Die Ergebnisse bzw. Meldungen wurden immer überprüft und meist der Empfehlung “Sichern und löschen” gefolgt. Zu keinem Zeitpunkt war Malware aktiv auf diesem System.

Soweit, so gut. Irgendwann fing allerdings der Virenschutz an, seine eigene Quarantäne als Malware-infiziert zu melden, das Anwenden der Empfehlung oder anderer Optionen half dabei nichts und die Auslastung ging hoch. In der lokalen GUI blinkte die Registerkarte “Quarantäne” nur noch, von dort aus konnte man gar nichts mehr unternehmen.

In der Zwischenzeit wurde der Support kontaktiert, noch bevor dieser Antworten konnte fand (s)ich ein erster Workaround:

• NSudo herunterladen und ausführen.
• Eine Eingabeaufforderung als Benutzer “Trusted Installer” (System reicht nicht aus!) ausführen:
  
• Den Dienst anhalten mit

  net stop GuardX

• Nun aus dem Pfad

  C:\Program Files\Securepoint Antivirus Pro\quarantine\files

  alle Dateien entfernen.

• Den Dienst starten mit

  net start GuardX

• Zuletzt gab es nur noch ein paar Phantome, die im AV-Portal und der lokalen GUI angezeigt wurden. Beide Listen waren allerdings unterschiedlich und mussten separat geleert werden.

Leider hilft dieser erste Workaround nicht auf die Dauer. Irgendwann geht die CPU-Auslastung wieder hoch, wenigstens ohne das es irgendeinen Treffer gibt.

In der Zwischenzeit meldete sich zudem der Support und schaute sich das Ganze an, offenbar gibt es seit den vergangenen ein-zwei Updates auf manchen Systemen Schwierigkeiten. Dabei spielt es keine Rolle ob es sich um z.B. Windows 10 oder eben Windows Server handelt. Auch sonst konnte man bislang keine Gemeinsamkeiten oder Rückschlüsse ziehen, das Ganze wird aktuell noch untersucht.

Als automatisierbare Lösung kann man beispielsweise eine Prozessüberwachung bauen, wenn “guardxservice_x64.exe” längere Zeit für CPU-Auslastung sorgt, kann der Virenschutz über die NSudo-CLI beendet werden:

NSudoLC.exe -U:T -P:E net stop GuardX

Ein (Neu-)Start des Dienstes gelingt ohne NSudo:

net start GuardX

Persönliche Bemerkung

Der bzw. die Workarounds sind nicht perfekt, aber sie helfen zumindest temporär. Der Support ist Securepoint-typisch gut und man schaut sich die Anliegen an. Im Großen und Ganzen bin ich mit Securepoint’s Antivirus Pro sehr zufrieden und Fälle wie dieser sind die absolute Ausnahme! Generell läuft dieser Virenschutz bei uns und unseren Kunden in der Regel völlig stressfrei.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Die Securepoint UTM unterstützt von Haus aus bereits IPsec und OpenVPN (dort SSL-VPN genannt), zukünftig könnte WireGuard als neue und moderne VPN-Lösung hinzukommen.

Der Eintrag in der Wunschbox das WireGuard unterstützt werden sollte datiert auf den 04. August 2019:

Wunschbox – Wireguard Tunnel

am 01. März 2021 ließ der Hersteller verlauten, das man eine Implementierung prüfe:

“Vielen Dank für die vielen Kommentare zu dieser Idee. Das Thema Wireguard ist sehr interessant und wir prüfen eine Implementierung.”

Am 13. September 2020 hieß es dann seitens Securepoint, das eine Implementierung kommen soll:

“Das Thema Wireguard ist nicht vom Tisch. Test haben nur auch Nachteile aufgezeigt und durch Verbesserungen von IPSEC und OpenVPN gibt es hier weitere Vorteile. Bedeutet, Wirequard wird noch eine Weile brauchen.”

An dieser Stelle wäre interessant wie erfahren, was für Nachteile die Tests aufgezeigt haben. Das Protokoll an sich ist (imho) evtl. noch nicht mal das Thema. Vielmehr evtl. solche Punkte wie keine Anbindung an LDAP und Co., keine Übermittlung von DNS oder Gateway, etc. wie man es z.B. von SSL-VPn (OpenVPN) her kennt. Das ist allerdings meinerseits reine Spekulation.

Ein erstes Anzeichen, das sich da etwas tut, fand ein Kollege bereits am 13. September 2021:

“In der aktuellen 12.1.8.1 gibt es bereits bei den impliziten Regeln eine für Wireguard, d.h. Securepoint ist tatsächlich an der Sache dran :-)”

Das sieht dann so aus:

Das ist auch so in der zu diesem Zeitpunkt aktuellen Version 12.2.1.2 vom 11.01.2022 noch so. Ich nahm nun die Inbetriebnahme einer neuen RC100 zum Anlass mal kurz unter die Haube zu schauen. Mittels ssh als root findet man wg (den WireGuard-Befehl) im System:

Offensichtlich ist man an dem Thema dran, nutzbar ist es wahrscheinlich noch nicht (hab’ ich nicht getestet und selbst wenn fehlt mindestens die Integration in das Web-Interface) und Produktionsreif ist es schon mal gar nicht. Man wird also noch ein wenig Geduld aufbringen müssen. Wenn die Integration weiter vorangeschritten ist wird es sicherlich eine Reseller-Preview geben und das Ganze wird dann Securepoint-typisch gut dokumentiert sowie einfach zu handhaben sein.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Ein gutes Jahr nach dem bei einem anderem Kunden ein LANCOM-Router durch eine Securepoint UTM ersetzt wurde und anschließend gut zwei Tage lang die Telefonanlage streikte folgt nun eine weitere Geschichte zu gleicher Kombi, aber mit neuen Überraschungen.

Für alle die es interessiert kann hier der erwähnte Beitrag nachgelesen werden:

Avaya IP Office-Telefonanlage: Kein Routing und kein DNS mehr nach Router-Tausch

Wer keine Lust hat, die Vorgeschichte zu lesen, kann hier direkt zur Konfiguration springen.

Ausgangslage und Vorgeschichte

Dieses Mal eine ähnliche Ausgangslage, d.h. der Kunde hat von der Telekom einen LANCOM-Router, der mittlerweile veraltet ist und den Ansprüchen nicht mehr gerecht wird sowie ebenfalls zum Einsatz kommt eine Avaya Office IP-Telefonanlage. Diese ist sogar halbwegs auf dem aktuellen Stand, allerdings haben es sich vor ein paar Jahren zuerst die Telekom und später Avaya selbst es sich leicht gemacht, als der Wechsel von ISDN zu VoIP erfolgte, soll heißen: Der SIP-Trunk wurde im LANCOM-Router eingerichtet und die vier Sprachkanäle wurden über die S0-Anschlüsse mit der PBX verbunden. Später bei einem Umbau oder eher einer komplett neuen Telefonanlage wurde dies einfach so übernommen bzw. weitergeführt.

Diese Kombination stand nun einem einfachen Router-Tausch im Weg, da zunächst der SIP-Trunk vom LANCOM in die Avaya wandern musste. Nebenbei bemerkt: Beide Geräte werden bzw. wurden durch uns nicht verwaltet oder unterstützt. Der anstehende Router-Wechsel wurde entsprechend bei Avaya angefragt mit der Bitte mitzuteilen, was denn alles sonst noch hinsichtlich des Netzwerks, etwaiger Firewall-Regeln, etc. benötigt wird. Zurück kam lediglich ein Angebot das die Nutzung von SIP-Trunk direkt in der PBX einen zusätzlichen Obolus pro Monat kostet (die Anlage ist wohl gemietet) und für die Änderung ein Technikereinsatz (kompletter Tagessatz) benötigt wird.

Persönliche Bemerkung (bis hier hin): Bei dem Angebot der Avaya war ich durchaus erstaunt, der zusätzliche Betrag für die Nutzung des SIP-Trunks ist zwar nicht sonderlich hoch, aber das so etwas extra kostet war mir neu. Auch das ein Techniker einen Tag braucht um einen (!) SIP-Trunk mit ein paar Rufnummern, also echt überschaubar, benötigen soll erschien mir bis hierhin seltsam.

Es folgte leider ein kleines hin und her zur Terminabsprache, irgendwie kam dann wohl die letzte Terminbestätigung auch nicht bei uns an. Gut eine Woche vor dem eigentlichen Termin meldete sich dann ein Avaya-Techniker mit ein paar Fragen und was nun anstehen würde und warum man denn den LANCOM loswerden wolle (die Kombi würde doch gut funktionieren), usw. Er war wohl auch mal kurz unangemeldet vor Ort. Zudem lies er verlauten, das man ein Software-Update auf der Anlage installieren müsste und das macht man in der Mittagspause, da es “eine Weile” dauern würde.

An diesem Punkt fragte ich mich schon, warum das so ist, da es laut Kunde einen Wartungsvertrag gibt. Warum ist dann die Anlagensoftware nicht aktuell?!

Der Tag X

Die erste oder wenn man nach dem Angebot so möchte zweite Überraschung folgte am Tag der Umstellung. Als ich morgens in den Hof des Kunden fuhr, standen da bereits zwei Avaya-Fahrzeuge. Ja, wie, zwei Techniker vor Ort?! Nach dem Ausladen, kurzer Vorstellung dann wirklich die Erkenntnis, die machen das heute zu zweit, also wirklich zwei erfahrene Techniker, also keine Kombi mit Azubi oder Praktikant bzw. Neueinsteiger oder sowas. Nicht das wir uns falsch verstehen, das hier ist nichts persönliches! Mit den Kollegen gibt bzw. gab es keine Schwierigkeiten, Techniker untereinander verstehen sich ja meist. Unschön ist einfach der (weitere) Ablauf.

Also meinerseits Router samt Peripherie ausgetauscht, geprüft ob man wieder online ist (die UTM war vorkonfiguriert), alles tutti, die Telefonanlage war zudem per Ping erreichbar, aber leider fing es erst jetzt richtig an.

Die Telefonanlage konnte nicht wirklich erreicht werden, weder über den IP Office-Manager oder -Admin (oder wie auch immer deren Software heißt) noch über das Web-Interface. Kurz nochmal nach der Route (die wir aus dem LANCOM-Router ausgelesen hatten) geschaut, diese ist vorhanden und greift.

An diesem Punkt muss man Wissen, das die Avaya dort einen eigenen Switch samt eigenem Netz hat. Die LAN-IP ist dabei dem Switch zugeordnet, der wiederum ins PBX-Netz routet.

LAN (192.168.0.0/24) -> PBX-Switch (192.168.42.0/24) -> PBX (192.168.42.1/32)

Kurz darüber nachgedacht, ja klar, es fehlt ein Netzwerkobjekt samt Portfilter-Regel(n) für dieses “pbx-network”, also angelegt, konfiguriert, geht immer noch nicht. Alles doof.

Das geht soweit auf meine Kappe, dafür stehe ich gerade und war ja auch schnell geklärt, gemeint sind die fehlenden Portfilter-Regeln. Aber auch schön zu sehen, das eine Securepoint UTM in Sachen Firewall und interner Netze da schon strikter ist als der alte Router. Besser wäre natürlich gewesen, wenn wir den Netzaufbau von Avaya gekannt hätten, dann hätte man das in der Werkstatt vorab berücksichtigen können.

In der Zwischenzeit behalfen sich die Avaya-Techniker damit, über den Management Port ihres Switches auf die Anlage zuzugreifen um weiter machen zu können. Da ich nicht mehr weiter wusste, rief ich bei Securepoint an und bat um Support, der sich kurze Zeit später meldete und die Sache mit dem nicht funktionierenden Zugriff zwischen den Netzen schnell klärte. Kurzum: Es handelt sich bei diesem Netzaufbau um ein asymmetrisches Routing.

Nachfolgend (m)ein Erklärungsversuch:

Bei TCP wird ein Paket an ein Ziel geschickt, für den Status (Flag) lautet die Reihenfolge:

SYN, SYN-ACK, ACK (Stichwort: Three-Way-Handshake)

Beim asymmetrischen Routing ist das allerdings nicht der Fall, da das Paket die UTM verlässt und durch eine weitere Firewall/Router/etc. (in diesem Fall der Avaya-Switch) weitergereicht wird. Folglich bleibt SYN-ACK aus oder die Antwort passt nicht zum ursprünglichen SYN, folglich verwirft die UTM das Paket.

An alle Netzwerker: Wenn das hier nicht stimmt, bitte Bescheid geben.

Asymmetrisches Routing in der UTM einrichten

Um nun dennoch den Datenverkehr zuzulassen müssen lediglich drei Punkte beachtet werden:

• Es muss eine Route zum Ziel-Netzwerk gesetzt sein.
• Bei Portfilter-Regel(n) muss für Aktion “Stateless” konfiguriert sein:
  
• Im “IDS / IPS” muss auf der Registerkarte “UNGÜLTIGE TCP-FLAGS” “NewStateWithoutSyn” deaktiviert sein:

Weiteres

Nun war geklärt, warum zunächst die Netze nicht miteinander reden konnten. Die nächste Überraschung folgte dann gleich und zwar in der Form, das die Vorgabe bei Avaya wohl ist, das über den WAN2-Port der PBX SIP-Trunks laufen sollten, ergo wollte ein Techniker mit seinem Kabel direkt auf die UTM. Das aber war nicht mehr möglich, da alle vier Ports der RC100 belegt sind:

• A0 – VDSL-Modem, wan0
• A1 – LAN
• A2 – LTE-Fallback (externes LTE-Modem)
• A3 – Zweiter DSL-Anschluss (über einen Zyxel-Router)

Ich bot an, via VLAN und dem LAN-Switch was zu machen, aber es hieß das wäre kein Problem, man nutze dann halt WAN1. Das klappte nicht auf Anhieb, weil, ich zitiere: “Da haben wir uns die Karten selbst gelegt, da eine Route gefehlt hat. Für WAN2 macht der Assistent das von selbst.”

Irgendwann lief dann doch der SIP-Trunk und dann kam die angekündigte Aktualisierung. Das oder eher die Updates brauchten mehr als eine Stunde, zwischendurch stürzte zudem der LAN-Port der Anlage mal ab, das merkte man aber nicht gleich und wartete und wartete und wartete…

Die Kollegen haben zeitweise (imho) recht viel mit ihrem Support telefoniert. Es schien als war da noch einiges mehr zu machen an “Feintuning”. Am Ende des Tages war dann wohl alles gut.

Persönliche Bemerkung

Trotz aller Überraschungen hat man wieder etwas dazugelernt. Dennoch bin ich enttäuscht, das trotz Bitte und Nachfrage für die Vorbereitung, was benötigt wird, usw. nichts von Avaya diesbezüglich zurückkam. Ich frage mich an dieser Stelle, wie man denn wohl bei größeren Kunden bzw. Projekten agiert.

Vielleicht liegt es ja auch an mir und meiner Herangehensweise. Mir ist immer daran gelegen, soviel wie möglich in der Werkstatt vorzubereiten, damit man vor Ort idealerweise nur noch kurz umstecken bzw. umbauen braucht. Das minimiert Ausfallzeit und sorgt für weniger Stress bei allen Beteiligten.

Am Beispiel des Internet- und VPN-Zugangs hat das so auch funktioniert, nach gerade mal 45 Minuten war der LANCOM raus, die UTM samt VDSL-Modem drin und online, ein externes LTE-Modem als Fallback ebenfalls installiert und eingerichtet (ich hatte vorher die SIM-Karte nicht) und an einem zweiten vorhandenen DSL-Anschluss der dortige Router (keine UTM) ausgetauscht und auch wieder online.

Schneller wäre es nur möglich gewesen, wenn im Netzwerkschrank mehr Platz gewesen wäre, damit man parallel zum Bestand VDSL-Modem und UTM hätte aufbauen können. Überhaupt nicht nachvollziehbar ist für mich, das die Telefonanlagensoftware nicht auf dem aktuellen Stand ist, bei den von uns verwalteten 3CX ist das nicht so, diese werden immer zeitnah aktualisiert und die dortigen Updates brauchen nicht so viel Zeit und SIP-Trunks (gemeint ist die Funktion, nicht irgendwelche Provider-Tarife) kosten nichts extra.

Danksagung

Einmal mehr ein fettes Dankeschön an den fachkundigen und schnellen Support von Securepoint!

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Wenn man über das Resellerprotal von Securepoint ein neues Ticket erstellt, kann man ungewollt auf die eine oder andere Hürde stoßen. Um so manchen Stolperstein zu umgehen nachfolgend ein paar Zeilen dazu.

So sind natürlich alle notwendigen Felder, mit einem * markiert, auszufüllen, und die der  Reihenfolge nach. Hat man beispielsweise einen Schreibfehler im Betreff entdeckt oder möchte man diesen ergänzen, kann man erst wieder in dieses Feld zurück, wenn man die Beschreibung ausgefüllt hat!

Speziell bei der Beschreibung kann man ungewollt auf zunächst unerklärliche Schwierigkeiten treffen, wenn beim finalen “Speichern” des Tickets schlicht nur folgendes erscheint:

Nicht gerade sehr informativ. Nach fünf Versuchen hatte ich dann raus, das es an einem in der Beschreibung eingefügten Log-Auszug lag, der wiederum eine Befehlszeile enthielt. Problem wenn man soweit gekommen ist das man speichern könnte, es gibt kein zurück, d.h. man steckt in diesem Fehler fest und darf das Ticket komplett neu erstellen.

Tipp: Alles markieren und in Notepad ö. ä. einfügen, so kann man das neue Ticket einfach per copy & paste füllen.

Bei der Produktversion sollte nur die Versionsnummer eingetragen werden:

• Falsch: UTM v12.2 – 12.2.1.2
• Richtig: 12.2.1.2

Macht man an dieser Stelle einen Fehler, bekommt man wenigstens eine Fehlermeldung im Klartext, die darauf hinweist, dass das Format nicht passt.

Es sind nur Kleinigkeiten die man beachten muss. Ärgerlich ist die fehlende Möglichkeit vor dem Speichern nochmal zurückgehen zu können. Ganz selten streikt das Ticketsystem aufgrund eines Ausfalls oder einer Wartung, im Großen und Ganzen läuft’s. Seit 2017 habe ich 35 Tickets erstellt, manche waren konkrete Fehler, manche Fragen, zwei Mal ein Defekt (in beiden Fällen die SSD). Soweit kann man glaub’ ich nicht meckern.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Am 01.03.2022 wurde in der Wunschbox zu GeoIP Block seitens Securepoint verkündet, dass das langersehnte Feature nun endlich kommt.

Hier ein Zitat vom entsprechenden Eintrag:

"Seit den Angriffen auf die Ukraine sind wir bei Securepoint in erhöhter Alarmbereitschaft.
So haben unsere automatischen Filtersysteme Threat Intelligence Feed und
Threat Intelligence Filter viele Angriffe eliminiert.

Die aktuelle Situation hat uns dazu bewogen,
die Fertigstellung des GeoIP-Filters zu beschleunigen.
Diese Funktion wird schon im nächsten Release 12.2.2 enthalten sein.
Der Release soll am 11.03.22 erscheinen.

Mit dem Release wird es möglich sein,
Regeln für Anfragen aus einzelnen Ländern oder
ganzen Kontinente auf Ebene des Portfilters festzulegen.

Auf diese Weise können etwa sämtliche aus Russland eingehenden Anfragen direkt
durch die Firewall blockiert werden."

Zum einen freue ich mich, das diese Neuerung bzw. Verbesserung nun endlich kommt, andererseits sind die aktuellen Umstände sehr unschön. Allerdings soll nicht unerwähnt bleiben, dass das IDS /IPS bereits einen sehr guten Job (zumindest bei uns und unseren Kunden) macht.

Generell Zugriffe aus unerwünschten Gegenden dieser Welt zu unterbinden erhöht ggf. nicht nur die Sicherheit, sondern vermindert (je nachdem welche Dienste man öffentlich anbietet) den Traffic.

Vorläufig abschließend sei darauf hingewiesen, das GeoIP-Filter ein weiterer Baustein in der IT-Sicherheit sind, aber keine generelle Lösung. Wenn jemand einen unbedingt Angreifen möchte, umgeht man diesen und weitere Schutzmechanismen beispielsweise via Tor oder durch VPN-Dienste oder Proxies um die eigene Herkunfts-IP-Adresse zu verschleiern. Unnütz ist es in keinem Fall, wie Beispiele in diesem Blog und Erfahrungen bei Kunden gezeigt haben.

Eine kleine Randnotiz ganz zum Schluss: Ich war schon drauf an dran mittels CLI und entsprechenden Länder-IP-Listen ein DIY GeoIP-Block für die UTM zu basteln. Die weiteren arbeiten daran kann ich mir nun ja sparen.

Update 02.03.2022

Mittlerweile wird ein aktueller Newsletter zu diesem Thema seitens Securepoint an die Partner versendet:

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Nach dem Ersetzen einer pfSense durch eine Securepoint UTM erhielt ein Notebook via DHCP keine IP-Adresse mehr, natürlich (gemäß Murphys Law) das vom Chef.

Direkt grafisch hat man an dem Notebook nicht viel gesehen, es wurde zwar angezeigt, das man mit dem WLAN verbunden sei, aber kein Internet habe. In der Eingabeaufforderung mittels “ipconfig /all” sah das schon anders aus, dort fand sich eine APIPA-Adresse. Gab man die IP-Adresse mit “ipconfig /release” frei und wollte eine Neue vom DHCP-Server mittels “ipconfig /renew” erhalten bekam man folgende Fehlermeldung:

"Beim Aktualisieren der Schnittstelle "WLAN" ist folgender Fehler aufgetreten:
Der im Netzwerkkontrollblock (NCB) angegebene Name ist auf einem Remoteadapter
in Verwendung. Die Daten stehen im NCB."

Kurz danach recherchiert findet man z.B. diesen Beitrag:

Linuxpeter Softwareblog – Windows: Der im Netzwerkkontrollblock (NCB) angegebene Name …

Kurzum: Das Problem liegt auf der Seite des DHCP-Servers, am Client kann man nichts machen. In diesem Fall läuft der DHCP-Server auf einem Windows Server 2021 R2 Standard. Dort in die DHCP-MMC geschaut fand sich nichts verdächtiges, es gab kein Lease passend zur MAC-Adresse des betroffenen Notebooks, auch nichts mit “BAD ADDRESS” o.ä. Ein Neustart des DHCP-Server(-Dienstes) änderte an dem Problem ebenfalls nichts.

Als Workaround wurde auf dem Notebook für das WLAN-Netz die zufällige MAC-Adresse aktiviert:

Nach dem erneuten de-/aktivieren des WLANs auf dem Notebook klappte die Verbindung wieder. Vier Tage später sollte das Thema nochmal angegangen werden, also wurde die “Zufällige Hardwareadresse” wieder deaktiviert, WLAN de- und erneut aktiviert und siehe da, es läuft alles wieder wie es soll.

Es scheint als habe der DHCP-Server oder ggf. das DHCP-Relay in der pfSense oder Securepoint UTM, irgendwo etwas zwischengespeichert. Die Relays halte ich allerdings für eher unwahrscheinlich, da diese die DHCP-Anfragen lediglich an den DHCP-Server weiterreichen.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Hat man bei der Nutzung des DHCP-Relays bei einer Securepoint UTM eine ungewöhnlich hohe Last auf der UTM und wird dazu das Log (“Nur Applikations- und Kernel-Meldungen anzeigen”) mit Meldungen vom DHCP-Relay geflutet gibt es mit Sicherheit einen Fehler in der Konfiguration.

DHCP-Relays sind eine feine Sache, wenn es nur einen zentralen DHCP-Server gibt, der für mehrere Netze zuständig ist. Dabei kommuniziert das Relay über die Ports 67/udp und 68/udp, es nimmt die Broadcasts der DHCP-Clients auf und leitet Sie (in ein anderes Netz) zum angegebenen DHCP-Server weiter. In der Regel klappt dies ohne Probleme. Im Falle einer UTM von Securepoint muss man dazu dank der impliziten Regeln keine zusätzliche Portfilter-Konfiguration vornehmen. Lediglich unter

Netzwerk - Netzwerkkonfiguration - DHCP-Relay

muss für IPv4 und IPv6 die IP-Adresse des DHCP-Servers eingetragen und die genutzten Schnittstellen ausgewählt werden. Das Einzige was es zu beachten gilt ist nur die Schnittstellen respektive Netze auszuwählen, die den DHCP-Server nutzen möchten abzüglich der Schnittstelle/des Netzes in dem sich der DHCP-Server befindet!

Gibt man auch die Schnittstelle bzw. das Netz im DHCP-Relay an, in dem sich der DHCP-Server befindet führt dies zu einer Reihe von Problemen. Kurios kann dabei wirken, das manche Clients eine IP-Adresse erhalten, andere wiederum nicht. Unter Windows (in der Eingabeaufforderung) kann einem die Meldung

"Beim Aktualisieren der Schnittstelle "LAN" ist folgender Fehler aufgetreten:
Der im Netzwerkkontrollblock (NCB) angegebene Name ist auf einem Remoteadapter
in Verwendung. Die Daten stehen im NCB."

begegnen, andere Clients wie beispielsweise Apples iOS zeigen wiederum überhaupt keinen Fehler an, es erhält schlicht keine IP-Konfiguration und meldet keinen Internet-Zugang. Auf der UTM selbst macht sie diese fehlerhafte Konfiguration zum einen in einer höheren Last bemerkbar und das es im Log ununterbrochen Meldungen des DHCP-Relays gibt. In letzterem kann man den Ablauf beobachten:

Zunächst gibt es einen DISCOVER oder REQUEST vom DHCP-Client, darauf folgt ein OFFER vom DHCP-Server. Normalerweise würde als nächstes ein ACK folgen, aber es kommt zu einem NACK, also einer Ablehnung durch den DHCP-Server.

Schaut man sich die Meldungen genau an, erkennt man die jeweilige Schnittstelle über die die Kommunikation gerade abläuft:

REQUEST from LAN2/0.0.0.0 for 00:12:34:56:ab:cd (<hostname-des-Clients>) to 255.255.255.255 forwarded to 192.168.175.20

Wird der DHCP-Server nun beispielswiese in LAN2/A1, für gewöhnlich “internal-network”, betrieben und erscheinen Meldungen wie DISCOVER oder REQUEST auf dieser Schnittstelle, so ist diese mit Sicherheit (aus Versehen oder im Übereifer) in der Konfiguration des DHCP-Relays eingetragen worden und muss entfernt werden. Sobald man dies getan hat, geht die Last schlagartig runter und auch das Log wird wesentlich ruhiger:

Quellen

Wikipedia – Dynamic Host Configuration Protocol

Microsoft – TechNet – Forum – Windows (DHCP) Server replying with DHCP NAK (RFC3527 Link Selection sub-option)

Microsoft – Docs – DHCP-Subnetzauswahloptionen

ADMINISTRATOR – Probleme mit DHCP Relay und Firewalls

VirtualizationHowto – Windows Server DHCP VLAN Configuration: Detailed Guide

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

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.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Viele NAS-Modelle von Synology können außer Netzwerk-Speicherfunktionen unter anderem zum VPN-Server gemacht werden. An Protokollen steht neben L2TP/IPsec unter anderem PPTP und OpenVPN zur Verfügung.

Bei einem Kunden streikte nach einem Update des Securepoint SSL-VPN Clients der Verbindungsversuch mit folgender Protokoll-Meldung:

ERROR: Unsafe configuration found: use of script-security greater than 1.
This connection is rejected!
For further informations see: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4, section: script-security level

Die Ursache bzw. der Hintergrund hierzu ist, das die aus dem NAS exportierte Konfigurationsdatei folgende Zeile enthält:

script-security 2

Eine Änderung auf den Wert 1 änderte allerdings nichts. Erst das Löschen der Zeile oder Auskommentieren mit einer vorangestellter Raute (#) samt Reimport in den VPN-Client löst das Problem.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Die Lüneburger IT-Sicherheitsspezialisten von Securepoint bieten für alle seit dem 01.06.2022 erworbenen oder gemieteten UTMs kostenlosen Vor-Ort-Service an. Mögliche Ausfallzeiten durch defekte Geräte werden weiter minimiert, da in der Regel innerhalb eines Werktags ein Austauschgerät zur Verfügung steht und von einem Service-Partner vor Ort beim Kunden ausgetauscht wird.

Nachfolgend die Pressemitteilung vom 08.06.2022:

Kostenloser Vor-Ort-Service für mehr KMU-Sicherheit

Bei allen seit dem 01.06.2022 erworbenen UTM-Desktop-Firewalls von Securepoint ist ab
sofort ein kostenloser Vor-Ort-Service (VOS) enthalten. Der Dienst gilt für entsprechende
Kauf- oder Mietmodelle des deutschen Herstellers. Systemhäuser und IT-Dienstleister
können sogar selbst zum Vor-Ort-Servicepartner werden und sich Einsatzzeiten vergüten
lassen.

“Wir haben uns zu diesem Schritt entschieden, weil wir durch möglichst kurze Ausfallzeiten
einen entscheidenden Beitrag zur Cybersicherheit kleiner und mittlerer Unternehmen leisten können. Im Vergleich zum regulären Bring-In-Service reduziert sich die Ausfallzeit durch den Vor-Ort-Service um bis zu 80 Prozent. Für Systemhäuser und Anbieter von Managed Security bedeutet das einen echten Service-Vorteil, für Endkunden einen weiteren Gewinn an IT-Sicherheit“, erläutert Eric Kaiser, Product Management Director bei Securepoint.

Der Austausch defekter UTM-Geräte erfolgt beim VOS ohne zusätzliche Kosten innerhalb eines Werktages durch einen Vor-Ort-Servicepartner des Herstellers. Fachhändler und Systemhäuser können durch einen individuellen Servicepartnervertrag zudem selbst zum Vor-Ort-Servicedienstleister werden. Die entsprechenden Einsatzzeiten werden dadurch vergütet.

Der VOS beinhaltet die Kauf- sowie die „as a Service“-Modelle der Black Dwarf G3, G5 und G5 Pro sowie die RC100 G5 und die RC200 G5. Zusätzlich ermöglicht der Lüneburger IT-Sicherheitshersteller auch einen kostenlosen Vor-Ort-Service für die entsprechenden „as a
Service“-VPN-Geräte.

Securepoints VOS ist in Deutschland, Österreich und der Schweiz verfügbar.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Versucht man bei einem ASUS ASMB8-iKVM eine Verbindung via “Remote Control – Console Redirection” aufzubauen, kann es kurz nach dem Start des Java Applets zu der Fehlermeldung “Video Socket Error: Abnormal Termination” kommen.

In der Regel kommt es zu dieser Fehlermeldung wenn man sich entweder in einem anderen Subnetz befindet (weiteres LAN, VLAN, VPN, …) oder ein Proxy dazwischen ist.

In solchen Fällen lohnt ein Blick in das Protokoll der Firewall die zwischen den Netzen sitzt, womöglich findet man hier schon entsprechende Treffer. Liegt es nicht am Regelwerk, kann es an einem Proxy liegen. Am Beispiel einer Securepoint UTM war der Transparente Proxy der Schuldige, an dieser Stelle eine Ausnahme festgelegt und das Zugriff gelang.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, dem Betrieb von Servern und Diensten.

www.andysblog.de/

Irgendwie habe ich mit der pfSense, wohlgemerkt in der Community Edition (CE), kein Glück mehr. Gefühlt seit Anfang 2021 gibt es immer häufiger Schwierigkeiten.

Das fing mehr oder weniger mit dem Absturz des DNS-Dienstes an, ging mit WireGuard weiter und traf schließlich auf OpenVPN, dazwischen gab es noch mehr, das sind allerdings so spontan die gröbsten Schnitzer die mir eingefallen sind. Irgendwie konnte immer alles umgangen oder gelöst werden, Spaß machen tut das so allerdings keinen.

Im Großen und Ganzen habe ich mit pfSense mittlerweile nichts mehr zu tun, das Hauptaugenmerk liegt mittlerweile schlicht auf Securepoint UTM. Es gibt lediglich noch eine pfSense-Installation in unserer Werkstatt die sporadisch entweder für Site-to-Site-OpenVPN, als PPPoE-Server genutzt wird, oder eben mal irgendwas ausprobiert wird.

Schon fast aus Tradition wollte ich jetzt das Site-to-Site-Thema hinsichtlich WireGuard aktualisieren, schließlich gab es ein paar Beiträge die sich damit befassten wie man das Ganze mit OpenVPN und Securepoint UTM macht. Wie schon beim WireGuard-Roadwarrior-Setup habe ich irgendwie keinen richtigen Erfolg dabei.

Auf Securepoint UTM-Seite diente die Anleitung aus dem Wiki dazu, den WireGuard-Teil einzurichten:

WireGuard Site-to-Site VPN (S2S)

Als Richtschnur für die pfSense-Seite diente unter anderem die Original-Dokumentation von Netgate:

WireGuard Site-to-Site VPN Configuration Example

Andere Dokus + Recherche wurden ebenfalls zu Rate gezogen.

Die Schlüssel erzeugen und entsprechend eintragen war dabei noch kein Problem. Der Handshake beiderseits klappt ebenfalls und ein- sowie ausgehenden Datenverkehr gibt es auch. Fehlt eines der beiden letztgenannten ist das im Rahmen des WireGuard-Troubleshootings immer ein Indikatoren dafür das irgendetwas mit den Schlüsseln nicht stimmt. Firewall-Regeln ebenso kein Ding und dennoch gibt’s ein Problem:

Von der UTM-Seite aus kann auf das entfernte Netz inkl. der pfSense zugegriffen werden. Umgekehrt, also von pfSense-Seite aus zur UTM und dem UTM-Netz, klappt das leider nicht.

Es gibt auf beiden Seiten keine Treffer in den Firewall-Logs, ergo sollten es die jeweiligen Regelwerke nicht sein. (Imho) Sieht das Ganze irgendwie nach Routing aus, wenn gleich mir nicht klar ist, warum es in einer Richtung funktioniert, allerdings ist die Routing-Konfiguration auf der pfSense auch relativ komplex.

Nach tagelangen probieren, abreißen, (wieder) neu machen, usw. habe ich das Ganze dann mal mit OpenWRT ausprobiert. Die UTM-Seite ist geblieben wie sie ist und die pfSense wurde durch OpenWRT ersetzt. Die gleichen Schlüssel und Netze wurden verwendet und siehe da, es läuft auf Anhieb. Dafür das ich zuvor noch nie etwas mit OpenWRT gemacht habe und echter Glückstreffer, ergo wird es vmtl. bald einen Beitrag hierzu geben. Der Vollständigkeit halber sei erwähnt, das Site-to-Site VPN auf WireGuard-Basis zwischen zwei Securepoint UTMs (natürlich) auch funktioniert.

Diese Zeilen sollen nun nicht als Abgesang auf pfSense (CE) verstanden werden, zumal es einen Unterschied macht, ob man die Community- oder Kommerzielle-Ausgabeverwendet. Ersteres bekommt keinen kommerziellen Support, letzteres schon.

Es ist halt frustrierend wenn man so lange an einem Thema “tüftelt” und es einfach nicht richtig funktionieren mag. Falls sich nochmal etwas Zeit und Nerven finden wird das nochmal angegangen.

Wenn jemand von euch das Problem kennt oder eine Idee dazu hat, dann einfach ein Kommentar schreiben.

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, dem Betrieb von Servern und Diensten.

www.andysblog.de/