ClamAV на Linux-сервере: реальная защита или карго-культ ради аудита

MAATRIX

Заказчик прислал чек-лист для аудита, и в пункте 14 значится «антивирус на сервере». Вы разворачиваете ClamAV, freshclam скачивает базы, systemd показывает зелёный статус — пункт закрыт. Вопрос в том, защищает ли это хоть от чего-то на практике, или вы только что добавили процесс, который ест память и раз в сутки грузит CPU на сканировании файлов, которые никто и никогда не откроет как исполняемый код. Ответ зависит от того, что именно делает ваш сервер — и он разный для веб-приложения с базой данных и для почтового шлюза или сервиса с пользовательской загрузкой файлов.

Что вообще делает ClamAV и на что он способен

ClamAV — сигнатурный антивирусный движок с открытым кодом, изначально заточенный под сканирование почтового трафика на серверах. Модель работы простая: движок сравнивает содержимое файла с базой сигнатур (main.cvd, daily.cvd, bytecode.cvd), которую периодически обновляет демон freshclam, и решает — заражён файл известной сигнатурой или нет. Есть три способа его использовать:

• clamscan — разовый обход файловой системы или конкретного пути, без демона, каждый раз заново подгружает базы в память;
• clamd + clamdscan — демон держит базы в памяти постоянно, сканирование через сокет идёт быстрее, это стандартный режим для продакшена;
• интеграция через milter/плагин — ClamAV подключается к почтовому серверу или к приложению как отдельный проверяющий узел, а не сканирует диск целиком.

Ключевое ограничение — сигнатурный движок ловит то, что уже известно и описано в базе. Свежий целевой зловред, веб-шелл, написанный под конкретный сайт, или PHP-бэкдор в одну строку с обфускацией — с высокой вероятностью пройдут мимо ClamAV, потому что для них просто нет сигнатуры. Это не претензия к продукту, а свойство самого класса технологии: сигнатурный антивирус исторически проектировался для десктопов, где угроза — это исполняемый файл, попавший на диск через вложение или флешку. О том, откуда вообще растёт привычка ставить антивирус на сервер по аналогии с десктопом, разобрано в статье про миф обязательности антивируса на сервере — контекст важен, потому что ClamAV это тот самый инструмент, вокруг которого миф чаще всего и строится.

Сценарий первый: проверка пользовательских загрузок — здесь ClamAV реально работает

Если сервер принимает файлы от посторонних людей — форма загрузки резюме на сайте вакансий, файловое хранилище вроде Nextcloud, загрузка вложений в тикет-систему, приём документов через веб-форму — ClamAV закрывает конкретную и реальную угрозу: пользователь (случайно или намеренно) загружает файл с известным вредоносным содержимым, который затем скачает другой пользователь или откроет сотрудник компании на своей рабочей машине. Сервер здесь не жертва заражения, а транзитный узел, через который зловред может добраться до чужого десктопа — и вот тут сигнатурная проверка на входе действительно снижает риск.

Практическая схема для веб-приложения: файл сохраняется во временную директорию, скрипт вызывает clamdscan через сокет, и только при чистом результате перекладывает файл в постоянное хранилище.

# проверка одного файла через демон (быстро, база уже в памяти)
clamdscan --fdpass /var/www/uploads/tmp/incoming_file.pdf
echo $?  # 0 — чисто, 1 — найдено, 2 — ошибка сканирования

Для Nextcloud есть готовое приложение files_antivirus из каталога приложений — оно подключается к тому же clamd через unix-сокет или TCP и блокирует загрузку заражённого файла до того, как он попадёт в хранилище пользователей. Установка самого Nextcloud разобрана в статье про развёртывание Nextcloud на VPS, а антивирусный плагин там — опциональный шаг именно для сценария общего файлового хранилища с внешними участниками.

Важная оговорка: ClamAV на входе не ловит веб-шеллы, которые заливают через уязвимость в самом приложении, а не через легитимную форму загрузки — это отдельный класс атаки, и для него нужен не антивирус, а поиск подозрительных файлов в директориях выполнения. Разница и практические команды для поиска чужого PHP-кода описаны в статье про веб-шелл в папке uploads.

Сценарий второй: почтовый шлюз — классическая и всё ещё живая задача ClamAV

Это исторически первое и самое отработанное применение движка. Почтовый сервер принимает вложения от кого угодно в интернете, и часть спам- и фишинг-кампаний до сих пор рассылает вложения с известными зловредами — макросы в Office-документах, исполняемые файлы под видом PDF, архивы с эксплойтами под старые версии офисных пакетов. Здесь сигнатурная база актуальна и реально отсекает известный мусор до того, как письмо попадёт в почтовый ящик получателя.

Типичная связка — Postfix + amavisd-new (или clamav-milter) + ClamAV:

apt install clamav clamav-daemon amavisd-new
systemctl enable --now clamav-daemon clamav-freshclam
# amavisd-new подключается к clamd через сокет /var/run/clamav/clamd.ctl
# и добавляется в Postfix как content_filter в main.cf

Если у вас уже развёрнут почтовый сервер на Postfix, антивирусная проверка вложений логично встаёт в конвейер вместе с проверкой на спам через SpamAssassin. Именно для почтового трафика регулярное обновление сигнатур особенно оправдано: freshclam по умолчанию проверяет обновления несколько раз в сутки, и это тот случай, когда свежесть базы напрямую влияет на процент отловленных писем.

Сценарий третий: требование аудита или комплаенса — формальность, но не всегда бессмысленная

Если заказчик работает по PCI DSS, проходит SOC 2 или у него в договоре с клиентом прописано требование антивирусной защиты на серверах, обрабатывающих определённые данные — наличие ClamAV в чек-листе часто обязательно вне зависимости от того, ловит ли он реальные угрозы именно на вашей инфраструктуре. Здесь честный подход — не спорить с аудитором о технической бесполезности сигнатурного сканера для конкретно вашей нагрузки, а просто закрыть формальное требование с минимальными накладными расходами: демон установлен, база обновляется, отчёт о последнем сканировании можно предъявить.

# еженедельный отчётный скан по cron с логированием для аудитора
0 3 * * 0 /usr/bin/clamscan -r --infected --log=/var/log/clamav/weekly-scan.log /var/www /home

Российский аналог — требования 152-ФЗ для персональных данных, где формулировки про «средства защиты информации» иногда трактуются проверяющими расширительно. Если у вас именно такой контекст, стоит сначала посмотреть на общую картину подготовки к проверке — она шире одного антивируса — в статье про подготовку сервера к аудиту безопасности. Важно не путать закрытие формального пункта с реальной защитой: это две разные задачи, и осознанно решать первую — нормально, если вы понимаете, что вторую она не решает.

Когда это карго-культ: типичная нагрузка веб-сервера и базы данных

Возьмём обычный сервер: nginx отдаёт статику и проксирует запросы, PHP-FPM или Node.js крутит приложение, PostgreSQL или MySQL хранит данные. Никто извне не загружает сюда произвольные файлы для последующего скачивания третьими лицами — вся файловая система состоит из кода, который вы сами задеплоили, конфигов, которые вы сами написали, и данных базы, которые ClamAV не умеет осмысленно интерпретировать (он видит бинарный дамп, а не SQL-инъекцию или логическую уязвимость). В этой модели угроз реальные векторы атаки — это:

• уязвимость в самом веб-приложении (RCE, SQL-инъекция, небезопасная десериализация);
• скомпрометированные учётные данные для SSH или админки;
• уязвимость в зависимостях (устаревший пакет с известным CVE);
• неправильно настроенные права доступа и открытые порты.

Ни один из этих векторов ClamAV не закрывает — он не анализирует сетевые соединения, не проверяет права файлов, не ищет аномалии в поведении процессов, и не защищает от эксплуатации 0-day или свежей уязвимости, для которой ещё не выпущена сигнатура. Периодический clamscan -r / на таком сервере — это в первую очередь трата CPU и I/O на пересканирование гигабайт кода и логов, которые физически не могут быть заражены классическим файловым вирусом, потому что этот класс угроз тут просто не встречается. Если основная причина установки — интуитивное «на сервере должен быть антивирус, как на компьютере», это тот самый перенос десктопной модели угроз, о котором подробнее в статье про миф обязательности антивируса.

Что действительно ловит признаки взлома на такой типичной нагрузке — открытые соединения к майнинг-пулам, аномальная загрузка CPU, подозрительные процессы — это отдельный набор приёмов и команд (ss, top, проверка автозапуска), никак не связанный с сигнатурным сканированием файлов. Это не замена ClamAV, а другой инструментарий — под другую модель угроз, ту, что реально актуальна для веб-сервера и базы данных.

Установка, ресурсы и практические грабли

Установка на Ubuntu/Debian занимает несколько минут:

apt update
apt install clamav clamav-daemon
systemctl stop clamav-freshclam   # freshclam может быть уже запущен инсталлятором
freshclam                         # первая полная загрузка баз, может занять несколько минут
systemctl enable --now clamav-freshclam clamav-daemon

Ресурсы — вот где карго-культ обычно и вылезает на маленьких VPS. clamd держит все загруженные базы сигнатур в оперативной памяти постоянно, и это не символическая цифра — счёт идёт на многие сотни мегабайт, а после обновлений баз может доходить и до гигабайта с лишним в зависимости от набора активных баз (bytecode, daily, main, дополнительные наборы вроде unofficial sigs, если вы их подключали). На сервере с 512 МБ–1 ГБ RAM, где и так тесно веб-приложению и базе данных, clamd может стать той каплей, из-за которой начинается своп и деградация всего остального. Точную цифру для вашей конфигурации нужно смотреть по факту — systemctl status clamav-daemon и ps aux | grep clamd покажут текущее потребление после прогрева.

Практические нюансы, на которые стоит обратить внимание до продакшена:

• freshclam и сетевой трафик. Демон обращается к CDN базами данных ClamAV по расписанию (по умолчанию несколько проверок в сутки); на серверах с ограниченным или платным исходящим трафиком это стоит учитывать, хотя объём самих обновлений обычно небольшой.
• Ложные срабатывания. Сигнатурная база время от времени даёт false positive на легитимные архивы или бинарники — если вы включаете clamscan --remove в автоматическом режиме без ручной проверки, есть шанс потерять нужный файл. Для прода разумнее --move в карантинную директорию, а не немедленное удаление.
• clamscan vs clamdscan. clamscan каждый раз заново грузит все базы в память процесса — это медленно и тратит CPU при частом запуске. Если сканирование нужно чаще, чем раз в сутки, используйте clamdscan, который обращается к уже прогретому демону через сокет.
• On-access сканирование. Модуль clamonacc умеет сканировать файлы в момент записи через fanotify, но это ощутимо более тяжёлый режим и имеет смысл только в сценарии с активной пользовательской загрузкой файлов — на обычном веб-сервере он не нужен и добавляет задержку на каждую запись.
• Systemd-таймер вместо cron, если нужен регулярный отчётный скан — так проще смотреть статус последнего запуска через systemctl status и журнал через journalctl, чем разбирать вывод почты от cron.

Как решить, нужен ли ClamAV именно вам

Практическая проверка на пять вопросов, без предположений о том, что «положено»:

1. Принимает ли сервер файлы от посторонних людей, которые потом скачивают или открывают другие люди (не вы сами через деплой)? Если да — сценарий загрузки, ClamAV оправдан.
2. Есть ли на сервере почтовый шлюз, принимающий вложения из внешнего мира? Если да — классический и всё ещё рабочий сценарий.
3. Требует ли договор, аудит или регулятор формального наличия антивируса вне зависимости от вашей оценки риска? Если да — ставьте для соответствия, но не переоценивайте реальную защиту, которую это даёт.
4. Сервер — это только код, конфиги и база данных, которые вы сами разворачиваете и не даёте загружать файлы посторонним? Тогда ClamAV, скорее всего, лишняя нагрузка без пользы, и ресурсы лучше потратить на актуальные патчи, мониторинг процессов и разумные права доступа.
5. Хватит ли ресурсов сервера, чтобы clamd держал базы в памяти постоянно без деградации остальных сервисов? Если сервер и так на грани по RAM, а сценарий из пунктов 1–3 не подтвердился — вопрос закрыт сам собой.

Частые вопросы