Overview

The Linux Firewall Policy allows administrators to manage iptables/nftables firewall rules on Linux devices. Use this policy to define granular network filtering rules by specifying the table, chain, match criteria, and target action. This policy supports both BYOD and company-owned device ownership models.

Supported Platforms: Linux
Device Ownership: Company-owned, BYOD
Minimum System Requirements: Linux

How It Works

When this policy is applied to a device, the Swifteam agent configures the Linux netfilter subsystem (iptables/nftables) with the rules you define. Each rule is inserted into a specified table and chain, matching traffic based on protocol, IP addresses, ports, interfaces, and connection state — then applying a target action (accept, drop, reject, etc.).

Policy Fields

Firewall Rules

Property	Description
Field Name	`rules`
Display Name	Firewall Rules
Type	Array of dictionaries
Description	A list of firewall rules to apply on the device.

Each rule in the array contains the following sub-fields:

Rule Structure

Field	Display Name	Type	Description	Options
`table`	Table	String	The netfilter table to apply the rule to.	`filter`, `nat`, `mangle`, `raw`, `security`
`chain`	Chain	String	The chain within the table to insert the rule into.	`INPUT`, `OUTPUT`, `FORWARD`, `PREROUTING`, `POSTROUTING`
`comment`	Comment	String	A human-readable description for the rule.	Free text
`rule`	Rule	Dictionary	The match criteria and target action for this firewall rule.	See below

Rule Match Criteria & Target

The rule dictionary defines what traffic to match and what action to take:

Field	Display Name	Type	Description	Options
`protocol`	Protocol	String	The network protocol to match.	`tcp`, `udp`, `icmp`, `all`
`src_ip`	Source IP	String	Source IP address or CIDR range to match.	Any valid IP/CIDR
`dst_ip`	Destination IP	String	Destination IP address or CIDR range to match.	Any valid IP/CIDR
`src_port`	Source Port	String	Source port or port range to match.	e.g., `22` or `1024:65535`
`dst_port`	Destination Port	String	Destination port or port range to match.	e.g., `22` or `80:443`
`in_interface`	In Interface	String	Incoming network interface to match.	e.g., `eth0`
`out_interface`	Out Interface	String	Outgoing network interface to match.	e.g., `eth1`
`conntrack_state`	Conntrack State	Array of strings	Connection tracking states to match.	`NEW`, `ESTABLISHED`, `RELATED`, `INVALID`, `UNTRACKED`
`target`	Target	String	The action to take when the rule matches.	`ACCEPT`, `DROP`, `REJECT`, `LOG`, `RETURN`

Example Configuration

Below is a sample policy payload that demonstrates common firewall rules:

{
  "rules": [
    {
      "table": "filter",
      "chain": "INPUT",
      "comment": "Allow established and related connections",
      "rule": {
        "protocol": "all",
        "conntrack_state": ["ESTABLISHED", "RELATED"],
        "target": "ACCEPT"
      }
    },
    {
      "table": "filter",
      "chain": "INPUT",
      "comment": "Allow SSH from corporate network",
      "rule": {
        "protocol": "tcp",
        "src_ip": "10.0.0.0/8",
        "dst_port": "22",
        "conntrack_state": ["NEW"],
        "target": "ACCEPT"
      }
    },
    {
      "table": "filter",
      "chain": "INPUT",
      "comment": "Allow HTTPS traffic",
      "rule": {
        "protocol": "tcp",
        "dst_port": "443",
        "in_interface": "eth0",
        "conntrack_state": ["NEW"],
        "target": "ACCEPT"
      }
    },
    {
      "table": "filter",
      "chain": "INPUT",
      "comment": "Drop all other inbound traffic",
      "rule": {
        "protocol": "all",
        "target": "DROP"
      }
    },
    {
      "table": "filter",
      "chain": "OUTPUT",
      "comment": "Allow all outbound traffic",
      "rule": {
        "protocol": "all",
        "target": "ACCEPT"
      }
    }
  ]
}

Best Practices

Order matters. Rules are evaluated top-to-bottom. Place more specific rules before broader catch-all rules (e.g., allow SSH before a blanket DROP).
Always allow established connections. Include a rule matching ESTABLISHED and RELATED conntrack states early in your INPUT chain to avoid breaking existing sessions.
Use comments. Every rule should have a descriptive comment so that auditors and other admins can understand the intent without reverse-engineering match criteria.
Restrict SSH access. Limit SSH (dst_port: 22) to known corporate CIDR ranges rather than allowing it from 0.0.0.0/0.
Log before dropping. Consider adding a LOG target rule before your final DROP rule to capture denied traffic for troubleshooting and audit purposes.
Scope to the correct table. Most access-control rules belong in the filter table. Use nat for address translation, mangle for packet modification, and raw/security only when needed.

Frequently Asked Questions

Q: Does this policy support IPv6?
A: The policy configures rules via the netfilter framework. IPv6 support depends on whether the agent applies rules to ip6tables/nftables inet family. Consult your deployment documentation for IPv6-specific guidance.

Q: Can I use custom chains?
A: The policy currently supports the built-in chains: INPUT, OUTPUT, FORWARD, PREROUTING, and POSTROUTING.

Q: What happens if I don't specify a protocol?
A: If omitted or set to all, the rule will match traffic regardless of protocol.

Q: Is this policy compatible with systems using nftables natively?
A: Yes. The Swifteam agent abstracts the underlying implementation and applies rules to whichever netfilter backend is active on the device.

Windows VPN Policy

Linux VPN Policy

Firewall Requirements for Using Swif.ai

Linux Home Encryption Policy

Windows Firewall Policy