Sophos Anti-Virus for Linux and UNIX: Changes to supported platforms


Announced 30 June 2017 – As part of Sophos’ ongoing product lifecycle review process, we plan to update the platforms that are supported by the Sophos Anti-Virus for Linux and UNIX offerings. The changes are designed to enable Sophos to provide the strongest protection for the most popular platforms, and will affect the following:

The following sections are covered:

Applies to the following Sophos products and versions

Central Managed Threat Response [MTR] for Linux


The number of customers requiring Anti-Virus capabilities for legacy UNIX platforms continues to decline. Sophos plans to support the most popular platforms going forward, and plans to retire support for HP-UX.


The latest versions of many popular Linux distributions are now only available for 64-bit platforms. After June 30, 2018, with the exception of Red Hat Enterprise Linux 6, Sophos Anti-Virus for Linux will support 64-bit versions of Linux distributions only.

Update July 1, 2018: In line with previous communications, Sophos Anti-Virus for Linux now supports 64-bit platforms only, with the exception of Red Hat Enterprise 6.


The Sophos Anti-Virus for Linux agent currently includes a large number of pre-compiled Talpa Binary Packs for on-access scanning, many of which are for very old and deprecated kernel versions. Most customers use newer kernels in order to benefit from kernel enhancements and improved security, therefore Sophos plans to reduce the number of pre-compiled Talpa Binary Packs that are provided with the product.

  • When a new kernel version is introduced for a specific Linux distribution, Sophos typically aims to provide a Talpa Binary Pack for the new kernel version within approximately two to four weeks.
  • After June 2018, Talpa Binary Packs for kernel versions that are older than 18 months for that Linux distribution will be removed from the agent download. Update: This change is now scheduled for release October 22, 2018.
  • Talpa Binary Packs for kernel versions that are older than 18 months for that Linux distribution will be removed from the agent download.
  • Sophos will continue to provide Talpa Binary Packs for all kernel versions for supported Red Hat Enterprise Linux 6/7 distributions.

  • A definitive list of kernel versions for which Talpa Binary Packs are provided will continue to be published and updated on a regular basis. See TalpaBinaryPacks.txt for the current list. Note: this list is updated automatically when Talpa Binary Packs are added and removed.
  • Existing Sophos Anti-Virus for Linux installations will not be affected by this change. Talpa on-access scanning will continue to function without interruption and Sophos will continue to support customers using the product.
  • If on-access scanning is required and Sophos does not provide a pre-compiled Talpa Binary Pack for your kernel, the following options are available:

Related:

Sophos Anti-virus for UNIX: Migrating a protected UNIX server managed by Sophos Enterprise Console to a Standalone (unmanaged) implementation

This article provides details on how to migrate a Sophos Enterprise Console (SEC) managed UNIX server to a Standalone implementation.

Note: This command is irreversible. To re-register the UNIX server to Sophos Enterprise Console after running this command, you will need to re-install Sophos Anti-virus.

The following sections are covered:

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

Enterprise Console 5.5.0

Enterprise Console 5.5.1

Sophos Anti-Virus for Unix version 9.15.x

Operating systems

Solaris SPARC, Solaris Intel, HP-UX and AIX running Sophos Anti-Virus version 9.15.x

Support for SEC-management of UNIX servers is due to end after 31 December 2019. Sophos will continue to support standalone deployments of Sophos Anti-virus for UNIX after this date. See Sophos Anti-Virus for Linux and UNIX: Changes to supported platforms.

Sophos recommends customers migrate SEC-managed Sophos Anti-virus for UNIX deployments to standalone configurations before December 2019.

In a SEC-managed configuration, the UNIX server receives updates and policy changes from the Sophos Enterprise Console (SEC) and reports any detected threats back to the console. After migration to a standalone configuration, SEC will not receive any alerts or events and the SEC entry for the UNIX server will display the machine as inactive. The UNIX server will continue to receive updates from the Central Installation Directories (CIDs) on the SEC server, but the Sophos Enterprise Console will no longer manage the updates. If the SEC server is turned off, updates on the standalone UNIX server will stop unless a secondary update source is defined.

In order to obtain alerts for the standalone UNIX server following migration from Sophos Enterprise Console you will need to configure a valid email address.

Actions before migration

Before starting please confirm whether scheduled scans have been created within the Sophos Enterprise Console and named using a double-byte non-ASCII character set. If so, please refer to the notes below for additional actions.

The ability to perform a migration to a standalone implementation is available as a new de-registration command line option with SAV for Unix v9.15.0 and later. After migration all configuration and management tasks for the UNIX server will require the use of the SAV command-line interface. There are some tasks which are simpler to perform on the SEC server before migration, including:

  • Setup all necessary email alerting. Please review the chapter titled Setting up alerts and messages in the Sophos Enterprise Console help guide for details on setting email alerting.

To initiate the migration to a standalone deployment, run the following command on your UNIX server.

Note: This command is irreversible. To re-register the UNIX server to Sophos Enterprise Console after running this command, you will need to re-install Sophos Anti-virus.

# /opt/sophos-av/bin/savdctl deregisterRMS

  • The de-registration process first stops the UNIX server reporting to the Sophos Enterprise Console (SEC) by stopping and removing Sophos’ Remote Management Services(RMS).
  • AutoUpdate is then configured on the standalone server with the update period that was configured in SEC.
  • The update source details are then copied from the Sophos Enterprise Console.
  • Any configured named scans are migrated to the standalone server. The name used to identify the scans is changed slightly from SEC:nameofscan to SEC_nameofscan. This is to help you to distinguish scan configurations that are migrated from SEC, from any newly created scans.
  • The process then migrates the email alert and messaging configurations from the Sophos Enterprise Console to the standalone deployment.
  • The output of the migration can be viewed in /opt/sophos-av/log/deregisterRMS.log

After migration

The entry for the migrated UNIX server is not removed from Sophos Enterprise Console. If required, entries remaining in SEC can be cleaned up after migration by deleting them in the console.

Note: If the UNIX updates are removed from the subscriptions in the Sophos Enterprise Console, then the CID UNIX update location will no longer be updated. This could cause the protection on the migrated standalone UNIX server to become out of date, even if a secondary source is available. In this situation, reconfigure the standalone server with a current and valid update source.

Air Gapped: In an Air Gapped environment, where the UNIX endpoint was receiving updates from a SEC server. The process used to update SEC should continue to include UNIX updates. This will ensure the UNIX server receives updates after moving to a standalone un-managed state.

Additional considerations for non-ASCII character scheduled scans

The deregisterRMS command needs to migrate scheduled scans that have been created within the Sophos Enterprise Console. The command can not process scans named using non-ASCII characters: Running deregisterRMS in C locale will fail.

As a workaround you can either

  1. Change names of scheduled scans only use ASCII characters
  2. OR Run deregisterRMS in a UTF-8 locale (LC_ALL and LANG environment variables)

    for example change environment:

AIX: LANG=JA_JP

HP-UX: LANG=ja_JP.utf8

Solaris: LANG=ja_JP.UTF-8

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:

Sophos Anti-Virus for Linux: How to use the –sec-group parameter with SAV for Linux package creator mkinstpkg

This article explains the usage for the --sec-group parameter with mkinstpkg.

Applies to the following Sophos products and versions

Sophos Anti-Virus for Linux

The --sec-group parameter can be used with the following syntax to put a Linux endpoint newly protected from a deployment package created with mkinstpkg into a pre-defined SEC group:

/opt/sophos-av/update/mkinstpkg --sec-group='<nameofserver><groupname>'

Note: This is case sensitive and must match the path in the Sophos Enterprise Console (SEC) exactly. It must not end in a backslash and must include the management server name.

For example:

/opt/sophos-av/update/mkinstpkg --sec-group='SophosServercomputersAbingdon'

If you prefer not to use the quotes, you can escape each space and backslash as follows

/opt/sophos-av/update/mkinstpkg --sec-group=\<nameofserver>\<groupname>

It should be noted that the endpoint will be seen in each parent and sub-group in the nested group tree. This is as designed as if an endpoint is assigned to a SEC sub-group it is also effectively assigned to the parent group.

Restrictions on characters used in Group names:

Spaces cannot be used to define group names with mkinstpkg. Operators for mkinstkg are stored in a file and spaces are discarded by design. Any UTF-8 characters will work and non-UTF-8 characters may work but we cannot guarantee this.

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:

Install Sophos Anti-Virus with On-access scanning provided by Fanotify and Talpa on-access disabled.

This article describes the steps to install Sophos Anti-Virus with On-access scanning provided by Fanotify and Talpa on-access disabled.

The following sections are covered:

Applies to the following Sophos products and versions

Sophos Anti-Virus for Linux

Sophos Anti-Virus for Linux

Sophos Anti-Virus for Linux

In some environments, it is necessary to install Sophos Anti-Virus for Linux without Talpa on-access scanning starting and for SAV to install with fanotify on-access enabled.

The install commands for this are : –

For a Central managed install:

# ./SophosInstall.sh –disableTalpa –disableFanotify=false

For a Sophos Enterprise Console managed install:

# ./install.sh –disableTalpa –disableFanotify=false

After the install, the configuration options used can be confirmed with:

root@ubuntucl5:/opt/sophos-av/bin# ./savdstatus

Sophos Anti-Virus is active and on-access scanning is running

root@ubuntucl5:/opt/sophos-av/bin# ./savconfig disableFanotify

false

root@ubuntucl5:/opt/sophos-av/bin# ./savconfig disableTalpa

true

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:

  • No Related Posts

Sophos Anti-Virus for Linux: How to incorporate Enterprise console managed SAV for Linux in a master image for systemctl based distributions

This article describes the steps to clone a Linux machine with Sophos Anti-Virus for Linux on-premise (Sophos Enterprise Console) managed.

The following sections are covered:

Applies to the following Sophos products and versions

Sophos Anti-Virus for Linux

Note: All mentioned commands should be running as root.

  1. Prepare Master Image.
  2. Stop the Sophos services and disable them by running the following commands:

    systemctl stop sav-rms

    systemctl stop sav-protect

    systemctl disable sav-rms

    systemctl disable sav-protect

  3. Delete the machine_ID.txt reported to SEC.
  4. rm /opt/sophos-av/engine/machine_ID.txt

  5. Clean up and reset the RMS files by running the following commands.
  6. cd /opt/sophos-av/rms

    cat router.config|sed -e 's/"NotifyClientUpdate"=.*$/"NotifyClientUpdate"=/g' > router.config.new

    cat mrouter.private | cut -d : -f1| sed s/hex// > mrouter.private.new

    cat magent.private | cut -d : -f1| sed s/hex// > magent.private.new

    mv router.config.new router.config

    mv mrouter.private.new mrouter.private

    mv magent.private.new magent.private

  7. Stop the master image.
  8. halt -p

  9. Clone the master image using your virtualization software.
  10. Power on the clone.
  11. Change hostname of the clone.
  12. hostnamectl set-hostname

  13. Edit the hosts file to reflect the changed hostname. In this example, Vi is used. You may use other tools or methods for this task.
  14. vi /etc/hosts

  15. Reboot the clone.
  16. Re enable and start the sav-services on the cloned machines.

systemctl enable sav-rms

systemctl enable sav-protect

systemctl start sav-rms

systemctl start sav-protect

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:

  • No Related Posts