On shared hosting the firewall is somebody else's job. On a dedicated server it is yours, and it is the difference between a machine exposed to everything and one exposed to what you chose.
It is also the fastest way to lock yourself out of a server you are holding the only key to.
Default deny, then open what you need
The principle that makes everything else simple: block all incoming traffic, then allow specific ports.
The alternative: allowing everything and blocking what worries you, requires you to think of every risk in advance, and you will not.
A typical web server needs very few ports open: HTTP, HTTPS, SSH, and mail ports if it handles mail. Everything else stays closed, including things you installed and forgot.
Which tool
CSF is the usual choice on a cPanel server. It configures the underlying firewall, integrates with the control panel, includes login-failure blocking, and (importantly) has a testing mode that undoes changes automatically.
firewalld or ufw on a plain server, both of which are friendlier than writing rules directly.
iptables or nftables directly when you need something the others cannot express.
Pick one and use only that one. Two firewall tools managing the same rules produce a configuration where neither shows the truth, and diagnosing that at a distance is miserable.
Testing mode is not optional
The single most important habit here.
CSF has a setting that reverts the firewall after a set number of minutes unless you confirm the change. Enable it before your first rule and leave it on until the configuration is settled.
Then a mistake costs five minutes of waiting instead of a support ticket to have someone attach a console.
Other tools have equivalents, or you can improvise one: schedule a task that flushes the rules in ten minutes, and cancel it once you have confirmed you are still connected.
Have a second way in
Before touching the firewall, know how you would reach the machine if SSH stops answering.
On a dedicated server that is IPMI, and it works because it sits beneath the operating system entirely. A firewall rule cannot block it, using IPMI walks through confirming it works before you need it.
Test that route first. A firewall change with no verified fallback is a bet.
Whitelist yourself, carefully
Allow your own address before adding restrictive rules.
Two cautions. A dynamic address changes, and a whitelist entry for an address you no longer hold is worthless, and it may now belong to someone else. And whitelisting an entire range because your address moves within it opens the server to everyone else in that range.
Prefer a fixed address if you have one, and rely on IPMI rather than on a whitelist as your safety net.
Moving SSH off port 22
Worth doing, and worth being clear about what it achieves.
It stops the constant automated scanning of port 22, which cleans up your logs considerably. It does not stop a targeted attacker, who will scan your ports and find it.
So it is noise reduction rather than security. The security comes from key-based authentication with passwords disabled, which removes guessing as a route entirely.
If you change the port, open the new one before restarting SSH, and keep the existing session open while you test the new one from a second terminal. Closing your only session before confirming is how this goes wrong.
Outbound rules are worth having
Most people filter inbound and leave outbound open. Restricting outbound catches something inbound rules cannot.
A compromised application typically connects out: to fetch a payload, to join a command channel, to send spam. Blocking outbound traffic except what you need limits what a compromise can do after it happens.
Start by blocking outbound SMTP from everything except your mail service. That alone stops a compromised script from turning your server into a spam source, which is the fastest way onto a blocklist. For that, see server hardening.
Do not forget IPv6
The mistake that produces a firewall that appears correct and is not.
IPv4 and IPv6 have separate rule sets in most tools. A configuration that blocks a port over IPv4 while leaving it open over IPv6 protects nothing, because the service answers on both.
Check both. If you are not using IPv6, disabling it is cleaner than maintaining two rule sets, but disable it properly instead of assuming it is unused.
Log, then read the logs
Log dropped packets so you can tell a genuine block from a service that stopped working for another reason.
Then look at them occasionally. A rule blocking something legitimate produces a pattern in the log long before anyone reports the problem, and connecting those two is much easier before the report than after.
Do not log everything on a busy server. The volume fills the disk, and a full disk stops the machine. Troubleshooting common issues explains that failure.
Verify from outside
Checking the firewall's own status tells you what it intends. Scanning from another machine tells you what is true.
Those differ more often than people expect; a service bound to all interfaces, a rule that never loaded at boot, a container publishing a port ahead of your rules. For that last one specifically, see running Docker.
Scan from outside after any significant change, and once more a week later. A rule set that is not loaded at boot works perfectly until the next reboot.
Whatever the rules are, applying them over the connection they may block needs one precaution. How to Configure a Firewall Without Locking Yourself Out goes into it.