This update includes support for the kernel level anti-malware and anti-virus module, dazuko. Th Dazuko implements scanning and blocking in real-time on file open, close, access, or execution events. Aside from being considerably faster, this feature is intended to cover alternate conditions where malware is added to the system over SSH and other file sharing methods (NFS, GFS, SMB, etc). It will require the addition of the kernel kmod-dazuko/kmod-dazuko-PAE rpms to the system. An additional ASL configuration setting "CLAMAV_ENABLE_DAZUKO" will need to be set to "yes". As of this release graphical integration is planned for ASL Web in the next release.

This feature will require configuring two optional files:

/etc/asl/dazuko-include, a list of directories or filesystems to monitor with dazuko (note: dont use /! Its both not necessary on a Linux system and will break things, scanning /proc for example will break your system)
/etc/asl/dazuko-exclude, a list of directories to exclude from monitoring (/var/spool/qscan for example)

Files identified as malware will return a permission denied message when someone tries to open them.

Two additional template files have been added to this update:
/var/asl/data/templates/template-clamd.conf
/var/asl/data/templates/template-freshclam.conf

Changelog:
[+] Support for Plesk 9.5
[+] Added support for the dazuko anti-spam kernel module
[+] Added detection for different userid environments for clamd (qscand, clamav, root)
[+] Added new template files, template-clamd.conf, and template-freshclam.conf
[+] Added init script for the asl-av (dazuko) module
[+] Added support to the OSSEC updater to manage decoder.xml
[+] Added support to manage the psa-proftpd user
[+] Added some feedback to the user that clamav is restarting when it takes a long time
[+] Added requires on vixie-cron for el4/el5 environments
[+] Added diagnostic utility for support
[+] Added WAF output redactor (MODSEC_99_REDACTOR)
[+] Added vulnerability check for Active Response mode being disabled
[+] Added requires on denyhosts 2.4-24+, ossec 2.4.1-4+, and conflicts on psa-proftp older than 1.3.3
[+] Added sysctl disabling fuctionality to asl-mod, this is tied to the ALLOW_kmod_loading token.
[+] Enabled safebrowsing by default in freshclam template
[+] Feature Request #144, fix events that effect OSSEC will no longer reload/purge the active response list
[+] Feature Request #327, RKHUNTER_SSH_ROOT_LOGIN has been deprecated, this check is always enabled
[=] core ASL package upgrades will now force asl -s -f at the next available monitor event (hourly normally)
[=] duplicate entries in whitelists will now be ignored.
[=] Extended mysql 5.1 detection for plesk environments
[=] Expanded deprecation module for denyhosts
[=] general_check services are now sorted by default, removed a duplicate gpm check
[=] rkhunter_check will now disable app scan checks by default

Bugfixes:
[-] Bugfix #XXX, removed a duplicate ASL kernel detection message
[-] Bugfix #XXX, for asl_user creation events
[-] Bugfix #XXX, fix for detecting the mysql version in a non-psa environment
[-] Bugfix #XXX, corrected a condition where disabled_modules would be attempted when the device did not exist.
[-] Bugfix #XXX, other half of the "too many files" error from psa-proftpd.
[-] Bugfix #311, psa_check will now correct a deprecated setting in psa-proftpd (Scoreboard) that would break session tracking
[-] Bugfix #324, corrects a condition where non-modsecurity 403 errors are defined as "undefined"
[-] Bugfix #344, detect proftp-tls/proftp-asl file contents and replace them if they are 0 length.

To Upgrade:
Step 1) yum upgrade asl asl-web

Step 2) yum install mod_sed


Optional: To use dazuko (ASL Kernel is required, 2.6.32.8 recommended)
Step 1)
(32 bit):
yum install kmod-dazuko

for 32-bit PAE:
yum install kmod-dazuko-PAE

for 64-bit:
yum install kmod-dazuko

Step 2) Upgrade ASL
yum upgrade asl asl-web

Step 3) Edit /etc/asl/dazuko-include, add directories to monitor
vim /etc/asl/dazuko-include
/home
/var/tmp

Step 4) Set "CLAMAV_ENABLE_DAZUKO", and "CLAMAV_SCANON..." settings to "yes" in /etc/asl/config

Step 5) Update the policy. The dazuko module will not load at this point, a failure message is expected here because the kernel doesnt allow modules to be loaded. Not to worry, a reboot will add the module.
asl -s -f

Step 6) reboot

Scott,

Added WAF output redactor (MODSEC_99_REDACTOR)

Are the rules now updated or is this still in a future build in the 2.2.6?

Mike said it was being worked on, I just wanted to know as now I have cron hourly copying rules across until this is fixed.

I saw the ASL update but decided to run it in a few days when I had the time to test fully/handle any issues. However, some of the components auto-updated last night - even though yum is not set to auto update (?):


Cannot FTP to any sites, programs (Coda/Transmit) reports:


PHP FTP Reports:


ASL GUI shows the following:


So the login looks successful. Decided the partial (auto) update was the cause, so ran:


No better! Still cannot FTP. All /etc/proftpd.* includes are intact and seem to have the correct entries.

So took a look at CLAM
/etc/clamd.conf
User root
/etc/freshclam.conf
DatabaseOwner root

/var/clamav /var/log/clamav /var/run/clamav are all root owned

Should it be root? or qscand? Would this stop FTP from working? E-mail etc is working and I don't want to fiddle with this and restart clamd if it makes everything a whole lot worse and e-mail breaks. Can anyone else confirm their settings?

I don't (really) want to get into kernel updates/dazuko modules/server reboot in the middle of the day - it also seems optional from the above notes?

Thanks

Yes the redactor system is active in 2.2.6.

kalimari- I suspect the root cause there is a firewall issue. FTP uses 2 separate ports, one for authentication and the other for data. That sounds like the data channel is being blocked to me. ASL doesnt effect the firewall rules in that way. Try clearing them though (/etc/init.d/iptables stop) and testing it again.

Firewall has rules for ctrl/data + passive FTP port range.

Think it might be caused by TLS settings, am able to FTP without TLS on, but we (normally) only allow FTP via TLS.

Just to confirm, are the root permissions on clam correct?

Yup, thats correct

OK, so we will temporarily allow FTP without TLS to allow clients to keep working. I'll post separately on that issue if necessary.

Any idea what may have caused ASL to auto update: ossec-hids-2.4.1-4.el5.art.x86_64, 1:asl-2.2.6-1.el5.art.x86_64, ossec-hids-server-2.4.1-4.el5.art.x86_64 & psa-proftpd-1.3.3-2.el5.art.x86_64? As mentioned yum is NOT set to auto-update on this server AFAIK. How can I double check? Don't want this to occur again...

Thanks

I wouldnt use passive port range rules. Linux has several FTP iptable modules that handle this automatically and dont require you to open any ports other than 21. Oening the passive range is definitely not needed and is very insecure. The iptables modules to load are:

nf_nat_ftp
nf_conntrack_ftp
nf_nat
iptable_nat

I could have imagined it, but I think that at some point in the past when 2.2.5 came out, when I ran asl -u, asl also updated itself from 2.2.4 to 2.2.5 even though all I was expecting it to do was update the rules.

Like I say, I could have imagined this/am remebering incorrectly. But if this is indeed what happened and it is still happening then it may be the cause of your mysterious update.

Faris.

asl -u will update ASL and its components via yum now.

Ah. OK. So this is expected behaviour then.

I'm not so sure it is a good idea? Or to put it another way, I think we really need an option to only update rules and not the asl components, at least when it comes to the cron job that runs every 24 hours by default. Personally rules are the only thing I'd ever want automatically updated.

Faris.

You can change the behaviour with AUTOMATIC_UPDATES= (hourly, daily, none). This was a feature request, to update ASL along with the rules. It also cuts down our support overhead by managing the ASL updates with it. You'd be surprised how many people still run 1.9

For some odd reason the automatic update to 2.2.6 caused OSSEC to go nuts. Had to manually run asl -s -f and then manually restart ossec to get it to stop.

Yes, but that just runs "asl -u" doesn't it, which updates rules and components?

A customer might want to update rules automatically, but not want to update asl components automatically. That's certainly the case here.

e.g. right now we are in the middle of some stuff that requires 99% of my attention. I don't want to be woken up at 2am by our server monitoring saying something is wrong, or by hordes of customers calling at 9am complaining about broken X Y or Z which would require time to investigate and resolve.

I want to schedule software updates to a time that is convenient to me, and to test on a system by system basis.

I have a feeling that I'm sounding a bit grumpy and moaning in this message but that's not my intention. Long Live Atomicorp! I'm just trying to explain why I think combining rules and component updates in one is not a thing that I agree with. I do understand why it is useful and good to have both happen at once, but not in a cron job that runs every 24 hours and can therefore cause unexpected problems when you least want them!

Faris.

In your case setting that to "none" will turn it off. Then you can decide when to plan your updates. As it stands now when the new version is out (2.2.6 in this case), the old version is no longer supported.