Sophos Anti-Virus for Linux: System requirements

This knowledge base article lists the system requirements of the Sophos Anti-Virus for Linux for Sophos Central, Sophos Enterprise Console and the standalone versions.

The following sections are covered:

Applies to the following Sophos products and versions

Sophos Anti-Virus for Linux

Sophos Anti-Virus for Linux 10

Sophos Anti-Virus for Linux 10 offers additional capabilities which include Malicious Traffic Detection and Sophos Security Heartbeat™ (applies to Central Server Protection license).

Here is the list of its minimum system requirements:

Sophos Anti-Virus for Linux 9

Sophos Anti-Virus for Linux 9 is the only version available for the standalone and Enterprise Console-managed versions.

Here is the list of its minimum system requirements:

  • Supported Distributions (latest minor point or LTS version):
    • Amazon Linux, Amazon Linux 2
    • CentOS 6/7
    • Debian 9, 10
    • Oracle Linux 6/7
    • Red Hat Enterprise 6/7/8
      • Red Hat Enterprise Linux 6 32-bit version supported until Nov 30th 2020
    • SUSE 12/15
    • Ubuntu 16/18 LTS
  • System type:x86_64
  • Free disk space: 1 GB
  • Free Memory: 1 GB
  • Stack sizes: Non-default stack sizes are not supported.
  • Language version: English and Japanese (EUC and UTF-8). Shift JIS and JIS are not supported.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable for us to ensure that we continually strive to give our customers the best information possible.

Related:

Sophos Anti-Virus for Linux: Additional steps required for SAV on Red Hat Enterprise Linux 8

This article provides the additional steps required to install and run Sophos Anti-Virus for Linux on Red Hat Enterprise Linux 8. For both Central and SEC managed environments

Applies to the following Sophos products and versions

Sophos Anti-Virus for Linux

Operating systems

Red Hat Enterprise Linux 8

With the release of Red Hat Enterprise Linux 8, a number of new and tighter security features have been introduced and these have meant some additional steps are required to install and run SAV for Linux.

  1. Set a variable to refer to the SAV install point.

    # INST=/opt/sophos-av

  2. Create a context to label all files in $INST/talpa with the ‘is-kernel-module’ label.



    # semanage fcontext -a -t modules_object_t "$INST/talpa(/.*)?

  3. Set the SELinux Boolean to allow all root processes to load kernel modules. [see note 1]

    # semanage boolean --modify --on domain_kernel_load_modules

  4. Install libnsl for UNC updating to work on SEC managed environments. [see note 2]

    # yum install -y libnsl

  5. Install SAV without starting savd.

    # ./install.sh $INST --autostart=False

  6. Apply the correct labels to $INST/talpa. [see note 3]

    # restorecon -R -v $INST/talpa

  7. Start savd.

# systemctl restart sav-protect

Additional Notes:

  • SAV for Linux requires the ability to load modules to kernel. This is disabled by default in SELinux. The SELinux Boolean option will allow all root processes to load kernel modules. By default SELinux on Red Hat Enterprise Linux 8 prevents daemons from loading kernel modules.

  • The libnsl step is only needed where SAV version 9 is updating via UNC cifs/windows share location.

  • The restorecon command is for restoring SELinux Context of the directory and will need to be done every time SAV is re-installed.
  • If on-access is required with Talpa the for on-access scanning, the following packagers are required

# yum install kernel-devel

# yum group install “development Tools”

# yum install elfutils-libelf-deveplease

Please see compiling Talpa for further details

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable for us to ensure that we continually strive to give our customers the best information possible.

Related:

Sophos Anti-Virus for Linux : Communication with Central Update Server uses HTTPS by default

This article is to advise that Central managed Sophos Anti-Virus (SAV) for Linux will use TLS secure protocol HTTPS to communicate with the configured Update Servers.

The following sections are covered:

Applies to the following Sophos product(s) and version(s)

Sophos Anti-Virus for Linux 9.14.2

Sophos Linux Security 10.4.0

  • Linux (supported Linux platforms)

From version 10.4 and Central managed 9.14.2 of SAV for Linux, SAV will use the secure TLS HTTPS protocol for communicating with the configured Update Server. If an HTTPS connection cannot be established after a 10 minute timeout, it switches back to an HTTP connection automatically.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

Related:

Researchers discover highly stealthy Microsoft Exchange backdoor

An extremely stealthy Microsoft Exchange backdoor can read, modify or block emails going through the compromised mail server and even compose and send new emails.

Microsoft Exchange backdoor

LightNeuron – as the backdoor has been dubbed by ESET researchers – is remotely controlled via emails using steganographic PDF and JPG attachments and is believed to have been used by the Turla cyber espionage group.

About LightNeuron

The LightNeuron backdoor is the first known instance of a backdoor employing a malicious Microsoft Exchange Transport Agent as a persistence mechanism.

“Microsoft Exchange allows extending its functionalities using Transport Agents that can process and modify all email messages going through the mail server. Transport Agents can be created by Microsoft, third-party vendors, or directly within an organization,” the researchers explained.

“The typical events handled by a Transport Agent occur when the mail server sends or receives an email. Before the event is actually executed, the Transport Agents are called and have the possibility to modify or block the email.”

They are usually used for legitimate purposes, but as we can see in this instance they can also be used for malicious ones.

Aside from the Transport Agent, which is dropped in the Exchange folder located in the Program Files folder and registered in the mail server’s configuration, the backdoor also uses a DLL file containing most of the malicious functions needed by the Transport Agent.

As mentioned before, the backdoor can block emails, modify their body, recipient and subject, created a new email, replace attachments, and re-create and re-send the email from the Exchange server to bypass the spam filter.

It can create email and attachment logs, encrypt emails and store then, and parse JPG/PDF attachments and decrypt and execute the commands found in them.

LightNeuron can also be instructed to write and execute files, delete and exfiltrate them, execute processes, disable itself, perform extensive logging (backdoor actions, debug, error, etc.) and perform automatic file exfiltration at a particular time of the day and night.

Microsoft Exchange backdoor

During their investigation, the researchers also noticed alongside LightNeuron the presence of tools like Remote Administration Software, RPC- based malware or .NET web shells targeting Outlook Web Access. By leveraging them, the attackers are able to control other machines on the local network using emails sent to the Exchange server.

Finally, judging by some strings decrypted from the malware samples, they believe its likely that a Linux variant of the malware exists and is used.

“That would not be surprising, given that many organizations have Linux mail servers,” they noted.

About Turla

Turla (aka Snake, aka Uroburos) is believed to be a Russian-speaking group of attackers that is likely state-sponsored. They’ve been active for more than a decade.

Their usual targets are government entities, diplomatic entities, military organizations and defense contractors, regional political organizations and research and education organizations around the world.

Even though LightNeuron dates back to at least 2014, it was discovered and analyzed by security researchers only now because of the previously unseen persistence mechanism, because it is hard to detect at the network level (no standard HTTP(S) communications), and because Turla deploys it only against its most important targets.

“This malware is not highly prevalent in the wild so it was able to stay under the radar for a long period of time,” ESET malware researcher Matthieu Faou told Help Net Security.

“We found LightNeuron while investigating machines already infected with known Turla malware. That’s how we were able to make the link between LightNeuron and Turla.”

The researchers pinpointed two targets hit with the backdoor: a Ministry of Foreign affairs in an Eastern European country and a regional diplomatic organization in the Middle East.

Removing the malware

ESET researchers have released IoCs for companies to check whether they’ve been with the malware, but warned against removing the two malicious files as the first order of business, as this will break Microsoft Exchange and prevent everybody in the organization from sending and receiving emails.

Administrators must first disable the malicious Transport Agents and then move to remove the two malicious files.

“If you do not plan to re-install the mail server, an important last step is to modify the passwords of all accounts that have administrative rights on the compromised server. Otherwise, attackers could access the server again to compromise it again,” they advised.

Related: