Freigeben über

Verwalten der Host-Firewall mit Azure IoT und OSConfig

  • Artikel

Wichtig

Version 1.0.3 (veröffentlicht am 28. Juni 2022) umfasst die Unterbrechung von Änderungen an Membernamen, die sich auf vorhandene Benutzer auswirken können. Weitere Informationen finden Sie unter: Membernamen Übergang von PascalCase zu CamelCase in Version 1.0.3

Zielgruppe

Dieser Artikel soll Personen unterstützen, die Geräte mit Azure IoT bereitstellen oder verwalten . Wenn dies nicht wie Sie klingt, sollten Sie sich die Zielgruppe für die OSConfig-Dokumentation ansehen.

Firewallübersicht

Wenn Geräte OSConfig installiert haben, können Sie Azure IoT-Dienste verwenden, um mehrere grundlegende Firewallverwaltungsaufgaben auszuführen. Beispiel:

  • Überprüfen, ob die Firewall aktiv ist
  • Stellen Sie sicher, dass bestimmte Regeln vorhanden sind (erstellen, wenn nicht vorhanden)
  • Stellen Sie sicher, dass bestimmte Regeln nicht vorhanden sind (löschen, wenn gefunden)
  • Vergleichen der Regeln vieler bereitgestellter Geräte mit einem bekannten guten Gerät
  • Festlegen von Standarddatenverkehrrichtlinien für eingehenden und ausgehenden Datenverkehr

Firewallsymbol

Tipp

Wenn Sie hier für die Objektmodellreferenz sind, können Sie die Beispiele für Anwendungsfälle zu den Referenzinformationen überspringen.

Beispiele für Anwendungsfälle

Diese Beispiele können als Ausgangspunkte dienen, um sich für Ihre einzigartige Umgebung anzupassen.

Jedes Beispiel enthält Schritte und Bildschirmaufnahmen für die Arbeit in den Azure-Portal und zum Arbeiten in Bash mit Azure CLI.

Jedes Beispiel enthält auch Variationen für ein Gerät (z. B. ein Problembehandlungsszenario) oder für viele Geräte (z. B. eine Konfigurationsbereitstellung oder ein Berichtsszenario).

Was erwartet werden soll:

In den einzelnen Geräteanweisungen lesen und schreiben Sie gemeldete und gewünschte Eigenschaften direkt im OSConfig-Twin für ein Gerät. In den Anweisungen zur Skalierung verwenden Sie IoT Hub Konfigurationen (auch als Automatische Geräteverwaltung oder ADM bezeichnet), um gewünschte Eigenschaften an viele Zwillinge zu pushen und IoT Hub Abfragen (unabhängig oder an Konfigurationen als Metriken angefügt) zu verwenden, um die Ergebnisse zu beobachten, die von Geräten zurückkommen.

Voraussetzungen zum Testen der Beispiele für Live-Systeme

Wenn Sie diesen Artikel zur Referenz verwenden, gibt es keine Voraussetzungen. Sie können die Beispiele überprüfen, Eigenschaftennamen kopieren usw.

Wenn Sie die Beispiele für Livesysteme (empfohlen) ausprobieren möchten, führen Sie die folgenden Schritte aus:

  1. Erstellen eines kostenlosen Azure-Kontos oder Verwenden eines vorhandenen Kontos

  2. Verbinden sie mindestens ein osConfig-aktiviertes Gerät mit einem IoT Hub

    Tipp

    Informationen zum einfachen Erstellen eines IoT Hub mit angefügten (virtuellen) Geräten finden Sie unter Erstellen einer OSConfig -Umgebung (mit Azure IoT) in 5 Minuten

  3. Können Sie entweder die Azure-Portal-Anweisung oder die Azure CLI-Anweisungen in den Beispielen befolgen:

Wenn Sie die Azure-Portal verwenden möchten

  1. Melden Sie sich bei Ihrem Azure-Portal an, und greifen Sie auf die Seite "Übersicht" Ihres IoT Hub mit IoT Hub und Geräten aus dem Azure-Portal zu.

-OR- Wenn Sie Azure CLI verwenden möchten

  1. EMPFOHLEN: Verwenden Sie Azure Cloud Shell als Bash-Umgebung, indem Sie sich bei Ihrem Azure-Portal anmelden, und starten Sie Dann Azure Cloud Shell im Bashmodus Bildschirmaufnahme öffnen Cloud Shell aus Azure Portal
  2. ALTERNATIVE: Wenn Sie ihre eigene Bash-Umgebung anstelle von Cloud Shell verwenden möchten, installieren Sie die Azure CLI und melden Sie sich an.
  3. Stellen Sie sicher, dass die Azure IoT-Erweiterung bereit ist, indem Sie ausführen az extension add --name azure-iot

Beispiel A. Ist die Host-Firewall aktiv?

Die state untere Eigenschaft properties.reported.Firewall gibt einen hohen Hinweis darauf, ob die Host-Firewall aktiv ist. So wird beispielsweise angegeben, ob das Host-Firewallmodul aktiviert ist und mindestens eine Regel in der FILTER-Tabelle vorhanden ist. Weitere Informationen zum state Einschließen möglicher Werte finden Sie unter: Referenzinformationen.

  1. Wählen Sie auf der Portalseite Ihres IoT Hub Geräte in der linken Navigation aus. Wenn das Gerät zusätzlich zu OSConfig IoT Edge installiert hat, wählen Sie IoT Edge anstelle von Geräten aus.

  2. Klicken Sie auf ein Gerät, auf dem OSConfig installiert ist.

  3. Klicken Sie unter "Modulidentitäten " auf "osconfig".

  4. Klicken Sie auf "Module Identity Twin", und navigieren Sie zum JSON-Objekt.properties.reported.Firewall.state Im folgenden Bildschirmaufnahmebeispiel können Sie sehen, dass state: enabled.

    Bildschirmaufnahme, die zeigt, wie Sie den Firewallstatus für ein bestimmtes Gerät mithilfe von Portal überprüfen

Beispiel B. Erstellen einer Firewallregel

In diesem Beispiel wird die desiredRules Funktion des Firewallmoduls verwendet. Wir erstellen eine neue Regel, die ausgehenden TCP-Port 443-Datenverkehr vom Gerät zu Subnetz 10.9.9.0/24 ermöglicht.

Weitere Informationen desiredRules zu (einschließlich Behandlung mehrerer Regeln und Regellöschung) finden Sie weiter unten in diesem Artikel unter Firewall desiredRules reference.

  1. Verwenden von Azure Portal, im osconfig-Modul Twin des Geräts, unter properties.desired Hinzufügen oder Ändern einer FirewalldesiredRules und Knoten wie folgt. Pro JSON-Standards müssen Sie möglicherweise ein Komma am Ende hinzufügen, um in andere gewünschte Eigenschaften zu integrieren, wenn vorhanden.

    "Firewall": {
   "desiredRules": [
      {
         "desiredState": "present",
         "action": "accept",
         "direction": "out",
         "protocol": "tcp",
         "destinationAddress": "10.9.9.0/24",
         "destinationPort": 443
      }
   ]
}

    Bildschirmaufnahme, die zeigt, wie Sie eine Firewallregel für ein einzelnes Gerät mithilfe des Portals konfigurieren

  2. Nach ca. 30 Sekunden können Sie überprüfen, ob die Änderung erfolgreich aus dem Modul-Twin vorgenommen wird. Aktualisieren Sie die Twin-Ansicht des Moduls, und scrollen Sie dann nach dem Suchenpropertiesreported, und stateFirewallconfigurationStatusdann .desiredRules

    Bildschirmaufnahme, die zeigt, wie die gemeldeten Eigenschaften für die Firewallkonfiguration für ein einzelnes Gerät mithilfe des Portals gelesen werden.

Beispiel C. Vergleichen des Firewallstatus-Fingerabdrucks vieler Geräte mit einem bekannten guten Gerät

Die fingerprint Eigenschaft ermöglicht schnelle Vergleiche zur Überprüfung der Compliance im Maßstab. Sie müssen nicht alle Regeln von allen Geräten abrufen und dann eine viele zu viele Vergleichsstrategie implementieren. Sie können einfach überprüfen, ob der Fingerabdruck auf Geräten identisch ist, die miteinander übereinstimmen sollen. Sie können beispielsweise zwischen bereitgestellten Geräten und einem bekannten Referenzgerät vergleichen.

In den Einzelgerätbeispielen rufen wir einfach den Wert ab, was bedeutet, dass Sie einen Vergleich aus Band ausführen. In den Beispielen wird IoT Hub GROUP BY-Operator IoT Hub Abfrage verwendet, um Gemeinsames oder Divergenz in einer Flotte anzuzeigen.

Nicht anwendbar, siehe Azure Portal, skaliert.

Referenzinformationen

Beschreibung des Objektmodells

In diesem Abschnitt werden die Zwillingseigenschaften und entsprechende Verhaltensweisen beschrieben.

Tipp

OsConfig-Referenzdokumentation gilt für Tools mit oder ohne Digitale Twin Definition Language (DTDL) erweiterte Perspektiven des Datenmodells. Weitere Informationen finden Sie unter: Informationen zu nur gewünschten/gemeldeten Ansichten und erweiterten DTDL-Ansichten.

Firewall gemeldete/schreibgeschützte Eigenschaften (für Berichts- und Überwachungsszenarien)

  • Pfad: properties.reported.Firewall (Firewall Komponente, schreibgeschützte Eigenschaften)

  • Beschreibung: Der Zustand der Host-Firewall, wie vom Firewallmodul von OSConfig erkannt

  • Mitglieder

    Name type Notizen
    configurationStatus Aufzählung von Zeichenfolgen Stellt den Fehler-/Erfolgszustand des Erreichens der gewünschten Konfiguration dar. Nur sinnvoll, wenn gewünschte Konfigurationseigenschaften wie z desiredRules . B. festgelegt wurden oder desiredDefaultPolicies festgelegt wurden. Möglicher Wert als dieser Schreibvorgang sind success, failureund unknown.
    configurationStatusDetail Zeichenfolge Text, der von zugrunde liegenden APIs oder Tools wie iptables zurückgegeben wird. Dient zum Bereitstellen der ersten Einblicke in schlechte Eingabeparameter usw., ohne dass sie durch Diagnoseprotokolle kombiniert werden.
    defaultPolicies Array von Objekten (siehe Beispiel-Nutzlast) Stellt die Standardmäßige Hand der Firewall von Paketen dar, die keine bestimmte Regel erfüllen. Im Kontext von iptables wird dies den Kettenrichtlinien für die Eingabe- und Ausgabeketten der Filtertabelle zugeordnet. In anderen Firewallmodulen würde dies dem Verhalten des Firewallmoduls nach Bedarf zugeordnet. Beispielsweise verfügen einige Firewallmodule nicht über einen expliziten Richtlinienbegriff und legen inhärent Datenverkehr ab, der keine Regel erfüllt.
    Fingerabdruck Zeichenfolge • Undurchsichtiger Fingerabdruck für die Liste aller Firewallregeln auf dem Gerät
    • Wird verwendet, um große Anzahl von Geräten mit einem bekannten guten Gerät zu vergleichen
    HINWEIS: In Versionen von OSConfig vor der Version vom Oktober 2022 wurde diese Eigenschaft als "firewallFingerprint" bezeichnet.
    state Aufzählung von Zeichenfolgen Hoher Status der Host-Firewall. Mögliche Werte:
    • unknown
    • enabled
    • disabled
    Die Logik besteht darin enabled , dass ein aktives Firewallmodul erkannt wurde und mindestens eine Regel in der FILTER-Tabelle enthält.
    HINWEIS: In Versionen von OSConfig vor der Version vom Oktober 2022 wurde diese Information als "firewallState" (statt "Zustand") angezeigt, und die Werte waren ganze Zahlen (anstelle von Zeichenfolgen).

  • Beispiel-Nutzlast (wie im Abschnitt "Twin properties.reported " dargestellt)

    "Firewall": {
    "configurationStatus": "success",
    "configurationStatusDetail": "",
    "defaultPolicies": [
       {
          "direction": "in",
          "action": "accept"
       },
       {
          "direction": "out",
          "action": "accept"
       }
    ],
    "fingerprint": "c30d8b8bf5327a8a325a686e0c4bbf73b1bd33a72779af88827e8ea256caddb2",
    "state": "enabled"
}
Firewall gewünschterRules

Achtung

Wie bei jeder Firewallverwaltung sorgen Sie beim Blockieren des Datenverkehrs sehr wichtig. Sie haben die Möglichkeit, das Gerät daran zu hindern, die Verbindung mit IoT Hub oder anderen administrativen Kanälen fortzusetzen. In solchen Fällen muss der lokale Zugriff auf das Gerät möglicherweise wiederhergestellt werden.

  • Pfad: properties.desired.Firewall.desiredRules (Firewall Komponente, desiredRules schreibbare Eigenschaft)

  • Beschreibung: Eine sortierte Liste der Regeldeskriptoren. Jeder Regeldeskriptor in der Liste kann die folgenden Elemente aufweisen.

  • Elemente jeder Regeldeskriptor

    Name Typ Notizen
    desiredState Aufzählung von Zeichenfolgen Immer erforderlich. Mögliche Werte sind present (bedeutet, dass eine solche Regel erstellt werden sollte, wenn eine übereinstimmende Regel noch nicht vorhanden ist), oder absent (bedeutet, dass eine vorhandene Regel auf dem Gerät, die diesem Deskriptor entspricht, gelöscht werden sollte, wenn sie gefunden wurde. Für Regeldeskriptoren, bei desiredState: "present" denen auf dem Gerät bereits keine übereinstimmende Regel vorhanden ist, wird die neue Regel oben in der Liste der Regeln auf dem Gerät hinzugefügt. Für Kontext können Sie dies als analog iptables -I zu betrachten, wie es sich im Gegensatz zu iptables -A. Wenn mehrere desiredState: "present" Regeldeskriptoren vorhanden desiredRulessind, werden sie so hinzugefügt, dass die Reihenfolge beibehalten wird. Mit anderen Worten desiredRules , die regel oben in der Regelliste auf dem Gerät steht, folgt die nächste Regel desiredRules in der Liste der Regeln auf dem Gerät und so weiter.
    action Aufzählung von Zeichenfolgen Immer erforderlich. Mögliche Werte sind accept, drop oder reject.
    direction Aufzählung von Zeichenfolgen Immer erforderlich. Mögliche Werte sind in oder out.
    Protokoll Aufzählung von Zeichenfolgen Immer erforderlich. Mögliche Werte sind any, udp, tcp oder icmp. Beachten Sie, dass any jeder Datenverkehr (im Gegensatz zu der Bedeutung "tcp und udp" bedeutet, aber nicht andere IP-Protokolle). Dementsprechend dürfen Regeln, in denen protocol: "any" keine Oder- oder Nicht-Regeln enthalten sourcePort sind destinationPort.
    sourceAddress Zeichenfolge IP-Adresse oder CIDR-Bereich. Wenn nicht angegeben, entspricht die resultierende Regel jeder Adresse
    sourcePort integer Relevant für Regeln, in denen protocol: tcp oder protocol:udp. Darf nicht in andere Regeln einbezogen werden. Gibt die Portnummer an, wenn sie in einer relevanten Regel enthalten ist. Gibt eine Regel an, die einer Portnummer entspricht.
    destinationAddress Zeichenfolge IP-Adresse oder CIDR-Bereich. Wenn nicht angegeben, entspricht die resultierende Regel jeder Adresse
    destinationPort integer Relevant für Regeln, in denen protocol: tcp oder protocol:udp. Darf nicht in andere Regeln einbezogen werden. Gibt die Portnummer an, wenn sie in einer relevanten Regel enthalten ist. Gibt eine Regel an, die einer Portnummer entspricht.

Beispiel-Nutzlast (wie im Abschnitt "Twin properties.desired " dargestellt)

Die folgenden Regeln stellen die folgenden Administratorabsichten dar:

  1. "Mein on-prem Admin-Subnetz ist 10.9.9.0/24, daher möchte ich Geräte, die eingehende Port 22 (SSH) von dort zulassen"

  2. "Mein altes Admin-Subnetz war 10.24.24.0/24, sodass jedes Gerät immer noch eine Regel besitzt, die Port 22 (SSH) dort erlaubt, möchte ich eine solche Regel entfernen"

  3. HINWEIS: Der Administrator möchte hier möglicherweise eine dritte Regel verwenden, um SSH überall zu blockieren (mit der obigen Ausnahme), aber in diesem Beispiel verwenden wir eine Standard-Drop-Richtlinie, wodurch eine solche Regel redundant ist. Siehe das desiredDefaultPolicies Beispiel weiter unten in diesem Dokument.

    "Firewall": {
   "desiredRules": [
      {
         "desiredState": "present",
         "action": "accept",
         "direction": "in",
         "protocol": "tcp",
         "sourceAddress": "10.9.9.0/24",
         "destinationPort": 22
      },
      {
         "desiredState": "absent",
         "action": "accept",
         "direction": "in",
         "protocol": "tcp",
         "sourceAddress": "10.24.24.0/24",
         "destinationPort": 22
      }
   ]
}

Beachten Sie, dass beim Festlegen eines administrativen Workflows properties.desired.Firewall.desiredRules (Firewall Komponente, schreibbare Eigenschaft aus DTDL-Perspektive) das Gerät den Empfang desselben bestätigt, desiredRules indem eine desiredRules Eigenschaft properties.reported.Firewallhinzugefügt wird. Der Wert dieser Eigenschaft enthält eine Kopie der ursprünglichen desiredRules Nutzlast zusammen mit einer Versionsnummer und einem Statuscode. IoT Hub basierten verwaltungsbasierten Workflows können dies verwenden, um festzustellen, ob der gewünschte Zustand noch das Gerät erreicht hat. Dies ist nur eine Bestätigung. Um zu ermitteln, ob das Gerät erfolgreich den gewünschten Zustand erreicht hat, finden Sie auch unter configurationStatus und configurationStatusDetail.

Firewall gewünschteDefaultPolicies

Achtung

Wie bei jeder Firewallverwaltung sorgen Sie beim Blockieren des Datenverkehrs sehr wichtig. Sie haben die Möglichkeit, das Gerät daran zu hindern, die Verbindung mit IoT Hub oder anderen administrativen Kanälen fortzusetzen. In solchen Fällen muss der lokale Zugriff auf das Gerät möglicherweise wiederhergestellt werden.

Standardrichtlinien erfordern besonders sorgfältige Anwendung. Auf iptables basierten Systemen gelten beispielsweise die Richtlinien für jedes Paket einzeln, ohne vorhandene Verbindungen zu berücksichtigen. Mit anderen Worten, eine eingehende Standardrichtlinie von drop Willen (zusätzlich zum Blockieren neuer eingehender Verbindungen) blockieren Antworten von Remotesystemen. Dies kann es unmöglich machen, dass das Gerät ausgehend über Protokolle (z. B. TCP) kommunizieren kann, die bidirektionale Paketfluss erfordern. Legen Sie nicht action auf drop die in Richtlinien out fest, ohne zunächst sicherzustellen, dass bestimmte Regeln vorhanden sind, um alle erforderlichen Pakete in beiden Richtungen zu aktivieren.

  • Pfad: properties.desired.Firewall.desiredDefaultPolicies (Firewall Komponente, desiredDefaultPolicies schreibbare Eigenschaft)

  • Beschreibung: Ein Array mit zwei Elementen, das das gewünschte Standardverhalten (akzeptieren oder ablegen) für eingehenden Datenverkehr und für ausgehenden Datenverkehr beschreibt.

  • Elemente jedes Elements

    Name Typ Notizen
    direction Aufzählung von Zeichenfolgen Mögliche Werte sind in oder out
    action Aufzählung von Zeichenfolgen Immer erforderlich. Mögliche Werte sind accept oder drop.

Beispiel-Nutzlast (wie im Abschnitt "Twin properties.desired " dargestellt)

"Firewall": {
   "desiredDefaultPolicies": [
      {"direction": "in", "action": "drop"},
      {"direction": "out", "action": "accept"}
   ]
}

Beachten Sie, dass beim Festlegen properties.desired.Firewall.desiredDefaultPolicies eines administrativen Workflows (Firewall Komponente, schreibbare Eigenschaft aus DTDL-Perspektive) das Gerät den Empfang desselben bestätigt, desiredDefaultPolicies indem eine desiredDefaultPolicies Eigenschaft properties.reported.Firewallhinzugefügt wird. Der Wert dieser Eigenschaft enthält eine Kopie der ursprünglichen Nutzlast zusammen mit einer Versionsnummer und einem Statuscode. IoT Hub basierenden verwaltungsbasierten Workflows kann dies verwenden, um festzustellen, ob der gewünschte Zustand noch das Gerät erreicht hat. Dies ist nur eine Bestätigung der Bestätigung und Verarbeitung. Weitere Informationen zum Erfolg oder Fehler des Erreichens des gewünschten Zustands finden Sie unter configurationStatus und configurationStatusDetail.

Weitere Informationen und Häufig gestellte Fragen

Was ist mit dem Fall "Alles ersetzen"?

In bestimmten Fällen sollten Administratoren die absolute Kontrolle über die Netzliste der Firewallregeln des Geräts erzwingen. Stellen Sie sich eine Absicht wie "Nur Regeln X, Y und Z sollte vorhanden sein; Alle anderen Regeln (vorab auf dem Gerät oder im Laufe der Zeit durch andere Prozesse erstellt) sollten regelmäßig entfernt werden." Zu diesem Zeitpunkt stellt das OSConfig Firewall-Modul nicht direkt für diesen Anwendungsfälle bereit. Die Entfernung spezifischer Regeln kann durch desiredRules und "desiredState": "absent"ausgeführt werden, aber es gibt keine explizite Ersetzen-All-Funktionalität. Wenn Sie ein solches Feature hinzufügen möchten, lesen Sie die Erweiterungsdokumentation unter https://github.com/Azure/azure-osconfig.

Nächste Schritte

Eine Übersicht über OSConfig-Szenarien und -Funktionen finden Sie unter:

Spezifische praktische Beispiele finden Sie unter: