Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 2559 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Various failures, one success. Windows and Linux

johnthesoftware

Hi,

I've used the standard EICAR anti-virus test file to check the operation of SophosAV on the following:

Windows XP Home 2002 SP2 Pentium
Windows 7 Enterprise 2009 SP1 Xeon E5430
RedHat Enterprise 5.1 - 2.6.15-53.el5 - gcc 4.1.2 -
Centos (CNServer) - 2.6.18-53.el5 - gcc 4.1.1

The only one that worked as expected was the RedHat installation, detecting the test file both on access and demand.  The XP and Windows 7 installations detected the test file on access. The Centos installation failed on both access and demand.

I was unable to test the on-demand operation of the Windows installations because although I explicitly selected a USB stick to be scanned, both Windows installations insisted on scanning the entire C: drive and I hadn't got the time to see what happened when they had completed.


The XP installation identified a legitimate (I think) file as a piece of 'malware' and refused to complete the scan until it was dealt with (which, because it was legit I didn't want to do).

The Centos installation indicates a problem in its log file 'Unable to load Talpa modules' though both the AV and Web services are running.

It's likely to be as much my ignorance as any shortcoming in the software but I'm running out of ideas.

All the installations are standalone. 

Linux: sav-linux-7-i386.tgz

Windows: savw_97_sa_sfx.exe

Thanks

J

:15199


This thread was automatically locked due to age.
  • 0
    Hi J,

    I have both (stil) XP SP2 and Win7 SP1 and it does work. Did you for on-demand configure and start an immediate scan or request it by right-click? The immediate scan might have been instructed to scan for rootkits.
    The scan rarely refuses to continue - if it does it usually indicates (correctly) some real nasty piece (although in case it is a "fragment" or "left-over" it's not or no longer a real threat). Anyway you shouldn't take this lightly.

    Can't help you with Centos right now, but seraching the knowledgebase for TALPA gives just a few hits - they might at least give you a hint. Could be a compiler issue.

    Christian
    :15203
  • 0

    For Linux:

    Talpa is the file operation interception system; a set of kernel modules. It has to be compiled for the precise kernel it is going to run against. For RHEL 5, which is a supported distribution, we ship compiled Talpa Binary Packs (TBP) for each kernel. For Centos, which isn't a supported distribution, you will need to compile Talpa locally. This is done automatically by Sophos Anti-Virus, but requires: make, gcc & kernel-headers to be installed.

    So you probably need to install kernel headers onto the Centos machine for on-access to work.

    :15209
  • 0

    Hi Douglas

    The windows stuff I've sorted (rootkit scan by default).  Linux is a bit more tricky; the machines I need to install SophosAV on are stripped down versions of Centos for security reasons.  I've succesfully installed Sophos on a full Centos installation and I can confirm that the talpa modules produced are happy to be loaded onto the stripped down version (insmod) but that they are deleted when I try to run the sav daemons.  Is there any way I can fool the installation into accepting these presumably working modules?

    Thanks

    John

    :15233
  • 0

    In the case of a stripped down non-supported distribution the following are possible:

    a) Install gcc,make,kernel-headers - chmod make and gcc so only root can run them.

    b) Chained updating with addition TBP (Talpa Binary Pack): Basically run one machine will build environment updating,

    copy Local Cache Directory to exported location, use addtbp.sh to add a TBP to the exported location (CID); then configure stripped down machine to update from CID. Rember to update TBP every time a new kernel is released, and when Talpa is updated. TBP is located on build machine under <installation>/talpa/compiled/. Support may be able to help you if you want to do this.

    c) Manually copy TBP onto stripped down machine in the <installation>/talpa/override/ directory. Rember to update TBP every time a new kernel is released, and when Talpa is updated. TBP is located on build machine under <installation>/talpa/compiled/ . This is not a supported thing to do long term.

    Option a) is by far the easiest, and most used.

    :15257
  • 0

    Douglas

    c.) Worked for me. Your description is slightly different to information I got from the web;  I had to rename the TBP to match the one expected by the failing installation.  In my case the name 'centos' had to be replaced with 'unknown' and the directory I used was talpa/custom.  I found the solution that worked for me in the troubleshooting section of...

    http://www.sophos.it/support/knowledgebase/article/110767.html

    We will have to come up with some process for keeping Talpa up-to-date.

    Thanks for your quick response.

    John

    :15259
  • 0

    The custom dir is used for the method b) which is described in your linked KBA. It may get overwritten by updates in certain circumstances . 

    The unkown happens because your minimal install has broken lsb_release, so that it isn't reporting the correct vendor/distribution. 

    :15261