205 Stimme

Wildcard FQDN für Hostname basierte Netzwerkobjekte (Portfilter)

In der Praxis geben "die Anbieter" (gerne ist das Microsoft mit Azure) ganz bewusst keine Liste von IPs oder DNS-Namen heraus. M$ eine Liste der FQDNs bestimmter Dienste aus den Rippen zu leiern ist praktisch unmöglich. Oft sollen auch temporär Dienste auf dedizierten Hosts (Datenbanken etc.) on demand und/oder automatisiert bereitgestellt und genutzt werden. Auch dann ist es nützlich, wenn eine Wildcard verwendet werden kann, um Servernamen wie FQS33MX.tennant05431108.databases.azure.com (oder so) pauschal unter *.tennant05431108.databases.azure.com berechtigen zu können.

  • Guest
  • Jul 22 2021
  • Feedback von der Community erwünscht
  • Attach files
  • Guest commented
    10 Nov 08:29

    Hallo Team Securepoint,

    gibt es zu dem Thema FQDN Wildcard (*.domain.com) ein Update oder ein release date?
    Das Feature wird wirklich sehr dringend benötigt und ist heute auf keiner Firewall mehr wegzudenken.

    Wir bitte um ein Feedback.
    Danke

  • Guest commented
    01 Nov 10:12

    *Push*

  • Guest commented
    22 Aug 08:52

    Gibt es schon ein Update dazu?

  • Guest commented
    06 May 06:30

    Tatsächlich zunehmend notwendig. Bin gerade auch ratlos wie ich das jetzt ohne ein Update pfuschen kann.

  • Guest commented
    October 22, 2023 05:28

    Hallo Securepoint,


    dieses Feature wird dringend benötigt um uns den Arbeitsalltag in der Cloudwelt zu vereinfachen.

    Gibts schon nen neuen Status oder evtl. ein release date für das Feature?

  • Guest commented
    September 06, 2023 11:32

    Wir steigen gerade von Sophos UTM um. Dort gibt es Netzwerkobjekte, die sich DNS-HOST (eine auflösbare IP) oder DNS-GRUPPE (mehrere auflösbare IPs) nennen und die ensprechend nicht statisch sind. Solche Objekte werden wirklich dringend benötigt als kleinster, gemeinsamer Nenner.

  • Guest commented
    December 02, 2022 07:37

    Gibt es zu diesem Thema etwas Neues? Wir arbeiten mit Azure und Amazon Tenants und es ist sehr mühselig diese alle als Netzwerkobjekt anzulegen.

  • Guest commented
    June 09, 2022 16:53

    Ein sehr wichtiges Thema da die Dienstanbieter mittlerweile häufiger mitteilen, dass *.Domain.com freigeschaltet werden sollen über die Ports XYZ.



    Insbesondere bei großen Anbietern die Dienste in Azure / AWS etc. hosten und diese ständig erweitern ist das Feature ein MUSS.

  • Guest commented
    February 18, 2022 15:54

    Wäre auch super, wenn SRV-Records aufgelöst werden könnten. Telekom IP-Telefonie/SIP-Trunk macht in dieser Hinsicht Probleme. Wildcard FQDN im Allgemeinen fände ich auch super. Auch Hersteller von Medizinsoftware haben oft dieses Wildcard-Problem.

  • Guest commented
    August 16, 2021 14:22

    Das Feature wäre sehr wünschenswert. Wir haben das Problem bei Datto, AWS, Adobe CC, Azure... The List goes on. Teilweise kann man die IPs nur aus dem Logfile erkennen, da es manchmal überhaupt keine Informationen seitens der Anbieter gibt, außer: *s3*.amazonaws.com erlauben.

  • Guest commented
    July 23, 2021 09:24

    Ich habe das Problem auch und wäre mit einer bedingten Lösung zufrieden. "Bedingt" insofern, als dass dann eben die Auflösung über die UTM erfolgen muss. Auch ein Domänencontroller kann sich ja seine DNS-Auflösung von der UTM holen etc. Spannend stelle ich mir eher vor, dass ja im selben Moment der DNS-Auflösung auch der Portfilter aktualisiert werden muss. Da könnte ich mir vorstellen, dass es zu Problemen kommt, wenn eine Anwendung wenig Toleranz bei Fehlern bzw. TimeOuts zeigt.

  • Admin
    Produkt Manager commented
    July 22, 2021 15:14

    Wir haben den Wunsch ja selber eingestellt :-)

    Der Anwendungsfall ist klar und DANKE für die gute Beschreibung.

    Ggf. gibt es ja noch Ideen wie man so etwas umsetzen kann. Deswegen hatte ich versucht die existierenden Konzepte und ihre Probleme zu beschreiben.

    Ich habe diese mal in die Wunschbeschreibung mit aufgenommen.

  • Guest commented
    July 22, 2021 15:04

    In der Praxis geben "die Anbieter" (gerne ist das Microsoft mit Azure) ganz bewusst keine Liste von IPs oder DNS-Namen heraus. M$ eine Liste der FQDNs bestimmter Dienste aus den Rippen zu leiern ist praktisch unmöglich. Oft sollen auch temporär Dienste auf dedizierten Hosts (Datenbanken etc.) on demand und/oder automatisiert bereitgestellt und genutzt werden. Auch dann ist es nützlich, wenn eine Wildcard verwendet werden kann, um Servernamen wie FQS33MX.tennant05431108.databases.azure.com (oder so) pauschal unter *.tennant05431108.databases.azure.com berechtigen zu können.

  • Admin
    Produkt Manager commented
    July 22, 2021 14:31

    Im Normalfall sollte für eine Cloud Anwendung oder ein Cloud-Dienst ein oder mehrere feste A-Records vom Provider zur Verfügung gestellt werden. Bei vielen Diensten ist das auch möglich. Spannend wird das wie. Wenn man z.B. ein Netzwerkobjekt *.securepoint.de erstellt gibt es ja keine Möglichkeit herauszufinden welche DNS-Einträge sich dahinter verbergen. Man müsste also DNS-Anfragen von Applikationen und Clients auswerten und diese "on-the-fly" in den Portfilter einbauen. Das funktioniert aber auch nur solange, wie die Anwendung oder der Client DNS über die Firewall verwendet. Ist in der Anwendung eine IP hinterlegt oder wird DNS über https aufgelöst gibt es keine Chance für die UTM hier zu reagieren. Oder ich habe an meinem Client gerade eine VPN-Verbindung in ein anderes Netzwerk offen und nutze den DNS-Server dort, dann bekommt meine lokale Firewall wieder nichts davon mit. Also eine sehr instabile Lösung. Für den Anbieter wäre es allerdings ein leichtes mir eine Liste der DNS-Einträge, die ich berücksichtigen muss, zu geben.

  • Guest commented
    July 22, 2021 13:33

    Für Cloud- und Hybrid-Szenarien ein sehr wichtiges Feature.