Ransomware is increasingly becoming a serious issue for many companies. It’s a type of malware that encrypts all data on and accessible by a computer, and holds the recovery key hostage until payment is made by a certain deadline. If the deadline passes without payment, the recovery key is destroyed and access to the encrypted data is permanently lost. With criminals making large sums of money using this method ransomware will continue to become even more commonplace in the future.

Plan For Recovery

Backups

A good first step is planning for recovery in the case of infection despite any of the protections put in place. Having timely, reliable backups is absolutely necessary and should be a focus regardless. Make sure there are regular backups running that cover all important data, and verify backup integrity by performing test restores often. If accessible, ransomware will also encrypt backups so it’s important to have off-site backups as well.

If there are solid backups in place then the worst case scenario of ransomware getting on the network is a (hopefully) short amount of downtime while all encrypted data is restored from backups. Although not a substitute for proper backups, restoring from shadow copies can help reduce downtime as well. Typically ransomware will attempt to delete shadow copies but limiting user privileges can prevent this.

Lock-Down Applications

Limit Privileges

The Principle Of Least Privilege is the idea that any process, program, or user must only be allowed access to the resources that are necessary for the tasks they need to carry out. For non-technical users this means using a normal, non-admin account with access only to the resources needed for the user’s job. For technical users this means using a non-admin account by default and elevating privileges as needed with a separate local admin account.

This is often enough to protect against malware infection; however, some ransomware variants are able to run even when using an account with limited privileges. Despite this, using a non-admin account by default is critical because it’s necessary for properly implementing application whitelisting.

Application Whitelisting

One of the most effective defenses against malware infection is application whitelisting. The basic idea is that all applications are blocked from running by default except for specific applications.

Many attempt to defend their network by blacklisting executables running from certain locations (such as the AppData directory) but the job of maintaining the blacklist is never-ending. It also means that you are vulnerable when encountering a new ransomware variant that uses a non-blacklisted location. A whitelist can potentially cause extra work if users need a wide range of applications but it guarantees safety compared to the blacklist approach. Typically once a whitelist is properly set up there is little work needed to maintain it.

A common way to implement application whitelisting is by using AppLocker though it requires an enterprise edition of Windows. Those not using an enterprise edition of Windows can implement it with Software Restriction Policies (SRP) in Group Policy.

Whitelisting via SRP is accomplished by blacklisting all locations with the exception of those requiring admin privileges to write to and other needed locations. There is also the option of whitelisting the hash of an executable instead of the location. This is preferable because it guarantees only the specific executable you’d like to run is allowed, avoiding the possibility of malware overwriting a whitelisted file path that doesn’t require admin privileges to write to. It also allows executables matching a whitelisted hash to run from any location. This is a good guide for setting up whitelisting with SRP.

Decrease Attack Surface

Install Security Updates

This is pretty self-explanatory. Install security updates for your operating system and applications as soon as possible. In particular, updates for Windows, Adobe products (Flash, Reader, Acrobat), and Java should be top priorities.

Improve Microsoft Office Security

A common attack vector is Microsoft Office documents containing macros. By default macros won’t run but the user is notified with the option to enable them so it’s a good idea to lockdown macro execution through group policy. There’s an option to disable all macros without notification or to disable all macros except for those that are digitally signed.

There are other Office security improvements worth consideration as well. For those using Office 2016 Microsoft is adding further management options to block macros in documents originating from the Internet.

Block Website Ads

Lately there has been a large controversy about whether people should block website advertisements or not. The fact of the matter is that ads are a popular attack vector, especially as of late. Because of this blocking ads are an important self-defense measure.

One approach is to block ads at the perimeter of the network using a capable router/firewall or UTM device. Something to keep in mind is that most traffic nowadays occurs over HTTPs, which means that it’s encrypted and unable to be inspected. The only way to inspect this traffic for ad-blocking purposes is to deploy digital certificates on all clients, essentially acting as a man-in-the-middle. There may be legal or privacy concerns to consider before implementing this.

Another approach is to block ads at each endpoint using a browser extension or similar solution. Group policy can be used to deploy the browser extension and settings. There’s less centralized control using this approach but blocking ads at each endpoint obviates the need to act as a man-in-the-middle to inspect HTTPs traffic.

Final Thoughts

Keep in mind there is no such thing as 100% security. Security should be approached with a defense in depth mindset, using as many defense measures as possible. The suggestions mentioned above are just a subset of possible defenses to implement but, despite being very basic, they are some of the most effective.

SSH is a common way to remotely control, or transfer data between, computers. It is a much more secure method compared to alternatives, such as Telnet, which transmit data in plain text. However, there are a few SSH server settings that can be improved. Below are a few changes to get you started.

Create and Upload SSH Key

First, we’ll create an SSH key pair. It’s important to do this now because we’ll be updating the SSH config on the server to only allow us to connect via key-based authentication. The public key will be uploaded to the server while the private key will exist only on the local machine. These should be backed up and it’s important to protect the private key. The public key will be added to the remote server and allow us to log in as a user called “remoteuser” on the server. Replace “host” with the hostname or IP address of the server.

To create a new key:

ssh-keygen -t ed25519

To upload public key to server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub remoteuser@host

Edit Or Add The Following Settings

Open the SSH server configuration file (/etc/ssh/sshd_config) in your editor of choice.

Port port_number

Replace port_number with your desired port number. Port numbers from 1024 to 65535 are usually a safe bet, just make sure it’s not already in use by another service. SSH typically runs on port 22, but selecting a custom port will make it more difficult for someone to gain unauthorized access to your server. This is considered security through obscurity and, while not helpful on its own, it is useful in the context of being one of many layers of security.

Note: In the future you will need to supply your chosen port number when connecting via SSH.

Protocol 2

Most current installations should be using version 2 of the SSH protocol by default, but if it’s set to version 1 update it. Version 2 offers much better security so there is no reason to use version 1.

PermitRootLogin no

Setting PermitRootLogin to no ensures that no one can login remotely as root. Normal users can use sudo to gain root level access when needed instead of logging in as root (this also provides the benefit of better system change auditing).

AllowUsers remoteuser

With AllowUsers you can specify which users are allowed to authenticate remotely. Change user_name to the name of any user you’d like to allow remote access. It’s best to limit access to only the absolutely necessary users.

PermitEmptyPasswords no

Setting PermitEmptyPasswords to no ensures that a user with a blank password cannot remotely login. We will not be using password authentication but there’s no reason to have this setting enabled.

PasswordAuthentication no

Setting PasswordAuthentication to no ensures that no one can login remotely with a password. Instead we will be using key-based authentication. This will prevent someone from having the opportunity to gain access by brute forcing your password.

HostbasedAuthentication no

Unless you need to use host-based authentication, disable it and rely on key-based authentication.

UseDNS no

The UseDNS option specifies whether the server should look up the remote host name when someone connects via SSH and verify that the resolved host name for the remote IP address maps to the same IP address. Leaving this option enabled will only generate a warning in the logs if the remote client’s DNS cannot be resolved, it doesn’t actually prevent an attack. Disabling this can provide improved server performance when logging in.

Wrapping Up

With these changes we’ve restricted the authentication methods that the server will accept and restricted the users that are allowed remote access. These changes also improve other security measures as well as server performance. There are other changes that can provide further improvements but these make for a good start.

To ensure any changes made take effect immediately, run the following command in the terminal:

sudo systemctl restart ssh