module ara::fw — Firewall

De Functional Cluster Firewall filtert netwerkpakketten volgens toestandafhankelijke regelsets uit het manifest en meldt geblokkeerde pakketten als Security Events aan de IdsM (EXP_PlatformDesign p. 92). Applicaties selecteren de actieve Firewall-toestand via FirewallStateSwitchInterface::SwitchFirewallState. De methode levert een ara::core::Future<void> op en meldt fouten zoals kServiceNotAvailable of kInvalidStateDependentFirewall [AP_SWS_Fw_82008]. De toestanden vormen geen vaste lijst, maar worden per gemodelleerde interface gegenereerd als enumeratie. Instanties van de interface kunnen alleen worden verplaatst, niet gekopieerd.

meer ›

De module fw specificeert de op daemons gebaseerde Functional Cluster Firewall van het Adaptive Platform. De applicatie-API ervan is de interface FirewallStateSwitchInterface met de operatie SwitchFirewallState(), die door een Adaptive Application wordt gebruikt (EXP_SWArchitecture p. 126). De cluster heeft twee taken: hij schakelt de Firewall-toestand om en meldt Security Events aan de Intrusion Detection System Manager (EXP_SWArchitecture p. 197).

Contextdiagram: De FC Firewall verbindt manifestconfiguratie, toestandsspecificatie van de applicatie, regeltoepassing in het besturingssysteem en SEv-melding aan de IdsM. Bronnen: EXP_PlatformDesign p. 97, EXP_SWArchitecture p. 197

De filtering is toestandafhankelijk. De OEM definieert toestanden zoals rijden, parkeren of diagnose, en voor een pakket gelden alleen de regels van de actieve toestand (EXP_PlatformDesign p. 92). In het manifest bundelt AdaptiveFirewallModuleInstantiation hiervoor StateDependentFirewall-elementen. Elk daarvan bevat geordende regeleigenschappen, een optionele defaultAction en verwijzingen naar de bijbehorende toestanden (TPS_ManifestSpecification p. 679). In de code verschijnen de toestanden als per interface gegenereerde enumeratie in ara::fw::states [AP_SWS_Fw_81001].

De applicatie maakt het interface-object aan vanuit een ara::core::InstanceSpecifier. Deze constructor is thread-safe [AP_SWS_Fw_82002]. SwitchFirewallState is noexcept en levert een ara::core::Future<void> op [AP_SWS_Fw_82008]. Intern past de cluster volgens het scenario elke Firewall-regel afzonderlijk toe in het besturingssysteem (EXP_SWArchitecture p. 232). Instanties kunnen niet worden gekopieerd, maar wel worden verplaatst. Move en destructor zijn niet thread-safe [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].

Sequentiediagram: De aanvraag van de toestandsverandering keert terug als Future. Daartussenin wordt elke regel afzonderlijk toegepast. Bronnen: EXP_SWArchitecture p. 232, [AP_SWS_Fw_82008]

In geval van een fout bevat de Future FwErrc::kServiceNotAvailable of FwErrc::kInvalidStateDependentFirewall [AP_SWS_Fw_83001]. De betekenis kan alleen worden afgeleid uit de namen: de service is vermoedelijk niet beschikbaar, of voor de doeltoestand ontbreekt een geldige regelconfiguratie. Vraag Q-45e3225696efb3dc (open) Via FwErrorDomain::ThrowAsException kan een fout als FwException worden geworpen [AP_SWS_Fw_83012]. Geblokkeerde pakketten zijn geen API-fout. Ze worden als Security Events gemeld aan de IdsM, in R23-11 bovendien onderscheiden naar afwijkend protocol (SWS_Firewall p. 31).

meer ›

Rol van de FC Firewall tussen applicatie, besturingssysteem en IdsM

De module fw beschrijft de Functional Cluster Firewall van het Adaptive Platform. Deze is op daemons gebaseerd en realiseert de interface FirewallStateSwitchInterface met de operatie SwitchFirewallState(). Een Adaptive Application gebruikt deze interface via een «use»-relatie (EXP_SWArchitecture p. 126). De use cases beperken de cluster tot twee taken. “Switch Firewall State” wordt getriggerd door de Adaptive Application, waarbij het besturingssysteem meewerkt. “Report Security Event” is gericht aan de eveneens op daemons gebaseerde Intrusion Detection System Manager (EXP_SWArchitecture p. 197).

Het architectuuroverzicht scheidt configuratie, besturing en uitvoering van elkaar:

• Het Machine Manifest levert de filterregels.
• De FC Firewall configureert daarmee een Firewall Engine.
• Een OEM-applicatie stelt de Firewall-toestand in.
• De cluster meldt Security Events (SEvs) aan de IdsM (EXP_PlatformDesign p. 97).

Op de voorgrond staan twee use cases. De eerste is de toestandafhankelijke filtering met OEM-specifieke toestanden zoals rijden, parkeren of diagnosesessie. De tweede is de ondersteuning van het Intrusion Detection System door Security Events bij geblokkeerde berichten. Kwalificatie, doorgifte aan een SOC of persistente opslag neemt de IdsM voor zijn rekening (EXP_PlatformDesign p. 92). De enige applicatie-API van de module is de toestandsverandering [AP_SWS_Fw_82008].

Contextdiagram: De FC Firewall ontvangt configuratie uit het Machine Manifest en toestandsspecificaties van de applicatie. Hij stuurt de engine en het besturingssysteem aan en meldt SEvs aan de IdsM. Bronnen: EXP_PlatformDesign p. 97, EXP_SWArchitecture p. 197, EXP_SWArchitecture p. 232

Firewall-toestanden: van state machine in het model tot gegenereerde enumeratie

In het manifest-metamodel specialiseert FirewallStateSwitchInterface een PortInterface. Via de rol firewallStateMachine aggregeert het willekeurig veel (0..*) ModeDeclarationGroupPrototype-elementen (TPS_ManifestSpecification p. 263). De afzonderlijke toestanden zijn ModeDeclaration's met het optionele attribuut value: PositiveInteger (TPS_ManifestSpecification p. 679).

Voor elke gemodelleerde interface wordt hieruit een eigen enumeratie enum class {<fwssi-sn>} : std::uint32_t gegenereerd in de namespace ara::fw::states. Deze wordt opgenomen via ara/fw/states/{<fwssi-sn>}.h [AP_SWS_Fw_81001]. Per gemodelleerde Firewall-toestand ontstaat een enumerator {<symbol-fw-state>} = {<fw-state-value>} [AP_SWS_Fw_81002].

Voor gebruikers betekent dit: er is geen platformbreed vaste toestandenlijst. Welke toestanden bestaan, bepaalt het OEM-model (EXP_PlatformDesign p. 92). SwitchFirewallState verwacht een parameter firewallState van het type EnumT [AP_SWS_Fw_82008]. Interpretatie: EnumT komt vermoedelijk overeen met de voor de desbetreffende interface gegenereerde toestandsenumeratie. Vraag Q-26dbe38f70cb0222 (open) Hiervoor pleit dat [AP_SWS_Fw_81001] deze uitdrukkelijk definieert als toestanden “for FirewallStateSwitchInterface”.

Contextdiagram (model–code): De toestanden zijn afkomstig uit de state machine van de interface in het model. Per interface wordt een enumeratie gegenereerd in ara::fw::states. Bronnen: TPS_ManifestSpecification p. 263, [AP_SWS_Fw_81001], [AP_SWS_Fw_81002], [AP_SWS_Fw_82008]

Manifestconfiguratie: module-instantie, toestandafhankelijke regelsets en port-toewijzing

De machinespecifieke instellingen van de Firewall-module worden verzameld in AdaptiveFirewallModuleInstantiation. De bijbehorende bepaling heeft in R25-11 de status DRAFT (TPS_ManifestSpecification p. 677). De module-instantie specialiseert NonOsModuleInstantiation en refereert via stateDepFirewall aan willekeurig veel StateDependentFirewall-elementen.

Een StateDependentFirewall bevat:

• optioneel een defaultAction van het type FirewallActionEnum,
• geordende firewallRuleProps,
• via firewallState (instanceRef) verwijzingen naar de ModeDeclaration's waarin deze van toepassing is (TPS_ManifestSpecification p. 679).

Het System Template beschrijft deze beknopt als “Firewall rules that are defined in a firewall state” (TPS_SystemTemplate p. 644).

De regels zelf zijn FirewallRule-elementen met attributen zoals bucketSize en refillAmount. Daarnaast bevat het metamodel NetworkLayerRule en TransportLayerRule, de laatste onder andere met portbereiken en checksumVerification. Ook een CouplingElement kan via firewallRule regels aggregeren (TPS_ManifestSpecification p. 679). Voor details verwijst het System Template uitdrukkelijk naar de manifestspecificatie (TPS_SystemTemplate p. 644).

De verbinding met de applicatie wordt tot stand gebracht door AdaptiveFirewallToPortPrototypeMapping. Deze beeldt de module-instantie (referentie firewall, 0..1) af op de RPortPrototype van de applicatie, die getypeerd is door de interface voor toestandswijziging (TPS_ManifestSpecification p. 677). Er gelden twee beperkingen:

• De klassenotitie noemt de interface FirewallModeSwitchInterface, de afbeeldingstitel en API daarentegen FirewallStateSwitchInterface. Voor de code is de naam uit [AP_SWS_Fw_82002] doorslaggevend.
• De mappingklasse en haar referentie hebben de status candidate (TPS_ManifestSpecification p. 677).

Contextdiagram (metamodel): De module-instantie bundelt toestandafhankelijke regelsets. De mapping verbindt deze met de R-port van de applicatie. Bronnen: TPS_ManifestSpecification p. 677, TPS_ManifestSpecification p. 679, TPS_ManifestSpecification p. 677

Verloop van een toestandsverandering met SwitchFirewallState

Aan de codezijde bindt de applicatie ara/fw/firewall_state.h in. Zij creëert ara::fw::FirewallStateSwitchInterface via de expliciete constructor vanuit een ara::core::InstanceSpecifier. Deze constructor is noexcept en thread-safe [AP_SWS_Fw_82002].

De toestandsverandering wordt aangevraagd door SwitchFirewallState(EnumT firewallState). De methode is noexcept en levert een ara::core::Future<void> op. De hiervoor vastgelegde fouten FwErrc::kServiceNotAvailable en FwErrc::kInvalidStateDependentFirewall komen daarom terug via de Future en niet als exceptie [AP_SWS_Fw_82008].

Het scenario “Switch Firewall State” toont het interne verloop in drie stappen (EXP_SWArchitecture p. 232):

1. De applicatie roept SwitchFirewallState() aan op de FC Firewall.
2. De cluster roept in een lus “foreach FirewallRule” telkens applyRule() aan op het besturingssysteem.
3. Pas na de lus keert het antwoord terug naar de applicatie.

applyRule() is daar aangeduid als «aapInformative». Hoe de regels in het besturingssysteem worden geactiveerd, is in de payload niet vastgelegd als platform-API. De R22-11-versie toonde hetzelfde verloop als succesvol scenario (EXP_SWArchitecture p. 158). Na de verandering controleren en filteren alleen nog de regels van de actieve toestand (EXP_PlatformDesign p. 92).

Sequentiediagram: De toestandsverandering wordt asynchroon teruggemeld via een Future. Intern past de cluster elke regel afzonderlijk toe. Bronnen: EXP_SWArchitecture p. 232, [AP_SWS_Fw_82002], [AP_SWS_Fw_82008]

Levensduur, kopieer- en move-regels van de interfaceklasse

De speciale functies van FirewallStateSwitchInterface leggen vast hoe instanties mogen worden doorgegeven ([AP_SWS_Fw_82003] tot [AP_SWS_Fw_82007]):

Element	Vastlegging	Thread-safety
Constructor uit InstanceSpecifier	explicit, noexcept [AP_SWS_Fw_82002]	thread-safe
Copy-constructor / copy-assignment	=delete [AP_SWS_Fw_82004] [AP_SWS_Fw_82005]	–
Move-constructor / move-assignment	noexcept [AP_SWS_Fw_82006] [AP_SWS_Fw_82007]	not thread-safe
Destructor	noexcept [AP_SWS_Fw_82003]	not thread-safe

Hieruit volgen drie regels voor het gebruik:

• Een instantie kan niet worden gedupliceerd, maar alleen via move worden doorgegeven [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].
• Move en vernietiging moet de applicatie zelf beveiligen tegen gelijktijdige toegangen [AP_SWS_Fw_82003].
• Interpretatie: Een bronobject na een move moet vermoedelijk niet meer voor SwitchFirewallState worden gebruikt, omdat de requirements alleen de overdracht, maar niet de resttoestand beschrijven [AP_SWS_Fw_82007]. Vraag Q-ccf0737ee5133103 (open)

Over de thread-safety van SwitchFirewallState zelf doet de requirementtekst geen uitspraak [AP_SWS_Fw_82008].

Toestandsdiagram: Een instantie ontstaat uit een InstanceSpecifier, wordt uitsluitend via move overgedragen en ten slotte vernietigd. Bronnen: [AP_SWS_Fw_82002], [AP_SWS_Fw_82003], [AP_SWS_Fw_82006], [AP_SWS_Fw_82007]

Pakketfiltering in de actieve toestand en melding van Security Events

Firewall-regels kunnen worden toegewezen aan een Firewall-toestand. Voor de controle van een pakket worden alleen de regels van de momenteel actieve toestand gebruikt (EXP_PlatformDesign p. 92). Per toestand stelt de StateDependentFirewall de geordende regeleigenschappen en de optionele defaultAction beschikbaar (TPS_ManifestSpecification p. 679).

De SWS-versie R23-11 beschrijft de toewijzing van Security Events nauwkeuriger (SWS_Firewall p. 31):

• Past een pakket op geen enkele regel, dan treedt de default-actie in werking.
• Blokkeert de default-actie het pakket, dan bepaalt de cluster het afwijkende protocol. Doorslaggevend is de regel met de meeste overeenkomende ISO/OSI-lagen, geteld vanaf de onderste laag. De eerste niet-overeenkomende laag daarboven bepaalt het protocol.
• Voor dit protocol wordt een SEv gemeld aan de IdsM, bijvoorbeeld SEV_FW_PACKET_BLOCKED_DATALINKLAYER_MISMATCH (Ethernet), SEV_FW_PACKET_BLOCKED_IPV4_MISMATCH, SEV_FW_PACKET_BLOCKED_IPV6_MISMATCH of SEV_FW_PACKET_BLOCKED_ICMP_MISMATCH.

Deze details zijn afkomstig uit R23-11. De bijbehorende requirements maken geen deel uit van de R25-11-payload en zijn hier daarom toelichtend, niet normatief weergegeven. Het uitgangspunt dat geblokkeerde berichten als SEvs naar de IdsM gaan, geldt volgens de architectuurbeschrijving ook voor R25-11 (EXP_PlatformDesign p. 92).

Activiteitendiagram: Een pakket wordt getoetst aan de regels van de actieve toestand. Een default-blokkering leidt tot een protocolspecifieke SEv naar de IdsM. Bronnen: EXP_PlatformDesign p. 92, SWS_Firewall p. 31 (R23-11)

Gedrag in het foutgeval

De foutcodes van de module worden gedefinieerd door FwErrc in header ara/fw/fw_error_domain.h: kServiceNotAvailable=1 en kInvalidStateDependentFirewall=2 [AP_SWS_Fw_83001]. Beide zijn voor SwitchFirewallState als mogelijke fouten vastgelegd [AP_SWS_Fw_82008]. Interpretatie van de namen, aangezien de requirements geen triggerende voorwaarden vermelden:

• kServiceNotAvailable meldt vermoedelijk dat de op daemons gebaseerde FC Firewall de dienst niet kan leveren. Vraag (open)
• kInvalidStateDependentFirewall meldt vermoedelijk dat er voor de opgevraagde toestand geen geldige StateDependentFirewall beschikbaar is. Vraag (open)

Het foutdomein volgt het gebruikelijke ara::core-patroon:

• GetFwErrorDomain() levert het domein thread-safe op [AP_SWS_Fw_83002]. De standaardconstructor van FwErrorDomain is verwijderd [AP_SWS_Fw_83009].
• MakeErrorCode genereert een ara::core::ErrorCode [AP_SWS_Fw_83003].
• Name() en Message() leveren domeinnaam en fouttekst op [AP_SWS_Fw_83010] [AP_SWS_Fw_83011].
• De aliassen Errc en Exception verwijzen naar FwErrc en FwException [AP_SWS_Fw_83007] [AP_SWS_Fw_83008].

Wie met excepties werkt, kan een foutcode via ThrowAsException omzetten in een FwException. Deze functie is noexcept(false) en geclassificeerd als „not exception safe” [AP_SWS_Fw_83012] [AP_SWS_Fw_83005]. Geblokkeerde pakketten vormen daarentegen geen API-fout. Ze verschijnen als Security Events bij de IdsM (EXP_PlatformDesign p. 92).

Activiteitendiagram: Het resultaat van de toestandswissel wordt via het Future geëvalueerd. Fouten verlopen via FwErrorDomain en kunnen optioneel als FwException worden geworpen. Bronnen: [AP_SWS_Fw_82008], [AP_SWS_Fw_83001], [AP_SWS_Fw_83011], [AP_SWS_Fw_83012]

Verdere gedetailleerde bewijzen

De volgende passages ondersteunen de stellingen in deze leidraad; de requirements zijn normatief voor R25-11 ([AP_SWS_Fw_82008]).

• [AP_SWS_Fw_82008]: enige functionele operatie met retourtype en foutenlijst.
• [AP_SWS_Fw_82002], [AP_SWS_Fw_82003]: constructie en destructie van de interfaceklasse inclusief thread safety.
• [AP_SWS_Fw_81001], [AP_SWS_Fw_81002]: gegenereerde toestandstypen.
• [AP_SWS_Fw_83001], [AP_SWS_Fw_83012]: foutcodes en omzetting in excepties.
• EXP_SWArchitecture p. 126, EXP_SWArchitecture p. 197: interface en use cases.
• EXP_SWArchitecture p. 232: verloop van de toestandswissel. De voorgaande versie uit R22-11 staat in EXP_SWArchitecture p. 158.
• TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 679: toestandsautomaat en regelmodel.
• TPS_SystemTemplate p. 644: korte beschrijving van de StateDependentFirewall. De versie uit R23-11 staat in TPS_SystemTemplate p. 583.
• SWS_Firewall p. 31: toewijzing van SEv bij default-blokkering, alleen in versie R23-11.