 |
|
|
|
Настраиваем DrWeb Enterprise Suite
Настраиваем DrWeb Enterprise Suite Мало кто ставит под сомнение факт, что на современном рабочем месте должен стоять антивирусный пакет. Сегодня вирусы берут не умением, а числом. В основном они не разрушают информацию – они создают условия к утечке коммерческой информации. Как защитить предприятие от вирусной активности? С одной стороны, можно отфильтровывать входящие и исходящие почтовые сообщения через почтовый шлюз. Здесь замечательно вписываются как коммерческие продукты, так и продукты формата Open Source. Можно настроить систему фильтрации содержимого, которое проходит через proxy-серверы, здесь также достаточно альтернатив. По сути происходит принудительная очистка от транзитных вирусных приложений. А стоит ли производить повсеместное развертывание антивирусных пакетов на каждом рабочем месте? Безусловно, никто это не ставит под сомнение. Но что именно выбрать в качестве основы, чтобы был централизованный центр обновления антивирусных агентов, имелся единый центр управления и велась оперативная статистика? На мой взгляд, стоит обратить внимание на антивирусные решения масштаба предприятия (Enterprise Solutions). На сегодняшний день наиболее распространенными являются enterprise-решения от компаний:
Последние два продукта выпускаются отечественными компаниями. Что из себя представляет антивирусное программное обеспечение масштаба предприятия? Это в первую очередь специализированный продукт, к примеру, от одной из вышеперечисленных компаний. Во-вторых, это клиент-серверный программный комплекс, задача серверной части в котором – обеспечивать централизованное обновление по сети антивирусного обеспечения для клиентов, вести журнал, где учитывается, на какой именно рабочей станции произошел тот или иной случай инфицирования, а также некоторые другие события. А задача клиентской части, которая была предварительно установлена на рабочей станции, – предотвращать «инфекции», производить «лечение». В целом общий функционал у всех решений одинаков. Что же касается деталей, то здесь намного интереснее, т.к. приходится рассматривать такие критерии, как соотношение цена/качество, сертификация в отечественных агентствах по информатизации, возможность использования на объектах повышенной секретности и т. п. Наша компания остановила свой выбор на антивирусном пакете DrWeb. Легковесный антивирус – размер антивирусного клиента, устанавливаемого на рабочем месте, достаточно компактен – несколько мегабайт. Есть русский язык. И что немаловажно – грамотная техническая поддержка. Вполне возможно, что вам и не придется обращаться за помощью, т.к. описания и документация, идущие с продуктом, охватывают, пожалуй, все ключевые моменты, которые могут возникнуть. Однако в вашей организации в качестве настольного антивируса может выступать решение и другой компании, благо их на рынке не две и даже не три. Выбор на самом деле более чем богатый. Наш выбор проходил достаточно давно, и в целом работа продукта на протяжении нескольких лет нас удовлетворяла, поэтому вполне логичным был шаг, что в дальнейшем мы перешли на комплексное решение – DrWeb Enterprise Suite. Установка программного комплекса С сайта компании загрузите серверную часть. В ее состав входит и базовый комплект для агента – это ядро и те антивирусные базы, которые были доступны на момент выпуска сервера. Здесь пока преждевременно думать о свежих базах и версиях, т.к. мы затем настроим обновление ПО и новые версии получим по сети, через сервис GUS – Global Update System. Серверная часть антивирусного ПО доступна как для Windows-платформы, так и для UNIX/Linux-систем. Когда вы решите разворачивать систему на базе Linux-сервера, то предварительно узнайте, какая GLIBC-библиотека используется в вашей системе, и забирайте нужную вам версию. Здесь и далее я буду расcматривать установку на Linux-сервер. Итак, забираем с сайта архив, совместимый с версией GLIBC-библиотеки в вашей системе (для моей системы – Slackware Linux 10.2 – оказался подходящим архив для Debian [17]): $ wget ftp://ftp.drweb.com/pub/drweb/esuite/drweb-es-4.33-200510280-linux-debian-sarge.tar.gz $ wget ftp://ftp.drweb.com/pub/drweb/esuite/drweb-es-4.33-200510280-unices.tar.gz $ tar xzvf drweb-es-4.33-200510280-linux-debian-sarge.tar.gz $ tar xzvf drweb-es-4.33-200510280-unices.tar.gz Создаем группу и пользователя в системе, от имени которого будет запускаться серверная часть антивирусного пакета: # groupadd drwcs # adduser drwcs В директорию /opt копируем содержание распакованного архива drweb-es-4.33-200510280-unices.tar.gz: # cp -R opt /opt/drwcs # chown -R drwcs:drwcs /opt/drwcs На этом шаге установка почти завершена. Будучи коммерческим продуктом, DrWeb Enterprise Suite не будет работать без ключа активации. Ключ генерирует дилер компании или сама компания на срок подписки, например, на год. В нем также учитывается, для скольких клиентских мест куплена поддержка. Будем считать, что ваша компания купила поддержку для 100 рабочих мест, ключ передан по электронной почте или другим способом. Переносим его на наш Linux-сервер. Будем считать, что файл – enterprise.key – находится на вашей рабочей станции UNIX и передаваться будет по SSH-протоколу. $ scp enterprise.key drwcs@drwcs.lan.net:/opt/drwcs/etc Таким образом, мы передали по SSH-протоколу ключ активации, от которого зависит работа серверной части комплекса. Не лишним будет сказать, что данный ключ активации – секретная часть комплекса, которая используется только на серверной стороне. Для работы комплекса следует еще сгенерировать приватный и публичный ключи. Что это такое и для чего нужно? Чтобы клиентская часть комплекса, которая устанавливается на рабочую станцию, смогла подключиться к серверу и быть им опознана, используется асимметричная схема криптования, в какой-то степени аналогичная PGP. С помощью публичного ключа, который используется на рабочей станции, и приватного ключа, который находится непосредственно на сервера, происходит установка шифрованного канала связи. По нему будут передаваться как сами антивирусные базы и обновления от сервера к клиенту, так и информация о заражении и статистика в обратном направлении. $ cd /opt/drwcs $ bin/drwsign genkey etc/drwcsd.pri etc/drwcsd.pub $ chmod 600 etc/drwcsd.pri $ chown drwcs:drwcs etc/drwcsd.pri $ mv etc/drwcsd.pub Installer И подготовьте еще один компонент – саму базу данных, где будет храниться вся текущая информация о станциях, вирусной активности, лечении и т. п. $ bin/drwcsd -var-root=./var -verbosity=all -log=var/server.log initdb agent.key База проинициализирована (см. документацию к продукту [18]). Теперь подготовим стартовый скрипт для запуска серверной части. У меня используется следующий вариант. Скрипт запуска/остановки серверной части для Slackware Linux #!/bin/sh DISTVER="Slackware 10.0" BIN=/opt/drwcs case "$1" in start) cd $BIN echo -n "Starting DRWEB Engine ..." su - drwcs -c "$BIN/bin/drwcsd -home=$BIN -var-root=$BIN/var -verbosity=all -log=$BIN/var/server.log -rotate=5,500000 -daemon -pid=$BIN/var/drwebd.pid" echo -e " Done" ;; stop) echo -n "Stopping DRWEB Engine ..." killall -15 drwcsd-unsafe echo -e " Done" ;; restart) $0 stop $0 start ;; echo "Usage: $0 {start|stop|restart}" exit 1 esac exit 0 Хотя официально Slackware Linux не поддерживается, однако совместимость GLIBC-библиотеки (2.3.2) на моей системе с Debian-системой, для которой уже есть архив на сайте фирмы, позволила развернуть антивирусный комплекс и на этой системе. На этом серверная часть готова. Запускаете серверную часть с помощью скрипта /etc/rc.d/rc.drwebd: # /etc/rc.d/rc.drwebd start Следующим шагом подготовьте установочные файлы для инсталляции на рабочих местах. Я поступил вот как – сделал самораспаковывающийся архив, в который я поместил файлы: drwinst.exe, drwcsd.pub, drwebc.bat. Первый файл – это инсталлятор, задача которого зарегистрировать рабочую станцию на сервере с помощью публичного ключа сервера (второй файл). А затем загрузить с сервера необходимые антивирусные обновления. Третий файл – пакетный, в котором хранится IP-адрес антивирусного сервера. drwinst.exe -interactive -verbosity=all drwcs.lan.net Не обязательно явно указывать адрес для сервера, т.к. установочный компонент посылает в сеть multicast-запросы, с помощью которых и определяется нужный IP-адрес сервера. Однако в сети со множеством маршрутизаторов и роутеров, лучше использовать явное задание адреса. Самораспаковывающийся архив я разместил на веб-странице сервера, так что, кроме самого DrWeb Enterprise Suite, на Linux-сервере еще крутится и Аpache-сервер. Решение достаточно удобно, ибо на рабочем месте запускается Internet Explorer, с помощью которого загружается архив. Затем архив распаковывается и запускается файл drwebc.bat. После регистрации рабочих станций основная работа уже происходит на станции, с которой управляется антивирусный комплекс. Данная работа производится через консоль управления (см. рис. 1).
Рисунок 1. Консоль управления комплексом Все рабочие станции можно разбить на отдельные группы, для каждой из которых составить правила, в частности, расписание на ежедневное или еженедельное сканирование, политика локального доступа с рабочих станций, т.е. можно ли останавливать клиентскую часть или нельзя и т. п. Все станции, которые в данный момент включены, находятся в группе Online. Те же, которые выключены, находятся в группе Offline. Как я уже отмечал, за непосредственную защиту отвечает клиентская часть комплекса (Enterprise Agent), которая представлена 3 компонентами: Dr.Web Scanner for Windows, Spider Guard for Windows и Spider Mail for Windows Workstations. Первый компонент предназначен для сканирования рабочей станции, может быть запущен как с самой рабочей станции, так и с операторской консоли управления. Второй компонент отвечает за проверку всех тех файлов, к которым происходит обращение операционной системы в режиме runtime. Третий компонент отвечает за проверку входящей и исходящей почты. То есть как только вы начинаете получать email с помощью почтового клиента, то все входящие сообщения будут проверены еще и этим компонентом. Чем хороша статистика, так это тем, что вы точно знаете, где и когда произошел факт инфицирования (см. рис. 2). А также названия наиболее «популярных» вирусов в вашей организации, которые были излечены (а иначе откуда бы вы знали об их существовании?). Это здорово, когда организация небольшая и подключений к глобальным сетям нет. Однако и в таких условиях вероятность того, что на ПЭВМ организации есть хотя бы один макровирус в документах Microsoft Word, в различного рода архивах, которые принесли сотрудники из дома, от знакомых или еще откуда-нибудь, будет отличаться от нулевой. Лучше изначально считать, что «пациент скорее инфицирован, нежели здоров». Однако и панику разводить, конечно же, не стоит.
Рисунок 2. Статистика по группе «Online». Серверная часть антивирусного комплекса периодически производит действия, указанные в расписании. Например, каждый час происходит проверка на наличие новых обновлений и антивирусных баз. На рис. 3 приведено расписание, которое будет использовано по умолчанию. Вы можете изменить его, добавив новый пункт или изменить время, когда необходимо производить те или иные действия.
Рисунок 3. Расписание сервера. Согласно расписанию происходит обновление комплекса. Однако что именно обновлять? Чтобы узнать это, стоит заглянуть в пункт «Administration > Configure Repository». Репозитарий представлен 5 частями: сам сервер, антивирусные базы, клиентская часть, консоль управления, агент. В настройках репозитария можно указать proxy-сервер, через который вы выходите в Интернет и через который будут забираться новые версии продукта. Допустимо настраивать репозиторий как по отдельным компонентам, так и в целом (см. рис. 4, 5).
Рисунок 4. Компонент репозитория «Enterprise Agent».
Рисунок 5. Общая настройка репозитория подразумевает глобальную настройку. Работа над программным комплексом ведется постоянно, и появляются все новые и новые функции. Когда я только начал работать с Enterprise Server, многих функций просто не было. Например, не было просмотра текущей загруженности сервера, не было статистики по суммарному трафику, прошедшему через антивирусный сервер и т. п. В новой версии (речь идет о 4.33) они представлены и, как мне кажется, очень удачно вписываются в общую картину (см. рис. 6, 7).
Рисунок 6. Суммарная статистика сервера.
Рисунок 7. Графические данные. Рассказ был бы неполным, если бы я не упомянул о том, как делать регулярную выгрузку базы. Какая цель здесь преследуется? Во-первых, самое ценное в работе антивирусного пакета – это информация о зарегистрированных станциях, точнее о hash-ключах, которые формируются при регистрации. Она хранится как на станции, так и в базе антивирусного сервера. Отчасти по этим ключевым данным происходит «узнавание» зарегистрированных станций. Во-вторых, знать, когда и где произошла «эпидемия» также важно. Поэтому даже если физически произойдет отказ сервера и у вас будет резервная копия антивирусной базы, то ввод в эксплуатацию нового серверного «железа», взамен отказавшего займет довольно короткое время. Не нужно будет заново регистрировать станций. Смотрите файл export_idb.sh. Скрипт для выгрузки внутренней БД #!/bin/sh ######################################################### # Exporting internal DrWEB DB into .SQL dump script # 28 Sep 2005, AB ######################################################### DATE=/usr/bin/date IDBSH=/opt/drwcs/bin/drwidbsh IDB=/opt/drwcs/var/dbinternal.dbs BZ2=/usr/bin/bzip2 ECHO=/usr/bin/echo DRWENGINE=/etc/rc.d/rc.drwebd OUTPATH=/root/System/drweb/ export LC_ALL="C" $DRWENGINE stop echo "Engine Stopped"; echo "Sleep 10 seconds"; sleep 10s; OUTPUT=`$ECHO IDB.$($DATE +%d_%b_%Y_-_%k_%M).sql.bz2`; echo "Exporting Internal DrwebDB into $OUTPUT .sql script"; $IDBSH $IDB ".dump" | $BZ2 > $OUTPATH$OUTPUT echo "DrWEB IntDB dumped" $DRWENGINE start Осталось добавить в cron новое расписание и вуаля! 50 0 * * * /root/System/export_idb.sh > /dev/null 2>&1 В качестве заключения Несмотря на то что существует множество альтернативных, как коммерческих, так и бесплатных антивирусных программных решений, стоит отметить, что компания «ООО «Доктор Веб» была одной из первых, кто предложил подобную методологию антивирусного управления. Что касается качества программного кода, а именно безаварийность в работе рабочих станций при развертывании системы и/или переходе со старой версии комплекса на новую, то в этой ситуации стоит понимать простые истины. Как и везде существуют стадии проверки и отладки, так и у рассмотренного комплекса есть beta-версии, задача которых «отловить» острые моменты и устранить их. Если придерживаться принципа здорового консерватизма и развертывать систему в стадии stable, то это позволит вам читать страшные истории о последствиях установки системы с улыбкой на устах. На этом всё, успехов!
|
Антон Борисов
| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
