lcer00
Goto Top

Aktuelle Azure IPs per URL Table List in firewall der OPNSense einbinden

Hallo zusammen,

in Corona- und Schneechaoszeiten hat man ja etwas Zeit. Folgendes ist dabei rausgekommen.

Ziel war es, für die Firewall unserer OPNSenses die Azure IP-Adressen als Alias automatisiert einzupflegen. Wir nutzen den Alias um die Verbindung zu Azure in der Firewall (OPNSense) zu erlauben und den Rest des Internets zu verbieten.

Das ganze habe ich wie folgt realisiert:


back-to-topSystemumgebung

  • OPNSense 20.7.8
  • Windows Server 2012R2 mit IIS und Powershell 5.1
  • ein Azure Abonnement

Wobei hier eigentlich nur Powershell 5.1 eine Mindestanforderung ist. IP-Listen kann man auch mit anderen Webservern bereitstellen und andere Firewalls können sie ebenfalls nutzen.

back-to-topIP-Adresslisten besorgen.

Microsoft stellt dazu freundlicherweise das Powershell CMDlet Get-AzNetworkServiceTag zur Verfügung.

Damit kann man die Daten automatisiert herunterladen. Realisiert habe ich das dann mit folgendem Powershell-Skript:
#connect-azaccount
#set-AzContext -Subscription "Subscrition-Name"  
$tags = get-AZNetworkServiceTag -Location "germanywestcentral"  
$AddressPrefixes = New-Object System.Collections.Generic.List[string]
$tags.Values.Properties | Where-Object { $_.SystemService -eq "AzureStorage" } | Where-Object { $_.Region -eq "westeurope" } | Foreach-Object { $AddressPrefixes.AddRange( $_.AddressPrefixes ) }  
$tags.Values.Properties | Where-Object { $_.SystemService -eq "AzureEventHub" } | Where-Object { $_.Region -eq "westeurope" } | Foreach-Object { $AddressPrefixes.AddRange( $_.AddressPrefixes ) }  
$tags.Values.Properties | Where-Object { $_.SystemService -eq "AzureIdentity" } | Where-Object { $_.Region -eq "" } | Foreach-Object { $AddressPrefixes.AddRange( $_.AddressPrefixes ) }  
$AddressPrefixes | out-file -FilePath C:\inetpub\wwwroot\firewall\AzureIPs.txt  -Encoding Utf8
Das Skript ist nicht perfekt. Insbesondere fehlt noch die Fehlerbehandlung.

back-to-topAber der Reihe nach

back-to-topAzure-Benutzer anlegen
Das Skript muss über Zugangsdaten zu Azure verfügen. Dazu habe ich im Azure Active Directory einen Benutzer angelegt und in Azure mit Leserechten versehen. Dazu muss man über ein Azure-Abonnement verfügen. Das zu Azure Active Directory gehörende Abonnement "Zugriff auf Azure Active Directory" genügt dazu nicht.
Man navigiert zum Abonnement Home -> Kostenverwaltung + Abrechnung, wählt den Abrechnungbereich und dann das Abonnement. Anschließend wählt man den Menüpunkt "Zugriffssteuerung (IAM)". Dort findet man unter "Zugriff auf diese Gruppe gewähren" dem Punkt "Rollenzuweisungen hinzufügen". Als Rolle wählt man z.B: "Leser" aus. Man kann hier die Rechte auch restriktiver vergeben, aber die dazu passende Rolle bzw. die entsprechende Berechtigung habe ich noch nicht herausgesucht.

Damit sind die Vorarbeiten in Azure erledigt.

back-to-topPowershell Modul installieren
Get-AZNetworkServiceTag ist im Modul Az.Network von Azure Powershell enthalten. Informationen zur Installation fondet man hier: https://docs.microsoft.com/en-us/powershell/azure/servicemanagement/inst ...
Eine korrekte Installation vom PowershellGet vorausgesetzt, gibt man einfach ein:
Install-Module Azure

back-to-topAzure-Context initialisieren
Das Skript soll später per regelmäßig über die Windows Aufgabenplanung aufgerufen werden. Folgende Schritte sind deshalb unbedingt unter dem Account des Benutzers, der später in der Aufgabenplanung angegeben wird auszuführen!
connect-azaccount
set-AzContext -Subscription "Subscrition-Name"  
Beim Verbinden wird der oben Vorbereitete Azure Account verwendet. Subscription-Name ist hier der beschreibende Bezeichner des Abonnements, der in Azure als "Angebot" benannt ist.

Weitere Informationen zum Speichern des Kontexts gibt es hier:

Das ist ganz nett, der Zugang zu Azure wird allerdings innerhalb des Benutzerprofils (USERPROFILE\.Azure ) gespeichert.

back-to-topAufgabenplanung
Über eine geplante Aufgabe wird das Skript aufgerufen. Dieses ruft die erforderlichen Daten ab und erzeugt eine Datei in einem Ordner des Webservers.
Aktion:			Programm starten
Programm/Skript:	powershell.exe
Argumente:		-Command "&'E:\Skripte\update-firewall-alias.ps1'"  
Als Benutzer muss der Benutzer angeben werden, für den der Azure-Context gespeichert worde. Die ersten beiden Zeilen sind des Skriptes sind auskommentiert. Diese sind nur erforderlich, wenn sich der Azure-Context oder der Benutzer ändert. Dann muss das Skript interaktiv ausgeführt werden, die beiden Zeilen sind wieder einzufügen.
connect-azaccount
set-AzContext -Subscription "Subscrition-Name"  
Das Skript sollte im angegebenen Verzeichnis eine Datei mit den IP-Adressen erzeugen.

back-to-topWebserver
Wählt man eine andere Dateiendung als txt, muss man sicherstellen, dass diese vom Webserver ausgeliefert wird. Der Webserver muss natürlich von der OPNSense erreichbar sein.

back-to-topOPNSense
Die Einrichtung von IP-Listen ist beispielhaft für Spamhouse DROP & EDROP in der OPNSense-Doku beschrieben: https://docs.opnsense.org/manual/how-tos/edrop.html Die Einrichtung unserer Liste erfolgt analog. Man definiert einen Alias mit der Eigenschaft "URL Table (IPs)" und der URL der Liste als Host. Für testzwecke sollte man zunächst eine Refresh Frequency von 0 Tagen und z.B. 0.01 Stunden einstellen. Später stellt man auf einen längeren Zeitraum um (z.B. 1 Tag).

Erfolg oder Fehler des Einbindens kann man unter System -> Protokolldateien -> Allgemein nachlesen. Im Erfolgsfall wird dort folgendes geloggt:
2021-02-12T12:42:01	/update_tables.py[50014]	fetch alias url http://192.168.50.53/firewall/AzureIPs.txt (lines: 948)
Das ganze klappt nur, wenn die Datei UTF-8 kodiert ist. Daher die steht im Skript auch "-Encoding Utf8"

back-to-topTestphase
Wir nutzen den firewall-Alias zum Erlauben der Azure-Verbingung für bestimmte Server. Hier sollte man die Liste auf ein Minimum an Einträgen beschränken. Dazu kann man wir folgt vorgehen:

Zur Testphase benötigt man die gesamte Liste AzureNetworkTags. Diese habe ich mir bequem unter https://docs.microsoft.com/en-us/azure/virtual-network/service-tags-over ... (ganz unten: Discover service tags by using downloadable JSON files -> Azure Public - nicht Germany, das ist die alte Deutschland-Cloud von MS) heruntergeladen.

Zunächst lässt man die Firewall alles blocken (und das geblockte loggen) und checkt die geblockten IPs gegen die Liste. Sollte es mehrere Treffer geben, nimmt man den spezifischesten. Im JSON file sind dann die Attribute "systemService" und "region" relevant. Diese setzt man im Skript ein:
$tags.Values.Properties | Where-Object { $_.SystemService -eq "AzureStorage" } | Where-Object { $_.Region -eq "westeurope" } | Foreach-Object { $AddressPrefixes.AddRange( $_.AddressPrefixes ) }  
$tags.Values.Properties | Where-Object { $_.SystemService -eq "AzureEventHub" } | Where-Object { $_.Region -eq "westeurope" } | Foreach-Object { $AddressPrefixes.AddRange( $_.AddressPrefixes ) }  
$tags.Values.Properties | Where-Object { $_.SystemService -eq "AzureIdentity" } | Where-Object { $_.Region -eq "" } | Foreach-Object { $AddressPrefixes.AddRange( $_.AddressPrefixes ) }  

Es gibt bei Microsoft auch infos zu des Tags, Servicenamen und Regionen. Die sind allerdings nicht zielführend:

Letztlich habe ich mittels Trial&Error iterativ die für mich passenden Einträge gefunden.

back-to-topToDo
  • Fehlerbehandlung im Skript vergänzen
  • Liste sortieren und Duplikate entfernen
  • Einschränken der Leserechte des Azure-Benutzers durch passendere Rollenzuweisung
  • SystemService und Region besser verstehen face-smile

Grüße

lcer

Content-Key: 651190

Url: https://administrator.de/contentid/651190

Ausgedruckt am: 28.03.2024 um 08:03 Uhr