mailto: amsand@yandex.ru
Статья Сергея Яремчука "Свободный антивирус", опубликованная в "Системном администраторе" за март 2004 года, вдохновила меня на установку этого пакета на вверенном мне сервере. Однако выяснилось, что под FreeBSD этот процесс порождает ряд аномалий, что и стало поводом для написания данной статьи. Правда, нужно заметить, что упомянутые выше аномалии довольно легко приводятся к "номалиям", и даже почти не требуется бубен. Поэтому статья ориентирована скорее на новичков.
Антивирус 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
Полагая, что подготовительные работы закончены, и все остальное инсталлятор сделает сам, была подана команда make. И тут случилась первая аномалия: утилита, как и положено, попыталась скачать дистрибутив пакета, но только с одного сайта - с ftp.freebsd.org, и заявила об отсутствии там нужного ей файла clamav-0.73.tar.gz. Раньше я такого не видел - на сервере операционной системы всегда в папке distfiles обнаруживался любой нужный портам архив. Пришлось забирать требуемый файл с сайта проекта clamav.sourceforge.net.
Сборка пошла, но через несколько минут заявила, что не будет нормально работать, пока в системе не появится пользователь clamav. Пришлось выполнить этот ультиматум вручную, хотя обычно порт создает нужных ему пользователей самостоятельно.
Сборка завершилась успешно, инсталляция тоже особых проблем не породила, не считая того, что с первого раза вывалилась ошибка, а повторный make install, запущенный для детального изучения проблемы, завершился без проблем. Видимо, с первой попытки не удалось закачать какой-то вспомогательный пакет.
На первый взгляд все выглядело весьма респектабельно: конфигурационные файлы clamav.conf и freshclam.conf чинно лежали в /usr/local/etc. В первом я включил закомментированные по умолчанию опции LogTime, выводящую в лог время события (лог при этом растет вдвое быстрее, зато понятно, что и когда происходит), и ScanRAR, разрешающую проверку rar-архивов (проверка остальных по умолчанию включена). Директория /usr/local/etc/rc.d обзавелась еще двумя сценариями, призванными автоматически запускать при перезагрузке компьютера демон clamd и утилиту обновления баз freshclam.
Запуск clamscan продемонстрировал его работоспособность и вселил надежды на светлое будущее:
$ clamscan /usr/home/serg/.login: OK ..... /usr/home/serg/clatest: OK ----------- SCAN SUMMARY ----------- Known viruses: 22313 Scanned directories: 1 Scanned files: 15 Infected files: 0 Data scanned: 0.02 MB I/O buffer size: 131072 bytes Time: 10.802 sec (0 m 10 s)
Однако сильно смущало время обработки - свыше 10 секунд для 20 килобайт проверенных файлов (конфигурация сервера - Celeron-466/64Mb, load average ~ 0.1). Может, дело в каких-то "подготовительных работах" вроде подгрузки базы данных, и на больших объемах дело пойдет лучше? Действительно, проверка на папке /usr/ports/distfiles показала некоторое увеличение скорости:
$ cd /usr/ports/distfiles $ clamscan mc-4.6.0.tar.gz: OK ..... clamav-0.74.tar.gz: ClamAV-Test-Signature FOUND clamav-0.73.tar.gz: ClamAV-Test-Signature FOUND ..... zoo-2.10pl1.tar.gz: OK arc-5.21j.tar.gz: OK ----------- SCAN SUMMARY ----------- Known viruses: 22313 Scanned directories: 1 Scanned files: 71 Infected files: 2 Data scanned: 303.71 MB I/O buffer size: 131072 bytes Time: 550.036 sec (9 m 10 s)
Почти 2 секунды на каждый мегабайт. Ну да ладно. Нагрузка на мой сервер пока минимальна, будем надеяться, что медлительность с лихвой окупится дотошностью. По крайней мере, тестовые сигнатуры в собственных пакетах антивирусу обнаружить удалось.
Следующая неприятность ждала меня при попытке запустить демон традиционным для FreeBSD способом:
/usr/local/etc/rc.d/clamav-clamd.sh start
Оказалось, что стартовые сценарии разработаны в стиле Linux и для запуска из /usr/local/etc/rc.d не годятся (если точнее, то проблема была вызвана тем, что моя FreeBSD на тот момент еще не умела работать с такими сценариями. Сейчас такой проблемы уже не существует.). Переносить их в /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. После правки исходника - повторная сборка и установка. Результат представлен на рисунке 1.
В заключение следует заметить, что проблемы, описанные в статье, вполне вероятны при попытке запустить на FreeBSD и иные приложения, первоначально разработанные для другой ОС. Методы решения большинства из них будут аналогичными. Главное - хорошо представлять себе, что должно получиться в итоге.
| © Amsand, 2005 (вер. от 21.11.2004) mailto: amsand@yandex.ru |
|
