Administración del firewall de host con Azure IoT y OSConfig
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.
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.
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
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.
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.
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:
Creación de una cuenta gratuita de Azure o uso de una cuenta existente
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.
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
- Inicio de sesión en el Azure Portal y acceso a la página Información general de la IoT Hub
-OR- Si prefiere usar la CLI de Azure
- 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 .
- ALTERNATIVA: Si prefiere usar su propio entorno de Bash en lugar de Cloud Shell, instale la CLI de Azure e inicie sesión.
- Asegúrese de que la extensión de Azure IoT está lista mediante la ejecución de
az extension add --name azure-iot
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.
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.
Haga clic en un dispositivo donde está instalado OSConfig.
En Identidades de módulo, haga clic en osconfig.
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 questate: enabled
.
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.
Mediante Azure Portal, en el módulo gemelo osconfig del dispositivo, en
properties.desired
Agregar o modificar unFirewall
ydesiredRules
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 } ] }
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
properties
yreported
, a continuaciónconfigurationStatus
Firewall
, ,state
y .desiredRules
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.
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.Firewall
Firewall
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
odesiredDefaultPolicies
. El valor posible a partir de esta escritura essuccess
,failure
yunknown
.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 deenabled
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" }
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) oabsent
(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 endesiredState: "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 eniptables -I
lugariptables -A
de . Si hay variosdesiredState: "present"
descriptores de regla presentes endesiredRules
, se agregan de modo que se conserve el orden. En otras palabras, la regla superior endesiredRules
estará en la parte superior de la lista de reglas del dispositivo, la siguiente regladesiredRules
de seguirá en la lista de reglas del dispositivo, etc.action enumeración de cadenas Siempre se requiere. Los valores posibles son accept
,drop
oreject
.direction enumeración de cadenas Siempre se requiere. Los valores posibles son in
oout
.protocol enumeración de cadenas Siempre se requiere. Los valores posibles son any
,udp
,tcp
oicmp
. Tenga en cuenta queany
significa cualquier tráfico (en lugar de "tcp y udp, pero no otros protocolos IP). En consecuencia, las reglas en las queprotocol: "any"
no deben incluirsesourcePort
nidestinationPort
.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
oprotocol: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
oprotocol: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:
"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í"
"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".
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.Firewall
Firewall
. 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
.
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 action
drop
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
oout
action enumeración de cadenas Siempre se requiere. Los valores posibles son accept
odrop
.
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.Firewall
Firewall
. 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
.
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.
Para obtener información general sobre los escenarios y funcionalidades de OSConfig, consulte:
Para obtener ejemplos prácticos específicos, consulte: