How to Configure a Linux Server Firewall Safely

A good firewall is not a list of multiple ports; it is a policy that specifies authorized flows between the user, proxy, application, database, monitoring, and management. The main risk in production is the application of the rule without knowing the actual path and disconnecting SSH, payback, DNS, or backup.

Quick answer:First inventory listener and input/output streams, have an emergency console and second session, and explicitly allow management access. Then step up default deni input, only open the necessary services and synchronize IPv4/IPv6 and cloud firewall. Test the result from the actual external network.

Start with the Flow Matrix.

Extract the port numbers from the actual config and listener; the table above is just the decision form. Each rule should have the owner, reason, revision date, and route removed.

Inventory reading

ip -br addr
ss -lntup
ip route
sudo nft list ruleset
sudo ufw status verbose

NFtables or UFW may not be installed/activated; the missing command is incorrect and you should not install the second tool just for viewing. The cloud security group and the provider rules are hosted outside and must be logged separately. Do not disclose the internal IP output and service name.

Before the application: Console and Rollback

Keep the existing session SSH open and try the new session on the second session. Timed rollback can be useful, but it shouldn't be the only protection that goes away when the session is interrupted.

Default Policy

For input, deny by default with explicit permissions reduces the attack level. Outputs are more complex: update, DNS, NTP, email, payment API, backup, and monitoring may be required. deny by default with no inventory can create blurred errors.

First authorise the SSH.

Before activating deny, allow the real SSH path to port, interface, IPv4/IPv6 and subnet management. If the IP is dynamic, design a VPN or bastion. Opening SSH to the entire Internet is not just a way to prevent lockout.Secure the SSHIt explains authentication and recovery pathways.

Public web and private backend

Usually 80/443 is on a public reverse proxy. PHP-FPM, app ports, databases, and Redis should only be accessible from the host or network required. Service binding to the private interface is a complementary layer; the firewall does not replace the config listener, and vice versa.

IPv4 and IPv6

IPv4 rule does not necessarily cover IPv6. If you have AAAA or listener v6, the policy should include both stacks. Immediate IPv6 disabling may spoil dependency; measure exposure and manage it consciously. External testing of both paths is required.

Cloud and Host Firewalls

The two layers can create deep defense, but their differences make troubleshooting difficult. The source of truth and order of change are clear. The cloud firewall may reject it before the packet reaches the host; the log host in this case will not show anything.

NAT and Port Forwarding

In a NAT network, the external and internal ports may be different. The rule on the chain or the faulty interface is invalid. The IP source after the NAT may also change.

Docker and the Automatic Rules.

The runtime container can add chain and NAT rules and make the published port available without waiting for the frontend of the firewall. The UFW output alone may not display the full Docker exposure. Check the published port, network and actual packet rule; do not manually change the directory or rule runtime.

Reverse proxy and real IP.

If the CDN or load balancer is the connection principle, the allowlist must see the valid and updated range.X-Forwarded-ForThe network layer is not reliable in the firewall and the application only accepts trusted proxies.

Don't blind the ICMP.

ICMP is not just ping; error messages and path MTU are important for network performance, especially in IPv6. The policy must manage the necessary types to fit the network. Closing all ICMPs can cause odd and difficult to find timeouts, without hiding the open service.

Rate Limit and Connection Limit

Restrictions can control a malicious burst, but the general threshold is not suitable for SSH, API, and Checkout. Consider users behind NAT and legal crawlers. The rate limit in proxies sometimes has more context than a firewall.

Outbound Filtering

Limiting output can reduce the compromise effect, but maintaining it is expensive. The API domain may have variable IP and the DNS itself needs an output. Do not start with sudden deny; first classify observe and essential flows. Secret exfiltration is not solved by port filtering alone.

Logging without filling the disk.

log All the packet streams on the Internet can consume disk and CPU. Define the rate limit for logging, retention and aggregation. Do not record payload or sensitive data. log must specify the rule and direction to enable troubleshooting.

Stage action

1. Record the current flow matrix, listener, and rule.
2. Console, backup and second session ready.
3. allow to create critical management and services.
4. Validate the config/ruleset with the same system tool.
5. Step by step activate deny input.
6. Test both allow and deny from the outside.
7. Check the Docker reboot persistence and engagement.
8. Complete the logs, alerts and documents.

Where will the test be conducted?

Testing localhost does not pass an external firewall path. Have a proper sample of the Internet, management network, application subnet, and proxy path. It is not enough to open a port; check the handshake and controlled application request. Confirm timeout/refusal for the banned port as well.

Change of Emergency

In fact, the complete shutdown of the firewall increases the exposure range and blurs the cause. The temporary rule is limited to the principle/service with expiration. Any emergency change must be recorded, reviewed, and removed or permanently post-incident.

Stability after reboot

The active rule in memory may not load after rebooting, or vice versa, the old rule will return. The persistence method must be the original tool and not contradict automation.

Common Mistakes

• Enable default deny before allowing SSH
• Ignoring IPv6
• Opening a database or Redis.
• Full confidence in the outcome of a frontend in the presence of Docker.
• Closing all ICMPs
• deny an output without identifying the DNS and API.
• Logging without rate limit
• Editing the cloud and host firewall simultaneously

Periodic review

Rules without hit or owner, previous contractor access, and deleted service ports must be deleted. Any change in the flow matrix architecture will update. Monitor drift between the version configuration and the active ruleset.Basic security for LinuxIt puts the firewall next to the patch, account, and backup.

When do you need special assistance?

If cloud firewall, Docker, CDN, and VPN are running at the same time, a wrong rule can interrupt the origin or management.Install and configure the Linux serverIt can implement flow matrix, ruleset, external testing and rollback to fit the actual architecture.

Common Questions

Is UFW better or nftables?

It depends on the complexity of the ruleset and the team standard. A simple frontend is suitable for simple needs; importantly, it is a source of truth and a true path test.

Is it enough to just open 80 and 443?

For the public web, it may be the main input, but management, monitoring, backup, DNS and dependencies must also be designed.

Why is the Docker port open despite the firewall?

Runtime may have added a standalone NAT/chain. Check the published port and the actual packet path.

Does the firewall prevent the hacking of the site?

It limits network level, but the vulnerability of the application on the authorized port, the stolen credential, and the faulty patch does not resolve.