ClamAV - pomalost, daemon mod (delší)

Středa Květen 11 08:52:10 CEST 2005

Přeji krásný den !

Mám dotaz ohledně virové kontroly pošty. Ve firmě používáme inflex + 
f-prot. Funguje to dobře, ale stává se, že přes f-prot občas něco 
proklouzne. Zkusil jsem do příslušných skriptů přidat ještě "nezávislý 
pohled", tedy oskenování antivirem ClamAV, ale nedopadlo to dobře. Za 
chvíli se zvedl load na hodnoty přes 100 (chvílemi i skoro 200) a server 
nestíhal odbavovat poštu. Sice je tu docela "frmol" (řádově cca tisíce 
mailů denně), ale dříve používané řešení (inflex + f-prot) v pohodě 
stíhalo - load je cca 0,2 - 0,5.

Zkusil jsem to prozkoumat blíž a zjistil jsem, že oproti f-prot-u je 
clamav _pekelně_ pomalý. Například zde je výsledek skenu jednoho ZIP 
souboru o velikosti 80620B :

a) F-PROT
=========
# time /usr/local/f-prot_4.5.4/f-prot -archive -server -old -dumb *
Virus scanning report  -  11 May 2005 @ 8:01

F-PROT ANTIVIRUS
Program version: 4.5.4
Engine version: 3.16.6

VIRUS SIGNATURE FILES
SIGN.DEF created 9 May 2005
SIGN2.DEF created 9 May 2005
MACRO.DEF created 7 May 2005

Search: 
screensaver______________________________________________________.zip
Action: Report only
Files: "Dumb" scan of all files
Switches: -ARCHIVE -PACKED -SERVER -OLD

Results of virus scanning:

Files: 1
MBRs: 0
Boot sectors: 0
Objects scanned: 2

Time: 0:00

No viruses or suspicious files/boot sectors were found.
0.23user 0.04system 0:00.26elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (217major+1252minor)pagefaults 0swaps

b) ClamAV
=========
# time /usr/local/bin/clamscan --stdout --tempdir=/tmp --unzip --unrar 
--arj --unzoo --lha --jar --tar --deb --tgz *
/var/Dblok/SblokBinf_2005051018324497/unpacked/q/screensaver______________________________________________________.zip: 
Trojan.W32.PWS.Prostor.A FOUND

----------- SCAN SUMMARY -----------
Known viruses: 34344
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.20 MB
I/O buffer size: 131072 bytes
Time: 2.692 sec (0 m 2 s)
Command exited with non-zero status 1
1.57user 0.16system 0:02.74elapsed 63%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2048major+1986minor)pagefaults 0swaps

Rozdíly jsou patrné na první pohled - kromě toho, že f-prot nic nenašel 
(a Clam ano) je taky zřejmé, že je Clam 2,692/0,23 ~ 11x pomalejší. 
Kromě toho průchodnost ClamAV je podle těchto hodnot (80 kB za 2,7 sec) 
necelých 30 kB/s (tedy cca 240 kb/s), což je na lince 4Mb/s docela málo. 
Sice se nedá předpokládat, že by se celá linka vytížila přijímáním 
mailů, ale vyloučit se to krátkodobě nedá...

Je taková "rychlost" ClamAV (oproti komerčním antivirům) normální ? 
Chápu že bude mít jiné parametry, ale proč o tolik ?!?
Na problematickém serveru je přitom IMHO obstojně výkonné železo - 
PIII660/256MB.

Je tato pomalost způsobená i zastaralostí systému ? Jde o stařičký 
RH6.2, do kterého jsem dostal ClamAV "násilím" - vyšel jsem z .src.rpm 
balíku, ve kterém jsem zakázal závislosti a v configure skriptu jsem 
povypínal co se dalo. Nakonec se většina částí přeložila a skener je 
funkční, ale byl by výrazně rychlejší kdyby se překládal s nejnovějšími 
verzemi knohoven, na kterých je původně závislý ?

Nemáte nějaké tipy jak rychlost skenování a celkovou propustnost zvýšit 
(kromě nápadu na povýšení HW na dual P4/3 GHz, což by sice mohl pomoci, 
ale bylo by to neprůchodné).

Další výkonotní problém může být i v tom, že se pro každé skenování 
zavádí clamav znovu. Bohužel nejde zprovoznit daemon mod, protože jeho 
kompilace hlásí chyby :
# cd usr/src/redhat/BUILD/clamav-0.83/clamd
# make
....
source='dazukoio.c' object='dazukoio.o' libtool=no \
depfile='.deps/dazukoio.Po' tmpdepfile='.deps/dazukoio.TPo' \
depmode=gcc /bin/sh ../depcomp \
i386-redhat-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../shared 
-I../libclamav    -O2 -m486 -fno-strength-reduce -c dazukoio.c
/bin/sh ../libtool --mode=link i386-redhat-linux-gcc  -O2 -m486 
-fno-strength-reduce  -lnsl -o clamd  output.o cfgparser.o getopt.o 
memory.o misc.o options.o clamd.o tcpserver.o localserver.o session.o 
thrmgr.o server-th.o scanner.o others.o clamuko.o dazukoio_compat12.o 
dazukoio.o  ../libclamav/libclamav.la  -lnsl -lpthread
libtool: ltconfig version `' does not match ltmain.sh version `1.3.4'
Fatal configuration error.  See the libtool docs for more information.
make: *** [clamd] Error 1

Moc se v tom stroji vrtat nemůžu - běží přes něj poštovní komunikace 
nejenom naše, ale i spřízněných firem, a jsme na něm závislí.

A kromě toho se "daemon mod" nechová tak jak bych očekával - původně 
jsem myslel, že když poběží po síti přes TCP, tak že může být ClamAV 
klient na jiném stroji než daemon. Ale ono to tak není - ukázka z strace 
clamdscan z jiného stroje (klient požadující sken od daemona přes TCP) :

...
connect(4, {sa_family=AF_INET, sin_port=htons(3310), 
sin_addr=inet_addr("192.168.17.70")}, 16) = 0
write(4, "CONTSCAN /tmp/eicar.com", 23) = 23
dup(4)                                  = 6
fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
fstat64(6, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb7fff000
_llseek(6, 0, 0xbfe21514, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
read(6, "/tmp/eicar.com: Eicar-Test-Signa"..., 1024) = 43
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 12), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb7ffe000
write(1, "/tmp/eicar.com: Eicar-Test-Signa"..., 43/tmp/eicar.com: 
Eicar-Test-Signature FOUND
) = 43

Takže rezidentní skener je požádán, aby prohlédl soubor "CONTSCAN 
/tmp/eicar.com" a cesta se předává _lokálně_. Stejně tak se chová i když 
je klient na jiném stroji. Původně jsem myslel, že si po síti předají 
zkoumaná data a zpět pak výsledek skenu - byl to můj mylný předpoklad 
nebo se ClamAV v deamon modu chová neobvykle ?

Předem děkuji za vaše názory / tipy.

Miroslav BENEŠ
System administrator
ŽĎAS a.s.