Modul ara::fw — Firewall

Der Functional Cluster Firewall filtert Netzwerkpakete nach zustandsabhängigen Regelsätzen aus dem Manifest und meldet blockierte Pakete als Security Events an den IdsM (EXP_PlatformDesign S. 92). Applikationen wählen den aktiven Firewall-Zustand über FirewallStateSwitchInterface::SwitchFirewallState. Die Methode liefert ein ara::core::Future<void> und meldet Fehler wie kServiceNotAvailable oder kInvalidStateDependentFirewall [AP_SWS_Fw_82008]. Die Zustände sind keine feste Liste, sondern werden je modelliertem Interface als Enumeration generiert. Instanzen der Schnittstelle lassen sich nur verschieben, nicht kopieren.

mehr ›

Das Modul fw spezifiziert den daemon-basierten Functional Cluster Firewall der Adaptive Platform. Seine Anwendungs-API ist die Schnittstelle FirewallStateSwitchInterface mit der Operation SwitchFirewallState(), die eine Adaptive Application nutzt (EXP_SWArchitecture S. 126). Der Cluster hat zwei Aufgaben: Er schaltet den Firewall-Zustand um und meldet Security Events an den Intrusion Detection System Manager (EXP_SWArchitecture S. 197).

Kontextdiagramm: Der FC Firewall verbindet Manifest-Konfiguration, Zustandsvorgabe der Applikation, Regelanwendung im Betriebssystem und SEv-Meldung an den IdsM. Quellen: EXP_PlatformDesign S. 97, EXP_SWArchitecture S. 197

Die Filterung ist zustandsabhängig. Der OEM definiert Zustände wie Fahren, Parken oder Diagnose, und für ein Paket gelten nur die Regeln des aktiven Zustands (EXP_PlatformDesign S. 92). Im Manifest bündelt AdaptiveFirewallModuleInstantiation dafür StateDependentFirewall-Elemente. Jedes davon enthält geordnete Regeleigenschaften, eine optionale defaultAction und Verweise auf die zugehörigen Zustände (TPS_ManifestSpecification S. 679). Im Code erscheinen die Zustände als je Interface generierte Enumeration in ara::fw::states [AP_SWS_Fw_81001].

Die Applikation erzeugt das Schnittstellenobjekt aus einem ara::core::InstanceSpecifier. Dieser Konstruktor ist thread-safe [AP_SWS_Fw_82002]. SwitchFirewallState ist noexcept und liefert ein ara::core::Future<void> [AP_SWS_Fw_82008]. Intern wendet der Cluster laut Szenario jede Firewall-Regel einzeln im Betriebssystem an (EXP_SWArchitecture S. 232). Instanzen lassen sich nicht kopieren, wohl aber verschieben. Move und Destruktor sind nicht thread-safe [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].

Sequenzdiagramm: Die Anforderung des Zustandswechsels kehrt als Future zurück. Dazwischen wird jede Regel einzeln angewendet. Quellen: EXP_SWArchitecture S. 232, [AP_SWS_Fw_82008]

Im Fehlerfall enthält das Future FwErrc::kServiceNotAvailable oder FwErrc::kInvalidStateDependentFirewall [AP_SWS_Fw_83001]. Die Bedeutung lässt sich nur aus den Namen erschließen: Der Dienst ist vermutlich nicht verfügbar, oder für den Zielzustand fehlt eine gültige Regelkonfiguration. Frage Q-45e3225696efb3dc (offen) Über FwErrorDomain::ThrowAsException lässt sich ein Fehler als FwException werfen [AP_SWS_Fw_83012]. Blockierte Pakete sind kein API-Fehler. Sie werden als Security Events an den IdsM gemeldet, in R23-11 zusätzlich nach abweichendem Protokoll unterschieden (SWS_Firewall S. 31).

mehr ›

Rolle des FC Firewall zwischen Applikation, Betriebssystem und IdsM

Das Modul fw beschreibt den Functional Cluster Firewall der Adaptive Platform. Er ist daemon-basiert und realisiert die Schnittstelle FirewallStateSwitchInterface mit der Operation SwitchFirewallState(). Eine Adaptive Application nutzt diese Schnittstelle über eine «use»-Beziehung (EXP_SWArchitecture S. 126). Die Use Cases beschränken den Cluster auf zwei Aufgaben. „Switch Firewall State“ wird von der Adaptive Application ausgelöst, das Betriebssystem wirkt mit. „Report Security Event“ richtet sich an den ebenfalls daemon-basierten Intrusion Detection System Manager (EXP_SWArchitecture S. 197).

Die Architekturübersicht trennt Konfiguration, Steuerung und Ausführung voneinander:

• Das Machine Manifest liefert die Filterregeln.
• Der FC Firewall konfiguriert damit eine Firewall Engine.
• Eine OEM-Applikation setzt den Firewall-Zustand.
• Der Cluster meldet Security Events (SEvs) an den IdsM (EXP_PlatformDesign S. 97).

Im Vordergrund stehen zwei Anwendungsfälle. Der erste ist die zustandsabhängige Filterung mit OEM-spezifischen Zuständen wie Fahren, Parken oder Diagnosesitzung. Der zweite ist die Unterstützung des Intrusion Detection System durch Security Events bei blockierten Nachrichten. Qualifizierung, Weitergabe an ein SOC oder persistente Ablage übernimmt der IdsM (EXP_PlatformDesign S. 92). Die einzige Anwendungs-API des Moduls ist der Zustandswechsel [AP_SWS_Fw_82008].

Kontextdiagramm: Der FC Firewall nimmt Konfiguration aus dem Machine Manifest und Zustandsvorgaben der Applikation entgegen. Er steuert Engine und Betriebssystem und meldet SEvs an den IdsM. Quellen: EXP_PlatformDesign S. 97, EXP_SWArchitecture S. 197, EXP_SWArchitecture S. 232

Firewall-Zustände: vom Zustandsautomaten im Modell zur generierten Enumeration

Im Manifest-Metamodell spezialisiert FirewallStateSwitchInterface ein PortInterface. Über die Rolle firewallStateMachine aggregiert es beliebig viele (0..*) ModeDeclarationGroupPrototype-Elemente (TPS_ManifestSpecification S. 263). Die einzelnen Zustände sind ModeDeclarations mit dem optionalen Attribut value: PositiveInteger (TPS_ManifestSpecification S. 679).

Für jedes modellierte Interface wird daraus eine eigene Enumeration enum class {<fwssi-sn>} : std::uint32_t im Namensraum ara::fw::states generiert. Sie wird über ara/fw/states/{<fwssi-sn>}.h eingebunden [AP_SWS_Fw_81001]. Je modelliertem Firewall-Zustand entsteht ein Enumerator {<symbol-fw-state>} = {<fw-state-value>} [AP_SWS_Fw_81002].

Für Anwender heißt das: Es gibt keine plattformweit feste Zustandsliste. Welche Zustände existieren, legt das OEM-Modell fest (EXP_PlatformDesign S. 92). SwitchFirewallState erwartet einen Parameter firewallState vom Typ EnumT [AP_SWS_Fw_82008]. Interpretation: EnumT dürfte der zum jeweiligen Interface generierten Zustands-Enumeration entsprechen. Frage Q-26dbe38f70cb0222 (offen) Dafür spricht, dass [AP_SWS_Fw_81001] sie ausdrücklich als Zustände „for FirewallStateSwitchInterface“ definiert.

Kontextdiagramm (Modell–Code): Die Zustände stammen aus dem Zustandsautomaten des Interfaces im Modell. Je Interface wird eine Enumeration in ara::fw::states generiert. Quellen: TPS_ManifestSpecification S. 263, [AP_SWS_Fw_81001], [AP_SWS_Fw_81002], [AP_SWS_Fw_82008]

Manifest-Konfiguration: Modulinstanz, zustandsabhängige Regelsätze und Port-Zuordnung

Die maschinenspezifischen Einstellungen des Firewall-Moduls werden in AdaptiveFirewallModuleInstantiation gesammelt. Die zugehörige Festlegung trägt in R25-11 den Status DRAFT (TPS_ManifestSpecification S. 677). Die Modulinstanz spezialisiert NonOsModuleInstantiation und referenziert über stateDepFirewall beliebig viele StateDependentFirewall-Elemente.

Eine StateDependentFirewall enthält:

• optional eine defaultAction vom Typ FirewallActionEnum,
• geordnete firewallRuleProps,
• über firewallState (instanceRef) Verweise auf die ModeDeclarations, in denen sie gilt (TPS_ManifestSpecification S. 679).

Das System Template beschreibt sie knapp als „Firewall rules that are defined in a firewall state“ (TPS_SystemTemplate S. 644).

Die Regeln selbst sind FirewallRule-Elemente mit Attributen wie bucketSize und refillAmount. Daneben führt das Metamodell NetworkLayerRule und TransportLayerRule, Letztere unter anderem mit Portbereichen und checksumVerification. Auch ein CouplingElement kann über firewallRule Regeln aggregieren (TPS_ManifestSpecification S. 679). Für Details verweist das System Template ausdrücklich auf die Manifest-Spezifikation (TPS_SystemTemplate S. 644).

Die Verbindung zur Applikation stellt AdaptiveFirewallToPortPrototypeMapping her. Es bildet die Modulinstanz (Referenz firewall, 0..1) auf den RPortPrototype der Applikation ab, der durch das Zustandsschalt-Interface typisiert ist (TPS_ManifestSpecification S. 677). Zwei Einschränkungen gelten:

• Die Klassennotiz nennt das Interface FirewallModeSwitchInterface, Bildtitel und API dagegen FirewallStateSwitchInterface. Für den Code maßgeblich ist der Name aus [AP_SWS_Fw_82002].
• Die Mapping-Klasse und ihre Referenz tragen den Status candidate (TPS_ManifestSpecification S. 677).

Kontextdiagramm (Metamodell): Die Modulinstanz bündelt zustandsabhängige Regelsätze. Das Mapping verbindet sie mit dem R-Port der Applikation. Quellen: TPS_ManifestSpecification S. 677, TPS_ManifestSpecification S. 679, TPS_ManifestSpecification S. 677

Ablauf eines Zustandswechsels mit SwitchFirewallState

Auf Code-Seite bindet die Applikation ara/fw/firewall_state.h ein. Sie erzeugt ara::fw::FirewallStateSwitchInterface über den expliziten Konstruktor aus einem ara::core::InstanceSpecifier. Dieser Konstruktor ist noexcept und thread-safe [AP_SWS_Fw_82002].

Den Zustandswechsel fordert SwitchFirewallState(EnumT firewallState) an. Die Methode ist noexcept und liefert ein ara::core::Future<void>. Die für sie festgelegten Fehler FwErrc::kServiceNotAvailable und FwErrc::kInvalidStateDependentFirewall kommen deshalb über das Future zurück und nicht als Ausnahme [AP_SWS_Fw_82008].

Das Szenario „Switch Firewall State“ zeigt den internen Ablauf in drei Schritten (EXP_SWArchitecture S. 232):

1. Die Applikation ruft SwitchFirewallState() am FC Firewall auf.
2. Der Cluster ruft in einer Schleife „foreach FirewallRule“ jeweils applyRule() am Betriebssystem auf.
3. Erst nach der Schleife kehrt die Antwort zur Applikation zurück.

applyRule() ist dort als «aapInformative» gekennzeichnet. Wie die Regeln im Betriebssystem aktiviert werden, ist im Payload nicht als Plattform-API festgelegt. Die R22-11-Fassung zeigte denselben Ablauf als erfolgreiches Szenario (EXP_SWArchitecture S. 158). Nach dem Wechsel prüfen und filtern nur noch die Regeln des aktiven Zustands (EXP_PlatformDesign S. 92).

Sequenzdiagramm: Der Zustandswechsel wird asynchron über ein Future zurückgemeldet. Intern wendet der Cluster jede Regel einzeln an. Quellen: EXP_SWArchitecture S. 232, [AP_SWS_Fw_82002], [AP_SWS_Fw_82008]

Lebensdauer, Kopier- und Move-Regeln der Schnittstellenklasse

Die Sonderfunktionen von FirewallStateSwitchInterface legen fest, wie Instanzen weitergegeben werden dürfen ([AP_SWS_Fw_82003] bis [AP_SWS_Fw_82007]):

Element	Festlegung	Thread-Sicherheit
Konstruktor aus InstanceSpecifier	explicit, noexcept [AP_SWS_Fw_82002]	thread-safe
Copy-Konstruktor / Copy-Zuweisung	=delete [AP_SWS_Fw_82004] [AP_SWS_Fw_82005]	–
Move-Konstruktor / Move-Zuweisung	noexcept [AP_SWS_Fw_82006] [AP_SWS_Fw_82007]	not thread-safe
Destruktor	noexcept [AP_SWS_Fw_82003]	not thread-safe

Daraus folgen drei Regeln für die Nutzung:

• Eine Instanz kann nicht dupliziert werden, sondern nur per Move weitergegeben werden [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].
• Move und Zerstörung muss die Applikation selbst gegen nebenläufige Zugriffe absichern [AP_SWS_Fw_82003].
• Interpretation: Ein Quellobjekt nach einem Move sollte vermutlich nicht mehr für SwitchFirewallState verwendet werden, weil die Requirements nur die Übertragung, nicht aber den Restzustand beschreiben [AP_SWS_Fw_82007]. Frage Q-ccf0737ee5133103 (offen)

Zur Thread-Sicherheit von SwitchFirewallState selbst macht der Requirement-Text keine Angabe [AP_SWS_Fw_82008].

Zustandsdiagramm: Eine Instanz entsteht aus einem InstanceSpecifier, wird nur per Move übertragen und schließlich zerstört. Quellen: [AP_SWS_Fw_82002], [AP_SWS_Fw_82003], [AP_SWS_Fw_82006], [AP_SWS_Fw_82007]

Paketfilterung im aktiven Zustand und Meldung von Security Events

Firewall-Regeln lassen sich einem Firewall-Zustand zuordnen. Zur Prüfung eines Pakets werden nur die Regeln des gerade aktiven Zustands herangezogen (EXP_PlatformDesign S. 92). Pro Zustand stellt die StateDependentFirewall die geordneten Regeleigenschaften und die optionale defaultAction bereit (TPS_ManifestSpecification S. 679).

Die SWS-Fassung R23-11 beschreibt die Zuordnung von Security Events genauer (SWS_Firewall S. 31):

• Passt ein Paket auf keine Regel, greift die Default-Aktion.
• Blockiert die Default-Aktion das Paket, bestimmt der Cluster das abweichende Protokoll. Maßgeblich ist die Regel mit den meisten passenden ISO/OSI-Schichten, gezählt ab der untersten Schicht. Die erste nicht passende Schicht darüber legt das Protokoll fest.
• Für dieses Protokoll wird ein SEv an den IdsM gemeldet, etwa SEV_FW_PACKET_BLOCKED_DATALINKLAYER_MISMATCH (Ethernet), SEV_FW_PACKET_BLOCKED_IPV4_MISMATCH, SEV_FW_PACKET_BLOCKED_IPV6_MISMATCH oder SEV_FW_PACKET_BLOCKED_ICMP_MISMATCH.

Diese Einzelheiten stammen aus R23-11. Die zugehörigen Requirements gehören nicht zum R25-11-Payload und sind hier deshalb erläuternd, nicht normativ wiedergegeben. Der Grundsatz, dass blockierte Nachrichten als SEvs an den IdsM gehen, gilt laut Architekturbeschreibung auch für R25-11 (EXP_PlatformDesign S. 92).

Aktivitätsdiagramm: Ein Paket wird gegen die Regeln des aktiven Zustands geprüft. Ein Default-Block führt zu einem protokollspezifischen SEv an den IdsM. Quellen: EXP_PlatformDesign S. 92, SWS_Firewall S. 31 (R23-11)

Verhalten im Fehlerfall

Die Fehlercodes des Moduls definiert FwErrc im Header ara/fw/fw_error_domain.h: kServiceNotAvailable=1 und kInvalidStateDependentFirewall=2 [AP_SWS_Fw_83001]. Beide sind für SwitchFirewallState als mögliche Fehler festgelegt [AP_SWS_Fw_82008]. Interpretation der Namen, da die Requirements keine Auslösebedingungen nennen:

• kServiceNotAvailable dürfte melden, dass der daemon-basierte FC Firewall den Dienst nicht erbringen kann. Frage (offen)
• kInvalidStateDependentFirewall dürfte melden, dass für den angeforderten Zustand keine gültige StateDependentFirewall vorliegt. Frage (offen)

Die Fehlerdomäne folgt dem üblichen ara::core-Muster:

• GetFwErrorDomain() liefert die Domäne thread-safe [AP_SWS_Fw_83002]. Der Standardkonstruktor von FwErrorDomain ist gelöscht [AP_SWS_Fw_83009].
• MakeErrorCode erzeugt einen ara::core::ErrorCode [AP_SWS_Fw_83003].
• Name() und Message() liefern Domänenname und Fehlertext [AP_SWS_Fw_83010] [AP_SWS_Fw_83011].
• Die Aliase Errc und Exception verweisen auf FwErrc und FwException [AP_SWS_Fw_83007] [AP_SWS_Fw_83008].

Wer mit Ausnahmen arbeitet, kann einen Fehlercode über ThrowAsException in eine FwException umwandeln. Diese Funktion ist noexcept(false) und als „not exception safe“ eingestuft [AP_SWS_Fw_83012] [AP_SWS_Fw_83005]. Blockierte Pakete sind dagegen kein API-Fehler. Sie erscheinen als Security Events beim IdsM (EXP_PlatformDesign S. 92).

Aktivitätsdiagramm: Das Ergebnis des Zustandswechsels wird über das Future ausgewertet. Fehler laufen über FwErrorDomain und können optional als FwException geworfen werden. Quellen: [AP_SWS_Fw_82008], [AP_SWS_Fw_83001], [AP_SWS_Fw_83011], [AP_SWS_Fw_83012]

Weiterführende Detailbelege

Die folgenden Stellen tragen die Aussagen dieses Leitfadens; die Requirements sind für R25-11 normativ ([AP_SWS_Fw_82008]).

• [AP_SWS_Fw_82008]: einzige fachliche Operation mit Rückgabetyp und Fehlerliste.
• [AP_SWS_Fw_82002], [AP_SWS_Fw_82003]: Konstruktion und Zerstörung der Schnittstellenklasse samt Thread-Sicherheit.
• [AP_SWS_Fw_81001], [AP_SWS_Fw_81002]: generierte Zustandstypen.
• [AP_SWS_Fw_83001], [AP_SWS_Fw_83012]: Fehlercodes und Umwandlung in Ausnahmen.
• EXP_SWArchitecture S. 126, EXP_SWArchitecture S. 197: Schnittstelle und Use Cases.
• EXP_SWArchitecture S. 232: Ablauf des Zustandswechsels. Die Vorgängerfassung aus R22-11 steht in EXP_SWArchitecture S. 158.
• TPS_ManifestSpecification S. 263, TPS_ManifestSpecification S. 679: Zustandsautomat und Regelmodell.
• TPS_SystemTemplate S. 644: Kurzbeschreibung der StateDependentFirewall. Die Fassung aus R23-11 steht in TPS_SystemTemplate S. 583.
• SWS_Firewall S. 31: SEv-Zuordnung bei Default-Blockierung, nur in der Fassung R23-11.