The built-in firewall: close every door you are not using

Within minutes of getting a public IPv4, your server is being scanned - not personally, just industrially, by bots sweeping the entire internet for open ports. The answer is boring and absolute: expose only what you use. Every InstantNode vServer includes a firewall managed from the panel, sitting in front of the operating system at the virtualization layer. Rules apply within seconds and work no matter what is (or is not) configured inside the OS.

How rules work

A rule is direction (in/out), action (ACCEPT, DROP, REJECT), optional protocol, port(s) and source. Ranges (8000:8100), lists (80,443) and CIDR sources (203.0.113.0/24) are all supported, up to 50 rules per server. Because the firewall lives outside the guest, a fat-fingered rule cannot brick your access path the way a botched iptables session can - fix it from the panel and carry on.

A sane baseline for a web server

1. ACCEPT in, TCP 22 - ideally with source set to your own IP or VPN range
2. ACCEPT in, TCP 80,443 - the actual product
3. ACCEPT in, ICMP - keep ping working, debugging without it is misery

That is the whole list for most servers. Databases, admin panels, metrics endpoints - none of that belongs on the public interface. Bind those services to localhost and reach them through an SSH tunnel or WireGuard.

Classic mistakes

Leaving the database open because the app connects over the public IP - bind to localhost instead. Opening a port range "temporarily" - temporary rules are permanent within a week; date them in the comment field. Blocking ICMP for stealth - scanners do not care and you lose ping and path-MTU discovery. And remember the firewall filters ports, not requests: what you expose on 443 still needs patching, which is your job - the hardening guide covers the rest.