модуль ara::fw — Firewall

Functional Cluster Firewall фильтрует сетевые пакеты в соответствии с зависимыми от состояния наборами правил из манифеста и сообщает о заблокированных пакетах в IdsM как о Security Events (EXP_PlatformDesign с. 92). Приложения выбирают активное состояние Firewall через FirewallStateSwitchInterface::SwitchFirewallState. Метод возвращает ara::core::Future<void> и сообщает об ошибках, таких как kServiceNotAvailable или kInvalidStateDependentFirewall [AP_SWS_Fw_82008]. Состояния не являются фиксированным списком, а генерируются как перечисление для каждого смоделированного интерфейса. Экземпляры интерфейса можно только перемещать, но не копировать.

больше ›

Модуль fw специфицирует основанный на демоне Functional Cluster Firewall платформы Adaptive Platform. Его прикладным API является интерфейс FirewallStateSwitchInterface с операцией SwitchFirewallState(), которую использует Adaptive Application (EXP_SWArchitecture с. 126). У кластера две задачи: он переключает состояние Firewall и сообщает о Security Events в Intrusion Detection System Manager (EXP_SWArchitecture с. 197).

Контекстная диаграмма: FC Firewall связывает конфигурацию манифеста, задание состояния приложением, применение правил в операционной системе и отправку сообщений SEv в IdsM. Источники: EXP_PlatformDesign с. 97, EXP_SWArchitecture с. 197

Фильтрация зависит от состояния. OEM определяет такие состояния, как вождение, парковка или диагностика, и к пакету применяются только правила активного состояния (EXP_PlatformDesign с. 92). В манифесте AdaptiveFirewallModuleInstantiation объединяет для этого элементы StateDependentFirewall. Каждый из них содержит упорядоченные свойства правил, опциональный defaultAction и ссылки на соответствующие состояния (TPS_ManifestSpecification с. 679). В коде состояния представлены в виде сгенерированного для каждого интерфейса перечисления в ara::fw::states [AP_SWS_Fw_81001].

Приложение создает объект интерфейса из ara::core::InstanceSpecifier. Этот конструктор является потокобезопасным (thread-safe) [AP_SWS_Fw_82002]. SwitchFirewallState является noexcept и возвращает ara::core::Future<void> [AP_SWS_Fw_82008]. Внутри кластер согласно сценарию применяет каждое правило Firewall по отдельности в операционной системе (EXP_SWArchitecture с. 232). Экземпляры нельзя копировать, но можно перемещать. Перемещение и деструктор не являются потокобезопасными [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].

Диаграмма последовательности: запрос на смену состояния возвращается в виде Future. Между этим каждое правило применяется по отдельности. Источники: EXP_SWArchitecture с. 232, [AP_SWS_Fw_82008]

В случае ошибки Future содержит FwErrc::kServiceNotAvailable или FwErrc::kInvalidStateDependentFirewall [AP_SWS_Fw_83001]. Значение можно понять только из названий: служба, вероятно, недоступна, или для целевого состояния отсутствует корректная конфигурация правил. Вопрос Q-45e3225696efb3dc (открытый) Через FwErrorDomain::ThrowAsException ошибку можно выбросить как FwException [AP_SWS_Fw_83012]. Заблокированные пакеты не являются ошибкой API. Они передаются как Security Events в IdsM, причем в R23-11 дополнительно различаются по отличающемуся протоколу (SWS_Firewall с. 31).

больше ›

Роль FC Firewall между приложением, операционной системой и IdsM

Модуль fw описывает Functional Cluster Firewall платформы Adaptive Platform. Он основан на демоне и реализует интерфейс FirewallStateSwitchInterface с операцией SwitchFirewallState(). Adaptive Application использует этот интерфейс через отношение «use» (EXP_SWArchitecture с. 126). Прецеденты использования (Use Cases) ограничивают кластер двумя задачами. «Switch Firewall State» инициируется Adaptive Application при участии операционной системы. «Report Security Event» направлен к Intrusion Detection System Manager, который также основан на демоне (EXP_SWArchitecture с. 197).

Архитектурный обзор разделяет конфигурацию, управление и выполнение:

• Machine Manifest предоставляет правила фильтрации.
• FC Firewall конфигурирует с их помощью Firewall Engine.
• OEM-приложение задает состояние Firewall.
• Кластер сообщает о Security Events (SEv) в IdsM (EXP_PlatformDesign с. 97).

На переднем плане находятся два сценария использования. Первый — фильтрация, зависящая от состояния, со специфичными для OEM состояниями, такими как движение, парковка или сеанс диагностики. Второй — поддержка Intrusion Detection System посредством Security Events при заблокированных сообщениях. Квалификацию, передачу в SOC или долговременное хранение берет на себя IdsM (EXP_PlatformDesign с. 92). Единственным прикладным API модуля является смена состояния [AP_SWS_Fw_82008].

Контекстная диаграмма: FC Firewall принимает конфигурацию из Machine Manifest и задаваемые приложением состояния. Он управляет Engine и операционной системой и сообщает о SEv в IdsM. Источники: EXP_PlatformDesign с. 97, EXP_SWArchitecture с. 197, EXP_SWArchitecture с. 232

Состояния Firewall: от автомата состояний в модели к сгенерированному перечислению

В метамодели манифеста FirewallStateSwitchInterface специализирует PortInterface. Через роль firewallStateMachine он агрегирует произвольное количество (0..*) элементов ModeDeclarationGroupPrototype (TPS_ManifestSpecification с. 263). Отдельные состояния представляют собой ModeDeclaration с опциональным атрибутом value: PositiveInteger (TPS_ManifestSpecification с. 679).

Для каждого смоделированного интерфейса на этой основе генерируется собственное перечисление enum class {<fwssi-sn>} : std::uint32_t в пространстве имен ara::fw::states. Оно подключается через ara/fw/states/{<fwssi-sn>}.h [AP_SWS_Fw_81001]. Для каждого смоделированного состояния Firewall создается элемент перечисления (enumerator) {<symbol-fw-state>} = {<fw-state-value>} [AP_SWS_Fw_81002].

Для пользователей это означает: фиксированного в масштабах платформы списка состояний не существует. Какие состояния существуют, определяет модель OEM (EXP_PlatformDesign с. 92). SwitchFirewallState ожидает параметр firewallState типа EnumT [AP_SWS_Fw_82008]. Интерпретация: EnumT, вероятно, соответствует перечислению состояний, сгенерированному для соответствующего интерфейса. Вопрос Q-26dbe38f70cb0222 (открытый) В пользу этого говорит то, что [AP_SWS_Fw_81001] явно определяет их как состояния «for FirewallStateSwitchInterface».

Контекстная диаграмма (модель — код): состояния берутся из автомата состояний интерфейса в модели. Для каждого интерфейса генерируется перечисление в ara::fw::states. Источники: TPS_ManifestSpecification с. 263, [AP_SWS_Fw_81001], [AP_SWS_Fw_81002], [AP_SWS_Fw_82008]

Конфигурация манифеста: экземпляр модуля, зависимые от состояния наборы правил и сопоставление портов

Специфичные для машины настройки модуля Firewall собираются в AdaptiveFirewallModuleInstantiation. Соответствующее определение имеет в R25-11 статус DRAFT (TPS_ManifestSpecification с. 677). Экземпляр модуля специализирует NonOsModuleInstantiation и ссылается через stateDepFirewall на любое количество элементов StateDependentFirewall.

StateDependentFirewall содержит:

• опционально defaultAction типа FirewallActionEnum,
• упорядоченные firewallRuleProps,
• через firewallState (instanceRef) ссылки на ModeDeclaration, в которых оно действует (TPS_ManifestSpecification с. 679).

System Template кратко описывает их как «Firewall rules that are defined in a firewall state» (TPS_SystemTemplate с. 644).

Сами правила представляют собой элементы FirewallRule с такими атрибутами, как bucketSize и refillAmount. Кроме того, метамодель содержит NetworkLayerRule и TransportLayerRule, последние, среди прочего, с диапазонами портов и checksumVerification. Также CouplingElement может агрегировать правила через firewallRule (TPS_ManifestSpecification с. 679). Для получения подробной информации System Template явно отсылает к спецификации манифеста (TPS_SystemTemplate с. 644).

Связь с приложением устанавливает AdaptiveFirewallToPortPrototypeMapping. Он отображает экземпляр модуля (ссылка firewall, 0..1) на RPortPrototype приложения, который типизирован интерфейсом переключения состояний (TPS_ManifestSpecification с. 677). Действуют два ограничения:

• В примечании к классу интерфейс называется FirewallModeSwitchInterface, тогда как в заголовке рисунка и в API — FirewallStateSwitchInterface. Для кода решающее значение имеет имя из [AP_SWS_Fw_82002].
• Класс отображения и его ссылка имеют статус candidate (TPS_ManifestSpecification с. 677).

Контекстная диаграмма (метамодель): экземпляр модуля объединяет зависимые от состояния наборы правил. Отображение связывает их с R-портом приложения. Источники: TPS_ManifestSpecification с. 677, TPS_ManifestSpecification с. 679, TPS_ManifestSpecification с. 677

Последовательность смены состояния с помощью SwitchFirewallState

На стороне кода приложение подключает ara/fw/firewall_state.h. Оно создает ara::fw::FirewallStateSwitchInterface через явный конструктор из ara::core::InstanceSpecifier. Этот конструктор является noexcept и потокобезопасным (thread-safe) [AP_SWS_Fw_82002].

Смену состояния запрашивает SwitchFirewallState(EnumT firewallState). Метод является noexcept и возвращает ara::core::Future<void>. Поэтому определенные для него ошибки FwErrc::kServiceNotAvailable и FwErrc::kInvalidStateDependentFirewall возвращаются через Future, а не как исключение [AP_SWS_Fw_82008].

Сценарий «Switch Firewall State» показывает внутренний процесс в три шага (EXP_SWArchitecture с. 232):

1. Приложение вызывает SwitchFirewallState() в FC Firewall.
2. Кластер вызывает в цикле «foreach FirewallRule» каждый раз applyRule() в операционной системе.
3. Только после завершения цикла ответ возвращается приложению.

applyRule() отмечен там как «aapInformative». Способ активации правил в операционной системе не определен в полезной нагрузке как API платформы. Версия R22-11 показывала ту же последовательность в качестве успешного сценария (EXP_SWArchitecture с. 158). После переключения проверку и фильтрацию выполняют только правила активного состояния (EXP_PlatformDesign с. 92).

Диаграмма последовательности: смена состояния подтверждается асинхронно через Future. Внутри кластер применяет каждое правило по отдельности. Источники: EXP_SWArchitecture с. 232, [AP_SWS_Fw_82002], [AP_SWS_Fw_82008]

Время жизни, правила копирования и перемещения класса интерфейса

Специальные функции FirewallStateSwitchInterface определяют, как разрешается передавать экземпляры (от [AP_SWS_Fw_82003] до [AP_SWS_Fw_82007]):

Элемент	Определение	Потокобезопасность
Конструктор из InstanceSpecifier	explicit, noexcept [AP_SWS_Fw_82002]	thread-safe
Конструктор копирования / операция присваивания копированием	=delete [AP_SWS_Fw_82004] [AP_SWS_Fw_82005]	–
Конструктор перемещения / операция присваивания перемещением	noexcept [AP_SWS_Fw_82006] [AP_SWS_Fw_82007]	not thread-safe
Деструктор	noexcept [AP_SWS_Fw_82003]	not thread-safe

Отсюда следуют три правила использования:

• Экземпляр нельзя дублировать, его можно только передавать с помощью перемещения [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].
• Приложение должно самостоятельно защитить перемещение и уничтожение от конкурентного доступа [AP_SWS_Fw_82003].
• Интерпретация: исходный объект после перемещения, вероятно, больше не следует использовать для SwitchFirewallState, поскольку требования описывают только передачу, но не оставшееся состояние [AP_SWS_Fw_82007]. Вопрос Q-ccf0737ee5133103 (открытый)

Относительно потокобезопасности самого SwitchFirewallState текст требований не содержит сведений [AP_SWS_Fw_82008].

Диаграмма состояний: экземпляр создается из InstanceSpecifier, передается только перемещением и в конечном счете уничтожается. Источники: [AP_SWS_Fw_82002], [AP_SWS_Fw_82003], [AP_SWS_Fw_82006], [AP_SWS_Fw_82007]

Фильтрация пакетов в активном состоянии и регистрация Security Events

Правила Firewall можно сопоставить состоянию Firewall. Для проверки пакета используются только правила текущего активного состояния (EXP_PlatformDesign с. 92). Для каждого состояния StateDependentFirewall предоставляет упорядоченные свойства правил и опциональное defaultAction (TPS_ManifestSpecification с. 679).

Версия SWS R23-11 описывает сопоставление Security Events более подробно (SWS_Firewall с. 31):

• Если пакет не подходит ни под одно правило, применяется действие по умолчанию.
• Если действие по умолчанию блокирует пакет, кластер определяет отклоняющийся протокол. Определяющим является правило с наибольшим количеством совпадающих уровней ISO/OSI, считая с самого нижнего уровня. Первый несовпадающий уровень выше него определяет протокол.
• Для этого протокола в IdsM отправляется сообщение о SEv, например SEV_FW_PACKET_BLOCKED_DATALINKLAYER_MISMATCH (Ethernet), SEV_FW_PACKET_BLOCKED_IPV4_MISMATCH, SEV_FW_PACKET_BLOCKED_IPV6_MISMATCH или SEV_FW_PACKET_BLOCKED_ICMP_MISMATCH.

Эти подробности взяты из R23-11. Соответствующие требования не входят в полезную нагрузку R25-11 и поэтому приведены здесь в качестве пояснения, а не как нормативные. Принцип, согласно которому заблокированные сообщения отправляются в IdsM как SEv, согласно описанию архитектуры действует и для R25-11 (EXP_PlatformDesign с. 92).

Диаграмма деятельности: пакет проверяется на соответствие правилам активного состояния. Блокировка по умолчанию приводит к отправке протокольно-специфичного SEv в IdsM. Источники: EXP_PlatformDesign с. 92, SWS_Firewall с. 31 (R23-11)

Поведение при ошибке

Коды ошибок модуля определяет FwErrc в заголовке ara/fw/fw_error_domain.h: kServiceNotAvailable=1 и kInvalidStateDependentFirewall=2 [AP_SWS_Fw_83001]. Оба определены для SwitchFirewallState как возможные ошибки [AP_SWS_Fw_82008]. Интерпретация названий, так как в требованиях не указаны условия возникновения:

• kServiceNotAvailable, по-видимому, сообщает о том, что демон-ориентированный FC Firewall не может предоставить сервис. Вопрос (открытый)
• kInvalidStateDependentFirewall, по-видимому, сообщает о том, что для запрошенного состояния отсутствует допустимое StateDependentFirewall. Вопрос (открытый)

Домен ошибок следует привычному шаблону ara::core:

• GetFwErrorDomain() потокобезопасно возвращает домен [AP_SWS_Fw_83002]. Конструктор по умолчанию FwErrorDomain удален [AP_SWS_Fw_83009].
• MakeErrorCode создает ara::core::ErrorCode [AP_SWS_Fw_83003].
• Name() и Message() возвращают имя домена и текст ошибки [AP_SWS_Fw_83010] [AP_SWS_Fw_83011].
• Псевдонимы Errc и Exception указывают на FwErrc и FwException [AP_SWS_Fw_83007] [AP_SWS_Fw_83008].

Те, кто работает с исключениями, могут преобразовать код ошибки в FwException с помощью ThrowAsException. Эта функция noexcept(false) и классифицирована как «not exception safe» [AP_SWS_Fw_83012] [AP_SWS_Fw_83005]. Заблокированные пакеты, напротив, не являются ошибкой API. Они отображаются как Security Events в IdsM (EXP_PlatformDesign с. 92).

Диаграмма деятельности: результат смены состояния оценивается через Future. Ошибки передаются через FwErrorDomain и при необходимости могут генерироваться как FwException. Источники: [AP_SWS_Fw_82008], [AP_SWS_Fw_83001], [AP_SWS_Fw_83011], [AP_SWS_Fw_83012]

Дальнейшие подробные доказательства

Следующие фрагменты содержат утверждения данного руководства; требования являются нормативными для R25-11 ([AP_SWS_Fw_82008]).

• [AP_SWS_Fw_82008]: единственная прикладная операция с типом возвращаемого значения и списком ошибок.
• [AP_SWS_Fw_82002], [AP_SWS_Fw_82003]: конструирование и уничтожение интерфейсного класса вместе с потокобезопасностью.
• [AP_SWS_Fw_81001], [AP_SWS_Fw_81002]: сгенерированные типы состояний.
• [AP_SWS_Fw_83001], [AP_SWS_Fw_83012]: коды ошибок и преобразование в исключения.
• EXP_SWArchitecture с. 126, EXP_SWArchitecture с. 197: интерфейс и Use Cases.
• EXP_SWArchitecture с. 232: последовательность смены состояния. Предшествующая версия из R22-11 находится в EXP_SWArchitecture с. 158.
• TPS_ManifestSpecification с. 263, TPS_ManifestSpecification с. 679: конечный автомат и модель правил.
• TPS_SystemTemplate с. 644: краткое описание StateDependentFirewall. Версия из R23-11 находится в TPS_SystemTemplate с. 583.
• SWS_Firewall с. 31: сопоставление SEv при блокировке по умолчанию, только в версии R23-11.