I successfully installed avastd on my Ubuntu box. However, it’s not picking anything up even though it appears to be initializing just fine. I popped the EICAR test virus on the box as well as a real virus (albeit defused). Without wanting to debate the merits of AV software of Linux, if anybody has any insight into this I’d really appreciate it.
Thanks!
Here is the avastd.log entry:
Dec 16 16:33:07 avastd[19791]: info: Starting avast! daemon
Dec 16 16:33:07 avastd[19791]: info: using this configuration for section ‘local’
Dec 16 16:33:07 avastd[19791]: info: daemons count: default=3, maximum=5
Dec 16 16:33:07 avastd[19791]: info: avast! interface: /var/run/avast4/local.sock (timeout: 300s)
Dec 16 16:33:07 avastd[19791]: info: user: root
Dec 16 16:33:07 avastd[19791]: info: rootdir: /
Dec 16 16:33:07 avastd[19791]: info: datadir: /var/lib/avast4
Dec 16 16:33:07 avastd[19791]: info: tempdir: /var/tmp/avast4
Dec 16 16:33:07 avastd[19791]: info: licensefile: /var/lib/avast4/License.dat
Dec 16 16:33:07 avastd[19791]: info: workdir: /
Dec 16 16:33:07 avastd[19791]: info: scan subdirectories: yes
Dec 16 16:33:07 avastd[19791]: info: avast! engine flags: testall
Dec 16 16:33:07 avastd[19791]: info: packers: types=A, maxdepth=32, summary archives=no
Dec 16 16:33:07 avastd[19791]: info: packers bombs: maxfilesize=500000, maxcompressratio=50, compresscheckthreshold=10000
Dec 16 16:33:07 avastd[19791]: info: maxtotalcompressratio=100, totalcompresscheckthreshold=1000
Dec 16 16:33:07 avastd[19791]: info: log scan results: logclean loginfected logscanerrors
Dec 16 16:33:07 avastd[19791]: info: listenning on unix socket /var/run/avast4/local.sock
Dec 16 16:33:07 avastd[19791]: info: started new ‘local’ process (pid=19792)
Dec 16 16:33:07 avastd[19791]: info: started new ‘local’ process (pid=19793)
Dec 16 16:33:07 avastd[19791]: info: started new ‘local’ process (pid=19794)
Hallo, avastd is the scanning service. It’s used by its clients (avastlite, avast4mail, avastguard etc.), thus use avastlite (comes with the daemon in its installation package)), for example, as probe. on-access functionality is provided by the avastguard.
Thanks very much for the answer! I will try working with avastlite. But it does lead me to the following question: Given the following excerpt from avastd.conf, is avastd, by itself, really not going to log any infections?
log scan results level :
Default is logging infected files and error scan results.
loginfected = 1
logerrors = 1
logclean = 1
This seems to me that avastd in and by itself would log infected files.
Also, is avastlite on-demand? Basically I am trying to find out how I would need to set up avast to write to /var/log as soon as a virus tries to be written to the file system and not X minutes after the fact, where X is whatever interval I put into a cronjob.
I tried avastlite and it certainly works - but I have to fire it off manually, as expected. Is there a way I can get avastd, or any component that ships with it, log an infection as it occurs, i.e. in real-time? It seems that there is really no reason to have a background resident daemon if all scanning is ultimately on-demand/by cronjob anyway. (Other than provide an API).
Hallo,
i’m not sure what do you mean - probably loggin an infection when it comes to the harddrive OR when it’s opened. that’s on-access scanning, and the component for avastd, doing this job, is avastguard (uses Dazuko kernel interface).
Infection logging is realtime already (the log line is dropped when the scanner/client goes through the infected file).
Ah, I see! OK, thanks again for all your help. Unfortunately I don’t think I’ll be installing avast4guard since it requires me to recomplie the kernel (for dazuko), which I’m frankly not prepared to do right now.
Hallo,
no fear, compiling kernel is quite straightforward and amusing job :). but, there’s also other possibility - tweaked LD_PRELOAD environment, with pre-loaded read/write/open/close hooks. each app, dynamically linked against libc, will be hooked this way (but, unfortunately, statically-linked binaries and even asm-written apps with direct kernel calls, will live happily outside this mechanism).