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.

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.

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.

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.

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.

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.

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.

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.

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