Security

Linux firewall basics: build rules around the services you actually run

A Linux firewall is most useful when it expresses a small, reviewable service policy: allow the ports the workload actually serves, keep administration deliberate, and reject exposure that exists only because software happened to start listening.

Inventory listeners before writing rules

Use ss or equivalent tools to list listening addresses and ports. Map each listener to a service owner and decide whether it should be loopback-only, private-network-only, publicly reachable, or not running at all.

Do not open a port because an installation guide mentions it if the current architecture does not need public access.

Build an allowlist from the application path

Typical public web service needs may include 80/443, while SSH, databases, dashboards, and management interfaces often deserve tighter source controls. IPv4 and IPv6 policy should match; allowing one family while forgetting the other creates an accidental bypass.

Keep established connection handling and required outbound behavior in mind before applying a default-deny policy remotely.

Separate host and provider firewalls

An upstream firewall and the guest firewall protect different boundaries. Document both so incident responders know which layer is rejecting traffic. A port reachable in one policy can still be blocked by the other.

Avoid duplicated complex rule sets unless the ownership of each layer is clear.

Test from outside after every change

Validate expected open and closed ports from an external network, confirm IPv6 too, and keep console recovery available. Save rules persistently so a reboot does not silently return the host to a different exposure state.

  • Inventory listeners.
  • Allow only required public services.
  • Apply equivalent IPv4/IPv6 intent.
  • Verify from an external source.
Related DotMoose serviceExplore DotMoose VPS hosting

Keep reading

Related guides.

More vps & linux →