На моем сервере проблема с антивирусом Clam. Я получаю это уведомление от OSSEC один раз в день. Я не уверен, где искать и в чем на самом деле проблема. Может ли кто-нибудь указать правильное направление?
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
Это не похоже на какую-либо угрозу, о которой вам следует беспокоиться, несмотря на сообщения HIDS. freshclam
проверяет /proc/<self>
(и /proc/filesystems
) после загрузки новых баз описаний вирусов.
Ваш AppArmor отрицал freshclam
от доступа /proc/7009
. Однако AFAIK не должен влиять на обновления определений вирусов. В pid=7009
совпадает, доказывая, что он получает доступ к собственному информация о процессе, что не является ненормальным. Тот факт, что это происходит ежедневно, указывает на то же направление.
Вы можете найти профиль AppArmor, влияющий на freshclam
из /etc/apparmor.d/usr.bin.freshclam
(или из возможно включенных /etc/apparmor.d/local/usr.bin.freshclam
). Чтобы разрешить эту нормальную работу, должны быть следующие политики:
@{PROC}/filesystems r,
owner @{PROC}/[0-9]*/status r,
Вы не упомянули свой дистрибутив; обычно это по умолчанию в профиле. Если это не так, вы можете добавить его в местный профиль и убедитесь, что он был include
d в основном профиле (из раздачи). В случае изменения, поскольку AppArmor является расширением ядра (LSM), профили обычно загружаются в ядро при (следующей) загрузке.
OSSEC HIDS отслеживает ваши журналы и сообщает обо всем, что отклонено AppArmor, как о возможной угрозе, что вовсе не является плохим предположением. Однако не всегда стоит принимать во внимание разумность конфигурации AppArmor или нет. В этом конкретном случае кажется, что AppArmor что-то отрицает без необходимости, но не следует обобщать, что эти уведомления всегда являются ложными срабатываниями.
В Классификация правил уровень упомянутый после правило сработало помогает оценить актуальность:
00 - Игнорируется - никаких действий не предпринимается. Используется во избежание ложных срабатываний. Эти правила проверяются раньше всех остальных. Они включают события, не имеющие отношения к безопасности.
02 - Уведомление о низком приоритете системы - Системные уведомления или сообщения о состоянии. Они не имеют отношения к безопасности.
Вы можете настроить OSSEC Параметры предупреждений и / или Подробные параметры электронной почты чтобы избежать получения электронной почты по правилам уровней 00-03 (небезопасные) или 00-06 (низкая релевантность). В /etc/ossec.conf
:
вариант alerts
подопция email_alert_level
устанавливает минимальный уровень оповещения для отправки уведомлений по электронной почте. В дефолт 7, как и в моем предложении.
вариант email_alerts
подопция level
устанавливает минимальный уровень предупреждений для пересылки электронных писем.