IPtables Firewall Guide: How to Secure Your Linux VPS

IPtables is the default firewall tool built into the Linux kernel. It filters network traffic by matching packets against a set of user-defined rules, deciding whether to accept, drop, or reject each connection. Every Linux VPS comes with iptables available out of the box, making it the most widely used firewall solution for securing servers. If you run a Linux server of any kind, understanding iptables is essential for protecting your system from unauthorized access, brute force attacks, and malicious traffic.

This guide covers everything you need to know about iptables on a Linux VPS. You will learn how iptables works, how to write rules, how to build a complete firewall configuration from scratch, and how to make your rules persistent across reboots. Every command in this guide works on Ubuntu, Debian, AlmaLinux, Rocky Linux, and CentOS.

How IPtables Works

IPtables organizes firewall rules into tables and chains. A table defines the type of processing, and a chain defines when that processing happens. When a network packet arrives at your server, iptables checks it against the rules in the appropriate chain. The first matching rule determines what happens to the packet. If no rule matches, the chain's default policy applies.

The three tables you will use most often are the filter table, the nat table, and the mangle table. The filter table handles standard firewall rules that accept or drop traffic. The nat table handles network address translation for routing and port forwarding. The mangle table handles advanced packet modification. For basic VPS security, you will work almost exclusively with the filter table.

The Three Default Chains

INPUT chain. Controls incoming traffic destined for the server itself. When someone connects to your SSH port, web server, or any other service running on your VPS, the packet passes through the INPUT chain. This is the most important chain for VPS security because it determines who can access your services.

OUTPUT chain. Controls outgoing traffic originating from the server. When your server makes an API call, downloads an update, or sends an email, the packet passes through the OUTPUT chain. Most configurations leave the OUTPUT chain open because restricting outbound traffic from your own server is rarely necessary.

FORWARD chain. Controls traffic that passes through the server to another destination. This chain is relevant when your server acts as a router or gateway. For a standard VPS running web services or applications, the FORWARD chain is not used.

IPtables Rule Syntax

Every iptables rule follows the same basic structure. You specify the chain, the matching criteria, and the action to take when a packet matches. The matching criteria can include the source IP address, destination port, protocol, network interface, and connection state.

The basic syntax for adding a rule is:

iptables -A [CHAIN] -p [PROTOCOL] --dport [PORT] -j [ACTION]

The -A flag appends the rule to the end of the specified chain. The -p flag specifies the protocol such as tcp or udp. The --dport flag specifies the destination port. The -j flag specifies the jump target, which is the action to take. The most common actions are ACCEPT, DROP, and REJECT.

ACCEPT vs DROP vs REJECT

ACCEPT allows the packet through. The connection proceeds normally and the client receives a response from your server.

DROP silently discards the packet. The client receives no response at all. The connection attempt simply times out. This is the preferred action for blocking malicious traffic because it gives the attacker no information about whether the port exists or the server is online.

REJECT discards the packet but sends an error response back to the client. The client immediately knows the connection was refused. This is more polite for legitimate traffic but gives attackers information about your firewall configuration.

Essential IPtables Commands

Before writing firewall rules, you need to know the basic commands for managing iptables. These commands let you view, add, delete, and flush rules.

View Current Rules

To see all active firewall rules with line numbers:

iptables -L -n -v --line-numbers

The -L flag lists rules. The -n flag shows IP addresses and port numbers instead of resolving hostnames. The -v flag shows packet and byte counters. The --line-numbers flag adds line numbers so you can reference specific rules for deletion.

Flush All Rules

To remove all existing rules and start fresh:

iptables -F

This clears all rules from all chains but does not change the default policies. If your default policy is DROP and you flush all rules, you will lock yourself out of the server. Always set the default INPUT policy to ACCEPT before flushing rules if you are connected via SSH.

Delete a Specific Rule

To delete a rule by its line number:

iptables -D INPUT 3

This deletes rule number 3 from the INPUT chain. Use iptables -L --line-numbers first to identify the correct rule number.

Insert a Rule at a Specific Position

To insert a rule at a specific position in the chain instead of appending it to the end:

iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

This inserts the rule at position 1 in the INPUT chain, making it the first rule evaluated. Rule order matters in iptables because the first matching rule wins.

Building a Complete VPS Firewall

A properly configured iptables firewall follows a simple principle: allow only the traffic you need and drop everything else. This is called a default-deny policy. The following configuration builds a complete firewall suitable for most Linux VPS deployments.

Step 1: Allow Loopback Traffic

The loopback interface is used for internal communication between services on the same server. Many applications depend on it. Always allow loopback traffic first.

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

Step 2: Allow Established and Related Connections

This rule allows traffic that belongs to connections your server has already established. Without it, your server could send requests but never receive the responses.

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

This single rule is the most important rule in any iptables configuration. It allows return traffic for outbound connections, responses to DNS queries, package manager updates, API calls, and every other connection your server initiates.

Step 3: Allow SSH

Allow SSH access so you can manage your server remotely. The default SSH port is 22. If you have changed your SSH port, replace 22 with your custom port number.

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

For better security, restrict SSH access to your specific IP address:

iptables -A INPUT -p tcp -s YOUR_IP_ADDRESS --dport 22 -j ACCEPT

Replace YOUR_IP_ADDRESS with your actual public IP. This means only connections from your IP can reach the SSH port. Everyone else gets dropped.

Step 4: Allow Web Traffic

If your server runs a website or web application, allow HTTP and HTTPS traffic:

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Step 5: Allow DNS

Your server needs to resolve domain names. Allow outbound DNS queries and their responses:

iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -j ACCEPT

If you already added the ESTABLISHED,RELATED rule in Step 2, DNS responses are already covered. These explicit DNS rules are an extra safety measure that some administrators prefer to include.

Step 6: Allow Ping (Optional)

ICMP ping is useful for monitoring and troubleshooting. Allow it if you want your server to respond to ping requests:

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

Some administrators drop ping to reduce the server's visibility to network scanners. This is a matter of preference. Dropping ping does not meaningfully improve security but it can interfere with monitoring tools.

Step 7: Set Default Policy to DROP

After allowing all the traffic you need, set the default policy for the INPUT chain to DROP. This means any traffic that does not match an explicit ACCEPT rule gets silently discarded.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

The OUTPUT chain default is set to ACCEPT because restricting outbound traffic from your own server is unnecessary in most configurations. The FORWARD chain is set to DROP because a standard VPS does not route traffic between networks.

The Complete Firewall Script

Here is the entire firewall configuration as a single script you can run on any Linux VPS:

#!/bin/bash

# Flush existing rules
iptables -F
iptables -X

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow established connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (change port if needed)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow HTTP and HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow ping
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Set default policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

echo "Firewall rules applied successfully"

Save this script as firewall.sh, make it executable with chmod +x firewall.sh, and run it with sudo ./firewall.sh. Verify the rules are active with iptables -L -n -v.

Making IPtables Rules Persistent

IPtables rules are stored in memory and are lost when the server reboots. To make your rules survive a reboot, you need to save them and configure your system to restore them automatically on startup.

On Ubuntu and Debian

Install the iptables-persistent package:

sudo apt install iptables-persistent

During installation, it will ask if you want to save current rules. Select yes. To save rules manually after making changes:

sudo netfilter-persistent save

The rules are saved to /etc/iptables/rules.v4 for IPv4 and /etc/iptables/rules.v6 for IPv6. They are automatically restored on every boot.

On AlmaLinux, Rocky Linux, and CentOS

Install the iptables-services package:

sudo yum install iptables-services
sudo systemctl enable iptables
sudo systemctl start iptables

Save your current rules:

sudo service iptables save

The rules are saved to /etc/sysconfig/iptables and automatically restored on boot.

Advanced IPtables Rules

Beyond basic port filtering, iptables supports advanced rules for rate limiting, logging, port forwarding, and IP-based blocking. These rules help you handle specific security scenarios.

Rate Limiting SSH Connections

Brute force attacks against SSH are extremely common. Rate limiting restricts the number of new SSH connections from a single IP address within a time window:

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

This allows a maximum of 3 new SSH connections per minute from any single IP address. The fourth connection attempt within 60 seconds gets dropped. Legitimate users connecting normally are unaffected. Automated brute force tools that try hundreds of passwords per minute get blocked.

Blocking a Specific IP Address

To block all traffic from a specific IP address:

iptables -I INPUT 1 -s 192.168.1.100 -j DROP

The -I INPUT 1 inserts this rule at the top of the INPUT chain so it is evaluated before any ACCEPT rules. Replace 192.168.1.100 with the IP address you want to block.

To block an entire subnet:

iptables -I INPUT 1 -s 192.168.1.0/24 -j DROP

Logging Dropped Packets

To log packets that get dropped by your firewall before they are discarded:

iptables -A INPUT -j LOG --log-prefix "IPtables-Dropped: " --log-level 4
iptables -A INPUT -j DROP

Logged packets appear in /var/log/syslog or /var/log/messages depending on your distribution. The log prefix makes it easy to filter firewall logs from other system messages. Be careful with logging on high-traffic servers because logging every dropped packet can fill your disk quickly.

Port Forwarding

To forward traffic from one port to another, use the nat table:

iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80

This redirects all traffic arriving on port 8080 to port 80. This is useful when you want to run a web server on port 80 but also accept connections on an alternative port.

Allowing Specific Port Ranges

To allow a range of ports instead of specifying each one individually:

iptables -A INPUT -p tcp --dport 3000:3100 -j ACCEPT

This allows TCP traffic on ports 3000 through 3100. This is useful for applications that use dynamic port ranges.

IPtables vs UFW vs Firewalld

IPtables is the underlying firewall framework on Linux, but there are higher-level tools that make firewall management easier. UFW and firewalld are the two most common alternatives.

UFW is a simplified frontend for iptables that is popular on Ubuntu and Debian. Instead of writing iptables rules directly, you use commands like sudo ufw allow 22 and sudo ufw enable. UFW translates these commands into iptables rules behind the scenes. UFW is easier to learn but less flexible than writing iptables rules directly.

Firewalld is the default firewall management tool on AlmaLinux, Rocky Linux, and CentOS. It uses zones and services to organize rules and supports runtime changes without restarting the firewall. Firewalld uses nftables or iptables as its backend depending on the distribution version.

IPtables directly gives you the most control and works on every Linux distribution. The syntax is more verbose than UFW or firewalld, but you can do things that the simplified tools cannot. If you manage multiple servers across different distributions, knowing iptables means you have one skill that works everywhere.

For most VPS users, any of these tools provides adequate security. The best firewall is the one you actually configure and maintain. An unconfigured iptables installation provides no more security than no firewall at all.

Common Mistakes to Avoid

Misconfiguring iptables can lock you out of your own server or leave it exposed to attacks. These are the most common mistakes and how to avoid them.

Locking yourself out via SSH. If you set the default INPUT policy to DROP before adding an SSH ACCEPT rule, you will immediately lose access to your server. Always add your SSH rule first, verify it works, and then set the default policy to DROP. If you do lock yourself out, use your hosting provider's console access or IPMI to regain access.

Forgetting to save rules. IPtables rules exist only in memory until you save them. If you spend an hour configuring your firewall and then reboot without saving, all your rules are gone. Always save your rules after making changes.

Rule order mistakes. IPtables evaluates rules from top to bottom and stops at the first match. If you add a DROP rule for port 22 before your ACCEPT rule for port 22, SSH will be blocked regardless of the ACCEPT rule. Always check rule order with iptables -L --line-numbers.

Ignoring IPv6. IPtables only handles IPv4 traffic. If your server has an IPv6 address, you need to configure ip6tables separately with equivalent rules. Attackers can bypass your IPv4 firewall entirely by connecting over IPv6 if ip6tables is not configured.

Overly permissive rules. A rule like iptables -A INPUT -j ACCEPT with no matching criteria accepts all traffic and makes your firewall useless. Every ACCEPT rule should specify at minimum a protocol and port number.

IPtables on a BlastVPS Server

Every BlastVPS Linux VPS comes with full root access and iptables pre-installed. You have complete control over your firewall configuration from the moment your server is deployed. Combined with BlastVPS DDoS protection at the network level, iptables gives you two layers of defense: the network-level DDoS mitigation handles volumetric attacks before they reach your server, and your iptables rules handle application-level filtering on the server itself.

For dedicated server deployments, BlastVPS dedicated servers include IPMI access so you can always recover from a firewall misconfiguration through the remote console, even if SSH is blocked by an incorrect iptables rule.

If you are running a Windows server instead of Linux, firewall configuration is handled through Windows Defender Firewall rather than iptables. BlastVPS Windows RDP plans come with Windows Firewall pre-configured with sensible defaults.

Frequently Asked Questions

What is iptables in Linux?

IPtables is the built-in firewall tool in the Linux kernel that filters network traffic based on user-defined rules. It controls which incoming and outgoing connections are allowed or blocked by matching packets against rules organized in chains. IPtables is available on every Linux distribution and is the most widely used firewall solution for Linux servers.

How do I check my iptables rules?

Run the command iptables -L -n -v --line-numbers to see all active firewall rules. The -L flag lists rules, -n shows numeric addresses instead of hostnames, -v shows packet counters, and --line-numbers adds line numbers for easy reference when deleting or inserting rules.

How do I allow a port through iptables?

Use the command iptables -A INPUT -p tcp --dport PORT_NUMBER -j ACCEPT to allow incoming TCP traffic on a specific port. Replace PORT_NUMBER with the port you want to open. For UDP traffic, replace tcp with udp. Remember to save your rules after making changes so they persist across reboots.

How do I block an IP address with iptables?

Use the command iptables -I INPUT 1 -s IP_ADDRESS -j DROP to block all traffic from a specific IP address. The -I INPUT 1 inserts the rule at the top of the INPUT chain so it is evaluated before any ACCEPT rules. To block an entire subnet, use CIDR notation like 192.168.1.0/24.

Do iptables rules survive a reboot?

No, iptables rules are stored in memory and are lost when the server reboots. To make rules persistent, install iptables-persistent on Ubuntu and Debian or iptables-services on AlmaLinux, Rocky Linux, and CentOS. These packages save your rules to disk and automatically restore them on boot.

What is the difference between DROP and REJECT in iptables?

DROP silently discards the packet with no response to the sender. The connection attempt simply times out. REJECT discards the packet but sends an error message back to the sender, letting them know the connection was refused. DROP is preferred for security because it gives attackers no information about your server. REJECT is more appropriate for internal networks where you want users to get immediate feedback.

Should I use iptables or UFW?

UFW is a simplified frontend for iptables that is easier to learn and use. IPtables gives you more control and works on every Linux distribution. For basic VPS security, UFW is sufficient. For advanced configurations like rate limiting, port forwarding, custom logging, or complex rule sets, iptables is the better choice. Both provide the same level of security when configured correctly.