Firewall IP Block

Overview

Firewall IP Block provides OS-level IP blocking. It performs better than the application-layer blacklist and is suited to malicious IPs that should be completely blocked.

Unlike the application-layer blacklist, Firewall IP Block stops traffic at the operating system firewall, so a blocked IP is rejected before it ever reaches the WAF application.

System firewall blocks apply globally to the machine and all ports, including the management port. The add, edit and batch-add dialogs no longer select a website; the search area has no website filter, and the list has no website column. Use IP Blacklist for website-scoped blocking.

Existing system block records are preserved after upgrading, even though their former website field is no longer shown. Editing and saving an existing record normalizes its scope to global. Existing WAF blacklist entries are preserved independently. If you previously selected "Both", manage the two records separately: deletion on either page does not cascade to the other.

Scope and allowlists

The system layer accepts single IPs and CIDRs, with no wildcards, ranges or IP group references. Targets covering an entire address family, such as 0.0.0.0/0 and ::/0, cannot be added, edited, batch-added or enabled; rule synchronization also skips such records.

WAF IP/URL allowlists cannot override an OS firewall DROP. The system firewall matches the network source; behind a CDN or reverse proxy, it may see the proxy node's IP. Check the actual network source to avoid blocking shared proxy nodes and management connections. To block by the client IP identified for a particular website, use the WAF blacklist.

The top of the page has two tabs: Manual and Feed Source. The Manual tab shows five statistics cards giving a live overview of the current block rules: Total, Active, Inactive, Expired, and Feed Landed (System) (the active count of threat-intel feeds landed into the system firewall). Clicking the Feed Landed (System) card switches to the Feed Source tab to view per-channel details.

Prerequisites

This feature relies on the firewall built into the operating system, so it has environment requirements:

Operating System	Requirement
Linux	iptables is installed (iptables-save is required as well), and the SamWaf process is allowed to modify iptables (usually means running as root).
Windows	Windows Firewall is turned on (any one of the Domain / Private / Public profiles is enough).
macOS	The pf firewall is enabled (sudo pfctl -e) and SamWaf runs as root.

When you open the page, SamWaf probes the current environment automatically. If the requirements are not met, a yellow banner at the top of the page explains why, the Add Firewall IP Block / Batch Add / Sync Rules buttons are disabled, and the Enable action is hidden from the list. Existing records can still be viewed, disabled, and deleted (in that case only the management-side records are cleaned up; the OS firewall is not touched).

Docker deployment

To use this feature inside a container, all three conditions below must be met:

1. iptables must be present in the image. The official SamWaf image ships with it; if you build your own image from a minimal Alpine base, add apk add --no-cache iptables.
2. The container needs the NET_ADMIN capability. Without it the commands fail on permissions even if iptables is installed.
3. The container must share the host network namespace (--network host). Otherwise the rules are written only into the container's own network namespace and have no effect on traffic reaching the host.

docker run example:

docker run -d --name samwaf-instance \
  --cap-add=NET_ADMIN \
  --network host \
  -v ./conf:/app/conf -v ./data:/app/data -v ./logs:/app/logs -v ./ssl:/app/ssl \
  samwaf/samwaf

The equivalent in docker-compose.yml:

services:
  samwaf-instance:
    image: samwaf/samwaf
    cap_add:
      - NET_ADMIN
    network_mode: host

Note

With network_mode: host you can no longer declare ports mappings or custom networks; the container uses the host network directly.

Tip

If you cannot meet these container requirements, use the IP Blacklist instead to block at the WAF application layer — it works in any environment.

Use Cases

• Completely block malicious IPs at the system level, not just at the application layer.
• Import a batch of known malicious IPs or IP ranges.
• Work with the automatic blocking mechanism to block source IPs that trigger rules, temporarily or long term.

Steps

Add a single block

1. Click Add Firewall IP Block at the top-left of the page.
2. In the dialog, enter the IP Address and Block Reason, and select a Block Type. Rules apply globally, with no website selection.
3. To set an Expire Time, pick a specific time; leave it blank for a permanent block.
4. Optionally add a remark, then click Confirm to save.

Batch add

1. Click the Batch Add button.
2. In the IP List text box, enter one IP address per line. Single IP and CIDR formats are supported.
3. Enter the Block Reason, select a Block Type, and add remarks. Batch-added rules also apply globally.
4. Click Confirm to block all of them at once.

Enable / Disable

• In the action column, an Inactive record can be re-enabled with Enable; an Active record can be turned off with Disable.

Sync Rules

• Click Sync Rules to push the management-side block rules to the operating system firewall.

Clear Expired

• Click Clear Expired; a confirmation dialog appears. After confirming, it removes the firewall rules and deletes all expired block records (cannot be undone). Permanent bans and non-expired records are not affected.

Edit / Delete / Batch Delete

• In the action column, click Edit to modify a single rule or Delete to remove it.
• Select multiple records and click Batch Delete to remove them at once.

Feed Source

Switch to the Feed Source tab at the top to view, read-only, a per-channel summary of Threat Intelligence IP Feeds landed into the system firewall: name, channel code, landing layer, enabled status, Landed (Active) count, last status, and last sync time.

For performance, subscribed IPs are not written row-by-row into this page's block list; they are summarized per channel. Click View IPs on a channel to browse its specific IPs/CIDRs read-only, with substring filtering.

Landed (Active) count

A disabled channel shows a landed count of 0 (removed from the system firewall), followed by a grey hint of its snapshot size (re-enabling re-lands it in seconds). So this column reflects the currently effective count, not the total subscribed entries.

Field Reference

Field	Description
IP Address	The IP to block. Supports single IP or CIDR format, e.g. 192.168.1.100 or 192.168.1.0/24.
IP List	Used for batch add: one IP address per line, single IP or CIDR format.
Block Reason	The reason for the block, for later traceability.
Block Type	One of Manual, Auto, or Temporary.
Status	Active, Inactive, or Pending.
Expire Time	When the block expires. Blank (or 0) means a permanent block; records past their time are shown as expired.
Remarks	Custom notes.

Block Type

Type	Description
Manual	A block added manually by an administrator.
Auto	A block created automatically by the system.
Temporary	A temporary block.

Status

Status	Description
Active	The block rule is in effect at the system level.
Inactive	The block rule is disabled and no longer in effect.
Pending	The block rule has not taken effect yet.

FAQ

• The IP is not blocked immediately after adding it? Click Sync Rules to push the rules to the operating system firewall.
• How do I make a block permanent? Leave the expire time blank when adding or editing; the list shows it as Permanent.
• How do I clean up expired records? Click the Clear Expired button at the top; after confirming, it removes the firewall rules and deletes all expired records (cannot be undone). Permanent bans and non-expired records are not affected.
• All buttons are greyed out with a "system firewall blocking is not available" message? The environment does not meet the prerequisites. The banner states the exact reason — commonly: iptables is not installed on Linux, the process lacks permission to modify iptables (root is required), or Windows Firewall is off. For container deployments, add iptables, the NET_ADMIN capability, and --network host as described above.
• The block succeeds inside a container, but the malicious IP can still reach the site? The container is most likely not running with --network host. The rules were written only into the container's own network namespace and do nothing to traffic arriving at the host.

Update History

Date	Applicable Version	Description
2026-10-30	v1.3.25-beta.9	System blocks apply globally to the machine; removed website selection, filter and column; preserved existing records with global scope on edit; disallowed whole-family targets and clarified independent records on the two pages.