The threat posed by ransomware such as Locky and other malware has been a hot topic on and off in the media for months now. In a number of cases, including some rather more prominent ones, hackers have managed and continue to manage to infect their victims’ files with malware, which encrypts them to the point where they can no longer be used – the files are only made available again once a “ransom” has been paid. The more accesses the user in question has, the higher the damage: if possible, files on servers in the network are also “captured”.

A great deal has already been written on the topic. At this point, I would like – albeit very subjectively – to introduce a couple of approaches for how to protect yourself against such attacks.

It All Starts With Basic Security: Updates – Access Protection – Virus Scanners

The first logical step in any technical security system is not to offer blackmailers any targets. This is achieved by running updates for operating systems and applications in good time so as to avoid any security vulnerabilities. Where possible, this should be done automatically. (This is also possible on UCS systems by the way.)

In the case of server services, it is practical to consider well in advance who requires access and to restrict the user groups accordingly as well as to install a firewall for restrictions to individual networks. After all, malware acting in a user’s name can only change files to which the user has write access. Being frugal can also help: desktop applications and server services which are not installed also do not require protection.

Virus scanners complement this protection and can intervene at different points: on the mail server (for UCS there are also expansions available in the App Center in addition to the preinstalled ClamAV), on the file server (in Samba via “VFS” module), and, of course, on the client. Working without any virus scanners seems particular negligent in environments with Windows clients, while excessive protection soon results in the users’ frustration at false alarms and poor performance. In addition, the very principle of virus scanners also means that they are always one step behind the viruses: the virus signatures can only be updated once the first victims have succumbed. My personal impression from practical experience is that the combination of one virus engine on the mail server, which remains the primary attack route, and a second one on the desktop systems is an established approach.

Raising Awareness: Informed Users

In many attack situations it is the end user who opens the door for the malware: It can be enough simply to open an e-mail attachment or download a file from the Internet. In some IT departments, the tendency is to suppress the most common attack patterns. As a result, Office documents and zip files attached to mails are rejected or quarantined. However, this approach is not practical in some fields and results in users’ becoming frustrated by the IT department and finding their own, often far riskier ways of exchanging information.

In order to avoid this kind of shadow IT systems, it is important to inform the users of the possible risks from the start. Attachments to mails from unknown sources are suspicious and should make users wary, but a forged e-mail can even find its way into communication with existing contacts. In this respect, effective dialog between the IT department and user is paramount: The IT department should report new threats at eye level and take all questions and requests received from users seriously. Only in this way can users be expected not to perceive the necessary restrictions as nannying.

Damage Limitation

However, even when full attention is paid, you should still be ready for an incident. Once a system becomes infected, files begin to be encrypted and attempt to infect other systems. There are mechanisms available for blocking individual workstations so as not to lose a Samba file server completely (see guide at end). However, these are not triggered until the first files have been “lost”.

Today, probably the most important component of damage limitation is a working, up-to-date backup – on a data carrier which is inaccessible to the infected client. Various apps in the Univention App Center provide the technology for this solution. The IT department in the company needs to discuss what needs to be backed up with the users in advance. It is also essential that this discussion be held at eye level: It is always easier for the IT department to back up the data on the server systems, whereas there are scenarios for the user where he wants to be able to save certain files locally on his end device.

If an incident occurs, the backup can only restore to the point where it was last saved. If in the worst case scenario that was the previous night, a whole day of work may be lost. As such, it is also worth thinking about setting up sensible time cycles for backups. Some cases can be cushioned through the use of automated synchronization and versioning. One of the most popular tools for this is OwnCloud, which can be used for both versioning and the availability of files on user devices. On the classic Samba file server, VFS modules allow comprehensive but also very time-consuming configuration possibilities. In the simplest case, the “recycle” module backs up deleted files for a number of days.

Example Configuration: Blocking of Infected Systems

A client infected with ransomware also attacks network services in order to try to encrypt files there. At this point, a significant action develops: many different files are changed. The files are also often furnished with a new suffix specific to the malware. These actions are detected by the combination of the Samba VFS module “full_audit” and the intrusion detection software “fail2ban” with the result that the accessing client is blocked.

Based on [1], the following steps are necessary on a UCS file server:

Installation of fail2ban

This is done by enabling the “unmaintained” repository [2] and installing the packages: ucr set repository/online/unmaintained='yes' univention-install fail2ban Global configuration of the “full_audit” Samba module

The primary parameters of the module are stored in the Samba configuration. This can be done using UCR variables: ucr set 'samba/global/options/full_audit:failure=none' \ 'samba/global/options/full_audit:success=pwrite write rename' \ 'samba/global/options/full_audit:prefix=IP=%I|USER=%u|MACHINE=%m|VOLUME=%S' \ 'samba/global/options/full_audit:facility=local7' \ 'samba/global/options/full_audit:priority=NOTICE' Configuration of fail2ban

As described in [1], the filter settings and the reaction to them (blocking of client and sending of notification) are configured in the configuration files /etc/fail2ban/filter.d/samba.conf und /etc/fail2ban/jail.conf . The service is then restarted via “service fail2ban restart” for the configuration to be adopted. Configuration of the network shares

In the Univention Management Console, the “full_audit”module is entered under “VFS objects” on the “samba” tab for every file share to be monitored. The audit is then enabled for this share.

It is important to remember that this protection can always only be as good or bad as the description of the “patterns” in /etc/fail2ban/filter.d/samba.conf. If the list is too restrictive, unaffected users may be blocked; if is it outdated, it may not intervene in new scenarios. As an introduction, here is an example for this file based on file suffixes for current ransomware documented in [3][4].

[Definition] failregex = (?i)smbd.*IP=<HOST>.*\.locky$ (?i)smbd.*IP=<HOST>.*\.ecc$ smbd.*IP=<HOST>.*\ 文件解密帮助 .txt$ (?i)smbd.*IP=<HOST>.*\.enigma$ (?i)smbd.*IP=<HOST>.*\.ecc$ (?i)smbd.*IP=<HOST>.*\.ezz$ (?i)smbd.*IP=<HOST>.*\.ecc$ (?i)smbd.*IP=<HOST>.*\.exx$ (?i)smbd.*IP=<HOST>.*\.zzz$ (?i)smbd.*IP=<HOST>.*\.xyz$ (?i)smbd.*IP=<HOST>.*\.aaa$ (?i)smbd.*IP=<HOST>.*\.abc$ (?i)smbd.*IP=<HOST>.*\.ccc$ (?i)smbd.*IP=<HOST>.*\.vvv$ (?i)smbd.*IP=<HOST>.*\.xxx$ (?i)smbd.*IP=<HOST>.*\.ttt$ (?i)smbd.*IP=<HOST>.*\.micro$ (?i)smbd.*IP=<HOST>.*\.encrypted$ (?i)smbd.*IP=<HOST>.*\.crypt$ (?i)smbd.*IP=<HOST>.*\.crypted$ (?i)smbd.*IP=<HOST>.*\.crypto$ (?i)smbd.*IP=<HOST>.*\._crypt$ (?i)smbd.*IP=<HOST>.*\.zcrypt$ (?i)smbd.*IP=<HOST>.*\.locked$ (?i)smbd.*IP=<HOST>.*\.crinf$ (?i)smbd.*IP=<HOST>.*\.r5a$ (?i)smbd.*IP=<HOST>.*\.XRNT$ (?i)smbd.*IP=<HOST>.*\.XTBL$ (?i)smbd.*IP=<HOST>.*\.R16M01D05$ (?i)smbd.*IP=<HOST>.*\.pzdc$ (?i)smbd.*IP=<HOST>.*\.good$ (?i)smbd.*IP=<HOST>.*\.LOL!$ (?i)smbd.*IP=<HOST>.*\.OMG!$ (?i)smbd.*IP=<HOST>.*\.RDM$ (?i)smbd.*IP=<HOST>.*\.RRK$ (?i)smbd.*IP=<HOST>.*\.encryptedRSA$ (?i)smbd.*IP=<HOST>.*\.crjoker$ (?i)smbd.*IP=<HOST>.*\.EnCiPhErEd$ (?i)smbd.*IP=<HOST>.*\.LeChiffre$ (?i)smbd.*IP=<HOST>.*\.keybtc@inbox_com$ (?i)smbd.*IP=<HOST>.*\.0x0$ (?i)smbd.*IP=<HOST>.*\.porno$ (?i)smbd.*IP=<HOST>.*\.bleep$ (?i)smbd.*IP=<HOST>.*\.1999$ (?i)smbd.*IP=<HOST>.*\.vault$ (?i)smbd.*IP=<HOST>.*\.HA3$ (?i)smbd.*IP=<HOST>.*\.toxcrypt$ (?i)smbd.*IP=<HOST>.*\.magic$ (?i)smbd.*IP=<HOST>.*\.SUPERCRYPT$ (?i)smbd.*IP=<HOST>.*\.CTBL$ (?i)smbd.*IP=<HOST>.*\.CTB2$ (?i)smbd.*IP=<HOST>.*\.[0-9]*$ ignoreregex =

Summary: The Vital Compromise

As is the case in most security matters, the key to fending off ransomware lies in finding a compromise between efforts, restrictions, and risks which suits your individual environment. Those who implement the “communication with the users”, “functioning backup”, and “up-to-date virus protection” components, which are fundamental requirements irrespective of this particular threat, are largely protected from the worst threats.

[1] Heise article about the configuration of „fail2ban” (German)

[2] Information on „unmaintained“ repository (UCS manual)

[3] The Week In Ransomware at bleepingcomputer.com

[4] List of ransomware extensions and known ransom files created by Crypto malware at reddit.com