Compartir a través de

Administración del firewall de host con Azure IoT y OSConfig

  • Artículo

Importante

La versión 1.0.3 (publicada el 28 de junio de 2022) incluye cambios importantes en los nombres de miembros que pueden afectar a los usuarios existentes. Para obtener más información, consulte: Los nombres de miembro pasan de PascalCase a camelCase en la versión 1.0.3.

Público

Este artículo está diseñado para admitir a los usuarios que aprovisionan o administran dispositivos con Azure IoT. Si eso no suena como usted, considere la posibilidad de echar un vistazo a la documentación de Audiences for OSConfig.

Información general de firewalls

Cuando los dispositivos tienen OSConfig instalado, puede usar los servicios de Azure IoT para realizar varias tareas básicas de administración del firewall. Por ejemplo:

  • Comprobación de si el firewall está activo
  • Asegúrese de que existen ciertas reglas (crear si no están presentes)
  • Asegúrese de que ciertas reglas no existen (elimine si se encuentra).
  • Comparación de las reglas de muchos dispositivos implementados con un dispositivo conocido
  • Establecimiento de directivas de tráfico predeterminadas para el tráfico entrante y saliente

Icono de firewall

Sugerencia

Si está aquí para la referencia del modelo de objetos, puede omitir los ejemplos de casos de uso a la información de referencia.

Ejemplos de casos de uso

Estos ejemplos pueden servir como puntos de partida para adaptarse a su entorno único.

Cada ejemplo incluye pasos y capturas de pantalla para trabajar en la Azure Portal y para trabajar en Bash con la CLI de Azure.

Cada ejemplo también incluye variaciones para un dispositivo (por ejemplo, un escenario de solución de problemas) o para muchos dispositivos (por ejemplo, un escenario de aprovisionamiento o informes de configuración).

Qué esperar:

En las instrucciones de un solo dispositivo, leerá y escribirá las propiedades notificadas y deseadas directamente en el gemelo OSConfig para un dispositivo. En las instrucciones a escala, usará IoT Hub Configuraciones (también conocidas como Automatic Administración de dispositivos o ADM) para insertar las propiedades deseadas en muchos gemelos y usar IoT Hub Consultas (de forma independiente o asociadas a configuraciones como métricas) para observar los resultados procedentes de los dispositivos.

Requisitos previos para probar los ejemplos en sistemas activos

Si usa este artículo como referencia, no hay requisitos previos. Puede revisar los ejemplos, copiar nombres de propiedad, etc.

Si desea probar los ejemplos en sistemas activos (recomendado), siga estos pasos:

  1. Creación de una cuenta gratuita de Azure o uso de una cuenta existente

  2. Conectar al menos un dispositivo habilitado para OSConfig a un IoT Hub

    Sugerencia

    Para crear fácilmente un IoT Hub con dispositivos (virtuales) conectados, consulte Creación de un entorno de laboratorio de OSConfig (con Azure IoT) en 5 minutos.

  3. Prepárese para seguir las instrucciones de Azure Portal o las instrucciones de la CLI de Azure en los ejemplos:

Si prefiere usar el Azure Portal

  1. Inicio de sesión en el Azure Portal y acceso a la página Información general de la IoT Hub Captura de pantalla que muestra IoT Hub y dispositivos desde Azure Portal

-OR- Si prefiere usar la CLI de Azure

  1. RECOMENDADO: Use Azure Cloud Shell como entorno de Bash iniciando sesión en Azure Portal y, a continuación, iniciando Azure Cloud Shell en modo bash Captura de pantalla que abre Cloud Shell desde Azure Portal.
  2. ALTERNATIVA: Si prefiere usar su propio entorno de Bash en lugar de Cloud Shell, instale la CLI de Azure e inicie sesión.
  3. Asegúrese de que la extensión de Azure IoT está lista mediante la ejecución de az extension add --name azure-iot

Ejemplo A. ¿Está activo el firewall del host?

La state propiedad debajo properties.reported.Firewall proporciona una indicación de alto nivel de si el firewall del host está activo. Por ejemplo, indica si el motor de firewall de host está habilitado y existe al menos una regla en la tabla FILTER . Para obtener más información sobre state la inclusión de valores posibles, vea: Información de referencia.

  1. En la página del portal de IoT Hub, elija Dispositivos en el panel de navegación izquierdo. Si el dispositivo tiene IoT Edge instalado además de OSConfig, elija IoT Edge en lugar de Dispositivos.

  2. Haga clic en un dispositivo donde está instalado OSConfig.

  3. En Identidades de módulo, haga clic en osconfig.

  4. Haga clic en Identidad de módulo gemelo y examine el archivo JSON a properties.reported.Firewall.state. En el ejemplo de captura de pantalla siguiente, puede ver que state: enabled.

    Captura de pantalla que muestra cómo comprobar el estado del firewall de un dispositivo específico mediante el portal

Ejemplo B. Creación de una regla de firewall

En este ejemplo se usa la desiredRules función del módulo Firewall. Se crea una nueva regla que permite el tráfico saliente del puerto tcp 443 desde el dispositivo a la subred 10.9.9.0/24.

Para obtener más información sobre desiredRules (incluido el control de varias reglas y la eliminación de reglas), consulte La referencia de DesiredRules del firewall más adelante en este artículo.

  1. Mediante Azure Portal, en el módulo gemelo osconfig del dispositivo, en properties.desired Agregar o modificar un Firewall y desiredRules nodos como se indica a continuación. Según los estándares JSON, es posible que tenga que agregar una coma al final para integrarse con otras propiedades deseadas si están presentes.

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

    Captura de pantalla que muestra cómo configurar una regla de firewall para un único dispositivo mediante el portal

  2. Después de aproximadamente 30 segundos, puede comprobar que el cambio se realiza correctamente desde el propio módulo gemelo. Actualice la vista del módulo gemelo y, a continuación, desplácese para buscar propertiesyreported, a continuaciónconfigurationStatusFirewall, , state y .desiredRules

    Captura de pantalla que muestra cómo leer las propiedades notificadas para la configuración del firewall para un único dispositivo mediante el portal

Ejemplo C. Comparar la huella digital de estado del firewall de muchos dispositivos con un dispositivo correcto conocido

La fingerprint propiedad permite comparaciones rápidas para comprobar el cumplimiento a escala. No es necesario recuperar todas las reglas de todos los dispositivos y, a continuación, implementar una estrategia de comparación de varios a varios. Simplemente puede comprobar que la huella digital es la misma en todos los dispositivos que se espera que coincidan entre sí. Por ejemplo, puede comparar entre los dispositivos implementados y un dispositivo de referencia conocido.

En los ejemplos de un solo dispositivo, simplemente recuperaremos el valor, lo que implica que está realizando una comparación fuera de banda. En los ejemplos a escala, usaremos IoT Hub operador GROUP BY de consulta para mostrar la divergencia o la similitud en una flota.

No aplicable, consulte Azure Portal, a escala.

Información de referencia

Descripción del modelo de objetos

En esta sección se describen las propiedades del gemelo y los comportamientos correspondientes.

Sugerencia

La documentación de referencia de OSConfig se aplica a las herramientas con o sin perspectivas mejoradas del lenguaje de definición de gemelos digitales (DTDL) del modelo de datos. Para obtener más información, consulte : Acerca de las vistas deseadas o notificadas sin formato y las vistas mejoradas de DTDL.

Propiedades notificadas o de solo lectura del firewall (para los escenarios de informes y auditoría)

  • Ruta de acceso: ( properties.reported.FirewallFirewall componente, propiedades de solo lectura)

  • Descripción: el estado del firewall de host detectado por el módulo firewall de OSConfig.

  • Miembros

    Nombre Tipo Notas
    configurationStatus enumeración de cadenas Representa el estado de error o éxito de alcanzar la configuración deseada. Solo es significativo si se han establecido propiedades de configuración deseadas, como desiredRules o desiredDefaultPolicies . El valor posible a partir de esta escritura es success, failurey unknown.
    configurationStatusDetail string Texto devuelto por las API o herramientas subyacentes, como iptables. Diseñado para proporcionar el primer nivel de información sobre los parámetros de entrada incorrectos, etc., sin tener que recurrir a la combinación mediante registros de diagnóstico.
    defaultPolicies matriz de objetos (consulte la carga de ejemplo) Representa la entrega predeterminada del firewall de paquetes que no cumplen ninguna regla específica. En el contexto de iptables, esto se asigna a las directivas de cadena para las cadenas de entrada y salida de la tabla de filtros. En otros motores de firewall, esto se asignaría al comportamiento del motor de firewall según sea necesario. Por ejemplo, algunos motores de firewall no tienen una noción de directiva explícita y quitan inherentemente el tráfico que no cumple ninguna regla.
    Huellas string • Huella digital opaca para la lista de todas las reglas de firewall en el dispositivo
    • Se usa para comparar un gran número de dispositivos con un dispositivo conocido
    NOTA: En versiones de OSConfig anteriores a la versión de octubre de 2022, esta propiedad se conocía como "firewallFingerprint".
    state enumeración de cadenas Estado de alto nivel del firewall del host. Los valores posibles son:
    • unknown
    • enabled
    • disabled
    La lógica de enabled es que se detectó un motor de firewall activo y con al menos una regla en la tabla FILTER.
    NOTA: En versiones de OSConfig anteriores a la versión de octubre de 2022, esta información se presentó como "firewallState" (en lugar de "state") y los valores eran enteros (en lugar de cadenas).

  • Carga de ejemplo (como se muestra en la sección del properties.reported gemelo)

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

Precaución

Al igual que con cualquier administración del firewall, tenga mucho cuidado al bloquear el tráfico. Tiene la capacidad de impedir que el dispositivo continúe su conexión con IoT Hub u otros canales administrativos. En tales casos, es posible que sea necesario acceder localmente al dispositivo para recuperarse.

  • Ruta de acceso: properties.desired.Firewall.desiredRules (Firewall componente, desiredRules propiedad grabable)

  • Descripción: lista ordenada de descriptores de regla. Cada descriptor de regla de la lista puede tener los siguientes miembros.

  • Miembros de cada descriptor de regla

    Nombre Tipo Notas
    desiredState enumeración de cadenas Siempre se requiere. Los valores posibles son present (significa que se debe crear esta regla si aún no existe una regla de coincidencia) o absent (significa que se debe eliminar cualquier regla existente en el dispositivo que coincida con este descriptor si se encuentra. En el caso de los descriptores de regla en desiredState: "present" los que no existe ninguna regla coincidente en el dispositivo, la nueva regla se agrega en la parte superior de la lista de reglas del dispositivo. En el contexto, puede considerar esto como análogo a en iptables -I lugar iptables -Ade . Si hay varios desiredState: "present" descriptores de regla presentes en desiredRules, se agregan de modo que se conserve el orden. En otras palabras, la regla superior en desiredRules estará en la parte superior de la lista de reglas del dispositivo, la siguiente regla desiredRules de seguirá en la lista de reglas del dispositivo, etc.
    action enumeración de cadenas Siempre se requiere. Los valores posibles son accept, drop o reject.
    direction enumeración de cadenas Siempre se requiere. Los valores posibles son in o out.
    protocol enumeración de cadenas Siempre se requiere. Los valores posibles son any, udp, tcp o icmp. Tenga en cuenta que any significa cualquier tráfico (en lugar de "tcp y udp, pero no otros protocolos IP). En consecuencia, las reglas en las que protocol: "any" no deben incluirse sourcePort ni destinationPort.
    sourceAddress string Dirección IP o intervalo CIDR. Si no se especifica, la regla resultante coincidiría con cualquier dirección.
    sourcePort integer Relevante para las reglas en las que protocol: tcp o protocol:udp. No se debe incluir en otras reglas. Especifica el número de puerto cuando se incluye en una regla pertinente. Cuando no se incluye, indica una regla que debe coincidir con cualquier número de puerto.
    destinationAddress string Dirección IP o intervalo CIDR. Si no se especifica, la regla resultante coincidiría con cualquier dirección.
    destinationPort integer Relevante para las reglas en las que protocol: tcp o protocol:udp. No se debe incluir en otras reglas. Especifica el número de puerto cuando se incluye en una regla pertinente. Cuando no se incluye, indica una regla que debe coincidir con cualquier número de puerto.

Carga de ejemplo (como se muestra en la sección del properties.desired gemelo)

Las reglas siguientes representan las siguientes intenciones de administrador:

  1. "Mi subred de administración local es 10.9.9.0/24, por lo que quiero que los dispositivos permitan el puerto entrante 22 (SSH) desde allí"

  2. "Mi antigua subred de administrador era 10.24.24.0/24, por lo que si algún dispositivo todavía tiene una regla que permite el puerto 22 (SSH) desde allí, quiero que se quite dicha regla".

  3. NOTA: Es posible que el administrador quiera que una tercera regla bloquee SSH desde cualquier lugar (con la excepción anterior), pero en este ejemplo usaremos una directiva de eliminación predeterminada, lo que hace que esta regla sea redundante. Vea el desiredDefaultPolicies ejemplo más adelante en este documento.

    "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
      }
   ]
}

Tenga en cuenta que cuando un flujo de trabajo administrativo establece properties.desired.Firewall.desiredRules ( componente, desiredRules propiedad grabable desde la perspectiva de DTDL), el dispositivo confirma la recepción del mismo agregando una desiredRules propiedad a properties.reported.FirewallFirewall . El valor de esa propiedad incluye una copia de la carga original desiredRules , junto con un número de versión y un código de estado. IoT Hub flujos de trabajo administrativos basados en esto pueden usarse para determinar si el estado deseado aún ha alcanzado el dispositivo. Esto es solo una confirmación. Para determinar si el dispositivo ha alcanzado correctamente el estado deseado, consulte también configurationStatus y configurationStatusDetail.

Firewall desiredDefaultPolicies

Precaución

Al igual que con cualquier administración del firewall, tenga mucho cuidado al bloquear el tráfico. Tiene la capacidad de impedir que el dispositivo continúe su conexión con IoT Hub u otros canales administrativos. En tales casos, es posible que sea necesario acceder localmente al dispositivo para recuperarse.

Las directivas predeterminadas requieren una aplicación especialmente cuidadosa. En sistemas basados en iptables, por ejemplo, las directivas se aplican a cada paquete individualmente sin tener en cuenta las conexiones existentes. Es decir, una directiva predeterminada de entrada de will (además de drop bloquear nuevas conexiones entrantes) bloquea las respuestas de los sistemas remotos. Esto puede hacer imposible que el dispositivo se comunique de salida mediante protocolos (como TCP) que requieren flujo de paquetes bidireccional. No establezca en actiondrop en las in directivas o out sin asegurarse primero de que existen reglas específicas para habilitar todos los paquetes necesarios en ambas direcciones.

  • Ruta de acceso: properties.desired.Firewall.desiredDefaultPolicies (Firewall componente, desiredDefaultPolicies propiedad grabable)

  • Descripción: una matriz con dos elementos, que describe el comportamiento predeterminado deseado (aceptar o quitar) para el tráfico entrante y para el tráfico saliente.

  • Miembros de cada elemento

    Nombre Tipo Notas
    direction enumeración de cadenas Los valores posibles son in o out
    action enumeración de cadenas Siempre se requiere. Los valores posibles son accept o drop.

Carga de ejemplo (como se muestra en la sección del properties.desired gemelo)

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

Tenga en cuenta que cuando un flujo de trabajo administrativo establece properties.desired.Firewall.desiredDefaultPolicies ( componente, desiredDefaultPolicies propiedad grabable desde la perspectiva de DTDL), el dispositivo confirma la recepción del mismo agregando una desiredDefaultPolicies propiedad a properties.reported.FirewallFirewall . El valor de esa propiedad incluye una copia de la carga original, junto con un número de versión y un código de estado. IoT Hub flujos de trabajo administrativos basados en esto pueden usarse para determinar si el estado deseado aún ha alcanzado el dispositivo. Esto es solo una confirmación de recepción y procesamiento. Para obtener más información sobre el éxito o el error de alcanzar el estado deseado, vea configurationStatus y configurationStatusDetail.

Información adicional y preguntas más frecuentes

¿Qué ocurre con un caso de uso de "reemplazar todo"?

En ciertos casos, es posible que los administradores quieran imponer un control absoluto sobre la lista neta de reglas de firewall del dispositivo. Imagine una intención como: "Sólo deben existir las reglas X, Y y Z; Cualquier otra regla (ya existente en el dispositivo o creada con el tiempo por otros procesos) se debe quitar periódicamente". En este momento, el módulo Firewall de OSConfig no proporciona directamente para este caso de uso. La eliminación de reglas específicas se puede realizar a través desiredRules de y "desiredState": "absent", pero no hay ninguna funcionalidad de reemplazo explícita. Si desea agregar esta característica, consulte la documentación de extensibilidad en https://github.com/Azure/azure-osconfig.

Pasos siguientes

Para obtener información general sobre los escenarios y funcionalidades de OSConfig, consulte:

Para obtener ejemplos prácticos específicos, consulte: