Linux is often deployed as a firewall, router, VPN gateway or NAT device. It can perform all of these roles extremely well, but combining them also means that a configuration mistake can affect an entire network.
One of the most common misconceptions is that NAT itself provides sufficient security.
It does not.
NAT translates addresses and ports. A firewall defines what traffic is allowed. DNS resolves names. Routing decides where packets go.
These functions work together, but they should not be confused with one another.
A Typical Linux Gateway
A small Linux gateway might look like this:
Internet
|
|
+-----------+
| Linux |
| Gateway |
| Firewall |
+-----------+
/ \
/ \
v v
LAN Server VLAN
The gateway may perform:
- IPv4/IPv6 routing
- NAT
- packet filtering
- VPN termination
- network segmentation
- traffic logging
That makes the Linux host a critical security component.
1. Enable Routing Only When Required
For IPv4 forwarding:
sudo sysctl -w net.ipv4.ip_forward=1
Check the current state:
sysctl net.ipv4.ip_forward
A router needs forwarding enabled, but a normal application server usually does not.
Unnecessary network functionality should not be enabled simply because Linux supports it.
2. NAT Is Not a Firewall
Consider this flow:
192.168.10.50:52344
|
v
NAT Gateway
|
v
203.0.113.10:41022
NAT translates the connection.
The firewall still needs to determine whether the traffic should be allowed.
A good mental model is:
NAT → translation
Routing → packet destination
Firewall → access control
DNS → name resolution
Each component solves a different problem.
Netbe has a broader guide covering UFW, nftables and iptables on Linux.
3. Control FORWARD Traffic
This is particularly important when Linux is acting as a router.
Traffic destined for the Linux machine and traffic passing through it are not the same thing.
Internet
|
v
Linux
|
v
Internal Server
The second connection is forwarded traffic.
A firewall policy should explicitly define which forwarded traffic is allowed.
For example:
LAN → Internet ALLOW
Internet → LAN DROP
LAN → Servers ALLOW
IoT → Servers LIMITED
IoT → LAN DROP
This prevents the gateway from becoming a simple packet-forwarding machine with little security control.
4. nftables for Modern Linux Systems
nftables is the modern Linux packet-filtering framework.
A simplified policy can be structured around:
INPUT
FORWARD
OUTPUT
For a router, FORWARD deserves particular attention.
A conceptual policy might be:
table inet filter
INPUT:
established connections → ACCEPT
management SSH → ACCEPT
everything else → DROP
FORWARD:
LAN → Internet → ACCEPT
established traffic → ACCEPT
everything else → DROP
OUTPUT:
required traffic → ACCEPT
A practical nftables configuration can be found in nftables Firewall on Linux.
5. Default Deny
A useful security principle is:
Default:
DROP
Exceptions:
ALLOW
Instead of trying to identify every malicious connection, the administrator defines what legitimate traffic is required.
For example, if a server only needs HTTPS:
TCP/443 → ALLOW
everything else → DROP
This is much easier to reason about than exposing multiple unnecessary services.
6. UFW for Simpler Configurations
For simpler Ubuntu deployments, UFW can provide a convenient firewall interface.
Example:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Verify:
sudo ufw status verbose
UFW is easier to operate than writing every nftables rule manually.
See How to Configure UFW Firewall on Ubuntu for a practical example.
7. DNS Is Part of the Security Model
Applications rarely connect to domain names directly.
The typical process is:
Application
|
| example.com
v
DNS Resolver
|
| IP address
v
Remote Server
If DNS resolution is manipulated, the application can be directed toward an unexpected IP address.
This is the basic idea behind DNS spoofing.
A detailed explanation is available in DNS Spoofing Attack: What It Is and How to Defend Against It.
8. Why DNS Spoofing Matters
DNS manipulation can potentially redirect users to:
- phishing websites,
- malicious downloads,
- fake login pages,
- attacker-controlled infrastructure.
Developers should therefore avoid assuming that DNS is always trustworthy.
Transport encryption such as HTTPS is another important layer because even if a user is redirected, certificate validation can prevent many straightforward impersonation attempts.
9. Network Segmentation
A flat network makes lateral movement easier.
Instead, divide systems into security zones:
Firewall
|
+------------+------------+
| | |
LAN Servers IoT
VLAN 10 VLAN 20 VLAN 30
Then define explicit policies.
For example:
LAN → Servers ALLOW
Servers → LAN LIMITED
IoT → Servers REQUIRED PORTS ONLY
IoT → LAN DROP
This architecture can significantly reduce the impact of a compromised device.
10. Protect SSH
A Linux gateway will often have SSH enabled.
Do not expose administration interfaces unnecessarily.
Prefer:
Internet
|
X
|
SSH
Management VLAN
|
v
SSH
|
v
Gateway
Useful hardening measures include:
- SSH keys instead of passwords,
- disabling root login,
- restricting administrative users,
- limiting SSH with firewall rules,
- monitoring authentication failures.
For practical configuration, see Linux SSH Hardening.
11. Do Not Forget IPv6
A firewall configuration may look secure while protecting only IPv4.
For example:
IPv4
Internet
|
NAT
|
Firewall
But IPv6 may provide a different path:
IPv6
Internet
|
|
Firewall
|
Internal Host
IPv6 therefore needs its own explicit security policy.
Using nftables with the inet family can simplify the management of IPv4 and IPv6 rules.
12. Check What Is Actually Listening
One of the simplest security checks on Linux is:
ss -lntup
This shows listening TCP/UDP sockets and can quickly reveal services that should not be exposed.
Also inspect the firewall:
sudo nft list ruleset
And routing:
ip route
A firewall is only as effective as the configuration behind it.
13. Monitor the Gateway
Security is not only about blocking traffic.
You also need visibility.
Look for:
Unexpected port scans
Repeated authentication failures
Unusual outbound connections
Unexpected DNS traffic
Large connection spikes
New port-forwarding rules
Monitoring can help detect both attacks and configuration mistakes.
14. Connection Tracking Is Security-Relevant
NAT gateways maintain state about active connections.
Conceptually:
Connection #1
Connection #2
Connection #3
Connection #4
...
The state table has finite resources.
Large numbers of connections can therefore become a resource-exhaustion problem.
This is one reason why network gateways should be monitored and protected against abnormal traffic patterns.
15. A Practical Defense-in-Depth Model
A good Linux network architecture can look like this:
Internet
|
v
Perimeter FW
|
v
NAT
|
v
VLAN / Segmentation
|
v
Host Firewall
|
v
Application
|
v
Monitoring
No single layer is expected to stop every attack.
Instead, each layer reduces a different class of risk.
16. Security Checklist
Before deploying a Linux gateway, verify:
[ ] IP forwarding is intentionally enabled
[ ] Firewall is enabled
[ ] FORWARD policy is restrictive
[ ] NAT rules are documented
[ ] Port forwarding is minimized
[ ] IPv4 is protected
[ ] IPv6 is protected
[ ] SSH is restricted
[ ] Network segmentation is configured
[ ] DNS configuration is trusted
[ ] Firewall logs are monitored
[ ] System updates are applied
[ ] Configuration backups exist
Conclusion
Linux is an extremely capable networking platform, but its flexibility also means that administrators need to understand the interaction between routing, NAT, firewalling and DNS.
The most important distinction is simple:
NAT ≠ Firewall
Routing ≠ Security
DNS ≠ Trust
A secure Linux gateway combines these technologies with explicit access-control policies, network segmentation, host hardening and monitoring.
The goal is not to make the network impossible to attack.
The goal is to make unauthorized traffic difficult to reach, difficult to move through the environment and easier to detect.
For more practical Linux and cybersecurity guides, visit Netbe.
Top comments (0)