Hardening a New Server in the first hour

A newly installed server is not automatically a secure server.

Default configurations are designed to make installation and compatibility straightforward. They may leave unnecessary services enabled, permit broad remote access, use temporary credentials, lack central monitoring or remain several security updates behind.

The first hour after deployment is therefore critical.

Before the server begins hosting production data or accepting normal user traffic, you should establish a secure baseline, reduce its exposed attack surface and make sure that suspicious activity will be visible.

The objective is not to configure every possible security control in 60 minutes. It is to close the most dangerous gaps before the machine becomes useful—and therefore valuable—to an attacker.

Before Starting: Know What the Server Is For

Server hardening should be based on the role the machine will perform.

A domain controller, database server, web server and file server require different:

• Network ports
• User accounts
• Applications
• Access rules
• Monitoring
• Backup schedules
• Recovery procedures

Write down:

• The server’s purpose
• Its owner
• Its operating system and version
• Whether it will be internet-facing
• Which systems need to connect
• Which administrators require access
• What data it will store
• How it will be backed up
• What downtime the business can tolerate

Without this information, administrators often leave services open “just in case”, creating unnecessary exposure.

Minute 0–5: Keep It Away From Untrusted Networks

Do not place a newly installed server directly onto the public internet before it has been updated and secured.

Use:

• An isolated deployment VLAN
• A restricted management network
• A cloud security group allowing only your administration address
• A hardware or virtual firewall
• A temporary private network

NIST hardening guidance includes blocking unnecessary networks and services, applying patches, replacing default credentials, configuring logging and enforcing least privilege.

The server should initially be reachable only by the people and systems required to configure it.

Minute 5–10: Change Every Default or Temporary Credential

Replace credentials created during installation, deployment or delivery.

This includes:

• Local administrator passwords
• Root passwords
• Cloud instance credentials
• Management-controller passwords
• Database administrator accounts
• Application default logins
• Backup-agent credentials
• Hypervisor credentials
• Temporary deployment accounts

Default credentials are routinely targeted because attackers can obtain them from manuals, leaked configurations and automated scanning.

Use long, unique passwords stored in an approved password-management system. Never reuse the password from another server.

Where supported, disable or rename well-known administrator accounts after creating properly controlled named administration accounts.

Create Named Administrator Accounts

Administrators should not share one generic login.

Create individual accounts so that activity can be attributed to a specific person.

For example:

• carl.hamilton-admin
• jane.smith-serveradmin

Keep everyday user accounts separate from privileged accounts.

An administrator should use their normal account for email, browsing and routine office work, then use the privileged account only when making authorised server changes.

This limits the exposure of powerful credentials.

Enable Multi-Factor Authentication

Enable multi-factor authentication wherever the platform supports it, especially for:

• Cloud portals
• Remote-management gateways
• Privileged access systems
• VPNs
• Hosting dashboards
• Backup consoles
• Password vaults

NIST’s hardening guidance includes MFA and least-privilege role assignment among its identity protections.

Direct Windows or Linux console logins may not always support MFA natively, so place remote administration behind an MFA-protected VPN, privileged-access workstation or secure management gateway.

Minute 10–20: Install Security Updates

Apply current:

• Operating-system updates
• Security patches
• Firmware updates
• Hypervisor tools
• Cloud-agent updates
• Hardware-management updates
• Application patches

A server image can be outdated even when it was downloaded recently. Templates and installation media may have been created months earlier.

Restart when required, then check for updates again. Some updates become available only after an earlier servicing update or reboot has completed.

Patch management should also be configured for the future rather than treated as a one-time installation task. NIST identifies patching and hotfixes as fundamental hardening steps.

Confirm the Operating System Is Supported

Do not put an unsupported operating system into production unless a formally approved isolation and migration plan exists.

A supported platform receives:

• Security updates
• Reliability fixes
• Vendor guidance
• Compatibility support
• Vulnerability remediation

For Linux, choose a supported long-term-support release where stability is required. Ubuntu documents that its LTS releases receive an extended standard-support period that includes security and bug fixes.

For Windows Server, verify the exact edition, build and support lifecycle rather than assuming all versions remain supported equally.

Minute 20–25: Set the Correct Time

Configure reliable time synchronisation.

Accurate time is essential for:

• Authentication
• Kerberos
• Certificates
• Log analysis
• Incident investigation
• Scheduled tasks
• Backups
• Database transactions
• Security alerts

Point the server towards:

• The domain hierarchy
• An approved internal time source
• A trusted external source where appropriate

Incorrect clocks can make valid certificates appear expired, disrupt authentication and make security events difficult to correlate.

NIST explicitly includes NTP configuration as part of network and system hardening.

Minute 25–35: Configure the Firewall

Enable the server’s host firewall and use a default-deny approach for unsolicited inbound connections.

Open only the ports required for the documented server role.

Examples might include:

• HTTPS for a web server
• DNS for an authorised DNS server
• SMB for an internal file server
• Database traffic from specific application servers
• Management access from an administration network

Do not open a management port to the entire internet when access can be limited to:

• A management subnet
• A VPN address range
• A jump server
• A specific administrator IP
• A privileged-access service

Microsoft and Ubuntu both provide platform firewall controls that can limit access by protocol, port and source address. Microsoft’s current firewall documentation applies across supported Windows Server releases, while Ubuntu documents restricting SSH to particular hosts or subnets through ufw.

Do Not Disable the Firewall to Make Something Work

When an application fails after the firewall is enabled, identify the exact traffic it requires.

Avoid creating rules such as:

• Allow all inbound traffic
• Allow any port from any address
• Disable firewall for the private profile
• Temporarily disable it and forget to restore it

A good rule should document:

• Application or service
• Protocol
• Port
• Source
• Destination
• Business owner
• Reason
• Review date

Lock Down Remote Desktop

For Windows servers, do not expose Remote Desktop Protocol directly to the public internet.

Prefer:

• A VPN
• Remote Desktop Gateway
• Azure Bastion or an equivalent cloud service
• A dedicated jump server
• A zero-trust access platform

When RDP is required:

• Restrict the source network.
• Enable Network Level Authentication.
• Allow only authorised administration groups.
• Set account-lockout protections.
• Use MFA at the access gateway.
• Log connection attempts.
• Remove access when no longer needed.

Harden SSH

For Linux and other SSH-managed servers:

• Use SSH version 2.
• Restrict access by source address.
• Prefer cryptographic keys over passwords.
• Disable direct remote root login.
• Remove unused keys.
• Protect private keys with appropriate permissions.
• Use a non-root named account with controlled sudo access.

Ubuntu recommends SSH for secure remote administration and provides firewall examples that limit SSH to specific hosts or networks.

Changing SSH from port 22 may reduce background scanning noise, but it is not a substitute for proper authentication and firewall restrictions.

Minute 35–40: Remove Unnecessary Roles and Services

Every listening service increases the server’s attack surface.

Review:

• Installed roles
• Optional features
• Running services
• Listening ports
• Default web applications
• Sample databases
• Printer services
• Discovery protocols
• Legacy file-sharing protocols
• Unused remote-management tools
• Vendor utilities

Remove or disable anything the server does not require.

However, do not disable services simply because their names are unfamiliar. Microsoft provides role-aware guidance because some Windows services are essential and should not be disabled arbitrarily.

Document what you remove so the configuration can be reproduced.

Use a Minimal Installation

Where operationally practical, use the smallest installation option appropriate to the server’s role.

This might mean:

• Windows Server Core rather than Desktop Experience
• A minimal Linux installation
• No graphical interface
• No office applications
• No browsers
• No development tools on production machines
• Only the required packages and roles

Fewer components normally mean:

• Fewer vulnerabilities
• Fewer patches
• Less resource use
• Fewer services
• Simpler monitoring

A minimal server should still include the tools required for safe administration, backup, security and recovery.

Minute 40–45: Apply a Security Baseline

Avoid inventing every hardening setting manually.

Use an appropriate published baseline, such as:

• Microsoft Security Baselines
• Windows Server role-aware baselines
• CIS Benchmarks
• Vendor hardening guides
• An approved organisational standard
• Cloud-provider security baselines

Microsoft describes its Windows Server 2025 baseline as a standardised, role-aware collection of recommended security settings that avoids configuring hundreds of controls individually.

Test baselines before enforcing them on production systems. Hardening controls can affect:

• Legacy applications
• Authentication
• File sharing
• Remote administration
• Encryption protocols
• Service accounts

Start with the vendor’s recommended baseline, then document approved exceptions.

Keep Linux Mandatory Access Controls Enabled

Linux distributions may include mandatory access-control systems such as:

• AppArmor
• SELinux

These restrict what applications can access, even when traditional file permissions might otherwise allow the action.

Ubuntu states that AppArmor is installed and loaded by default and that it applies per-program profiles to limit application capabilities.

Do not disable these protections simply to silence an application error. Review logs and adjust the relevant profile safely.

Minute 45–50: Configure Logging and Monitoring

A hardened server should tell you when something suspicious happens.

Enable and centralise logs covering:

• Successful and failed logins
• Administrator activity
• Account changes
• Service installation
• Firewall events
• Security alerts
• Software installation
• Application failures
• Backup results
• System restarts
• Privilege use
• Configuration changes

NIST log-management guidance emphasises collecting records that support security operations, including patch history and security-relevant events.

Forward important logs to a central location so an attacker cannot erase the only copy by compromising the server.

Configure Alerts, Not Just Logs

Logs are useful only when somebody reviews them.

Create alerts for events such as:

• Repeated failed logins
• New administrator accounts
• Security software disabled
• Firewall changes
• Backup failure
• Low storage
• Service failure
• Unexpected restart
• High processor or memory usage
• Suspicious outbound connections
• Malware detection

Define who receives the alert and what they should do.

An alert sent to an unmonitored mailbox provides little protection.

Install Endpoint Protection

Ensure the server has an appropriate, supported security agent.

Depending on the environment, this may include:

• Antivirus
• Endpoint detection and response
• Behavioural monitoring
• Application control
• Vulnerability management
• File-integrity monitoring

Confirm that the agent:

• Is registered with the management platform
• Has current detection intelligence
• Is reporting normally
• Has not been left in audit-only mode unintentionally
• Uses server-appropriate policies
• Does not conflict with another security product

Do not install two competing real-time antivirus products.

Minute 50–55: Configure Least Privilege

Applications and services should run with only the permissions they genuinely require.

Avoid:

• Running ordinary services as domain administrator
• Giving application pools local administrator rights
• Using one powerful service account across many servers
• Allowing all IT staff unrestricted access
• Granting users direct login rights to production servers

NIST defines least privilege as providing only the functionality required by each authorised user or process.

Create dedicated service accounts with:

• No interactive login
• Restricted local rights
• Access only to required folders and services
• Managed password rotation
• Clear ownership
• Documented dependencies

Use group-managed service accounts or equivalent managed identities where supported.

Restrict Local and Remote Login Rights

Review who can:

• Log on locally
• Log on through Remote Desktop
• Use SSH
• Access file shares
• Run scheduled tasks
• Install software
• Manage services
• Read backups
• Change security settings

Remove broad groups that do not need access.

Be cautious with built-in groups inherited from templates or old domain policies.

Secure Service Accounts

Service accounts are frequently overlooked because they do not belong to normal users.

For each service account, document:

• Owner
• Purpose
• Systems used
• Permissions
• Password-management method
• Rotation process
• Expiry policy
• Dependencies

Do not use passwords that never change unless the account is protected through an approved managed-identity system.

Monitor service-account use from unexpected devices or locations.

Minute 55–60: Configure Backups and Recovery

A server is not ready for production until it has a tested recovery plan.

Configure backups for:

• Operating-system state where required
• Application data
• Databases
• Configuration
• Encryption keys
• Certificates
• Recovery information
• Logs where required
• Virtual-machine configuration

Backups should be:

• Separated from the production server
• Protected with different credentials
• Encrypted
• Monitored
• Retained according to policy
• Resistant to unauthorised deletion
• Regularly tested

A successful backup notification does not prove that the data can be restored.

Protect the Backup Platform

Backup systems hold valuable copies of almost everything.

They are frequent ransomware targets.

Use:

• Separate administrative credentials
• MFA
• Restricted network access
• Immutable or offline copies
• Dedicated backup accounts
• Alerting for deletion or configuration changes
• Tested recovery keys

Do not allow the ordinary server administrator account to delete every production and backup copy without additional control.

Confirm Disk Encryption

Enable storage encryption where appropriate.

For Windows, this may involve BitLocker.

For Linux, it may involve LUKS or encrypted cloud volumes.

Also verify encryption for:

• Data disks
• Backups
• Temporary storage
• Snapshots
• Replicas

Store recovery keys in a controlled system separate from the encrypted server.

Encryption protects data when storage is copied, removed or accessed outside the normal operating environment. It does not replace permissions, backups or endpoint security.

Record the Configuration

Before the first hour ends, create a deployment record containing:

• Hostname
• IP address
• Operating system and build
• Installed roles
• Open ports
• Firewall rules
• Administrator groups
• Service accounts
• Backup policy
• Monitoring status
• Security-agent status
• Applied baseline
• Approved exceptions
• Recovery-key location
• Server owner
• Support contact

This information should not be stored only on the server itself.

Documentation makes future troubleshooting, auditing and replacement much easier.

Take a Secure Baseline Snapshot

For a virtual server, consider taking a clean snapshot or template after:

• Updates are installed
• Hardening is complete
• Security agents are operating
• Configuration is documented

Do not treat a snapshot as a backup.

Snapshots normally depend on the same storage platform and can grow, degrade performance or be deleted alongside the virtual machine.

Use them only for short-term deployment or rollback purposes.

Run a Vulnerability Scan

Perform an authenticated vulnerability scan before placing the server into production.

The scan can identify:

• Missing patches
• Weak protocols
• Exposed services
• Default configurations
• Unsupported software
• Certificate problems
• Insecure permissions
• Security-baseline deviations

Review the findings rather than automatically applying every suggested change.

A scanner can identify risk, but it may not understand the server’s business role or application dependencies.

Verify Listening Ports

Check which ports are actually listening after hardening.

On Windows, tools may include:

Get-NetTCPConnection -State Listen

or:

netstat -ano

On Linux:

ss -tulpn

Compare the results with the documented server role.

An unexpected listening port may indicate:

• An unnecessary service
• A management agent
• A development tool
• A misconfigured application
• Malicious software

Confirm the owning process before disabling anything.

Test the Firewall From Another Device

Do not rely only on the local firewall console.

From an authorised test system, confirm that:

• Required ports are reachable.
• Unnecessary ports are blocked.
• Management access is restricted correctly.
• Internet-facing services are available only where intended.
• Internal services are not accidentally public.
• IPv6 rules match the intended policy.

Test both allowed and denied connections.

Validate DNS and Network Configuration

Confirm:

• Correct static or reserved IP address
• Appropriate subnet and gateway
• Approved DNS servers
• Correct DNS registration
• Valid hostname
• Network time source
• VLAN placement
• Cloud security groups
• Reverse DNS where needed

Do not use public DNS resolvers directly on domain controllers or internal application servers when they require internal name resolution.

Misconfigured DNS can cause authentication delays, application failures and inconsistent access.

Review IPv6

Do not ignore IPv6.

A server may be protected carefully over IPv4 while remaining broadly accessible through IPv6.

Check:

• Assigned IPv6 addresses
• Host-firewall rules
• Cloud firewall rules
• DNS records
• Router advertisements
• Application bindings
• Monitoring coverage

Do not disable IPv6 automatically on Windows domain environments without understanding the dependencies.

Secure it consistently with IPv4.

Secure the Hardware Management Interface

Physical servers may include out-of-band management systems such as:

• iDRAC
• iLO
• IPMI
• BMC interfaces

These interfaces can control power, firmware, storage and remote console access.

Place them on a dedicated management network.

Then:

• Change default credentials.
• Update firmware.
• Restrict source addresses.
• Enable MFA where available.
• Disable unused legacy protocols.
• Monitor login attempts.
• Use trusted certificates.

Never expose a hardware-management interface directly to the public internet.

Secure Cloud Metadata and Identity

For cloud servers:

• Assign only the required instance role.
• Avoid storing permanent cloud keys on disk.
• Restrict access to metadata services.
• Use managed identities.
• Review security groups.
• Disable public IP addresses where unnecessary.
• Enable cloud activity logging.
• Protect the cloud management account with MFA.

A securely configured operating system can still be compromised through excessive cloud permissions.

Do Not Install Everyday User Software

A production server should not be used as a normal workstation.

Avoid installing:

• General web browsers
• Consumer messaging apps
• Office software
• Personal cloud-storage clients
• Games
• Unapproved remote-control tools
• Download utilities
• Email clients

Administrators should browse documentation and download packages from a secured management workstation, then transfer verified files through an approved process.

Do Not Browse the Web as Administrator

Browsing from a privileged server session exposes highly valuable credentials and system access to:

• Malicious websites
• Browser vulnerabilities
• Drive-by downloads
• Phishing
• Dangerous attachments

Use a privileged-access workstation or jump server for administration.

The production server should perform its server role—not double as an administrator’s desktop.

Disable Obsolete Protocols

Remove or restrict legacy technologies that are not required, which may include:

• SMBv1
• Telnet
• FTP without encryption
• Older TLS versions
• Insecure authentication methods
• Unencrypted management protocols
• Legacy name-resolution protocols

Confirm application compatibility before disabling protocols.

When an application requires an obsolete protocol, document the exception, isolate the service and create a replacement plan.

Protect Certificates and Private Keys

Servers may use certificates for:

• HTTPS
• VPNs
• Authentication
• Code signing
• Database encryption
• Remote management

Private keys should be:

• Accessible only to the required service
• Stored securely
• Backed up where recovery is necessary
• Renewed before expiry
• Removed when no longer needed
• Protected from export where possible

Monitor certificate expiration.

A hardened server can still suffer an outage when an overlooked certificate expires.

Check File and Folder Permissions

Review sensitive locations, including:

• Application configuration
• Database files
• Web roots
• Backup folders
• Log folders
• Certificate stores
• Script directories
• Upload folders
• Service-account profiles

Avoid granting broad permissions such as:

• Everyone: Full Control
• Authenticated Users: Modify
• World-writable directories

Applications should receive the minimum read, write or execute access they need.

Configure Account Lockout and Password Policies

Apply the organisation’s approved policies for:

• Password length
• Password reuse
• Account lockout
• Failed login thresholds
• Inactive accounts
• Privileged-account review

Be careful with service accounts. An inappropriate expiry policy can cause a production outage when an unattended service password expires.

Managed service identities are preferable where available.

Create an Emergency Access Plan

Define how administrators will regain access when normal identity services fail.

This may involve:

• A protected local emergency account
• A cloud break-glass account
• Offline recovery codes
• Hardware console access
• Securely stored recovery keys

Emergency credentials should be:

• Long and unique
• Stored securely
• Monitored
• Tested
• Used only for emergencies
• Rotated after use

Do not leave an undocumented backdoor account with a simple password.

The First-Hour Checklist

Before the server enters production, confirm that:

• It is on a restricted network.
• Default credentials have been replaced.
• Named administrator accounts exist.
• MFA protects management access.
• Updates and firmware are current.
• Time synchronisation works.
• The firewall is enabled.
• Only required ports are open.
• Remote access is restricted.
• Unnecessary services have been removed.
• A recognised security baseline is applied.
• Endpoint protection is reporting.
• Logging is enabled and centralised.
• Alerts have owners.
• Least privilege is enforced.
• Backups are configured.
• Recovery keys are secured.
• Encryption is enabled where appropriate.
• Vulnerability scanning has been completed.
• The configuration is documented.
• The server has a named business and technical owner.

What Happens After the First Hour?

Hardening is not a one-time event.

The server now needs an ongoing programme covering:

• Patch management
• Vulnerability scanning
• Configuration monitoring
• Log review
• Access reviews
• Backup testing
• Certificate renewal
• Capacity monitoring
• Incident response
• Replacement planning

Changes should be compared against the approved baseline.

A server that was secure on installation can become exposed later through a temporary firewall rule, forgotten account, obsolete application or failed security agent.

Secure the Server Before It Becomes Important

The easiest time to harden a server is before users, applications and business data depend on it.

Once it enters production, simple changes may require maintenance windows, vendor approval and outage planning.

The first hour should focus on the controls that reduce the greatest immediate risk:

• Patch it.
• Restrict the network.
• Replace default credentials.
• Protect privileged access.
• Enable the firewall.
• Remove unnecessary services.
• Apply a baseline.
• Configure monitoring.
• Enforce least privilege.
• Establish recoverable backups.

A server is ready for production only when it is both functional and defensible.

Hamilton Group can design, deploy and harden Windows, Linux, virtual and cloud servers, with secure access, monitoring, backups and ongoing management.

Call 0330 043 0069 or visit hgmssp.com to speak with one of our experts.