Еще раз о ClamAV: особенности установки во FreeBSD

СЕРГЕЙ СУПРУНОВ

Еще раз о ClamAV:
особенности установки во FreeBSD

Статья Сергея Яремчука «Свободный антивирус», опубликованная в мартовском номере журнала «Системный администратор» 2004 года, вдохновила меня на установку этого пакета на вверенном мне сервере. Однако выяснилось, что под FreeBSD этот процесс происходит несколько иначе, чем под Linux, что и стало поводом для написания данной статьи. Впрочем, ничего сложного нет, поэтому материал ориентирован скорее на новичков.

Антивирус ClamAV имеется в коллекции портов FreeBSD, а потому вполне разумным мне показалось выполнить установку именно оттуда. Ряд проблем, с которыми пришлось столкнуться, показал, что ClamAV портирован на эту ОС не совсем корректно. Но обо всем по порядку…

Первым делом я отправился в /usr/ports/security/clamav. Чтение Makefile позволило узнать, что предлагаемая версия – 0.73, что выглядит довольно хорошо (последняя на тот момент была 0.74, но, как известно, «последнее» – не значит «лучшее»). Там же узнаем опции, с которыми пакет будет сконфигурирован:

CONFIGURE_ARGS= --with-dbdir=${DATADIR} --disable-clamuko --disable-clamav --enable-bigstack --disable-dependency-tracking

Опцию --disable-clamav, отменяющую работу от имени пользователя clamav, я решил убрать – зачем пренебрегать дополнительной безопасностью? Ну и поскольку системные администраторы – люди исключительно бескорыстные, и все их заботы и труды – о пользователях и ради пользователей, то была добавлена поддержка milter для последующей интеграции нашего антивируса с sendmail:

CONFIGURE_ARGS+= --enable-milter

Попутно я обратил внимание на следующую строчку:

OPTIONS= MILTER "Compile the milter interface" off

Попытка собрать систему вышеприведенной опцией и без нее не обнаружила никаких различий. Более того, в bsd.ports.mk упоминания параметра OPTIONS не нашлось. Возможно, во FreeBSD он не используется.

Полагая, что подготовительные работы закончены и все остальное инсталлятор сделает сам, была подана команда make. И тут случилась первая аномалия: утилита, как и положено, попыталась скачать дистрибутив пакета, но только с одного сайта – с ftp.freebsd.org, и заявила об отсутствии там нужного ей файла clamav-0.73.tar.gz. Раньше я такого не видел – на сервере операционной системы всегда в папке distfiles обнаруживался любой нужный портам архив. Пришлось забирать требуемый файл с сайта проекта clamav.sourceforge.net.

Сборка пошла, но через несколько минут появилось сообщение, что программа не будет нормально работать, пока в системе не появится пользователь clamav. Пришлось выполнить этот ультиматум вручную, хотя обычно порт создает нужных ему пользователей самостоятельно.

Сборка завершилась успешно, инсталляция тоже особых проблем не породила, не считая того, что с первого раза вывалилась ошибка, а повторный make install, запущенный для детального изучения проблемы, завершился без проблем. Видимо, с первой попытки не удалось закачать какой-то вспомогательный пакет. На стадии инсталляции тоже частенько докачиваются и устанавливаются вспомогательные пакеты, которые для сборки не нужны, но используются в дальнейшей работе. В частности, для clamav именно на этом этапе происходит установка портов unarj, unrar и т. д., если их нет в системе, а проверка архивов включена.

На первый взгляд все выглядело весьма респектабельно: конфигурационные файлы clamav.conf и freshclam.conf чинно лежали в /usr/local/etc. В первом я включил закомментированные по умолчанию опции LogTime, выводящую в лог время события (лог при этом растет вдвое быстрее, зато понятно, что и когда происходит), и ScanRAR, разрешающую проверку rar-архивов (проверка остальных по умолчанию включена). Директория /usr/local/etc/rc.d обзавелась еще двумя сценариями, призванными автоматически запускать при перезагрузке компьютера демон clamd и утилиту обновления баз freshclam.

Запуск clamscan продемонстрировал его работоспособность и вселил надежды на светлое будущее:

$ clamscan

Однако сильно смущало время обработки – свыше 10 секунд для 20 Кб проверенных файлов (конфигурация сервера – Celeron-466/64 Мб, load average ~ 0.1). Может, дело в каких-то «подготовительных работах» вроде подгрузки базы данных, и на больших объемах дело пойдет лучше? Действительно, проверка на папке /usr/ports/distfiles показала некоторое увеличение скорости:

$ cd /usr/ports/distfiles

$ clamscan

Почти 2 секунды на каждый мегабайт. Ну да ладно. Нагрузка на мой сервер пока минимальна, будем надеяться, что медлительность с лихвой окупится дотошностью. По крайней мере тестовые сигнатуры в собственных пакетах антивирусу обнаружить удалось. Следующая неприятность ждала меня при попытке запустить демон традиционным для FreeBSD способом:

/usr/local/etc/rc.d/clamav-clamd.sh start

Оказалось, что стартовые сценарии разработаны в стиле Linux и для запуска из /usr/local/etc/rc.d не годятся. Переносить их в /etc/rc.d с добавлением соответствующих опций (приведенных в начале стартовых скриптов) в файл /etc/rc.conf я посчитал неправильным. Как бы то ни было, но место всех программ, устанавливаемых пользователем, – в /usr/local.

Ну что ж, раз не хочешь по-хорошему, сделаем все по-своему. Созданные при инсталляции стартовые сценарии были безжалостно уничтожены, а их место занял следующий:

#!/bin/sh

# Manager for ClamAV: clamd & clamav-milter

case $1 in

    start)

           if [ -e /var/run/clamav/clamd.pid ]; then

                 echo "Ingored - clamd already started."

                 exit 0

      fi

           if [ -e /var/run/clamav/clmilter.sock ]; then

                 rm /var/run/clamav/clmilter.sock

           fi

           /usr/local/sbin/clamd

           /usr/local/sbin/clamav-milter -blo/var/run/clamav/clmilter.sock

           echo "clamd & clamav-milter started"

           ;;

    stop)

           killall clamav-milter

           kill -15 `cat /var/run/clamav/clamd.pid`

           echo "clamd & clav-milter stopped"

           ;;

    restart)

           kill -1 `cat /var/run/clamav/clamd.pid`

           echo "clamd restarted"

           ;;

    fresh)

           /usr/local/bin/freshclam

           ;;

    *)

           echo "Usage: `basename $0` {start|stop|restart|fresh}" >&2

           ;;

esac

exit 0

Удалять clmilter.sock я решил вручную, поскольку натолкнулся на то, что иногда он удаляется с некоторой паузой (или не удаляется вообще) в результате уничтожения демона clamav-milter, и при повторном запуске milter возникает ошибка. (Кстати, следует убедиться, что имена и пути сокетов соответствуют друг другу в строке запуска clamav-milter и в sendmail.mc.) С сокетом clamd.sock таких манипуляций не понадобилось, поскольку демон успешно убивает старый сокет сам, лишь сообщив в лог-файл об этом. Как видно из файла, помимо демона clamd запускается и clamav-milter. А вот в вопросе обновления баз я решил на демонизацию freshclam не полагаться (хотя такая возможность предусмотрена) – зачем запускать еще один демон, когда с этим отлично справится cron:

0   0,12   *      *      *      /usr/local/bin/freshclam

Настройка sendmail была выполнена в полном соответствии с документацией и проблем не вызвала (см. статью Сергея Яремчука). Нужно только не забыть перезапустить сервер (make restart в /etc/mail).

Итак, затратив немного усилий, удалось заставить clamav работать так, как это принято во FreeBSD. Конечно, если бы порт был разработан более корректно, то и эти усилия не понадобились бы.

В первые часы работы было «зарезано» около 50 зараженных писем (напомню, что лечить файлы ClamAV пока не умеет), извещения о данном прискорбном факте были добросовестно разосланы отправителям, получателям и администратору. Огорчало одно – язык сообщений был английским, а зная своих пользователей, нетрудно было спрогнозировать раскаленный телефон службы технической поддержки.

Но и эта проблема оказалась более чем решаемой: все сообщения, отсылаемые пользователям, были сосредоточены в исходном файле clamav-milter.c и насчитывали не более пяти строк. Таким образом, «русификация» свелась к простому вбиванию новых слов взамен старых. Ну и в заголовок отсылаемого письма была добавлена (в том же clamav-milter.c) строчка «Content-Type: text/plain; charset= ”koi8-r”», поскольку без нее мой Outlook упорно пытался подсунуть мне письма под видом win-1251. После правки исходника – повторная сборка и установка. Результат представлен на рисунке.

В заключение следует заметить, что проблемы, описанные в статье, вполне вероятны при попытке запустить на FreeBSD и иные приложения, первоначально разработанные для другой ОС. Методы решения большинства из них будут аналогичными. Главное – хорошо представлять себе, что должно получиться в итоге.

Комментарии могут оставлять только зарегистрированные пользователи