Hardening Reference
How a firewall decides what your server answers
You opened a port for one job months ago, and nothing on the box will remind you it is still open.
The short answer
A firewall is the packet-level rule set that decides which ports on a machine answer at all — anything you have not explicitly permitted is dropped before a single process sees the connection.
Two commands settle the question on any Linux host. ufw status numbered prints what you have allowed; ss -tlnp prints what is genuinely listening. Where those two disagree — a daemon bound to 0.0.0.0 on a port the filter also permits, and you cannot say why — that is your exposure, and it is usually older than you think.
By the HostingFast team · Reviewed 12 August 2026
100+
Definitions on file
2 min
Typical time on one
Plain
English, no marketing
24/7
Engineers on the desk
The useful shape is short: deny inbound by default, allow 22, 80 and 443, stop. On a well-run box the allow list fits on one screen. If yours does not, the extra lines are nearly always leftovers from a debugging session nobody reversed, and each one is a service you have quietly signed up to patch for as long as the machine lives.
It works at layers three and four, so it reasons about addresses and ports and nothing above them. It cannot tell a legitimate checkout POST from an injection attempt on port 443, because both are simply bytes arriving on an open port. That distinction is the WAF's job, and confusing the two is how people convince themselves a tight rule set protects an unpatched plugin.
What filtering actually costs you
Very little, at the scale a web server runs at. nftables rules are evaluated in kernel space and the dozen a web host needs cost less than a single DNS lookup. Worrying that a firewall slows a site down is misplaced; worrying about the connection-tracking table under load is not.
The number worth knowing is conntrack. Compare nf_conntrack_count with nf_conntrack_max on a busy machine. As the first approaches the second, new connections start being dropped and the site looks down while top shows an idle box. Raising the ceiling is one sysctl line, but only once you have confirmed that is the failure you have.
Reading your own rule set honestly
Start with ss -tlnp rather than with the firewall. It names the process behind every listening socket and the interface it is bound to, and it regularly surprises people: MySQL on 0.0.0.0 instead of 127.0.0.1, a stale Node process on 3000, a memcached left over from an experiment. Bind services to loopback first and let the filter be your second line rather than your only one.
Then read ufw status numbered and account for every line out loud. Rules carry indexes so you can delete by number. A rule you cannot explain should be removed and the consequence observed, not left in place because taking it out feels risky.
Where the managed line falls
On shared, business and WordPress plans the packet filter is ours to run, and that is most of what managed means in practice. You will not find nftables anywhere in cPanel and you do not need it: the ports that answer are the web and mail ports, and the account isolation underneath does more for you than any rule you would have added.
Take a VPS and the machine is yours, root included, at which point ufw, fail2ban and the habit of reading auth.log stop being optional. Neighbouring entries worth two minutes each: WAF, DDoS Attack, Brute-Force Attack and SSH.
Proving the change from outside
Verify from another host. A port scan run from somewhere else, or a public port checker, tells you what the internet can actually reach. Testing from the server itself tells you nothing, because loopback traffic never meets the rules you are trying to check. Capture the before and after and keep both.
Free SSL ships with every plan here and renews itself ahead of expiry, so the one port you definitely want answering stays useful without a diary entry.
Written by the people who read the logs
This reference exists because the support desk answers the same question at two in the morning more often than it should. Every entry carries the mechanism, a command you can run, and the number that tells you whether it worked.
NVMe storage under LiteSpeed caching is the floor on every tier here, entry plan included, so the platform is never the variable you are debugging.
- 100+ entries, mechanism first
- Commands and numbers, not analogies
- Neighbouring terms wired together
- Written by the engineers on support
Why HostingFast
Standard on every plan
Firewall, at packet level
What default-deny really drops, why ss and ufw have to agree, and the conntrack ceiling nobody checks.
Commands, not diagrams
Every claim here comes with the command that confirms or kills it on your own box.
The layer boundary, stated
Ports and addresses stop here; HTTP payloads start at the WAF. Knowing the seam saves whole afternoons.
Verified from outside
Checks run from another host, because a scan of the server by the server proves nothing at all.
Wired to its neighbours
WAF, Brute-Force Attack and SSH finish this picture, each a two-minute read.
Honest about the managed line
Says plainly which parts are yours on a VPS and which are ours on shared hosting.
Quick Start
From order to online
- 1
List what is listening
Run ss -tlnp before touching a rule. Anything bound to 0.0.0.0 that you cannot name is the finding, and rebinding it to 127.0.0.1 fixes more than a rule ever will.
- 2
Justify every allow line
ufw status numbered prints the list with indexes. Delete what you cannot account for, one line at a time, and watch what breaks instead of guessing.
- 3
Scan from somewhere else
Confirm the result from another host. Loopback ignores the filter completely, so a test run on the machine says nothing about what the internet sees.
Built In
Loaded onto every plan
- Free SSL on every plan, renewed automatically before it can expire
- Spam and virus screening on every mailbox as standard
- Staging environments for testing changes before they ship
- SSH, Git and Composer on the developer-focused plans
- WordPress Toolkit, with updates handled for you
- LiteSpeed caching built into the server rather than patched in by plugin
- 99.9% uptime as the target, monitored around the clock
- WordPress and 400+ other applications installed in one click
- Email addresses that run on your own domain name
- Year one of your domain free when you order annually
Frequently Asked
What people ask us most often
Does a firewall add latency you can measure?
Not at web-server scale. Rules run in the kernel and a dozen of them cost less than one DNS lookup. The failure people mistake for firewall latency is connection tracking: once nf_conntrack_count reaches nf_conntrack_max, new connections are dropped and the site appears down while the load average sits near nothing. Read those two values before blaming the rule set.
Which ports should a web server answer on, and no others?
80 and 443 for the web, 22 for SSH. Mail ports only if that machine actually handles mail. MySQL should not appear at all: bind it to 127.0.0.1 and let the application reach it over loopback. Moving SSH off port 22 trims log noise but changes nothing structural — key-only authentication is the control that matters. Every extra open port is one more service you have committed to patching.
Do I get root and my own rule set on these plans?
On shared, business and WordPress plans the filter is ours; what you get is SSH inside your own account with Git and Composer available. On a VPS the machine is yours, root included, and ufw, fail2ban and log discipline become your responsibility. Moving between the two is an in-place plan change from the client area, with no migration and no downtime.
What gets a blocked connection diagnosed fastest?
Send the evidence, not the symptom. The failing command, the source address, the timestamp and what you expected to happen turn a diagnosis into a lookup. The desk is staffed around the clock and aims to reply inside two hours, or one when a site is down.
Keep reading
DDoS Attack
Volumetric floods, why blocking sources cannot work, and where mitigation has to sit.
VPS (Virtual Private Server)
Root on a KVM slice with reserved CPU and memory — the point where the rule set becomes yours.
How to Set Up a Firewall with UFW
The default-deny build, rule by rule, with the lockout mistake flagged before you make it.
Mail Filtering
Spam and virus screening in front of any mailbox, wherever that mailbox is hosted.
Secure Hosting
Imunify360, isolated accounts and hardened defaults, without a tuning project attached.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Ship it on a box already tuned.
NVMe under LiteSpeed, free SSL, free migration, and a renewal price identical to the one you signed up at.
View Mail Filtering plans