Malware prevention on servers

Why this matters

Servers are rarely where malware first lands. It usually arrives on a workstation through an email or a web page, and then spreads. But servers are where it does the most damage: a file server holds everyone's documents, a domain controller holds every account, and a backup server holds the means of recovery. Ransomware operators aim specifically for servers, because encrypting them stops the organisation.

Malware prevention on servers is therefore about more than installing antivirus. This lesson covers endpoint protection and the special care servers need, restricting what can run at all, patching, the specific threat of ransomware and what really defends against it, and scanning the files that users bring to servers.

The lesson

Antivirus and EDR on servers, and the exclusions databases need

Antivirus software detects and removes malware, traditionally by matching files against signatures of known malware, and increasingly by heuristics and behaviour analysis that spot suspicious activity from unknown malware. Servers run server editions of antivirus, including Microsoft Defender, which is built into Windows Server.

Endpoint detection and response (EDR) goes further. It continuously records activity on the server, such as processes started, network connections made, and files changed, detects suspicious patterns, and lets security staff investigate and respond, for example by isolating a server from the network with one action. EDR catches attacks that use legitimate tools, which antivirus alone often misses.

On servers, scanning needs care. Real-time scanning inspects every file as it is read or written. On a busy database, mail or virtualisation server, scanning its constantly changing data files can slow it badly, and can even corrupt data if the scanner locks a file the application needs. So vendors publish recommended exclusions: for example, database data and log files, the folders holding virtual machine disks, and certain application directories.

Exclusions must be kept as narrow as possible and documented, because an excluded location is one malware can use without being scanned. Exclude the specific files and folders the vendor lists, not whole drives, and review exclusions periodically.

Application allow-listing

Antivirus tries to recognise what is bad. Application allow-listing, also called whitelisting, takes the opposite approach: only software that has been explicitly approved may run, and everything else is blocked, whether it is known malware or not.

It suits servers particularly well. A server runs a small, known set of applications that changes rarely, unlike a user's workstation, so the list of approved software is short and stable. Anything else that tries to run, such as a malicious tool dropped by an attacker, is refused.

Rules can identify approved software by:

• publisher, using the software's digital signature, which allows updates from the same vendor;
• path, allowing whatever runs from protected folders such as Program Files;
• file hash, allowing one exact file and nothing else.

On Windows, AppLocker and Windows Defender Application Control implement allow-listing. On Linux, mandatory access control systems such as SELinux and AppArmor restrict what each program can do. Allow-listing is normally introduced in an audit mode first, which logs what would have been blocked without blocking it, so the rules can be corrected before enforcement.

Patching as malware prevention

Much malware does not need anyone to open anything. It exploits vulnerabilities in software to run itself, and it spreads from server to server by the same means. Some of the most destructive outbreaks, such as WannaCry and NotPetya in 2017, spread using a Windows vulnerability for which a patch had been available for weeks or months. Organisations that had patched were not affected.

So patching is one of the most effective malware defences there is. A vulnerability that has been patched cannot be exploited, whatever malware arrives. Priorities follow risk:

• servers exposed to the internet, such as web and mail servers, need patches first, because they can be attacked directly;
• critical vulnerabilities, especially those being actively exploited, need patching urgently, not in the next routine cycle;
• everything needs patching, including applications, firmware and the hypervisor, not just the operating system.

Where a patch cannot yet be applied, mitigations, such as disabling the vulnerable feature or blocking its port, reduce the risk until it can. The patching process itself is covered in the patching lesson later in this domain.

Ransomware, and why backups must be offline or immutable

Ransomware encrypts an organisation's data and demands payment for the key. Modern ransomware operators also steal data first and threaten to publish it, and they deliberately look for backups to delete or encrypt before starting, because an organisation that can restore does not pay.

This is why ordinary backups are not enough. If backups sit on a share the ransomware can reach, or are managed by a backup server using the same domain administrator account the attacker has stolen, they are encrypted along with everything else.

Backups that survive ransomware are:

• Offline or air-gapped: physically disconnected, such as tapes removed from the library or disks unplugged and stored away. What is not connected cannot be encrypted.
• Immutable: stored so they cannot be changed or deleted until a retention period ends, even by an administrator. Many backup systems and cloud storage services offer immutable storage, sometimes called WORM (write once, read many) or object lock.
• Separated: managed with different credentials from the main environment, so stolen domain administrator rights do not reach them.

The 3-2-1 backup rule in the backup lessons later in the course builds this in. Other defences reduce the chance of ransomware reaching the point of encrypting anything: MFA and separate admin accounts, patching, allow-listing, EDR, and network segmentation that limits how far it can spread.

Scanning file shares and uploads

Servers store files that come from elsewhere: documents saved to shares, email attachments, files uploaded through websites and applications. Any of them may carry malware, which the server then stores and serves to everyone who opens it.

• File shares are protected by real-time scanning, which checks files as they are written, and by scheduled full scans that pick up malware that was not recognised when it arrived but is detected by newer signatures.
• Uploads to web applications should be scanned before being stored or made available, checked for their real file type rather than trusting their name, and stored outside the web server's executable paths so an uploaded script cannot be run.
• Email is scanned at the mail gateway, before it reaches mailboxes.

Scanning also reveals trouble in progress. A sudden surge of file changes, or files being renamed with unfamiliar extensions, on a file share is a classic sign of ransomware at work, and EDR and file server monitoring can alert on exactly that pattern.