0

There is a problem with Clam antivirus on my server. I am getting this notification from OSSEC once per day. I am not sure where to look or what the problem actually is. Could anyone point to the right direction?

 Received From:->/var/log/syslog
    Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
    Portion of the log(s):

    Apr 27 16:00:51 kernel: [237797.696615] audit: type=1400
     audit(1493305251.498:23): apparmor="DENIED" operation="open"
     profile="/usr/bin/freshclam" name="/proc/7009/status" pid=7009 comm="freshclam" requested_mask="r"
     denied_mask="r" fsuid=115 ouid=0

1 Answer 1

0

This doesn't seem like any threat you should be worried about, despite reported by HIDS. freshclam does some checking in /proc/<self> (and /proc/filesystems) after it has downloaded new virus definition databases.

Your AppArmor has denied freshclam from accessing /proc/7009. AFAIK that shouldn't affect on virus definition updates, though. The pid=7009 is matching, proving that it is accessing its own process info, which isn't abnormal. The fact that this happens daily points to the same direction.

You can find the AppArmor profile affecting freshclam from /etc/apparmor.d/usr.bin.freshclam (or from possibly included /etc/apparmor.d/local/usr.bin.freshclam). In order to permit this normal operation, there should be the following policies:

@{PROC}/filesystems r,
owner @{PROC}/[0-9]*/status r,

You didn't mention your distribution; usually this is in the profile by default. If it isn't, you could add it to the local profile and make sure it has been included in the main profile (from distribution). If modified, as AppArmor is a kernel (LSM) enhancement, the profiles are typically loaded to kernel on (next) boot.


OSSEC HIDS monitors your logs and reports anything denied by AppArmor as a possible threat, which isn't a bad assumption at all. However, it doesn't always take a stand whether the AppArmor configuration is reasonable or not. In this particular case it seems that AppArmor is denying something unnecessarily, but you shouldn't generalize that these notifications are always false positives.

The Rules Classification level mentioned after the rule fired helps you in evaluating the relevance:

00 - Ignored - No action taken. Used to avoid false positives. These rules are scanned before all the others. They include events with no security relevance.

02 - System low priority notification - System notification or status messages. They have no security relevance.

You could adjust OSSEC Alerts Options and/or Granular Email options to avoid having email on levels 00-03 (non-security) or 00-06 (low relevance) rules. In /etc/ossec.conf:

  • option alerts sub-option email_alert_level sets the minimum alert level to send e-mail notifications. The default is 7, just like in my suggestion.

  • option email_alerts sub-option level sets the minimum alerting level to forward the e-mails.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .