FirewallRuleManager.hpp

1. Overview

The FirewallRuleManager.hpp header defines the FirewallRuleManager utility class, a backend enforcement component responsible for applying IP-based blocking rules to the system firewall. The class abstracts differences between supported firewall backends (firewalld and UFW) and provides a single entry point to install blacklist rules generated from threat intelligence or security events.

Functionally, FirewallRuleManager provides:

  • A unified API for applying IP blacklist rules to supported firewalls
  • Backend-specific rule application for firewalld and UFW
  • Command execution helper for running firewall commands
  • Separation of firewall policy logic from UI and detection components
  • Integration point for automated network defense workflows

2. Dependencies and Includes

#include <string>
#include <vector>
#include "FirewallDetector.hpp"
  • <string> – command strings and helper I/O
  • <vector> – container for IP address lists
  • FirewallDetector.hpp – firewall type definitions and detection integration

3. Class Declaration and Scope

class FirewallRuleManager

The class is implemented as a static utility container. All methods are static, and no instances are intended to be created.

4. Public Interface

4.1 Apply Firewall Rules

static void apply(FirewallType fw,
                  const std::vector<std::string>& ips);

Applies a set of IP-based rules using the selected firewall backend. The caller supplies the firewall type (typically detected earlier) and the list of IPs to be blocked or otherwise regulated.

  • fw – firewall backend type (e.g., FirewallType::FIREWALLD, FirewallType::UFW)
  • ips – list of IP addresses to be applied as rules

When fw indicates that no firewall is available, the implementation is expected to fail safely (no changes) and provide appropriate feedback at higher layers.

5. UI Components

This component does not define graphical UI elements. It is designed to be invoked by services, background jobs, or UI controllers after user confirmation.

6. Internal State and Data Model

No persistent state is stored in this class. All actions are based on:

  • The firewall backend selected by the caller
  • The runtime list of IP addresses to enforce
  • Command execution results (success/failure)

7. Internal Logic

7.1 Command Execution Helper

static bool run(const std::string& cmd);

Executes a system command and returns whether it succeeded. This helper centralizes error handling for firewall command invocations.

The implementation typically captures exit codes, optionally logs output, and ensures commands are run in a controlled manner.

7.2 Backend-Specific Application

static void applyWithFirewalld(const std::vector<std::string>& ips);
static void applyWithUfw(const std::vector<std::string>& ips);

Applies rules using the corresponding firewall backend. Each method translates the list of IPs into the appropriate backend commands and ensures rules are persisted and activated.

  • applyWithFirewalld() – typically uses firewall-cmd rich rules or ipsets
  • applyWithUfw() – typically uses ufw deny from <ip> or equivalent constructs

8. Integration with Detection and Threat Feeds

FirewallRuleManager commonly integrates with:

  • Threat intelligence ingestion pipelines
  • BlacklistIpExtractor for feed parsing and output generation
  • Intrusion detection systems and log analyzers
  • Setup dialogs and settings pages where users enable firewall protection

9. Auto-Update (Scheduled Refresh)

This class does not implement scheduling. Periodic updates of rules are typically orchestrated by a service, cron job, or BastionGuard update subsystem.

10. Settings Storage

Rule persistence is handled by the underlying firewall backend:

  • firewalld persists rules through its configuration framework
  • UFW persists rules via its internal configuration files and state

BastionGuard may additionally store the selected backend and feed configuration in its own settings store; that persistence is external to this class.

11. Helper Functions and Platform Integration

This module relies on platform tools and conventions:

  • firewall-cmd and firewalld runtime/permanent rule management
  • ufw command-line interface and rule persistence
  • Privilege escalation mechanisms (sudo/pkexec) where required
  • Systemd services (firewalld.service, ufw.service) depending on distribution

12. Runtime and Security Considerations

  • Privilege boundaries: firewall rule changes typically require root privileges. Execution should be mediated through controlled privilege escalation with explicit user consent.
  • Command safety: avoid shell interpolation; sanitize IP inputs and prefer argument-vector execution to mitigate injection risks.
  • Validation: ensure IP addresses are syntactically valid and reject private/reserved ranges if inappropriate for the blacklist policy.
  • Idempotency: applying rules repeatedly should not create duplicates or degrade performance. Backend-specific strategies (ipset, rich rules) should be chosen accordingly.
  • Availability impact: blocking rules can disrupt connectivity; provide auditing/logging and a recovery path (rollback) at higher layers.
  • Atomicity: where possible, apply changes in batches and commit only after successful validation to avoid partial updates.
Published on:
Last updated on: