After going through two different vendors, this year I finally decided to try Symantec Endpoint Protection Small Business Edition, v. 12. I'm a convert. Incredibly lightweight, responsive, and... cost effective. As in, under $15 a seat cost effective. I love it.
Never bothered with their Linux version, even though it was included with my purchase. ClamAV has been doing just fine for us for years, thank you.
Until last month. For some reason - I assume the definition file - ClamAV is now taking forever to make a scan:
Data scanned: 803.16 MB
Data read: 240.92 MB (ratio 3.33:1)
Time: 8035.814 sec (133 m 55 s)
100K a second? Let's see, to scan our home directory would take... about a week.
So, easy solution - I've got plenty of SEP licences left; it runs on Linux; it's very easy to administer on Windows - I'll just install SEP on my Linux boxes!
Well, as easy as the Windows install/administration was, the Linux install is that complex. First of all, the Linux download is hard to find. Once I had it I wanted to set up a local LiveUpdate server on the Windows box. Easy enough. Then, I had to point the Linux server towards the LiveUpdate server. That's when things got crazy.
The docs say that you should change the server name in /etc/liveupdate.conf, but there are at least two documented ways of doing so. In addition, they changed the port from 8080 to 7070 in the most recent LiveUpdate Administration release. So I got all of that sorted out in the file, ran liveupdate... and nothing happened.
Well, something happened, actually:
Command failed: Failure in pre processing of micro definitions before update.
Unable to perform update
and the /etc/liveupdate.conf file was nulled out.
After a couple of days of back-and-forth with Symantec (Linux? What's that?), I finally found someone who gave me this link:
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008050713154648
Cause:
Once executed, JLU reads the contents of the unencrypted liveupdate.conf file, runs LiveUpdate, and then encrypts the liveupdate.conf file to prevent tampering. The encryption level used is above the maximum encryption level allowed by default in Sun Java. JLU requires the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files be applied to the version of Java being used to execute JLU.
Solution:
To allow JLU to properly encrypt the liveupdate.conf file, you must apply the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files to the installation of Java being used to execute JLU.
Ah. I need super-secret crypto, available only to true believers. So I went to Sun, eventually found the
Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files, downloaded them and replaced the on my system. It consists of two files, local_policy.jar and US_export_policy.jar. Replaced the files on my system with those, made a mental note not to ever let these machines leave the country, and...
Still didn't work. Crud.
OK, one more tech request. They sent me to this link on 'Configuring JavaLiveUpdate':
http://service1.symantec.com/support/ent-security.nsf/docid/2006021007250213
which was wrong in an interesting way. The table it's got is off by one row - the 'Parameter' column lines up with the 'Description' of the row above it.
But it did give me a hint - it pointed me to a Liveupdt.hst file. I'd seen this before on the Windows side; the LiveUpdate Administration docs told me how to generate this file, but not what to do with it. This seemed to imply that I pointed 'hostfile=' to it. So I generated it on the Windows side (Configure/Client Settings/Export Java Settings), moved it over, and put it into my /etc/liveupdate.conf file, which now reads:
hostfile=/opt/Symantec/symantec_antivirus/liveupdt.hst
logfile=/var/log/symantec/liveupdt.log
Hah! That worked!
And it's slightly faster. That 133-minute clamav scan finished in just under 8 minutes.
Sheesh. But worth it, I think.
Posts
Thank you for the very helpful article. I have a few questions, hopefully not too dumb as I just started trying to install this this afternoon.
ReplyDeleteYou say you "replaced" the policy jar files. You already had files of the same name somewhere? I did not. I put them in /usr/share/java and also in the LiveUpdate dir but liveupdate still complains "Command failed: Problem with LiveUpdate. Check that java directory is in PATH"
I made sure /usr/share/java was in PATH. I edited liveupdate.conf to have the dir to the LiveUpdate path, and then to jle.jar but none of that helped.
I checked Symantec's website and found one person struggling with the 0 byte problem and a tech support person and a trusted adviser pointing him in the wrong direction so I posted a link to your blog :)
Would the liveupdy.hst file fix my problem? I don't have this installed on windows anywhere but I could do so.
Thanks in advance and have a great weekend.
Seth -
ReplyDeleteI already had the jar files existing. But the one thing you might try - they released 1.0.9 for Linux last week, and I installed it - and it seems to have helped.
Of course, that may be because I've already gone through hell on the first install... :)
I was using that version already.
ReplyDeleteI started over from scratch, downloaded a JRE bin from sun instead of using apt-get, installed it, replaced the jar files (they existed this time), then installed SAV, but when I ran the liveupdate it didn't run. I played with that conf file but when liveupdate ran it would give me java errors. I thought about that hostfile you mentioned but decided to work on something else first.
Well, later on after rebooting the machine I looked through the logs and saw that it's been updating itself.
So, um, yay?
Now if I could just get it to report when a manualscan finds a virus, or report when the file is clean. I did find some logs hidden in /var/symantec/Logs but setting rtvscand to log debug messages does nothing at all
>> Now if I could just get it to report when a manualscan finds a virus
ReplyDeleteI do this, immediately after the manual scan:
/opt/Symantec/symantec_antivirus/sav quarantine -l
to tell me what's in the quarantine. Full script looks like this:
#! /bin/bash
# set -x
ECHO="/bin/echo -e"
SAVDIR="/opt/Symantec/symantec_antivirus"
SAV="/opt/Symantec/symantec_antivirus/sav"
SUBJ="$(hostname -s) : Error from $(basename $0)"
MAIL="/bin/mailx"
HOST="$(hostname -s)"
OPT="$*"
if [ "$OPT" = "" ]
then
OPT="q"
else
OPT="v"
fi
if ! test -d $SAVDIR; then
$ECHO "SAV directory failed!"|$MAIL -s "$SUBJ" root
exit 1
fi
if ! test -f $SAV; then
$ECHO "sav file failed!"|$MAIL -s "$SUBJ" root
exit 1
fi
$ECHO "\nBegin SBE update at " `date` "\n"
cd $SAVDIR
/usr/bin/wget -"$OPT" \
ftp://ftp.symantec.com/AVDEFS/symantec_antivirus_corp/static/symcdefs-unix.sh \
||{ $ECHO "wget failed"|$MAIL -s "$SUBJ" root;exit 1; }
chmod 755 symcdefs-unix.sh
./symcdefs-unix.sh
/etc/init.d/rtvscand restart
$ECHO "\nBegin SBE scan at " `date` "\n"
$ECHO "\nSBE info:\n"
$ECHO "Version "`$SAV info -p`", "`$SAV info -d`
$ECHO "\nBegin SBE scan at " `date` "\n"
DIRLIST="/root /tmp /misc /var/tmp /var/spool/mqueue /var/mail \
/var/spool/clientmqueue /bin /usr/bin /usr/local/bin /sbin \
/usr/sbin /usr/local/sbin /boot"
ACTIVEDIR=""
for DIR in $DIRLIST; do
if [ -d "$DIR" ]; then
ACTIVEDIR="$ACTIVEDIR"" $DIR"
fi
done
$SAV manualscan --clscan $ACTIVEDIR
QFILES=`$SAV quarantine -l`
if [ "$QFILES" ]; then
$ECHO "SAV has files in quarantine:\n\n$QFILES"|$MAIL -s "$SUBJ" root
$ECHO "\nSBE quarantined files:\n\n$QFILES"
fi
$ECHO "\nEnd scan at " `date` "\n"
/bin/rm -f symcdefs-unix.sh
exit 0
Has anyone found a way to use Liveupdate on a Linux box while pointing to an internal Liveupdate server via the liveupdate.conf file, without it encypting the file? I have an internal liveupdate server that is setup and working correctly but because of the encryption process on the first run of java liveupdate which is failing,I have to keep providing a custom liveupdate.conf. Even setting liveupdate.conf to point to the exported liveupdt.hst from the liveupdate server, doesn't work. I'm hoping there is an (undocumented?!) option I can put in the /etc/liveupdate.conf file to make liveupdate not encrypt the settings when it runs. This would solve two problems since the linux boxes I am installing SAV for linux on are under heavy government regulation and making any changes to them is very difficult. Unfortunately they absolutely must have SAV for linux installed though. Manually installing the antivirus .JDB file is not really a practical solution either.
ReplyDeleteJohn -
ReplyDeleteI don't think there's any way - it'll fail unless you have the Unlimited Strength java extension installed.
I feel your pain on the government servers - I just started a job with the OPM in Boyers, PA.
After a fairly extensive amount of research and a lucky roll of the dice, I was able to get a Linux client to update via our local SEPM by modifying /etc/liveupdate.conf. I didn't have to mess with a liveupdt.hst file or JCE.
ReplyDeleteWhat I _did_ need to do was (1) use LUAdmin to find out the URL for our update server (listed in the client config section), (2) change the "hosts/0" entry in liveupdate.conf to match that URL, e.g. "hosts/0/http://my.update.server:7070/virtualpath", and (3) remove the other "hosts/" entries.
That's all I needed to be able to use the applet in the system tray to update.
@Tim: You didn't want to use Symantec, so you used Symantec?
Gee, that didn't come out like I meant, did it? Let's try 'After three years of futzing around with two other solutions, I finally gave up and went back to the dark side', or something like that...
ReplyDelete