módulo ara::fw — Firewall

El Functional Cluster Firewall filtra paquetes de red según conjuntos de reglas dependientes del estado procedentes del manifiesto y notifica los paquetes bloqueados como Security Events al IdsM (EXP_PlatformDesign p. 92). Las aplicaciones seleccionan el estado activo del Firewall mediante FirewallStateSwitchInterface::SwitchFirewallState. El método devuelve un ara::core::Future<void> y notifica errores como kServiceNotAvailable o kInvalidStateDependentFirewall [AP_SWS_Fw_82008]. Los estados no constituyen una lista fija, sino que se generan como una enumeración para cada interfaz modelada. Las instancias de la interfaz solo se pueden mover, no copiar.

más ›

El módulo fw especifica el Functional Cluster Firewall basado en demonio de la Adaptive Platform. Su API de aplicación es la interfaz FirewallStateSwitchInterface con la operación SwitchFirewallState(), que utiliza una Adaptive Application (EXP_SWArchitecture p. 126). El cluster tiene dos tareas: conmuta el estado del Firewall y notifica Security Events al Intrusion Detection System Manager (EXP_SWArchitecture p. 197).

Diagrama de contexto: el FC Firewall conecta la configuración del manifiesto, la especificación de estado por parte de la aplicación, la aplicación de reglas en el sistema operativo y la notificación de SEvs al IdsM. Fuentes: EXP_PlatformDesign p. 97, EXP_SWArchitecture p. 197

El filtrado depende del estado. El OEM define estados como conducción, estacionamiento o diagnóstico, y a un paquete solo se le aplican las reglas del estado activo (EXP_PlatformDesign p. 92). Para ello, en el manifiesto AdaptiveFirewallModuleInstantiation agrupa elementos StateDependentFirewall. Cada uno de ellos contiene propiedades de regla ordenadas, una defaultAction opcional y referencias a los estados correspondientes (TPS_ManifestSpecification p. 679). En el código, los estados aparecen como una enumeración generada para cada interfaz en ara::fw::states [AP_SWS_Fw_81001].

La aplicación crea el objeto de interfaz a partir de un ara::core::InstanceSpecifier. Este constructor es seguro para hilos (thread-safe) [AP_SWS_Fw_82002]. SwitchFirewallState es noexcept y devuelve un ara::core::Future<void> [AP_SWS_Fw_82008]. A nivel interno, según el escenario, el cluster aplica cada regla de Firewall individualmente en el sistema operativo (EXP_SWArchitecture p. 232). Las instancias no se pueden copiar, pero sí mover. El movimiento (move) y el destructor no son seguros para hilos [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].

Diagrama de secuencia: la solicitud de cambio de estado retorna como un Future. Entremedias, cada regla se aplica individualmente. Fuentes: EXP_SWArchitecture p. 232, [AP_SWS_Fw_82008]

En caso de error, el Future contiene FwErrc::kServiceNotAvailable o FwErrc::kInvalidStateDependentFirewall [AP_SWS_Fw_83001]. El significado solo puede deducirse a partir de los nombres: es probable que el servicio no esté disponible o que falte una configuración de reglas válida para el estado de destino. Pregunta Q-45e3225696efb3dc (abierta) Mediante FwErrorDomain::ThrowAsException se puede lanzar un error como FwException [AP_SWS_Fw_83012]. Los paquetes bloqueados no constituyen un error de API. Se notifican como Security Events al IdsM, y en R23-11 se diferencian además según el protocolo divergente (SWS_Firewall p. 31).

más ›

Rol del FC Firewall entre la aplicación, el sistema operativo y el IdsM

El módulo fw describe el Functional Cluster Firewall de la Adaptive Platform. Está basado en demonio e implementa la interfaz FirewallStateSwitchInterface con la operación SwitchFirewallState(). Una Adaptive Application utiliza esta interfaz mediante una relación «use» (EXP_SWArchitecture p. 126). Los casos de uso restringen el cluster a dos tareas. «Switch Firewall State» es desencadenada por la Adaptive Application, interviniendo el sistema operativo. «Report Security Event» se dirige al Intrusion Detection System Manager, también basado en demonio (EXP_SWArchitecture p. 197).

La vista general de la arquitectura separa la configuración, el control y la ejecución entre sí:

• El Machine Manifest proporciona las reglas de filtrado.
• El FC Firewall configura con ellas un Firewall Engine.
• Una aplicación OEM establece el estado del Firewall.
• El cluster notifica Security Events (SEvs) al IdsM (EXP_PlatformDesign p. 97).

En primer plano se encuentran dos casos de uso. El primero es el filtrado dependiente del estado con estados específicos de OEM como conducir, estacionar o sesión de diagnóstico. El segundo es la compatibilidad con el Intrusion Detection System mediante Security Events en mensajes bloqueados. De la cualificación, la transferencia a un SOC o el almacenamiento persistente se encarga el IdsM (EXP_PlatformDesign p. 92). La única API de aplicación del módulo es el cambio de estado [AP_SWS_Fw_82008].

Diagrama de contexto: el FC Firewall recibe la configuración del Machine Manifest y las especificaciones de estado de la aplicación. Controla el motor y el sistema operativo y notifica SEvs al IdsM. Fuentes: EXP_PlatformDesign p. 97, EXP_SWArchitecture p. 197, EXP_SWArchitecture p. 232

Estados de Firewall: de la máquina de estados en el modelo a la enumeración generada

En el metamodelo de manifest, FirewallStateSwitchInterface especializa un PortInterface. A través del rol firewallStateMachine agrega cualquier número (0..*) de elementos ModeDeclarationGroupPrototype (TPS_ManifestSpecification p. 263). Los estados individuales son ModeDeclarations con el atributo opcional value: PositiveInteger (TPS_ManifestSpecification p. 679).

Para cada interfaz modelada se genera a partir de ello una enumeración propia enum class {<fwssi-sn>} : std::uint32_t en el espacio de nombres ara::fw::states. Esta se incluye a través de ara/fw/states/{<fwssi-sn>}.h [AP_SWS_Fw_81001]. Por cada estado de Firewall modelado surge un enumerador {<symbol-fw-state>} = {<fw-state-value>} [AP_SWS_Fw_81002].

Para los usuarios esto significa: no existe una lista de estados fija para toda la plataforma. Qué estados existen lo determina el modelo OEM (EXP_PlatformDesign p. 92). SwitchFirewallState espera un parámetro firewallState del tipo EnumT [AP_SWS_Fw_82008]. Interpretación: es probable que EnumT se corresponda con la enumeración de estados generada para la interfaz correspondiente. Pregunta Q-26dbe38f70cb0222 (abierta) A favor de esto apunta que [AP_SWS_Fw_81001] la define expresamente como estados «for FirewallStateSwitchInterface».

Diagrama de contexto (modelo–código): los estados proceden de la máquina de estados de la interfaz en el modelo. Por interfaz se genera una enumeración en ara::fw::states. Fuentes: TPS_ManifestSpecification p. 263, [AP_SWS_Fw_81001], [AP_SWS_Fw_81002], [AP_SWS_Fw_82008]

Configuración de manifest: instancia de módulo, conjuntos de reglas dependientes del estado y asignación de puertos

Los ajustes específicos de la máquina del módulo Firewall se recopilan en AdaptiveFirewallModuleInstantiation. La especificación correspondiente tiene en R25-11 el estado DRAFT (TPS_ManifestSpecification p. 677). La instancia del módulo especializa NonOsModuleInstantiation y referencia a través de stateDepFirewall cualquier número de elementos StateDependentFirewall.

Una StateDependentFirewall contiene:

• opcionalmente una defaultAction del tipo FirewallActionEnum,
• firewallRuleProps ordenadas,
• a través de firewallState (instanceRef), referencias a los ModeDeclarations en los que se aplica (TPS_ManifestSpecification p. 679).

El System Template la describe brevemente como «Firewall rules that are defined in a firewall state» (TPS_SystemTemplate p. 644).

Las reglas mismas son elementos FirewallRule con atributos como bucketSize y refillAmount. Además, el metamodelo incluye NetworkLayerRule y TransportLayerRule, esta última entre otros con rangos de puertos y checksumVerification. También un CouplingElement puede agregar reglas a través de firewallRule (TPS_ManifestSpecification p. 679). Para más detalles, el System Template remite expresamente a la especificación del manifest (TPS_SystemTemplate p. 644).

La conexión con la aplicación la establece AdaptiveFirewallToPortPrototypeMapping. Asigna la instancia del módulo (referencia firewall, 0..1) al RPortPrototype de la aplicación, tipificado mediante la interfaz de conmutación de estado (TPS_ManifestSpecification p. 677). Aplican dos restricciones:

• La nota de clase denomina la interfaz FirewallModeSwitchInterface, mientras que el título de la figura y la API la denominan FirewallStateSwitchInterface. Para el código es determinante el nombre de [AP_SWS_Fw_82002].
• La clase de mapeo y su referencia tienen el estado candidate (TPS_ManifestSpecification p. 677).

Diagrama de contexto (metamodelo): la instancia de módulo agrupa conjuntos de reglas dependientes del estado. El mapeo la conecta con el R-Port de la aplicación. Fuentes: TPS_ManifestSpecification p. 677, TPS_ManifestSpecification p. 679, TPS_ManifestSpecification p. 677

Flujo de un cambio de estado con SwitchFirewallState

En el lado del código, la aplicación incluye ara/fw/firewall_state.h. Crea ara::fw::FirewallStateSwitchInterface mediante el constructor explícito a partir de un ara::core::InstanceSpecifier. Este constructor es noexcept y seguro para subprocesos (thread-safe) [AP_SWS_Fw_82002].

El cambio de estado lo solicita SwitchFirewallState(EnumT firewallState). El método es noexcept y devuelve un ara::core::Future<void>. Por tanto, los errores FwErrc::kServiceNotAvailable y FwErrc::kInvalidStateDependentFirewall definidos para él retornan a través del future y no como excepción [AP_SWS_Fw_82008].

El escenario «Switch Firewall State» muestra el flujo interno en tres pasos (EXP_SWArchitecture p. 232):

1. La aplicación invoca SwitchFirewallState() en el FC Firewall.
2. El clúster invoca en un bucle «foreach FirewallRule» cada vez applyRule() en el sistema operativo.
3. Solo tras el bucle regresa la respuesta a la aplicación.

applyRule() está marcado allí como «aapInformative». Cómo se activan las reglas en el sistema operativo no está especificado en el payload como API de plataforma. La versión de R22-11 mostraba el mismo flujo como escenario exitoso (EXP_SWArchitecture p. 158). Tras el cambio, solo comprueban y filtran las reglas del estado activo (EXP_PlatformDesign p. 92).

Diagrama de secuencia: el cambio de estado se notifica de forma asíncrona a través de un future. Internamente, el clúster aplica cada regla individualmente. Fuentes: EXP_SWArchitecture p. 232, [AP_SWS_Fw_82002], [AP_SWS_Fw_82008]

Vida útil, reglas de copia y de movimiento de la clase de interfaz

Las funciones especiales de FirewallStateSwitchInterface determinan cómo se pueden transferir las instancias ([AP_SWS_Fw_82003] a [AP_SWS_Fw_82007]):

Elemento	Especificación	Seguridad para hilos
Constructor de InstanceSpecifier	explicit, noexcept [AP_SWS_Fw_82002]	thread-safe
Constructor de copia / Asignación por copia	=delete [AP_SWS_Fw_82004] [AP_SWS_Fw_82005]	–
Constructor de movimiento / Asignación por movimiento	noexcept [AP_SWS_Fw_82006] [AP_SWS_Fw_82007]	not thread-safe
Destructor	noexcept [AP_SWS_Fw_82003]	not thread-safe

De ello se derivan tres reglas de uso:

• Una instancia no puede duplicarse, sino solo transferirse por movimiento [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].
• El movimiento y la destrucción deben protegerse por la propia aplicación frente a accesos concurrentes [AP_SWS_Fw_82003].
• Interpretación: presumiblemente un objeto de origen ya no debería utilizarse tras un movimiento para SwitchFirewallState, ya que los Requirements solo describen la transferencia, pero no el estado residual [AP_SWS_Fw_82007]. Pregunta Q-ccf0737ee5133103 (abierta)

El texto de los Requirements no proporciona información sobre la seguridad para subprocesos de SwitchFirewallState en sí [AP_SWS_Fw_82008].

Diagrama de estados: una instancia surge a partir de un InstanceSpecifier, solo se transfiere por movimiento y finalmente se destruye. Fuentes: [AP_SWS_Fw_82002], [AP_SWS_Fw_82003], [AP_SWS_Fw_82006], [AP_SWS_Fw_82007]

Filtrado de paquetes en el estado activo y notificación de Security Events

Las reglas de firewall pueden asignarse a un estado de firewall. Para verificar un paquete solo se recurre a las reglas del estado actualmente activo (EXP_PlatformDesign p. 92). Por cada estado, la StateDependentFirewall proporciona las propiedades de regla ordenadas y la defaultAction opcional (TPS_ManifestSpecification p. 679).

La versión SWS R23-11 describe la asignación de Security Events de forma más precisa (SWS_Firewall p. 31):

• Si un paquete no coincide con ninguna regla, se aplica la acción por defecto.
• Si la acción por defecto bloquea el paquete, el clúster determina el protocolo divergente. Es determinante la regla con el mayor número de capas ISO/OSI coincidentes, contadas a partir de la capa inferior. La primera capa por encima que no coincida determina el protocolo.
• Para este protocolo se notifica un SEv al IdsM, tal como SEV_FW_PACKET_BLOCKED_DATALINKLAYER_MISMATCH (Ethernet), SEV_FW_PACKET_BLOCKED_IPV4_MISMATCH, SEV_FW_PACKET_BLOCKED_IPV6_MISMATCH o SEV_FW_PACKET_BLOCKED_ICMP_MISMATCH.

Estos detalles proceden de R23-11. Los Requirements correspondientes no pertenecen al payload de R25-11 y, por lo tanto, se reproducen aquí de forma explicativa, no normativa. El principio de que los mensajes bloqueados se envían como SEvs al IdsM se aplica, según la descripción de arquitectura, también para R25-11 (EXP_PlatformDesign p. 92).

Diagrama de actividades: un paquete se comprueba frente a las reglas del estado activo. Un bloqueo por defecto conduce a un SEv específico del protocolo al IdsM. Fuentes: EXP_PlatformDesign p. 92, SWS_Firewall p. 31 (R23-11)

Comportamiento en caso de error

Los códigos de error del módulo los define FwErrc en la cabecera ara/fw/fw_error_domain.h: kServiceNotAvailable=1 y kInvalidStateDependentFirewall=2 [AP_SWS_Fw_83001]. Ambos están fijados como posibles errores para SwitchFirewallState [AP_SWS_Fw_82008]. Interpretación de los nombres, dado que los Requirements no indican condiciones de activación:

• kServiceNotAvailable probablemente indique que el FC Firewall basado en demonio no puede prestar el servicio. Pregunta (abierta)
• kInvalidStateDependentFirewall probablemente indique que para el estado solicitado no existe una StateDependentFirewall válida. Pregunta (abierta)

El dominio de error sigue el patrón habitual de ara::core:

• GetFwErrorDomain() devuelve el dominio de forma segura para subprocesos [AP_SWS_Fw_83002]. El constructor por defecto de FwErrorDomain está eliminado [AP_SWS_Fw_83009].
• MakeErrorCode crea un ara::core::ErrorCode [AP_SWS_Fw_83003].
• Name() y Message() devuelven el nombre de dominio y el texto del error [AP_SWS_Fw_83010] [AP_SWS_Fw_83011].
• Los alias Errc y Exception hacen referencia a FwErrc y FwException [AP_SWS_Fw_83007] [AP_SWS_Fw_83008].

Quien trabaje con excepciones puede convertir un código de error mediante ThrowAsException en una FwException. Esta función es noexcept(false) y está clasificada como «not exception safe» [AP_SWS_Fw_83012] [AP_SWS_Fw_83005]. Por el contrario, los paquetes bloqueados no son un error de la API. Aparecen como Security Events en el IdsM (EXP_PlatformDesign p. 92).

Diagrama de actividades: el resultado del cambio de estado se evalúa a través del future. Los errores se gestionan a través de FwErrorDomain y pueden lanzarse opcionalmente como FwException. Fuentes: [AP_SWS_Fw_82008], [AP_SWS_Fw_83001], [AP_SWS_Fw_83011], [AP_SWS_Fw_83012]

Más evidencia detallada

Los siguientes pasajes sustentan las afirmaciones de esta guía; los Requirements son normativos para R25-11 ([AP_SWS_Fw_82008]).

• [AP_SWS_Fw_82008]: única operación funcional con tipo de retorno y lista de errores.
• [AP_SWS_Fw_82002], [AP_SWS_Fw_82003]: construcción y destrucción de la clase de interfaz junto con la seguridad para subprocesos.
• [AP_SWS_Fw_81001], [AP_SWS_Fw_81002]: tipos de estado generados.
• [AP_SWS_Fw_83001], [AP_SWS_Fw_83012]: códigos de error y conversión a excepciones.
• EXP_SWArchitecture p. 126, EXP_SWArchitecture p. 197: interfaz y casos de uso.
• EXP_SWArchitecture p. 232: flujo del cambio de estado. La versión predecesora de R22-11 se encuentra en EXP_SWArchitecture p. 158.
• TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 679: máquina de estados y modelo de reglas.
• TPS_SystemTemplate p. 644: breve descripción de la StateDependentFirewall. La versión de R23-11 se encuentra en TPS_SystemTemplate p. 583.
• SWS_Firewall p. 31: asignación de SEv en caso de bloqueo por defecto, solo en la versión R23-11.