SCANTIDE GUIDES
Infrastructure Security · Scantide Guides

Server Security Baseline: Operating Systems, Patching, Services and Local Firewalls

A server-baseline checklist covering supported operating systems, patching, firmware, local firewalls, service accounts, permissions and recovery.

Short answer: Server hardening is not one setting. It is the accumulated effect of supported software, patching, local firewalling, controlled services, permissions, monitoring and recoverability.
From the archive: This guide was refurbished from Juha Jurvanen's earlier technical writing, primarily Securing your server environment - Part III - Operating systems (2020). Historical vendor/product specifics were not silently presented as current guidance.

Start with supportability

The source begins with operating-system support. If an older server must remain because of application dependencies, reduce who and what can reach it and document why it still exists. Unsupported systems should be exceptions that receive additional containment, not invisible permanent fixtures.

Know the hardware and firmware underneath

The article also emphasizes drivers, firmware and documentation. A failed update or hardware replacement becomes much harder when nobody knows which working driver, firmware or RAID/NIC configuration the server depended on.

Patch with an operational plan

Patching is necessary, but the source is equally concerned with what happens when a patch goes wrong. The lesson is to combine patch discipline with maintenance windows, recovery options and someone who can respond when production behaves differently afterwards.

Keep the local firewall

A recurring JufCorp theme is that local firewalls should not be disabled merely to make troubleshooting easier. Logging and clear rules make it possible to diagnose connectivity while still limiting unnecessary paths to the server.

Reduce unnecessary privilege and services

Review running services, their accounts and whether they need the privileges they have. Disable services that are not required, use constrained service identities where possible, and revisit file permissions that were left broad for installation convenience.

Include backup and monitoring in the baseline

A server is not well managed if it is hardened but cannot be restored or nobody notices when it degrades. The source explicitly connects antivirus, backups and operational monitoring with the baseline rather than treating them as separate projects.

FAQ

Questions that usually come next

Is a baseline the same as a one-time hardening project?

No. The source describes items that change over time: versions, patches, services, drivers, accounts, permissions and backups. A baseline has to be revisited.

What should happen to an unavoidable legacy server?

Document the dependency, restrict access, segment it and compensate for the risks that cannot be removed immediately.

Use the evidence, then choose the tool

Scantide Guides explains the problem. Use Online for outside-in public evidence, Auditor for authorized internal visibility, Observe for browser-visible behavior and Guard for active server protection.

All Scantide GuidesScantide Products

Practical depth: examples, failure modes and what to verify

Source note: current Scantide material describes the present platform. Older JufCorp/Red Cloud material is retained as field experience and historical context. Old product names, versions and configuration examples are not presented as current requirements.

Field experience from the archive

Historical source · JufCorp: Securing your server environment - Part III - Operating systems

In many environments, local firewalls are disabled out of pure laziness. "We can't be bothered troubleshooting why SQL traffic doesn't work .." Have local firewalls enabled , enable logging so you can easily find what's going on. If you're in a shared environment you'll also get alerted about noisy neighbors . Local firewalls also enables you to utilize a brute force prevention software and have those attacks mitigated, no matter where they come from. If you want, I'll happily help you out with getting a brute force prevention software in place.

If possible, do not use unsupported versions of operating systems If you still need to use older server versions (due to old applications etc), make sure to have them secured from access by anyone not explicitly needing it. Have it behind firewalls and VLANs etc

Go through all services started and make sure the ones they don't use SYSTEM accounts etc unless they need to. Should the service running contain a bug and someone manages to exploit that bug, they've got SYSTEM access to your server, meaning the entire server. If you have service-users running services instead and those user are locked down, you'll minimize the damage at least When setting up the server, make sure to disable services not in use. Both from a security point of view and for performance. Windows for instance starts quite a few services that you probably don't use nor need.

Historical source · JufCorp: Securing your servers, users and customers online

Minimize the attack surface behind a good firewall that can deal with the SYN Floods and port scans and stuff. Be cautious not to open up anything more than what's absolutely necessary to and from the outside world. Use local firewalls also!

I - Physical , II - Networking , III - Operating systems and also few pointers about Holidays and getting your stuff ready for Santa

Also a bit off topic but still important. Be sure to have a good monitoring on the hardware aspects of your server and operating system aspects (running services, disk space used and so on ) . Personally I'm fond of Spiceworks för monitoring server health, licenses and inventory but it all boils down to resources and taking the time to set it up. As long as you have some working monitoring and someone who actually deals with the alerts that come up.

Practical review checklist