LiveChat 
Support 
Firewall Rules for Applications: How to Safely Allow an App Through
When an application can’t connect, the fastest-looking fix is to turn the firewall off entirely. Resist that urge. The correct, secure approach is to write firewall rules for applications that open only the specific ports a program needs, while every other port stays closed. This guide shows you how to do exactly that on Linux servers using `ufw` and `firewalld`, plus the basics of router port forwarding.
Key Takeaways
• Never fully disable a firewall. Doing so exposes every service on the machine, not just the one app you’re troubleshooting.
• Open only the specific port or service the application requires (the principle of least privilege).
• Use `ufw allow` or `firewall-cmd –add-port` to permit a single port instead of opening everything.
• Restrict by source IP wherever possible so only trusted networks can reach the port.
• Always test the rule and confirm the rest of your ports remain closed.
Why should you never just disable the firewall?
A firewall is the gatekeeper between your server and the open internet. When you run something like `ufw disable` or stop `firewalld`, you don’t just unblock the one application you’re working on. You unblock everything: database ports, internal admin panels, cache servers, and any service listening on the box that was never meant to face the public internet.
That is the core problem with the “disable the firewall” instinct. It treats a precision problem with a sledgehammer. An application that needs one open port does not need all 65,535 ports exposed. Disabling the firewall to fix a single connection is like unlocking every door in a building because one visitor needs to reach one room.
The responsible alternative is the principle of least privilege: grant the minimum access required and nothing more. In firewall terms, that means opening exactly the port your app listens on, optionally limiting which IP addresses can reach it, and leaving the default-deny posture intact for everything else.
The single most useful firewall habit: “disable the firewall” is almost never the right fix. In nearly every real case where an app “needs the firewall off,” it actually needs one port opened. Find that port, allow it, and keep everything else closed. If you ever feel tempted to disable the firewall to make something work, treat that as a signal that you haven’t yet identified the specific port, not as a reason to drop your defenses.
How do you find which port an application uses?
Before you can write a rule, you need to know the port. A firewall rule is only as good as the precision behind it, so start here.
Check the application’s documentation first; most software states its default port clearly. If it doesn’t, inspect what’s actually listening on the server:
“`bash
sudo ss -tulpn
sudo netstat -tulpn “`
Look for the line matching your application’s process name. The address column shows the port (for example, `0.0.0.0:8080` means the app listens on TCP port 8080 on all interfaces). Note both the port number and whether it uses TCP or UDP — you’ll need both for the rule.
How do you allow a specific port with ufw?
`ufw` (Uncomplicated Firewall) is the default front-end on Ubuntu and Debian-based systems. Allowing a single port is a one-line command.
“`bash
sudo ufw allow 8080/tcp
sudo ufw allow 51820/udp
sudo ufw allow https
sudo ufw status verbose “`
Notice what you are not doing: you’re not running `ufw disable`. You’re adding one targeted rule. The default-deny policy stays in place for every other port.
Tightening the rule by source IP
If only a known network or office IP needs access, restrict the rule so the port isn’t open to the entire internet:
“`bash
sudo ufw allow from 203.0.113.10 to any port 8080 proto tcp
sudo ufw allow from 203.0.113.0/24 to any port 8080 proto tcp “`
This is the difference between leaving a window open to the street and opening it only for a guest you invited. Source-restricted rules dramatically reduce your exposure for any port that doesn’t genuinely need to be public.
How do you open a port with firewalld?
On RHEL, CentOS, Rocky Linux, AlmaLinux, and Fedora, `firewalld` is the standard. It organizes rules into zones and supports both port-based and service-based rules.
“`bash
sudo firewall-cmd –permanent –add-port=8080/tcp sudo firewall-cmd –reload
sudo firewall-cmd –permanent –add-service=https sudo firewall-cmd –reload
sudo firewall-cmd –permanent –add-rich-rule=’rule family=”ipv4″ source address=”203.0.113.10″ port port=”8080″ protocol=”tcp” accept’ sudo firewall-cmd –reload
sudo firewall-cmd –list-all “`
The `–permanent` flag writes the rule to disk so it survives a reboot; `–reload` activates it. Again, the goal is one precise addition, never a blanket shutdown of the firewall.
Should you allow by service name or by port number?
Both `ufw` and `firewalld` let you allow traffic by a named service (like `https`, `ssh`, or `dns`) or by a raw port number. Each has a place:
- By service name is cleaner and self-documenting when the app uses a well-known, standard port. `ufw allow https` is easier to read months later than `ufw allow 443/tcp`.
- By port number is necessary when an app uses a non-standard or custom port, or when you run software on a port that differs from its default.
Service-name rules rely on the system’s service definitions, so for anything custom, the explicit port number is the reliable choice. When in doubt, the port number is always unambiguous.
What about opening a port on a home or office router?
Server firewalls control the machine itself. A router, by contrast, controls whether outside traffic reaches a device on your local network at all. If your application runs behind a router (a self-hosted service at home, for instance), you may also need port forwarding.
Port forwarding tells the router: “When traffic arrives on port X, send it to this internal device.” The same least-privilege rule applies — forward only the one port the application needs, never place the device in a “DMZ” or open all ports to it, and prefer forwarding to a static internal IP.
Keep the device’s own firewall active too. Router forwarding and the host firewall are two independent layers; you want both.
Common application ports reference
Here are widely used services and the ports you’d typically open for them. Always confirm against your specific software’s documentation, since custom configurations vary.
| Application / Service | Typical Port(s) | Protocol | Notes |
|---|---|---|---|
| HTTP (web) | 80 | TCP | Plain web traffic |
| HTTPS (secure web) | 443 | TCP | Encrypted web traffic |
| SSH (remote admin) | 22 | TCP | Restrict by source IP where possible |
| DNS | 53 | TCP/UDP | Both protocols often needed |
| SMTP (email send) | 25, 587 | TCP | 587 for submission |
| IMAP / IMAPS | 143 / 993 | TCP | 993 is TLS |
| PostgreSQL | 5432 | TCP | Bind to localhost if not remote |
| MySQL / MariaDB | 3306 | TCP | Avoid public exposure |
| Redis | 6379 | TCP | Never expose publicly without auth |
| Custom app servers | 8080, 3000, etc. | TCP | Confirm in app docs |
The pattern is consistent: identify the port from this table or your app’s docs, then write one targeted allow rule.
DarazHost: full firewall control on secure infrastructure
Configuring firewall rules cleanly is much easier when you have full control of your environment and a secure foundation beneath it. DarazHost VPS and dedicated server plans give you complete root-level firewall control, so you can configure `ufw`, `firewalld`, or CSF exactly the way your applications require — opening only the ports you need and keeping the rest locked down.
On top of your own rules, DarazHost runs server-level firewall protection across its infrastructure, adding a network-edge layer of defense before traffic ever reaches your instance. Our security-focused hosting is backed by 24/7 expert support, so if you’re ever unsure which port an application needs or how to scope a rule tightly, our team can help you do it the right way — without ever resorting to disabling your firewall.
How do you test that a firewall rule works?
After adding a rule, verify two things: the intended port is reachable, and nothing else opened up by accident.
“`bash
nc -zv your.server.ip 8080
nmap -p 8080 your.server.ip
sudo ufw status numbered # ufw sudo firewall-cmd –list-all # firewalld “`
If the port responds and your rule list contains only the entries you deliberately added, you’ve done it correctly. If you ever need to remove a rule, delete that specific entry rather than disabling the whole firewall:
“`bash sudo ufw delete allow 8080/tcp sudo firewall-cmd –permanent –remove-port=8080/tcp && sudo firewall-cmd –reload “`
Frequently asked questions
Is it ever okay to fully disable a firewall? Almost never on a server reachable from the internet. The only reasonable cases are a brief, isolated diagnostic on a machine with no public exposure. Even then, open the specific port instead — disabling the firewall to “test” something usually hides the real misconfiguration rather than solving it.
How do I know if a port should use TCP or UDP? Check the application’s documentation. Most web and database services use TCP; some real-time, streaming, and VPN protocols use UDP, and a few (like DNS) use both. When the docs specify, match exactly; when unsure, the listening-ports check (`ss -tulpn`) shows which protocol the app actually binds to.
My app still can’t connect after I opened the port. What’s wrong? Work through the layers: confirm the app is actually listening (`ss -tulpn`), confirm the firewall rule matches the right port and protocol, and check whether a router or cloud provider’s security group is blocking traffic upstream. The host firewall is only one of several possible gates.
What’s the difference between allowing a service and allowing a port? A service rule maps to a predefined, well-known port (for example, `https` to 443). A port rule names the number directly. For standard services, the service name is cleaner; for custom or non-default ports, name the port explicitly so there’s no ambiguity.
Should database ports be open to the internet? Generally no. Ports for databases like MySQL, PostgreSQL, or Redis should be bound to localhost or restricted to specific trusted application servers by source IP. Exposing them publicly is a common and serious security mistake — exactly the kind of exposure that disabling a firewall would create wholesale.
