Archive for the ‘Firewall’ Category

How to Restrict a Program to Use Only a Specific Port Range for Outgoing Connections (Linux)

Wednesday, October 22nd, 2025

In some advanced system administration and security scenarios, you might want to restrict a specific program (or a user) to only use a specific range of source ports when making outbound connections. This can be important for:

  • Securing network access per service
  • Enforcing port-based identity
  • Making firewall rules easier to manage
  • Avoiding source port collisions in NAT environments

This article explains how to achieve this using iptables, cgroups, and kernel-level ephemeral port controls, with practical, copy-paste-ready examples.

What meant by "Port Range Restriction"?

When a program connects to an external server (e.g., with curl or a custom app), the kernel assigns a source port — typically from a dynamic range like 32768–60999. If you want to limit a specific app or user to only use, say, source ports 50000–51000 for all its outbound connections, you have to implement that at the firewall or kernel level.

Option 1: Using iptables with the owner Module (Per-User Limiting)

This is the most straightforward way if the program runs as a known user or UID.

Example: Allow only source ports 50000–51000 for myuser

# Block all outgoing TCP traffic from 'myuser' outside the port range

# iptables -A OUTPUT -p tcp -m owner –uid-owner myuser ! –sport 50000:51000 -j DROP

 

# Optional: for UDP

# iptables -A OUTPUT -p udp -m owner –uid-owner myuser ! –sport 50000:51000 -j DROP

Note: This will not stop the application from running — it just ensures the kernel drops packets that don't meet your policy.

Option 2: Using cgroups with net_cls + iptables (Per-Process Control)

For more precise control, especially in multi-user systems or containers, you can use Linux cgroups to classify traffic per process.

Step-by-step:

  1. Create a net_cls cgroup:

# mkdir -p /sys/fs/cgroup/net_cls/myapp

# echo 0x100001 | sudo tee /sys/fs/cgroup/net_cls/myapp/net_cls.classid

  1. Assign your process to the cgroup:

# Replace <PID> with the actual process ID

# echo <PID> | sudo tee /sys/fs/cgroup/net_cls/myapp/tasks

  1. Add iptables rule:

# iptables -A OUTPUT -m cgroup –cgroup 0x100001 -p tcp ! –sport 50000:51000 -j DROP


This gives you fine-grained per-process port restrictions.


Optional: Set Ephemeral Port Range (Globally or Per Namespace)

Linux picks ephemeral ports from a default system-wide range (32768–60999). You can limit this globally (not recommended in shared systems) or within a network namespace.

To view the current range:

# cat /proc/sys/net/ipv4/ip_local_port_range

To change the range:

# echo "50000 51000" | sudo tee /proc/sys/net/ipv4/ip_local_port_range

Warning: This affects all processes. Better used inside isolated environments (e.g., containers or netns).

Run the App with Explicit bind() to Source Port

If you control the source code of the app, the cleanest method is to explicitly bind to the desired source port(s) before making the connection.

Python Example:

import socket

 

s = socket.socket()

s.bind(('', 50001))  # bind to specific source port

s.connect(('example.com', 443))

Many apps and libraries (like curl, wget, netcat, python requests, etc.) don't expose source port binding — in those cases, control must be done externally.

Logging Violations

To log connection attempts from disallowed source ports:
 

# iptables -A OUTPUT -p tcp -m owner –uid-owner myuser ! –sport 50000:51000 \

  -j LOG –log-prefix "PORT VIOLATION: " –log-level 4
 

Containerized or Isolated Environments: Use Namespaces or Docker

For Docker or custom network namespaces, you can:

  • Use a private ephemeral port range
  • Use iptables inside the namespace
  • Isolate the entire network stack for maximum safety

Docker Example:

 # docker run -d –name limited_app –net=custom_net -p 50000-51000:50000-51000 myimage

Then configure the app inside the container to bind or use that port range.

Important Limitations

  • iptables owner match works only for UIDs, not process names.
  • If the app doesn’t bind explicitly, the kernel still picks a port — make sure the global range or netns is set correctly.
  • Some apps (e.g. Java, browsers) may use multiple ephemeral ports simultaneously — test carefully.
  • Not all programs allow setting source port via command line.

Recommended Best Practices

Let’s say you want to allow only ports 50000–51000 for a service called myapp:

  1. Create a dedicated system user:

# sudo useradd -r -s /sbin/nologin myapp

  1. Run the program as this user:

# sudo -u myapp /path/to/myapp

  1. Set the desired port range system-wide (optional):

# echo "50000 51000" | sudo tee /proc/sys/net/ipv4/ip_local_port_range

  1. Add iptables rule:

# iptables -A OUTPUT -p tcp -m owner –uid-owner myapp ! –sport 50000:51000 -j DROP

  1. (Optional) Add logging:

# iptables -A OUTPUT -p tcp -m owner –uid-owner myapp ! –sport 50000:51000 -j LOG –log-prefix "MYAPP PORT BLOCKED: "

  1. Make sure the app binds or connects correctly from that range.

Final Thoughts

Restricting outbound source port ranges per application or user is an underused but powerful technique to lock down systems, especially in:

  • High-security environments
  • Multi-tenant servers
  • NAT/firewall-managed networks
  • IDS/IPS-aware setups


You can start with simple iptables rules for users, and later adopt cgroups or container namespaces for deeper isolation.

Force specific source ports for a app like curl

To force specific source ports in general-purpose tools like curl or nc, try using iptables SNAT (with care), or consider writing wrappers/scripts that handle binding via LD_PRELOAD or custom socket logic.

How to Create Secure Stateful Firewall Rules with nftables on Linux

Monday, October 6th, 2025

nftables-logo-linux-mastering-stateful-firewall-rules-with-nftables-firewall

Firewalls are the frontline defense of any server or network. While many sysadmins are familiar with iptables, nftables is the modern Linux firewall framework offering more power, flexibility, and performance.

One of the key features of nftables is stateful packet inspection, which lets you track the state of network connections and write precise rules that dynamically accept or reject packets based on connection status.

In this guide, we’ll deep dive into stateful firewall rules using nftables — what they are, why they matter, and how to master them for a robust, secure network.

What is Stateful Firewalling?

A stateful firewall keeps track of all active connections passing through it. It monitors the state of a connection (new, established, related, invalid) and makes decisions based on that state rather than just static IP or port rules.

This allows:

  • Legitimate traffic for existing connections to pass freely
  • Blocking unexpected or invalid packets
  • Better security and less manual rule writing

Understanding Connection States in nftables

nftables uses the conntrack subsystem to track connections. Common states are:

State

Description

new

Packet is trying to establish a new connection

established

Packet belongs to an existing connection

related

Packet related to an existing connection (e.g. FTP data)

invalid

Packet that does not belong to any connection or is malformed

Basic Stateful Rule Syntax in nftables

The key keyword is ct state. For example:

nft add rule inet filter input ct state established,related accept

This means: allow any incoming packets that are part of an established or related connection.

Step-by-Step: Writing a Stateful Firewall with nftables

  1. Create the base table and chains


nft add table inet filter

nft add chain inet filter input { type filter hook input priority 0 \; }

nft add chain inet filter forward { type filter hook forward priority 0 \; }

nft add chain inet filter output { type filter hook output priority 0 \; }

  1. Allow loopback traffic

nft add rule inet filter input iif lo accept

  1. Allow established and related connections

nft add rule inet filter input ct state established,related accept

  1. Drop invalid packets

nft add rule inet filter input ct state invalid drop

  1. Allow new SSH connections

nft add rule inet filter input tcp dport ssh ct state new accept

  1. Drop everything else

nft add rule inet filter input drop

Why Use Stateful Filtering?

  • Avoid writing long lists of rules for each connection direction
  • Automatically handle protocols with dynamic ports (e.g. FTP, SIP)
  • Efficient resource usage and faster lookups
  • Better security by rejecting invalid or unexpected packets
nftables-tcpip-model-diagram-logo

Advanced Tips for Stateful nftables Rules

  • Use ct helper for protocols requiring connection tracking helpers (e.g., FTP)
  • Combine ct state with interface or user match for granular control
  • Use counters with rules to monitor connection states
  • Rate-limit new connections using limit rate with ct state new

Real-World Example: Preventing SSH Brute Force with Stateful Rules

nft add rule inet filter input tcp dport ssh ct state new limit rate 5/minute accept

nft add rule inet filter input tcp dport ssh drop

This allows only 5 new SSH connections per minute.

Troubleshooting Stateful Rules

  • Use conntrack -L to list tracked connections
  • Logs can help; enable logging on dropped packets temporarily
  • Check if your firewall blocks ICMP (important for some connections)
  • Remember some protocols may require connection helpers

Making Your nftables Rules Permanent

By default, any rules you add using nft commands are temporary — they live in memory and are lost after a reboot.

To make your nftables rules persistent, you need to save them to a configuration file and ensure they're loaded at boot.

Option 1. Using the nftables Service (Preferred on Most Distros)

Most modern Linux distributions (Debian ≥10, Ubuntu ≥20.04, CentOS/RHEL ≥8) come with a systemd service called nftables.service that automatically loads rules from /etc/nftables.conf at boot.

 Do the following to make nftables load on boot:

Dump your current rules into a file:

# nft list ruleset > /etc/nftables.conf

Enable the nftables service to load them at boot:

# systemctl enable nftables

(Optional) Start the service immediately if it’s not running:

# systemctl start nftables

Check status:

# systemctl status nftables

Now your rules will survive reboots.

Alternative way to load nftables on network UP, Use Hooks in
/etc/network/if-pre-up.d/ or Custom Scripts (Advanced)

If your distro doesn't use nftables.service or you're on a minimal setup (e.g., Alpine, Slackware, older Debian), you can load the rules manually at boot:

Save your rules:

# nft list ruleset > /etc/nftables.rules

Create a script to load them (e.g., /etc/network/if-pre-up.d/nftables):

#!/bin/sh

nft -f /etc/nftables.rules

Make it executable:

chmod +x /etc/network/if-pre-up.d/nftables

This method works on systems without systemd.

Sample /etc/nftables.conf config

We first define variables which we can use later on in our ruleset:

 

define NIC_NAME = "eth0"

define NIC_MAC_GW = "DE:AD:BE:EF:01:01"

define NIC_IP = "192.168.1.12"

define LOCAL_INETW = { 192.168.0.0/16 }

define LOCAL_INETWv6 = { fe80::/10 }

define DNS_SERVERS = { 1.1.1.1, 8.8.8.8 }

define NTP_SERVERS = { time1.google.com, time2.google.com, time3.google.com, time4.google.com }

define DHCP_SERVER = "192.168.1.1"

Next code block shows ip filter and ip6 filter sample:

We first create an explicit deny rule (policy drop;) for the chain input and chain output.
This means all network traffic is dropped unless its explicitly allowed later on.

Next we have to define these exceptions based on network traffic we want to allow.
Loopback network traffic is only allowed from the loopback interface and within RFC loopback network space.

nftables automatically maps network protocol names to port numbers (e.g. HTTPS 443).
In this example, we only allow incoming sessions which we initiated (ct state established accept) from ephemeral ports (dport 32768-65535). Be aware an app or web server should allow newly initiated sessions (ct state new).

Certain network sessions initiated by this host (ct state new,established accept) in the chain output are explicitly allowed in the output chain. We also allow outgoing ping requests (icmp type echo-request), but do not want others to ping this host, hence ct state established in the icmp type input chain. 

table ip filter {

    chain input {

       type filter hook input priority 0; policy drop;

       iifname "lo" accept

       iifname "lo" ip saddr != 127.0.0.0/8 drop

       iifname $NIC_NAME ip saddr 0.0.0.0/0 ip daddr $NIC_IP tcp sport { ssh, http, https, http-alt } tcp dport 32768-65535 ct state established accept

       iifname $NIC_NAME ip saddr $NTP_SERVERS ip daddr $NIC_IP udp sport ntp udp dport 32768-65535 ct state established accept

       iifname $NIC_NAME ip saddr $DHCP_SERVER ip daddr $NIC_IP udp sport bootpc udp dport 32768-65535 ct state established log accept

       iifname $NIC_NAME ip saddr $DNS_SERVERS ip daddr $NIC_IP udp sport domain udp dport 32768-65535 ct state established accept

       iifname $NIC_NAME ip saddr $LOCAL_INETW ip daddr $NIC_IP icmp type echo-reply ct state established accept

    }

 

    chain output {

       type filter hook output priority 0; policy drop;

       oifname "lo" accept

       oifname "lo" ip daddr != 127.0.0.0/8 drop

       oifname $NIC_NAME ip daddr 0.0.0.0/0 ip saddr $NIC_IP tcp dport { ssh, http, https, http-alt } tcp sport 32768-65535 ct state new,established accept

       oifname $NIC_NAME ip daddr $NTP_SERVERS ip saddr $NIC_IP udp dport ntp udp sport 32768-65535 ct state new,established accept

       oifname $NIC_NAME ip daddr $DHCP_SERVER ip saddr $NIC_IP udp dport bootpc udp sport 32768-65535 ct state new,established log accept

       oifname $NIC_NAME ip daddr $DNS_SERVERS ip saddr $NIC_IP udp dport domain udp sport 32768-65535 ct state new,established accept

       oifname $NIC_NAME ip daddr $LOCAL_INETW ip saddr $NIC_IP icmp type echo-request ct state new,established accept

    }

 

    chain forward {

       type filter hook forward priority 0; policy drop;

    }

}

 

The next code block is used to block incoming and outgoing IPv6 traffic, except ping requests (icmpv6 type echo-request) and IPv6 network discovery (nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert).

vNICs are often automatically provisioned with IPv6 addresses and left untouched. These interfaces can be abused by malicious entities to tunnel out confidential data or even a shell.

table ip6 filter {

    chain input {

       type filter hook input priority 0; policy drop;

       iifname "lo" accept

       iifname "lo" ip6 saddr != ::1/128 drop

       iifname $NIC_NAME ip6 saddr $LOCAL_INETWv6 icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, echo-reply, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } ct state established accept

    }

 

    chain output {

       type filter hook output priority 0; policy drop;

       oifname "lo" accept

       oifname "lo" ip6 daddr != ::1/128 drop

       oifname $NIC_NAME ip6 daddr $LOCAL_INETWv6 icmpv6 type echo-request ct state new,established accept

    }

 

    chain forward {

       type filter hook forward priority 0; policy drop;

    }

}

 Last code block is used for ARP traffic which limits ARP broadcast network frames:

table arp filter {

   chain input {

       type filter hook input priority 0; policy accept;

       iif $NIC_NAME limit rate 1/second burst 2 packets accept

   }

 

   chain output {

       type filter hook output priority 0; policy accept;

   }

}

To load up nftables rules

# systemctl restart nftables && systemctl status nftables && nft list ruleset

Test Before Save and Apply

NB !!! Always test your rules before saving them permanently. A typo can lock you out of your server !!!

Try:

# nft flush ruleset

# nft -f /etc/nftables.conf


!!! Make sure to test your ports are truly open or closed. You can use nc, telnet or tcpdump for this. !!!

Or use a screen or tmux session and set a watchdog timer (e.g., at now +2 minutes reboot) so you can recover if something goes wrong.

Conclusion

In the ever-evolving landscape of network security, relying on static firewall rules is no longer enough. Stateful filtering with nftables gives sysadmins the intelligence and flexibility needed to deal with real-world traffic — allowing good connections, rejecting bad ones, and keeping things efficient.

With just a few lines, you can build a firewall that’s not only more secure but also easier to manage and audit over time.Whether you're protecting a personal server, a VPS, or a corporate gateway, understanding ct state is a critical step in moving from "good enough" security to proactive, intelligent defense.
If you're still relying on outdated iptables chains with hundreds of line-by-line port filters, maybe it's time to embrace the modern way.
nftables isn’t just the future — it’s the present. Further on log, monitor, and learn from your own traffic.

Start with the basics, then layer on your custom rules and monitoring and enjoy your system services and newtork being a bit more secure than before.


Cheers ! 🙂

IPFilter firewall basics use for Adding / Removing and Cloning firewall rules

Thursday, June 1st, 2023

ipfilter-bsd-solaris-unix-firewall-short-review-ofLinux_firewalls-BSD_Firewall_logo

Linux users have most definitely used Netfilter (the older from us might remember and have used ipchains) and rest
should know well or at least partially tried iptables or if you have digged into Linux firewalls more professionally, might have tried nftables
and the newer firewalld (firewall-cmd) that is the standard nowadays in CentOS / Fedora and RHEL (again an abstraction over iptables.).
On Debian firewall is organized around custom shell scripts that deal with iptables chains, or if on Ubuntu perhaps you have tried UFW (The Uncomplicated Firewall)
frontend program for managing firewalls again with iptables. For the lazy ones UFW even has another GUI frontend called Gufw (intended to be easy, intuitive,
graphical user interface for managing Uncomlicated firewall.

Different Linux distributions do use a different set of firewall mechanisms preconfigure but there are other firewall solutions on other Unixes such as ipfilter.
That historically were heavily used that is worthy mentioning and if you happen to pop-up working as a network guy inside some large corporations you might face it.

IPFilter (commonly referred to as ipf) is an open-source software package that provides firewall services and network address translation (NAT) for many Unix-like operating systems.
The author and software maintainer is Darren Reed. IPFilter supports both IPv4 and IPv6 protocols, and is a stateful firewall.
IPFilter is delivered with FreeBSD, NetBSD, Solaris 10 & 11, illumos, OpenIndiana and HP-UX.
It used to be a part of OpenBSD, but it was removed by Theo de Raadt in May 2001 due to problems with its license.
It was subsequently replaced in OpenBSD by PF, which was developed by OpenBSD's own developers.
DragonFly BSD removed its support for IPFilter in May 2011.

IPFilter can be installed as a runtime-loadable kernel module or directly incorporated into the operating system kernel, depending on the specifics of each kernel and user preferences.
The software's documentation recommends the module approach, if possible.

Here are some commands for displaying, changing and distributing IP filters with ipfilter.
It will be mostly useful, if you happen to have some obsolete OS infrastructure or OpenBSD.

The commands given below are to add / remove and activate rules on machine with ipfilter:

# ipfilter –clone
# ipfilter –save
# ipfilter –activate
# ipfilter -addrule
# ipfilter -delrule
# help ipfilter

1. Check ipfilter current config

# ipfilter –show
Name: default_ipv4, Type: ipv4, State: active
Rule    Source IP                               Protocol   Dest Port   Action
1     any                                            tcp       22     permit
2     any                                            tcp       23     permit
3     any                                            tcp       80     permit
4     any                                            tcp      443     permit
5     any                                            udp      161     permit
6     any                                            udp      123     permit
7     any                                            tcp      600 – 1023     permit
8     any                                            udp      600 – 1023     permit
Name: default_ipv6, Type: ipv6, State: active
Rule    Source IP                               Protocol   Dest Port   Action
1     any                                            tcp       22     permit
2     any                                            tcp       23     permit
3     any                                            tcp       80     permit
4     any                                            tcp      443     permit
5     any                                            udp      161     permit
6     any                                            udp      123     permit
7     any                                            tcp      600 – 1023     permit
8     any                                            udp      600 – 1023     permit
Name: default_ipv4_new, Type: ipv4, State: defined
Rule    Source IP                               Protocol   Dest Port   Action
1     any                                            tcp       22     permit
2     any                                            tcp       23     permit
3     any                                            tcp       80     permit
4     any                                            tcp      443     permit
5     any                                            udp      161     permit
6     any                                            udp      123     permit
7     any                                            tcp      600 – 1023     permit
8     any                                            udp      600 – 1023     permit

2. Clone and activate ipfilter configuration

# ipfilter –clone default_ipv4_new -from default_ipv4
# ipfilter –activate default_ipv4_new
# ipfilter –show
Name: default_ipv4, Type: ipv4, State: defined
Rule    Source IP                               Protocol   Dest Port   Action
1     any                                            tcp       22     permit
2     any                                            tcp       23     permit
3     any                                            tcp       80     permit
4     any                                            tcp      443     permit
5     any                                            udp      161     permit
6     any                                            udp      123     permit
7     any                                            tcp      600 – 1023     permit
8     any                                            udp      600 – 1023     permit
Name: default_ipv6, Type: ipv6, State: active
Rule    Source IP                               Protocol   Dest Port   Action
1     any                                            tcp       22     permit
2     any                                            tcp       23     permit
3     any                                            tcp       80     permit
4     any                                            tcp      443     permit
5     any                                            udp      161     permit
6     any                                            udp      123     permit
7     any                                            tcp      600 – 1023     permit
8     any                                            udp      600 – 1023     permit
Name: default_ipv4_neu, Type: ipv4, State: active
Rule    Source IP                               Protocol   Dest Port   Action
1     any                                            tcp       22     permit
2     any                                            tcp       23     permit
3     any                                            tcp       80     permit
4     any                                            tcp      443     permit
5     any                                            udp      161     permit
6     any                                            udp      123     permit
7     any                                            tcp      600 – 1023     permit
8     any                                            udp      600 – 1023     permit

3. Modify cloned configuration

Lets say we would like to delete the telnet port accept traffic rule  (port 23)

# ipfilter –delrule default_ipv4_new -rule 2

To permit the rule agian

# ipfilter –addrule default_ipv4_new -rule 2 -sip any -dp 23 -proto tcp -act permit

To save the rule

# ipfilter –save default_ipv4_new