A firewall applied per server is one of the simplest ways to reduce the attack surface of a business environment. It limits which systems can connect, from where, and for what purpose. That matters even when a server is behind a cloud security group, a virtual network or a physical perimeter firewall.
The most reliable starting point is a default-deny policy: block unsolicited inbound traffic, permit only documented services, and control outbound traffic where the risk justifies it. The rules should reflect the server’s role rather than being copied from a generic port list. A public web server, database server, mail relay and backup source have different requirements.
This approach also makes ownership clearer. Each server has an explicit network policy, so a forgotten service is not automatically reachable simply because it is listening.
Start with a default-deny policy
A practical server firewall normally has three layers of decision-making:
- Inbound traffic: deny by default, then allow only the ports required by legitimate services.
- Outbound traffic: permit required connections, but restrict sensitive or unnecessary destinations where possible.
- Internal traffic: allow only the communication needed between defined server roles, networks or management systems.
Before changing rules, document the server’s function, the services listening on it, their expected clients, and whether those clients are public, private or administrative. Useful sources include service configuration, cloud security groups, load balancer settings, DNS records, application documentation and connection logs.
Do not treat a port as safe or dangerous in isolation. A port number identifies a conventional service, not the quality of its configuration. Port 443 can still expose a vulnerable application, while SSH on port 22 can be well protected when access is restricted and authentication is hardened. Changing a default port may reduce background scanning, but it is not a substitute for access control.
Common service ports and their exposure risk
Teams often search for common server firewall ports to open and block, but a list should always be followed by an access decision. The important question is not only whether a service uses a port, but who needs to reach it and from which network.
Ports 80 and 443: public web services
Ports 80 and 443 are normally appropriate for a public website or web application. Port 443 carries HTTPS and should be the primary public entry point. Port 80 may be needed for HTTP-to-HTTPS redirects, certificate validation, legacy compatibility or a deliberately public HTTP service.
If the server is behind a reverse proxy, CDN or load balancer, the origin does not necessarily need to accept web traffic from the whole internet. Restricting inbound connections to the proxy’s published address ranges can reduce direct-origin attacks. Make sure the application still receives trustworthy client information and that health checks, certificate renewal and deployment processes are included in the design.
For an internal application, neither port needs to be public. Permit access from the corporate network, VPN, application gateway or named private subnets instead.
Port 22: SSH security
SSH is essential for Linux administration, automation and some file transfer workflows, but exposing it globally invites password guessing, credential attacks and exploitation of weaknesses in the SSH stack or its surrounding configuration.
For strong SSH security, allow port 22 only from a VPN address range, a corporate egress IP, a hardened bastion host or a private management network. Prefer key-based authentication, disable direct password login where practical, restrict privileged access, and use separate named accounts with audited elevation. Multi-factor authentication can add another layer, particularly where administrative access crosses an untrusted network.
Moving SSH to another port can reduce noise in logs, but it does not make an internet-facing service private. If remote administration is occasional, a VPN or just-in-time firewall rule is usually a better control than relying on obscurity.
Port 3389: RDP security
RDP is a high-value target because it provides interactive access to Windows systems. Port 3389 should not be open to the public internet as a normal operating model. Use a VPN, private network, remote access gateway or bastion service, and restrict source addresses to approved administrative networks.
Good RDP security also depends on Network Level Authentication, strong identity controls, patching, account lockout or equivalent detection policies, and limiting which administrators can log in. If a third-party support team needs access, give it a defined route and time-limited permission rather than a permanent any-source rule.
Port 25: SMTP
Port 25 is used for server-to-server email delivery. A mail server that sends or receives mail directly may require it, although providers and upstream networks sometimes restrict outbound SMTP to reduce abuse. A server that does not operate mail services should not expose port 25.
Do not assume that allowing outbound port 25 on every server is harmless. A compromised application server can become a spam source or damage the organisation’s mail reputation. Where possible, route application email through an approved relay and permit outbound SMTP only to that relay. Inbound port 25 should be limited to a genuine mail-handling role, with anti-abuse controls managed separately.
Port 53: DNS
DNS uses both UDP and TCP port 53. A recursive resolver may need to answer client queries from an internal network, while an authoritative DNS server may need to answer public queries. These are different roles and should not be combined casually.
Never expose an open recursive resolver to the internet. Restrict recursion to approved networks, allow zone transfers only between designated name servers, and permit TCP 53 where large responses, DNSSEC or zone transfer operations require it. A server that merely consumes DNS should normally make outbound queries to specified resolvers rather than accept inbound DNS traffic.
Ports 3306 and 5432: MySQL and PostgreSQL
MySQL commonly listens on port 3306 and PostgreSQL on port 5432. These ports should almost never be public. Databases contain valuable business data and are frequent targets for credential attacks, misconfiguration discovery and exploitation of unpatched software.
Permit database traffic only from the application servers, reporting systems, administrative bastion or private network that genuinely needs it. Use database-native authentication, encryption where supported, least-privilege accounts and network rules that match the application topology. Binding a database to a private interface is useful, but it should complement rather than replace the firewall.
Control panels, orchestration interfaces, hypervisor consoles and monitoring endpoints deserve the same treatment. They should be available only through a management network, VPN or tightly controlled allowlist. A publicly exposed management interface can turn one stolen password or unpatched component into control of the server and, potentially, its connected environment.
Separate public, application and management traffic
Port rules are more effective when the network is segmented. A typical small business deployment might separate:
- Public services: web or mail services that must accept connections from the internet.
- Application services: APIs, queues and internal application components reachable only from approved systems.
- Data services: databases and storage reachable only by application or administration networks.
- Management services: SSH, RDP, control panels, monitoring and orchestration tools reachable only through private administration paths.
- Backup connectivity: outbound connections from protected servers to an approved backup destination, with no general inbound access to the backup repository.
This model limits lateral movement. If a public web service is compromised, the attacker should not automatically be able to connect to the database, hypervisor or backup system. Firewall rules should name the source and destination role, not merely permit an entire virtual network because it is convenient.
Internal traffic also needs scrutiny. Private IP addresses are not automatically trusted. A compromised internal server can scan and attack another system just as effectively as an internet host. Apply least privilege between subnets and server roles, and avoid broad rules such as allowing every port from every internal address.
Protect backup connectivity and recovery copies
Backup traffic needs a deliberate path because backup systems are valuable targets. A common safer pattern is for the customer-controlled source server to initiate an outbound connection to the backup service, while inbound connections from the internet to the backup repository remain blocked. Permit only the destination, protocol and direction required by the backup design.
Do not publish a backup repository, storage endpoint or backup management interface directly to the internet. If a backup product requires inbound communication, place that communication behind a private network, VPN or tightly restricted allowlist, and document why it is necessary. Separate backup credentials from production credentials and avoid using a domain administrator account for backup operations.
Safenix provides off-site backup for business servers controlled by the customer. Backups are encrypted with a key Safenix never holds, stored in Germany, and immutable for the length of the retention window. The customer should still restrict backup connections at the source firewall and permit only the traffic needed to reach the service. Details for Safenix business server backup and off-site recovery protection can be reviewed alongside the customer’s firewall design.
Exposed backup connectivity creates two risks. An attacker may use it as a route into the backup platform, or may disrupt, delete or encrypt recovery copies. Keeping backup traffic narrow and one-directional where possible reduces the chance that a compromise of a production server becomes a compromise of the recovery environment.
IPv4 and IPv6 rules must match
A frequent firewall mistake is securing IPv4 while leaving IPv6 broadly reachable. If the server has a public IPv6 address, it needs an IPv6 firewall policy with the same default-deny stance, service restrictions and logging expectations as IPv4.
Do not assume that disabling an IPv4 rule protects the service. Check listening addresses, cloud security groups, host firewall configuration and provider-level controls for both protocols. If IPv6 is not required, disable it only after confirming that applications, monitoring, DNS and network dependencies will continue to work. Otherwise, maintain it properly.
Review outbound IPv6 as well as inbound traffic. An application that can reach external systems over an unmonitored address family may bypass assumptions built into an IPv4-only security design.
Outbound rules, logging and alerting
Blocking all outbound traffic is rarely practical for a business server. Updates, DNS, time synchronisation, email, APIs, monitoring and backups may all require outbound access. A sensible policy begins by identifying those dependencies, then limits destinations and ports where the operational risk warrants it.
For example, an application server may need HTTPS to specific software services, DNS to approved resolvers, NTP to approved time sources and an outbound backup connection. It may have no reason to connect to arbitrary SMTP servers, database ports or remote administration services on the internet.
Log denied traffic, but make logs useful rather than overwhelming. Record the source, destination, port, protocol, interface, action and timestamp. Rate-limit repetitive events and forward important logs to a location an attacker cannot easily alter. Alert on patterns such as repeated SSH or RDP attempts, scans across many ports, unexpected outbound SMTP, new access to database ports, or a sudden change in backup connection behaviour.
Logging should support investigation, not replace prevention. A rule that generates thousands of alerts every day will eventually be ignored. Tune thresholds against normal traffic and define who reviews alerts, how quickly, and what evidence should be retained.
How agencies can manage many client environments
Agencies need consistency without pretending that every client has the same architecture. The answer is a controlled baseline with documented exceptions.
- Create role-based templates for web, application, database, mail, Windows administration and backup-source servers.
- Use variables for client IP ranges, VPN addresses, private subnets and approved service destinations rather than hard-coding assumptions.
- Store firewall rules as version-controlled configuration where the platform permits it, with peer review and a recorded change history.
- Apply a standard naming convention for rules, including purpose, source, destination, owner and review date.
- Use automation to test syntax, confirm required ports are listening, and check that IPv4 and IPv6 policies are aligned.
- Keep emergency access procedures separate and time-limited, with automatic expiry where possible.
Before deploying a template, build a service inventory. Check application documentation, active connections and scheduled jobs, and ask the client which external suppliers need access. A short discovery phase is cheaper than breaking a billing integration, monitoring agent or deployment pipeline.
Roll out changes in stages. Apply a proposed policy in audit or logging mode when available, compare observed traffic with the intended design, then enforce it during a maintenance window. Keep an out-of-band console or recovery route available so an administrator is not locked out by a mistaken rule.
VPS firewalls versus shared hosting
A VPS gives the customer control over the operating system, installed services and usually the host-level firewall. That means the customer or its agency is responsible for deciding which ports are listening and which sources can reach them, alongside any controls provided by the hosting platform.
Shared hosting is different. Multiple customers use a provider-managed environment, and the provider controls the perimeter, network isolation and service exposure. The customer typically cannot apply a complete per-server firewall policy to the underlying host or alter the provider’s inbound rules. For a useful distinction between customer-managed VPS infrastructure and shared-hosting services, see this VPS and hosting infrastructure reference.
This distinction matters for security planning. A website on shared hosting is not the same as a customer-controlled business server with an operating-system firewall. Safenix protects servers controlled by the customer; it does not provide a backup plan for a site simply because it is hosted on shared hosting. The hosting provider’s capabilities and the customer’s responsibility must be confirmed before designing backup and recovery procedures.
Review firewall rules as part of operations
A firewall policy becomes inaccurate as soon as services, suppliers, networks or administrators change. Review rules at least periodically and after significant architectural changes, migrations, security incidents or staff changes.
During a review, remove rules with no owner, source or documented business purpose. Check for temporary allowlists that were never revoked, overly broad network ranges, duplicate entries, unused listening services and management ports exposed through IPv6. Confirm that database and backup interfaces remain private and that public services still use current certificates and secure configurations.
Keep a simple record for every exception: what it permits, why it exists, who approved it, when it should be reviewed and what would replace it. This turns firewall administration from a collection of ad hoc fixes into a repeatable control.
A per-server, default-deny firewall will not prevent every compromise, but it can stop many unnecessary paths to a system and limit movement after an incident. Combine it with hardened authentication, patch management, segmentation, monitoring and protected off-site backups. The result is a smaller attack surface and a more dependable route to recovery when a server or network is no longer trustworthy.