Reducing the attack surface: services, ports and host firewalls

Why this matters

A server's attack surface is everything about it that an attacker could try to use: every running service, every open port, every account, every installed program. Each one might contain a vulnerability or a misconfiguration. Patching fixes known flaws in what is there; reducing the attack surface removes things that do not need to be there at all, so their flaws, known or not, cannot be used.

This process is called hardening, and it is the capstone of the security domain because it draws on nearly everything before it: the roles lesson's rule to install only what a server needs, least privilege from the accounts lessons, patching, and the monitoring that notices when something changes. This lesson covers removing services, controlling ports, dealing with defaults, working from published baselines, and detecting intrusions on the host itself.

The lesson

Disabling unused services and roles

Every running service is code listening for input, consuming resources, and potentially exploitable. A service that is not running cannot be attacked.

Start from the server's purpose. A web server needs its web service and the management services used to administer it. It does not need a print spooler, a file sharing service, a mail server, or the graphical desktop.

• On Windows Server, remove roles and features that are not needed, and set unneeded services to Disabled rather than merely stopped, since a stopped service can be started again by anything that asks for it. Consider Server Core, the installation option without a desktop interface, which has far fewer components to attack and to patch.
• On Linux, install a minimal system and add only the packages the server needs. List running services with systemctl, and use systemctl disable --now to stop a service and prevent it starting at boot. Remove packages that are not needed at all.

Removing is better than disabling where possible, because disabled software still needs patching and can be re-enabled. Document why each remaining service is there, and test after each change, since some services are dependencies of others in ways that are not obvious.

Closing ports, and host-based firewalls

A port is open when a service is listening on it. Closing ports mostly follows from disabling services: stop the service and its port closes. The first step is therefore to find what is listening:

• netstat on Windows, for example netstat -ano, shows listening ports and the process that owns each; PowerShell's Get-NetTCPConnection does the same.
• ss on Linux, for example ss -tulpn, lists listening TCP and UDP ports with their processes.
• A port scan from another machine, using a tool such as nmap, shows what is actually reachable over the network, which is what an attacker sees. Only scan systems you are authorised to test.

Any listening port that is not needed means a service to disable.

A host-based firewall adds a second layer: it controls which traffic can reach the ports that remain open, and from where. Windows Defender Firewall is built into Windows Server; Linux uses firewalld, ufw, or nftables directly. The right approach is default deny: block all inbound traffic, then allow only the specific ports the server needs, from the specific sources that need them. The database port is open to the application servers, not the whole network; remote management is allowed only from the jump box, as the MFA lesson described.

A host firewall works alongside network firewalls rather than replacing them, and it protects the server even from other machines on the same network segment, which a network firewall at the edge cannot.

Removing default accounts and changing defaults

Software ships with defaults designed to make it easy to install, and attackers know every one of them.

• Default accounts: built-in administrator or guest accounts, and accounts created by applications and appliances. Disable accounts that are not needed, such as the guest account; rename the built-in administrator where policy requires, and give it a strong, unique password, managed as the accounts lesson described with a tool such as LAPS.
• Default passwords: network devices, management controllers, databases and applications often ship with published default credentials. Every one must be changed before the device is connected to the network. Default passwords on management controllers are especially dangerous, since they give complete control of the server's hardware.
• Other defaults: sample applications and pages installed with web servers, default SNMP community strings such as public, insecure older protocol versions such as SMBv1 and early TLS, and file shares or permissions that are more open than needed.

A new server or device is not ready for production until its defaults have been reviewed. The build checklist should say so explicitly.

Hardening baselines from CIS and the vendor

Nobody needs to work out every hardening setting from scratch. Published hardening baselines set out recommended secure configurations, setting by setting.

• The CIS Benchmarks, from the Center for Internet Security, cover operating systems, databases, web servers and cloud platforms, with explanations and recommended values. They come in levels, with a basic level suitable for most systems and stricter levels for high-security environments.
• Vendor baselines, such as Microsoft's security baselines for Windows Server, applied through Group Policy, and vendors' own hardening guides.
• Government guidance, such as the US DISA Security Technical Implementation Guides (STIGs), required for some environments.

Baselines are not applied blindly. Some settings will break applications or conflict with requirements, so they are tested in the lab, and any deviation is documented with its reason. Once adopted, the baseline becomes the server's configuration baseline, as in the documentation lesson: applied automatically through Group Policy or configuration management tools, and checked regularly with scanning tools to detect drift away from it.

Host-based intrusion detection and prevention

Even a hardened server may be attacked successfully, so it is watched for signs of intrusion.

A host-based intrusion detection system (HIDS) monitors the server itself for signs of compromise. It watches logs for suspicious events and, through file integrity monitoring, alerts when important files, such as system binaries, configuration files and the web server's content, change unexpectedly. OSSEC and Wazuh are well-known examples, and EDR tools, covered in the malware lesson, provide similar monitoring.

A host-based intrusion prevention system (HIPS) goes further, acting on what it detects: blocking a suspicious process, a connection, or a change to a protected file.

The distinction mirrors network intrusion detection and prevention, which watch network traffic rather than a single host. Host-based systems see what network tools cannot, including activity inside encrypted connections once it reaches the server, and changes made by someone already logged on.

Their alerts belong in the SIEM with everything else, and they need the same tuning, since legitimate changes such as patches also alter system files. Taken together, hardening makes an attack harder, and detection makes one that succeeds visible quickly.