Microsegmentation Linux Server Setup

Updated on Apr 15, 2026
Mila H
12 MINS READ
Table of Contents
Microsegmentation Linux Server Setup

Microsegmentation is a security technique. You can divide your network into very small, isolated zones and control how they communicate with each other. With Microsegmentation Linux Server Setup, you can create strict rules so that only the right servers can connect on the right ports. In Linux servers, this can be done with host-based firewalls such as nftables, iptables, or higher-level tools like firewalld.

In simple words, Microsegmentation blocks everything and allows only what’s needed. This creates multiple security layers. Even if an attacker breaks into one server, they can’t freely move around the network.

In this guide, we have three groups of servers:

  • Web server: This faces the internet and handles HTTP/HTTPS (ports 80 and 443).
  • App server: This runs the main application logic and listens on port 8080.
  • Database server: This stores your data and listens on port 5432 (Postgres) or 3306 (MySQL).

We will use nftables directly on each server and define simple lists of IPs, so rules are easy to manage.

In short, we are building a strict, least-privilege firewall setup where each server can only talk to the server it needs, and only on the ports it needs.

This works on bare metal, VMs, and cloud instances, with or without Kubernetes. If you are looking for secure and high-performance Bare metal servers, you can explore Perlod Hosting.

Let's dive into the Microsegmentation Linux Server Setup.

Prerequisites for Microsegmentation Linux Server Setup

You can use this instruction for Ubuntu 22.04 and 24.04, as well as RHEL 8 and 9. Log in to your server as a root or non-root user with sudo privileges.

Example subnets used in this guide:

  • Admin/Mgmt: 10.10.0.0/26
  • Web server: 10.10.1.10 - 10.10.1.19
  • App server: 10.10.1.20 - 10.10.1.29
  • DB server: 10.10.1.30 - 10.10.1.39

Note: When using nftables, remember to disable UFW or firewalld if they are already in use. If you want to use Firewalld, you can proceed to the FirewallD Alternative section.

Step 1. Install and Enable nftables

The first step is to install and enable nftables.

On Ubuntu and Debian-based OS, run the commands below:

Bash
apt update apt install nftables -y systemctl enable --now nftables

On RHEL, Rocky Linux, or AlmaLinux, run the commands below:

Bash
dnf install nftables -y systemctl enable --now nftables

Step 2. Backup and Validate Current nftables Rules and Config Files

It is recommended that, before you start loading a new ruleset, you back up and validate your current nftables configuration. If you have any rulesets and config files, make a backup of them by using the following commands:

Bash
nft list ruleset > /root/nft.rules.backup.$(date +%F-%H%M).nft [ -f /etc/nftables.conf ] && cp -a /etc/nftables.conf /etc/nftables.conf.bak.$(date +%F-%H%M)

Then, you can validate your config file for errors without loading it by using the following command:

Bash
nft -c -f /etc/nftables.conf

You can also immediately load a previous backup ruleset to recover from a bad configuration that locked you out:

Bash
nft -f /root/nft.rules.backup.YYYY-MM-DD-HHMM.nft

You must replace the YYYY-MM-DD-HHMM with the timestamp of your backup file.

Step 3. Create a Base nftables Ruleset

At this point, we will use a base ruleset template and only change the role section per server (web/app/db).

First, create the directory with the following command:

Bash
mkdir -p /etc/nftables.d

Then, use your desired text editor to create and open the main /etc/nftables.conf file:

Bash
nano /etc/nftables.conf

Add the following nftables configuration script to the file:

Bash
#!/usr/sbin/nft -f flush ruleset # ======== Edit these sets to match your network ========define ADMIN_NET = { 10.10.0.0/26 }define WEB_NODES = { 10.10.1.10-10.10.1.19 }define APP_NODES = { 10.10.1.20-10.10.1.29 }define DB_NODES  = { 10.10.1.30-10.10.1.39 } table inet filter {  sets {    admin_net { type ipv4_addr; flags interval; elements = $ADMIN_NET; }    web_nodes { type ipv4_addr; flags interval; elements = $WEB_NODES; }    app_nodes { type ipv4_addr; flags interval; elements = $APP_NODES; }    db_nodes  { type ipv4_addr; flags interval; elements = $DB_NODES; }  }   chains {    input {      type filter hook input priority 0; policy drop;       # Allow safe basics      ct state { established, related } accept      iif lo accept       # ICMP/ICMPv6 for PMTU and diagnostics      ip protocol icmp accept      ip6 nexthdr icmpv6 accept       # SSH from admin network only      ip saddr @admin_net tcp dport 22 accept       # Role-specific inbound rules go here      # (Inserted via /etc/nftables.d/role-input.nft)      include "/etc/nftables.d/role-input.nft"       # Last resort: log & drop      counter log prefix "NFT-IN-DROP " group 1 level info limit rate 10/second drop    }     output {      type filter hook output priority 0; policy drop;       # Allow replies and loopback      ct state { established, related } accept      oif lo accept       # Minimal OS egress: DNS, NTP, HTTP/S (for updates), CRL/OCSP      udp dport 53 accept      udp dport 123 accept      tcp dport { 80, 443 } accept       # Role-specific egress rules go here      include "/etc/nftables.d/role-output.nft"       # Last resort: log & drop      counter log prefix "NFT-OUT-DROP " group 1 level info limit rate 10/second drop    }     forward {      type filter hook forward priority 0; policy drop;    }  }}

Once you are done, save and close the file.

This config file:

  • Creates a strict, default-deny firewall (all incoming/outgoing traffic is blocked by default).
  • Uses defined sets for different groups of servers (web, app, database) and an admin network.
  • Allows only minimal, essential traffic (like SSH from admin networks, ICMP, and basic OS egress for updates).
  • Includes external files (/etc/nftables.d/role-input.nft) for adding role-specific rules without editing the main file.
  • Logs and counts any dropped packets for troubleshooting.

Step 4. Implement A Zero-Trust and Least-Privilege Network Model

At this point, we will define exactly what traffic each type of server (Web, App, DB) is allowed to receive and send.

1. Web Server: It accepts HTTP/HTTPS (ports 80/443) from anyone and can send traffic only to the App server on port 8080.

Create and define the Web input role by using the command below:

Bash
cat >/etc/nftables.d/role-input.nft <<'EOF'tcp dport { 80, 443 } acceptEOF

Create and define the Web output role by using the command below:

Bash
cat >/etc/nftables.d/role-output.nft <<'EOF'ip daddr @app_nodes tcp dport 8080 acceptEOF

2. App Server: It accepts traffic only from the Web server on port 8080 and can send traffic only to the Database server on ports 5432 (PostgreSQL) or 3306 (MySQL).

Create and define the App input role by using the command below:

Bash
cat >/etc/nftables.d/role-input.nft <<'EOF'ip saddr @web_nodes tcp dport 8080 acceptEOF

Create and define the App output role by using the command below:

Bash
cat >/etc/nftables.d/role-output.nft <<'EOF'ip daddr @db_nodes tcp dport { 5432, 3306 } acceptEOF

3. Database Server: It accepts traffic only from the App server on database ports (5432/3306) and can not send anything; it can only send the basic OS traffic from the base rules.

Create and define the Database input role by using the command below:

Bash
cat >/etc/nftables.d/role-input.nft <<'EOF'ip saddr @app_nodes tcp dport { 5432, 3306 } acceptEOF

For Database output role:

Bash
cat >/etc/nftables.d/role-output.nft <<'EOF'# DB nodes typically do not initiate app/data connections.# Keep only the minimal OS egress allowed by the base rules.# Add backup/monitoring destinations here if needed.EOF

Step 5. Activate nftables Ruleset

At this point, you can validate the configuration file for syntax errors with the following command:

Bash
nft -c -f /etc/nftables.conf

Then, activate the ruleset immediately with the following command:

Bash
nft -f /etc/nftables.conf

Next, enable he nftables service to start automatically at boot:

Bash
systemctl enable --now nftables

Finally, you can list the current active ruleset to verify your rules have been loaded correctly:

Bash
nft list ruleset

Step 6. Test and Debug nftables Roles

For the functional tests, you can prove the zero-trust model works:

  • Web nodes can talk to App nodes.
  • App nodes can talk to DB nodes.
  • All other direct communication (e.g., Web to DB) is blocked.
  • Public internet can only access web services on Web nodes.

From the Web server, you can run:

Bash
# Should work: web → app:8080nc -vz 10.10.1.20 8080 # Should FAIL: web → db:5432 (blocked)nc -vz 10.10.1.30 5432 || echo "EXPECTED BLOCK"

From the App server, you can run:

Bash
# Should work: app → db:5432nc -vz 10.10.1.30 5432 # Should FAIL: app → internet random ports (blocked by output policy)nc -vz 1.1.1.1 25 || echo "EXPECTED BLOCK"

From the internet (or another non-web host) to the Web server:

Bash
# Should work:curl -I http://<web-node-ip>curl -I https://<web-node-ip>  # if TLS configured # Should FAIL to app/db direct ports:nc -vz <app-node-ip> 8080 || echo "EXPECTED BLOCK"nc -vz <db-node-ip> 5432 || echo "EXPECTED BLOCK"

For real-time monitoring, you can use the following command, which shows a live trace of how packets are processed by the nftables ruleset, telling you exactly which role accepted or dropped a packet.

Bash
nft monitor trace

Also, you can look for the rate-limited drop logs. This shows you what is being blocked.

Check kernel logs with:

Bash
journalctl -k -f

Or check /var/log/kern.log (Debian/Ubuntu), depending on your rsyslog/journald setup.

You can also get a detailed view of the active rules with the following command.

The -a (or --handle) flag is essential. It shows a unique number for each rule. You need this handle to delete or update a specific rule later. Also, it displays counters, proving which rules are being used.

Bash
nft -a list table inet filter

Step 7. Zero-Downtime Set Updates in nftables Ruleset

At this point, you can dynamically modify the IP addresses in your sets. For example, adding a new server without reloading the entire firewall and disrupting existing connections.

Bash
# Add a new app servernft add element inet filter app_nodes { 10.10.1.25 } # Remove onenft delete element inet filter app_nodes { 10.10.1.25 }

Also, you can use the following command to allow for atomic and immediate changes to your defined sets:

Bash
nft replace set inet filter app_nodes { type ipv4_addr; elements = { 10.10.1.20-10.10.1.29, 10.10.1.50 } }

Tips for Microsegmentation Setup

At this point, you can consider the following tips for your Microsegmentation Linux Server Setup.

1. Kernel Network Hardening (sysctl): You can configure the Linux kernel itself to be more secure against certain types of network attacks (like IP spoofing and redirects). You can add the following configuration to the /etc/sysctl.d/99-microseg.conf file:

Bash
net.ipv4.conf.all.accept_redirects = 0net.ipv4.conf.default.accept_redirects = 0net.ipv6.conf.all.accept_redirects = 0net.ipv6.conf.default.accept_redirects = 0net.ipv4.conf.all.send_redirects = 0net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.all.rp_filter = 1net.ipv4.conf.default.rp_filter = 1 net.ipv4.tcp_syncookies = 1
  • accept_redirects = 0: Ignores malicious ICMP redirect messages.
  • rp_filter = 1: Reverse Path Filtering. Blocks packets that arrive on an interface that isn't the best route back to their source, preventing IP spoofing.
  • tcp_syncookies = 1: Protects against SYN flood denial-of-service attacks.

Then, you can apply the changes with:

Bash
sysctl --system

2. Allowing Infrastructure Services: You can demonstrate how to punch specific and minimal holes in the strict default-deny policy for essential backend services like backups, monitoring, and internal repositories. You can add acceptance rules to the role-output.nft file of the clients that need to initiate connections to these services. For example, for a backup server like Veeam/proxy, add:

Bash
ip daddr { 10.10.2.50 } tcp dport { 2500-3300 } accept

3. Stricter Web Server Roles: To reduce attacks, you can restrict inbound web traffic only to trusted sources like your Load Balancer or Cloudflare's IP ranges.

In /etc/nftables.d/role-input.nft on the web server, you can replace:

Bash
tcp dport { 80, 443 } accept

With:

Bash
ip saddr { 203.0.113.0/24, 198.51.100.0/24 } tcp dport { 80, 443 } accept

4. Clean rollback: If you need to revert, you can use your saved backup:

Bash
nft -f /root/nft.rules.backup.YYYY-MM-DD-HHMM.nft

Or you can completely disable the firewall (set policy to accept). It should only be used if you are completely locked out and need immediate access before fixing the rules.

Bash
nft flush ruleset

FirewallD Alternative for Microsegmentation in RHEL

If you want to use firewalld instead of using nftables in RHEL distributions, you can go forward with these steps.

First, disable nftables and enable firewalld:

Bash
systemctl disable --now nftablessystemctl enable --now firewalld

Then, you must create zones for each server and assign server subnets. To create zones, you can run the command below:

Bash
firewall-cmd --permanent --new-zone=webfirewall-cmd --permanent --new-zone=appfirewall-cmd --permanent --new-zone=db

Next, assign the sources with the commands below. Adjust the CIDR assignments to cover your exact ranges.

Bash
firewall-cmd --permanent --zone=web --add-source=10.10.1.10/31firewall-cmd --permanent --zone=web --add-source=10.10.1.12/30firewall-cmd --permanent --zone=web --add-source=10.10.1.16/30

Note: You must continue these commands until all servers are included appropriately.

Now, you must allow per-zone services and ports with the commands below:

Bash
# Web: allow HTTP/S from anywherefirewall-cmd --permanent --zone=web --add-service=httpfirewall-cmd --permanent --zone=web --add-service=https # App: only allow from web → app:8080 (rich rule with source)firewall-cmd --permanent --zone=app \  --add-rich-rule='rule family="ipv4" source address="10.10.1.10/28" port protocol="tcp" port="8080" accept' # DB: only allow from app → db portsfirewall-cmd --permanent --zone=db \  --add-rich-rule='rule family="ipv4" source address="10.10.1.20/28" port protocol="tcp" port="5432" accept' firewall-cmd --permanent --zone=db \  --add-rich-rule='rule family="ipv4" source address="10.10.1.20/28" port protocol="tcp" port="3306" accept'

Also, you must restrict SSH to the admin net only. Apply to all zones or create a dedicated “admin” zone and bind the mgmt NIC to it:

Bash
firewall-cmd --permanent \  --add-rich-rule='rule family="ipv4" source address="10.10.0.0/26" service name="ssh" accept' firewall-cmd --permanent --remove-service=ssh

Finally, make a default drop for everything else:

Bash
firewall-cmd --set-default-zone=dropfirewall-cmd --reloadfirewall-cmd --list-all-zones | less

With FirewallD, you can add sources and ports easily, but with nftables, you have more control.

Conclusion

Microsegmentation on Linux Server Setup is one of the most effective ways to increase network security. By using host-based firewall rules with tools like nftables, you can be sure each server only communicates with the exact services and ports it truly needs. The setup process may seem difficult, but by following the steps carefully, preparing configs, applying them per server role (Web, App, DB), and testing, you can easily set up your microsegmentation.

If you need reliable VPS hosting services or dedicated servers, you can check out Perlod Hosting.

We hope you enjoy Microsegmentation on Linux Server Setup. Subscribe to our X and Facebook channels to get the latest updates and articles.

For further reading:

Discover VPS Kodee AI Sysadmin

Explore Multi-Cloud Hosting Trends in 2025

Migrate from Shared to VPS Hosting Without Downtime

Best Tips for VPS Performance Optimization in 2025

You can use tools like nftables, which is modern and recommended. Also, you can use firewalld, SELinux / AppArmor, and eBPF-based tools like Cilium.

Yes. Best practice is to default deny and allow only what’s required.

Yes, you can combine it with VPNs to secure traffic between zones, use it with IDS/IPS like Suricata for intrusion detection, and use it with monitoring tools like Grafana to check your logs.

Prev PostHorizontal vs Vertical Scaling in Dedicated Servers
Next PostAI Dedicated Servers in 2025
Category:Security & Hardening
Tag:

We use cookies to run PerLod and to understand how the site is used. You can accept everything, or open Manage to turn individual categories off. Cookie policy.