Sentinel HASP Dongle / Broadcast auf UDP 1947

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
tlietz
Beiträge: 10
Registriert: Mi 12.06.2019, 08:53

Sentinel HASP Dongle / Broadcast auf UDP 1947

Beitrag von tlietz »

Hallo zusammen,

wir verwenden bei uns im Netzwerk eine Software die an einem Rechner einen Lizenzdongle vom Typ Sentinel HASP verwendet.
Alle Clients die die Software nutzen wollen fragen per Broadcast an Zielport UDP 1947 nach diesem Rechner - die Pakete werden aber gedroped weil es wohl keine passende Regel gibt: 

Code: Alles auswählen

DROP: (DEFAULT DROP)192.168.29.2:65084  eth1  192.168.29.255:1947 UDP
oder aber auch

Code: Alles auswählen

DROP: (DEFAULT DROP)192.168.29.2:65084  eth1  255.255.255.255:1947 UDP
Ich habe versucht mittels folgendem Portfilter die Pakete zu erlauben aber ohne Erfolg:

Code: Alles auswählen

internal-network	internal-broadcast	hasp		ACCEPT
internal-network        broadcast               hasp            ACCEPT
Wobei hasp als UDP 1947 sowie internal-broadcast als 192.168.29.255/23 und broadcast als 255.255.255.255/32 definiert ist.
Musste ich hier überhaupt die broadcast Objekte anlegen? Im Forum las ich das die UTM grundsätzlich alle Broadcast Pakete dropt, hat das Gründe?

Bei der Gelegenheit eine Anfängerfrage: Wann verwendet man in dem Portfilter als Ziel das interface und wann das network?

Vielen Dank & Gruß

HaPe
Beiträge: 56
Registriert: Di 09.05.2017, 22:40

Beitrag von HaPe »

Hallo,

die Pakete werden klarerweise von der UTM gedropped weil - kurz und bündig: Was soll sie mit dem Sentinel Lizenzdongle?
Dass die UTM die Broadcastpakete dropped heißt ja nur, dass sie diese nicht empfängt (oder viell. besser formuliert: verarbeitet) - andere Geräte, die an der selben Schnittstelle und somit wahrscheinlich auch im selben LAN hängen sind davon klarerweise nicht betroffen (die empfangen den Broadcast ja wie gehabt weiterhin).

Was klarerweise nicht geht ist Dongle steckt im internal-lan und der Client dazu steht in der DMZ.

Portfilterziele:
Die network-Objekte stehen sozusagen für ein komplettes Subnet - allerdings exkl. Schnittstellen der UTM im jeweiligen Subnet
Um auf ein UTM-Interface zugreifen zu können, benötigt man immer eine Regel mit dem jeweiligen interface-Objekt als Ziel

Beispiel: SSLVPN - internal-lan

SSLVPN     internal-lan      any      ACCEPT
SSLVPN     internal-interface      dns     ACCEPT

Nun könnte man meinen, DNS mit dem internal-interface als Server funktioniert aus dem VPN heraus - tut es allerdings erst dann, wenn auch die 2. Regel dazu angelegt wird.
DNS aus dem VPN heraus mit einem Server, der im internal-lan steht (z.B. DC) - dafür reicht die erste Regel aus (die gibt dann allerdings aus dem VPN heraus alles auf allen Geräten (außer der UTM) im internal-lan frei, wäre also etwas zuviel des Guten sofern´s nur um DNS ginge).

Auch wenn´s manchmal nervt - ich würde die ganzen Broadcasts jedenfalls nicht durchlassen, weil
a) wird man mit Regel anlegen nicht fertig (heute schaut einer mit installierter Dropbox vorbei, morgen tauscht der ISP den Router (da sind manche auch sehr neugierig), übermorgen ein neuer Lizenzdongle, und in 2 Monaten kommt irgendein Virus daher der auch munter Broadcasts verschickt, ...)
b) kann man so relativ fix - zumindest in Kombination mit den Logs am SOC - feststellen, wer z.B. eine Dropbox am Laufen hat
c) hab ich zugegebenermaßen auch schon mit dem Gedanken gespielt Broadcasts einfach zu erlauben oder zumindest ohne Logging zu droppen - bin daran allerdings auch bravourös gescheitert... :lol:

Was man allerdings machen könnte: In den Servereinstellungen unter "Erweiterte Einstellungen" das Last-Rule-Logging anders einstellen - wenn viell. auch nur temporär.

Svenja
Beiträge: 85
Registriert: Mo 16.04.2018, 12:00

Beitrag von Svenja »

Moin!

Die UTM wird den Broadcast niemals routen, denn Broadcast kann man nicht routen ;-)
Sollte hier ein Routing benötigt sein, dann über Multicast

Grüße
Svenja

Antworten