Демонстрация возможностей Dr.Web Office Shield. Сценарий 1

Dr.Web® для интернет-шлюзов Unix
Версия 6.0.2
Сценарий тестирования 1
Развертывание системы антивирусной защиты
Тестирование производительности
Версия программного обеспечения
6.0.2
Версия документа
1.1
Статус документа
Утвержден
Дата последнего изменения
25 января 2012 года
Основные этапы тестирования:
Установка и настройка Dr.Web для интернет-шлюзов Unix
Управление сервисом защиты интернет-трафика
Контроль работы сервиса
Настройка действий для зараженного трафика
Управление доступом к ресурсам сети Интернет
Настройка параметров работы карантина
Оптимизация проверки трафика
Настройка правил обработки файлов в зависимости от их MIME-типа
Задание параметров для групп пользователей
Настройка шаблонов
Отмена проведенных обновлений
Управление защитой интернет-трафика под ОС Unix из Центра управления Dr.Web
Enterprise Security Suite
2.10.1 Подключение к Центру управления Dr.Web Enterprise Security Suite
2.10.2 Настройка запуска сервиса из Центра управления Dr.Web Enterprise Security Suite
3
Тестирование работоспособности
4
Тестирование производительности
4.1
Тестирование производительности системы фильтрации интернет-трафика
4.2
Тестирование функционирования системы фильтрации интернет-трафика
1
2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
Внимание! Возможности Dr.Web для интернет-шлюзов Unix не ограничиваются функционалом,
описанным в данной методике. Для ознакомления с возможностями Dr.Web для интернет-шлюзов
Unix используйте документацию к продукту.
Введение
Данный документ описывает примеры создания и тестирования системы антивирусной
защиты локальной сети предприятия с помощью Dr.Web для интернет-шлюзов Unix. Целью
каждого из описанных этапов тестирования является проверка правильности
функционирования конкретной подсистемы сервера.
В документе не рассматриваются вопросы, связанные с выбором профилей пользователей,
набора характерных потоков данных (размеров и типов скачиваемых файлов и т. д.).
Соответствующие методики могут быть составлены самостоятельно. Типовые методики
могут быть запрошены в компании «Доктор Веб».
Документ рассчитан на пользователей, имеющих достаточную для проведения тестирования
квалификацию. В связи с этим в нем не рассматриваются вопросы установки необходимых
для тестирования программ, их сборки и т. д.
Назначение и варианты использования Dr.Web для интернет-шлюзов Unix
Dr.Web для интернет-шлюзов Unix предназначен для использования в качестве шлюза
доступа в Интернет. Доступность функционала определяется ключами продукта.
Внимание! В данном руководстве не рассматриваются вопросы установки и настройки
продуктов, не входящих в состав Dr.Web для интернет-шлюзов Unix.
Процедура тестирования Dr.Web для интернет-шлюзов Unix
Процедура тестирования включает:
1.
Установку и первоначальную настройку Dr.Web для интернет-шлюзов Unix.
2.
Тестирование производительности системы фильтрации интернет-трафика.
3.
Тестирование функционирования системы фильтрации интернет-трафика.
Суммарная продолжительность тестирования: 4–8 рабочих часов с учетом изучения
документации.
Рекомендуемая процедура тестирования
1
Установка и настройка Dr.Web для интернет-шлюзов Unix
Установка сервиса Dr.Web для интернет-шлюзов Unix возможна как из командной строки,
так и с помощью графического инсталлятора. Процедура установки с помощью графического
инсталлятора подробно описана в документации на продукт, поэтому ниже будет
рассмотрена процедура установки и настройки из командной строки как наиболее часто
встречающийся случай для серверов с минимумом сервисов и отсутствием графического
интерфейса.
Получив доступ к серверу Linux, скопируй те инсталляционный файл (в нашем случае drwebinternet-gateways_6.0.2.0-1110281114~linux_x86.run — установка осуществлялась на 32битную систему) во временную директорию и запустите его (установив бит исполняемости
или использовав команду sh):
mkdir /tmp/icapd/
cp /root/drweb/drweb-internet-gateways_6.0.2.0-1110281114~linux_x86.run /tmp/icapd/
cd /tmp/icapd/
sh /tmp/icapd/drweb-internet-gateways_6.0.2.0-1110281114~linux_x86.run
Сразу после запуска необходимо подтвердить согласие на установку.
Далее выбираем тип установки (с настройками по умолчанию или в пользовательской
конфигурации). Выбираем установку по умолчанию.
После этого вам будет показан текст лицензии. Вы можете ознакомиться с ней, нажимая
пробел для прокрутки текста, либо прервать показ, нажав клавишу Q.
Подтверждаем согласие с текстом лицензии, введя Yes.
Аналогично просматриваем список авторских прав. Вы можете ознакомиться с правами на
используемые компоненты, нажимая пробел для прокрутки текста, либо прервать показ,
нажав последовательно клавишу Q и клавишу ввода.
После этого начинается непосредственно процесс установки.
После завершения установки продукта инсталляционный скрипт предлагает настроить
параметры работы программы. Введите Yes и ответьте на вопросы, задаваемые в ходе
настройки.
Укажите путь к используемому вами ключевому файлу и его полное имя (в том случае, если
продукт не работает в составе централизованно управляемой антивирусной сети Dr.Web
Enterprise Security Suite).
В случае приобретения Dr.Web для интернет-шлюзов Unix в составе программного
комплекса Dr.Web Enterprise Security Suite, для работы комплекса необходимы два файла:
ключевой файл для Сервера централизованной защиты (enterprise.key) и ключевой файл
продукта (agent.key). При установке вы можете использовать agent.key, переименовав его в
drweb32.key и скопировав в папку установки.
После этого окончательная настройка продукта происходит в автоматическом режиме.
После установки необходимо проверить содержимое файлов drwebd.enable drwebmonitor.enable и при необходимости присвоить переменной ENABLE значение 1. Это
позволит запустить компоненты Dr.Web Daemon и Dr.Web Monitor. Если запускать Dr.Web
Daemon не нужно (используется Демон, запущенный на другом компьютере в локальной
сети), то для переменной ENABLE нужно оставить присвоенное по умолчанию значение 0.
В случае ручной установки (без использования процедуры автоматической установки) для
обеспечения взаимодействия с Squid требуется отредактировать конфигурационный файл
squid.conf (обычно находится в директории /usr/local/squid/etc/) с целью подключения
возможности использования ICAP-протокола.
Если нижеприведенные строки уже есть в конфигурационном файле, то нужно
раскомментировать их и исправить значения по умолчанию в случае необходимости. В
противном случае нужно добавить данные настройки в конец файла.
Подключение возможности использования протокола ICAP:
icap_enable on
Регистрация новой службы ICAP:
# ICAP service description:
# icap_service <name> <type> <pass> <url>
# <name> – name of service
# <type> – type of service
# <pass> – can content be passed (1) past
# ICAP server or not (0)
# <url> - url of service
icap_service service_1 respmod_precache 0
icap://localhost:1344/respmod
Далее нужно создать класс для новой службы:
icap_class class_1 service_1
Новому классу нужно разрешить доступ к HTTP, GET и т. д.:
icap_access class_1 allow all
При использовании возможности preview необходимы дополнительные настройки.
Подключение возможности использования режима preview:
icap_preview_enable on
Установка размера тела сообщения (в байтах), посылаемого в preview:
icap_preview_size 0
Для вывода в файл отчета информации об IP-адресе клиента, запрашивающего ресурс:
icap_send_client_ip on
Для поддержки постоянных соединений между drwebicapd и Squid, что повышает
производительность:
icap_persistent_connections on
В связи с тем, что на данный момент в Squid не реализован режим respmod-postcache, при
использовании данного прокси-сервера невозможно произвести проверку контента после
того, как он попал в кеш.
В качестве средства удаленного администрирования используется Webmin. Если вы хотите
использовать для управления Веб-интерфейс, вы должны установить его.
В случае необходимости дистрибутив Webmin’а может быть загружен с
www.webmin.com/download.html.
Внимание! В связи с тем, что используемый по умолчанию в Windows XP браузер Internet
Explorer версии 6.0 имеет значительные проблемы с безопасностью и не рекомендуется к
использованию своим производителем, дальнейшая демонстрация проводится с помощью
браузера Firefox.
Для того чтобы получить доступ к консоли Webmin’а, в строке браузера нужно указать адрес
сервера Linux, на котором был установлен Webmin, и 10000. Например,
http://192.168.100.82:10000. В качестве логина используется root, пароля — пароль доступа к
серверу Linux.
Для установки консоли управления Dr.Web для интернет-шлюзов Unix необходимо в папке
Webmin выбрать пункт Webmin Configuration (Настройка Вебмин) и на открывшейся
странице выбрать Webmin Modules (Модули Вебмин).
На странице Webmin Modules необходимо выбрать вариант From local file (Из локального
файла) и указать путь к файлу drweb-icapd-web.vbm.gz. По умолчанию он находится в
каталоге /opt/drweb/web.
Указав файл, необходимо на странице Webmin Modules нажать на кнопку Install Module
(Установить Модуль). Иногда после завершения установки нужно перезагрузить Webmin.
Консоль управления Dr.Web для интернет-шлюзов Unix — Dr.Web консоль для интернетшлюзов Unix — находится в папке Servers (Службы).
В том случае, если для работы консоли не хватает ряда дополнительных модулей, их список
будет показан при попытке запуска консоли.
Недостающие модули можно установить как автоматически, нажав кнопку install modules,
так и из командной строки. Рекомендуется устанавливать недостающие модули из командной
строки. Имена модулей могут различаться, однако, как правило, они содержатся в пакетах
perl-Encode-HanExtra, perl-Text-Iconv. Для установки в rpm-системах рекомендуется
выбирать пакеты noarch.rpm.
После завершения установки модуля управления рекомендуется обновить страницу Webmin.
2
Управление сервисом защиты интернет-трафика
Как правило в качестве интернет-шлюза используется squid. Однако это не обязательно – в
качестве основы для построения системы антивирусной проверки интернет-трафика может
послужить любой шлюз, поддерживающий ICAP
В начале установки Dr.Web для интернет-шлюзов Unix (drweb-icapd) предполагается что сам
squid уже скомпилирован с поддержкой icap и настроен.
Для работы с Dr.Web для интернет-шлюзов Unix в настройки squid должны быть внесены
изменения. минимальные изменения для текущей третьей версии squid выглядят так (для
случая работы на одном хосте с icapd через lo):
icap_enable on
icap_service service_1 respmod_precache 0 icap://127.0.0.1:1344/respmod
# создаем класс для новой службы: icap_class class_1 service_1
#для старых squid
# разрешаем доступ нового класса к HTTP, GET и т.д. icap_access class_1
allow al
#lдля старых squid
# для новых squid это будет выглядеть так:
adaptation_service_set service_1
adaptation_access service_1 allow all
icap_preview_enable on
icap_preview_size 0
icap_send_client_ip on
icap_persistent_connections on
Также предполагается, что в системе корректно работает ресолвер и проблем с dns нет.
Настройки непосредственно самого Dr.Web для интернет-шлюзов Unix хранятся в файле
/etc/drweb/drweb-icapd.ini для Linux/Solaris и /usr/local/etc/drweb/drweb-icapd.ini для FreeBSD.
В большинстве случаев после установки для обеспечения совместной работы всех частей
(squid, drweb-icapd и антивирусного демона drwebd ) системы фильтрации трафика при ее
равботе на одном хосте ничего делать не нужно.
Однако Dr.Web для интернет-шлюзов Unix помимо антивирусной проверки умеет
блокировать или разрешать посещение определенных url, а также безусловно разрешать или
блокировать без проверки на вирусы обращения к определенным хостам. В случае
необходимости настройки этих функций можно использовать как возможности вебинтерфейса, так и прямое редактирование конфигурационных файлов
Все настройки Dr.Web для интернет-шлюзов Unix условно можно разделить на:

общесистемные. Настройки, отвечающие за протоколирование, коммуникацию с
компонентами, а также системные настройки (пользователь от имени которого
работаем, пути до нужных в работе файлов, адрес администратора и тд);

настройки параметров сканирования. Список проверяемых объектов, парметры
проверки;

настройки действий на случай возникновения тех или иных ситуаций;

настройки разграничения доступа - какие ресурсы можно или запрещено посещать.
Какие ресурсы проверяются при их посещении, а какие нет и тд;

сключения или индивидуальные настройки клиентов;

правила.
Рассмотрим эти настройки подробнее
Начнем с общесистемных:

Настройки Loglevel, Logfile, SyslogFacility, SyslogPriority указывают степень
подробностей логов и виды сообщений, которые нужно заносить в логии. Можно также
указать место, где будут вести логи с систему логирования;

Параметр Hostmaster указывает почтовый адрес администратора, на который будут
направляться оповещения по email о состоянии и работе drweb-icapd;

Параметр User задает имя системного пользователя от имени которого будет работать
drweb-icapd;

Параметры Cache и DwsDirectory определяют каталоги размещения кеша самого drwebicapd и списков категорированных url, используемых для блокировки ресурсов;

Параметр Templates задает каталог с настраиваемыми шаблонами ответов
пользователям
Наиболее важными среди общесистемных являются параметры BindPort (по умолчанию
1344) и BindAddress (127.0.0.1) - адрес, на котором drweb-icapd будет обслуживать клиентов.
Для распределенных конфигураций или конфигураций с несколькими сетевыми
интерфейсами также потребуется корректировка параметра DrwebAddress, указывающего по
какому адресу нужно обращаться к демону антивирусной проверки drwebd.
В случае работы демона на одной машине с drweb-icapd и наличия для него прямого доступа
к файлам, обрабатываемым drweb-icapd, можно установить LocalScan = yes
Если же конфигурация распределенная или же демон работает от другого пользователя,
отличного от того, на котором работает drweb-icapd, то LocalScan = no и DrwebAddress
задается в виде inet (tcp) сокета. В этих же конфигурациях важна правильная настройка
параметров, определяющих таймауты обработки
далее рассмотрим настройки параметров сканирования. Здесь задаются типы проверяемого
mime-контента и размер проверяемых обьектов:
MimeStart
*
scan 1M pass
application
scan 1M pass
image
scan 1M pass
message
scan 1M pass
multipart
scan 1M pass
text
scan 1M pass
audio
pass all
video
pass all
application/x-mms-framed pass all
MimeEnd
Согласно приведенным выше параметрам проверяются все (*) объекты размером менее
1Mегабайта, объекты с большим размером пропускаются.
Аналогично настроена проверка объектов с типами application, image, message, multipart, text,
а вот типы audio, video, application/x-mms-framed будут пропускаться без проверки вообще.
Используя эти настройки можно определить политику компании в области ограничений на
пропуск или проверку тех или иных объектов. Их настройка также может быть необходима в
случае, если недостаточно аппаратной производительности.
Параметры, относящиеся к настройке реакций на те или иные события практически
полностью идентичны настройкам plugin_drweb для maild:

Incurable – действие в случае обнаружения неизлечимых объектов,

Suspicious - подозрительных,

Infected - зараженных,

Adware, Dialers, Jokes, Riskware, Hacktools - соответственно для рекламных программ,
звонилок, шуток, потенциально опасных и хакерских программ
В общем случае доступны действия Cure, move, pass, truncate, Report. Однако эти все
действия доступны не для всех типов вредоносных объектов. Так действие Cure (лечить)
возможно только для излечимых объектов
Аналогичные действия задаются для

ArchiveRestriction - действия в случае проверки архивных файлов которые превосходят
значений ряда параметров (степени сжатия, размера запакованных объектов, степени
вложенности), заданных в главном конфигурационном файле drweb32.ini

DaemonError, SkipObject – действия в случае сбоев или пропущенных объектов

LicenseError - действия в случае если превышаются лицензионные ограничения или
закончился срок действия клюбча.
Подробно все эти значения описаны в документации
Для настройки ограничений доступа можно использовать параметры BlockPorno,
BlockViolence, BlockWeapon, BlockGamble, BlockDrugs, BlockObscenity, BlockChats,
BlockTerrorism, BlockEmail, BlockSocialNetwork, BlockMalwareLinks, BlockSocialEngineering
– их назначение ясно из их наименований, каждый из этих параметров включает или
выключает доступа к одной из категорий сайтов, размещенных в составе предопределенных
.dws списков
Для полного отключения доступа ко всем сайтам, определенных в dws списках можно
использовать параметр BlockAll
Дополнить или переопределить предопределенные значения можно с помощью параметра –
WhiteDwsFiles. Он задает список разрешенных к посещению ресурсов т.е. тех, которые будут
исключены из проверки на соответствие вышеуказанным спискам
Параметры BlackHosts и WhiteHosts задают список файлов, в которых размещены списки
безусловно блокируемых хостов и хостов, доступ к которым полностью открыт и трафик
которых не проверяется
Правила и исключения задаются в секциях [def] и [match] соответственно. Подробно ихз
использование описано в файле, находящемся в /opt/drweb/doc/icapd/readme.rus.utf8, глава
“2.5 Переопределение конфигурационных параметров в зависимости от запроса”.
В ходе проверки drweb-icapd "знает" и может использовать значения URL текущего запроса,
имя пользователя, под которым он авторизовался на прокси-сервере, IP пользователя, от
которого пришел запрос на прокси-сервер, текущее системное время (часы и минуты). Все
эти значения можно использовать для составления условий и по ним переопределять
основные настройки.
Наиболее часто встречающиеся проблемы:

в случаях распределенных конфигураций нужно уделить должное внимание всем
настройкам межпроцессного взаимодействия (, в том числе настройкам сокетов и
таймаутам)

в случаях когда сервер не справляется с нагрузкой, необходимо ограничить
проверяемые mime-type, настроить правила в случае их использования, таймауты и
режимы сокетов
В частности

в настройках drweb-icapd для параметра KeepAlive заменить yes на no

в настройках самого squid’а для значения icap_persistent_connections сменить on на
off

в настройках демона drwebd в секции [daemon] файла drweb32.ini задать
параметры работы в части дочерних процессов, а также со стороны drweb-icapd
указать localscan.
Кроме этого:
2.1

необходимо понимать, что все запрашиваемые объекты проверяются _до_ помещения
их в кэш. Соответственно при повторном запросе все будет отдаваться из кеша,
повторная антивирусная проверка через drweb-icapd производится не будет.

списки .dws обновляются, как и антивирусные базы, модулем обновления, после
получения новых .dws процессу drweb-icapd отправляется сигнал HUP.

Задержка старта и рестарта (временная недоступность) icap-сервиса может быть связана
с загрузкой dws-списков в память и процессом мх их ресолва, поэтому необходимо
правильно настроить системные ресолвер и dns.

при большом трафике и нагрузке нужно подумать о перемещении Cache (заданного
через drweb-icapd.ini) в более быстрое или производительное место или замене
файловой системы
Контроль работы сервиса
Контроль работы сервиса доступен со страницы Dr.Web консоль для интернет-шлюзов
Unix, находящейся в папке Servers (Службы) сервера Webmin.
2.2
Настройка действий для зараженного трафика
Определить действия по отношению к зараженному трафику можно либо через Вебинтерфейс, либо напрямую — через редактирование конфигурационных файлов.
Для настройки через Веб-интерфейс необходимо в разделе Конфигурация перейти на
закладку Действия над угрозами и выставить необходимые значения для параметров
Infected (инфицированные файлы), Suspicious (подозрительные), Incurable (неизлечимые) и
т. д.
Предлагаемый список действий различается для вредоносных программ различного типа.
Так, для вирусов на выбор предлагаются действия Информировать (report — вывести htmlстраницу с соответствующим сообщением), Отсечь (truncate — обрезать файл до нулевой
длины и вернуть его получателю), Лечить (cure/pass — пропустить вылеченный файл),
Переместить (move — переместить файл в карантин и вывести html-страницу с
соответствующим сообщением). Для троянских программ действие Лечить недоступно —
программы такого типа не имеют механизма размножения, и их лечение невозможно.
Информация о возможных действиях доступна по нажатию на ссылку Подробнее.
Применить сделанные изменения можно, нажав кнопку Применить и сохранить изменения
внизу страницы.
2.3
Управление доступом к ресурсам сети Интернет
Управление доступом к ресурсам сети Интернет производится в разделе Конфигурация на
закладке Тематический фильтр.
Для управления черными и белыми списками нужно на закладку Системные настройки.
Списки должны находиться в файлах. Для добавления доступны списки хостов, доступ
которым запрещен, хостов, содержимое которых не будет проверяться на вирусы, и хостов,
которые не будут проверяться на наличие в тематических списках. Для добавления ресурсов
в список используется кнопка
.
Администратор имеет возможность отредактировать имя ресурса, используя кнопку
С помощью кнопки Отменить администратор может отменить изменения.
Настройка режима уведомления администратора о попытках доступа к заблокированным
ресурсам производится на закладке Действия над угрозами, адрес администратора задается
на закладке Системные настройки.
Применить сделанные изменения можно, нажав кнопку Применить и сохранить
изменения.
2.4
Настройка параметров работы карантина
Настройка параметров доступа к файлам карантина производится на закладке Системные
настройки.
Применить сделанные изменения можно, нажав кнопку Применить и сохранить
изменения.
2.5
Оптимизация проверки трафика
Администратор имеет возможность значительно уменьшить трафик — как внешний (за счет
использования возможности фильтрации доступа по MIME-типу и размеру или по имени
хоста), так и внутренний — используя режим preview.
Режим preview позволяет задавать файлы, которые не требуют проверки и, соответственно,
закачки ICAP-сервером (к примеру, потоковое видео и аудио). При использования режимов
Allow 204 и preview_size = 0 повышается общая скорость и комфортность работы конечного
пользователя.
2.6
Настройка правил обработки файлов в зависимости от их MIME-типа
Настройка правил обработки файлов в зависимости от их MIME-типа (идентификатора типа
файла, используемого в Интернете) производится на закладке Правила фильтрации
интернет-трафика.
Нажмите Добавить правило, чтобы добавить новое правило. Чтобы удалить правило,
нажмите кнопку рядом с правилом, которое необходимо удалить. Каждое правило состоит из
следующих полей:

Тип — основной MIME-тип файла;

Любой — файл любого типа;

application — исполняемые, архивированные файлы, документы в формате PDF, MS
Word и др.;

audio — аудиофайлы (mp3, wav, wma и др.);

image — изображения (gif, jpg, png, svg и др.);

message — сообщения между веб-серверами и клиентами;

multipart — контейнеры (почтовые файлы, запакованные файлы);

text — текст или исходный код (html, xml, css и др.);

video — видеофайлы (mpeg-1, mp4, wma);

model — файлы трехмерных моделей.

Формат — дополнительный MIME-тип файла. Может быть выбран из списка или
введен вручную.

Если размер — укажите, требуется ли фильтровать файлы по размеру и, если
требуется, введите размер в мегабайтах в соответствующем поле.

Действие — укажите действия для файлов указанного размера.

Иначе — укажите действия для всех остальных файлов данного типа.
Применить сделанные изменения можно, нажав кнопку Применить и сохранить
изменения.
2.7
Задание параметров для групп пользователей
Для разных пользователей или групп пользователей можно задавать индивидуальные
настройки доступа к интернет-ресурсам различных типов, указывая отличные от базовых
значения для некоторых параметров из файла конфигурации. Такое переопределение
параметров осуществляется с помощью специальных правил.
Примеры использования
Если требуется заблокировать доступ к интернет-ресурсам из списков Porno и Email в
рабочее время для пользователей из локальной сети, а также для пользователей с
определенного IP-адреса, то можно использовать следующее правило:
[match]
if (local_ip() || request_ip <<=
"87.249.57.20") && worktime() {
BlockPorno = yes
BlockEmail = yes
}
Если требуется заблокировать доступ к интернет-ресурсам из списка Terrorism в ночное
время (с 23:00 до 8:00) для пользователей с определенных IP-адресов, то можно задать
следующее правило:
[match]
if (request_ip <<= "93.185.182.46" ||
request_ip <<= "195.98.93.66")
&& (system_time>="23:00" ||
system_time<="8:00")
{
BlockTerrorism = yes
}
Чтобы запретить пользователю "edx" доступ к сети Интернет в нерабочее время:
[match]
if request_username=="edx" && !worktime()
{
BlockAll = yes
}
Обратите внимание, что функция worktime() должна быть предварительно определена в
секции [def].
Чтобы запретить доступ к конкретному интернет-ресурсу всем пользователям, чьи имена
удовлетворяют регулярному выражению "vasya.*", либо удовлетворяют любому из
регулярных выражений, перечисленных в файле, либо совпадают с одной из строк в файле,
используйте следующее правило:
[match]
if
(request_username ~ "vasya.*"
|| request_username ~ file:"/tmp/icapd/
users_re_block.txt"
|| request_username == file:"/tmp/icapd/
users_block.txt")
&& (request_url=="http://example.com/
mega_music.mp3")
{
BlockAll = yes
}
Внимание! Для получения возможности использовать переменные request_username и
request_ip необходима дополнительная настройка прокси-сервера Squid. Для этого требуется
отредактировать конфигурационный файл squid. conf (обычно находится в директории
/usr/local/squid/etc/).
2.8
Настройка шаблонов
Настройка шаблонов веб-страниц, которые показываются конечному пользователю в ответ
на попытку доступа к заблокированному содержимому (когда для соответствующих
параметров заданы действия информировать или переместить), производится на странице
Шаблоны.
При нажатии кнопку Предпросмотр показывается вид редактируемого шаблона.
Применить сделанные изменения можно, нажав кнопку Сохранить.
2.9
Отмена проведенных обновлений
При обновлении компонентов Dr.Web для интернет-шлюзов Unix сохраняет в рабочей
директории их резервные копии. Это позволяет вернуть компонент к предыдущему
состоянию в случае каких-либо проблем.
Чтобы восстановить компонент к предыдущему состоянию, запустите компонент Updater с
параметром командной строки -- restore=<components>, где <components> — это список имен
компонентов, разделенных запятыми.
Пример:
# ./update.pl --restore=drweb
Restoring backup for component 'drweb'...
Updates for component 'drweb' are frozen.
Run command './updater --unfreeze=drweb' to start updates again.
Backup for component 'drweb' has been restored!
Dr.Web (R) restore details:
Following files has been restored:
/var/drweb/bases/drwtoday.vdb
/var/drweb/bases/dwntoday.vdb
/var/drweb/bases/dwrtoday.vdb
/var/drweb/bases/timestamp
/var/drweb/updates/timestamp
2.10 Управление сервисом защиты интернет-трафика из Центра управления Dr.Web
Enterprise Security Suite
2.10.1 Подключение к Центру управления Dr.Web Enterprise Security Suite
Сервис защиты интернет-трафика может управляться из центра управления антивирусной
сети Dr.Web Enterprise Security Suite. Работа в режиме центральной защиты не требует
установки дополнительного программного обеспечения.
Для обеспечения этой возможности сервис может работать в одном из двух режимов:

Одиночном (standalone mode) режиме, когда сервис управляется локально. В этом
режиме конфигурационные и ключевые файлы находятся на локальных дисках.

Центральной защиты (enterprise mode), когда защитой компьютера управляет сервер
центральной защиты. В этом режиме некоторые функции и настройки Dr.Web для
интернет-шлюзов Unix могут быть изменены или заблокированы в соответствии с
общей (корпоративной) стратегией антивирусной защиты. В этом режиме используется
лицензионный ключевой файл с центрального сервера защиты. Персональный
лицензионный ключевой файл на локальном компьютере не используется.
Подключить сервис защиты интернет-трафика к Центру управления можно, настроив
компоненты Агент и Монитор для работы в режиме Enterprise и создав учетную запись на
сервере автоматически или вручную. Ниже будет рассмотрено автоматическое подключение.
Для запуска установленного продукта Dr.Web для интернет-шлюзов Unix в режиме
Enterprise необходимо вручную внести изменения в локальные конфигурационные файлы
компонентов Агент и Монитор. Для этого:
Зайдите на сервер, на котором установлен почтовый сервис (например, с помощью утилиты
pytty).
Откройте для редактирования (например, с помощью редактора vi) файл /etc/drweb/agent.conf
и отредактируйте в секции [EnterpriseMode] параметры UseEnterpriseMode и PublicKeyFile.
Параметр PublicKeyFile должен указывать путь к файлу drwcsd.pub, созданному в процессе
инсталляции сервера Dr.Web Enterprise Suite. В том случае, если сервис проверки почты
развернут на одном сервере с Dr.Web Enterprise Suite, в данном параметре можно указать
путь к месторасположению данного файла; в том случае, если сервисы расположены на
разных сервера, файл необходимо скопировать:
UseEnterpriseMode = Yes;
PublicKeyFile = /opt/drwcs/Installer/drwcsd.pub
Здесь drwcsd.pub — открытый ключ шифрования для доступа к ESS-серверу. Администратор
должен самостоятельно взять данный файл из соответствующей директории ESS-сервера и
положить его по указанному пути.
Параметры ServerHost и ServerPort должны содержать соответственно IP-адрес или имя хоста
сервера Dr.Web Enterprise Security Suite и номер порта этого сервера (по умолчанию 2193).
Если сервис проверки почты развернут на сервере Dr.Web Enterprise Security Suite, то можно
оставить значения по умолчанию.
ServerHost = 127.0.0.1
ServerPort = 2193
.
Аналогичным способом откройте для редактирования файл /etc/drweb/monitor.conf и
установите UseEnterpriseMode = Yes.
Значения ENABLE в файлах /etc/drweb/drwebd.enable и /etc/drweb/drweb-monitor.enable
должны быть установлены в 1.
Перезапустите сервис:
/etc/init.d/drweb-monitor start
Для работы Агента в режиме центральной защиты должен быть установлен пакет drwebagent-es.
После подключения сервер Dr.Web Enterprise Security Suite автоматически не импортирует
настройки подключенных компонентов. Если в эти настройки были внесены какие-либо
изменения — их необходимо экспортировать на сервер с использованием параметра
командной строки -- export-config (или -e) с обязательным указанием названия компонента
(DAEMON, MAILD):
/opt/drweb/drweb-agent –exportconfig ICAP
Внимание! При автоматическом создании учетной записи при первом запуске в режиме
Enterprise агент запрашивает регистрационные данные (идентификатор станции и пароль) у
сервера Dr.Web Enterprise Security Suite. Если в Dr.Web Enterprise Security Suite
установлен режим Ручное подтверждение доступа, действующий по умолчанию, то
администратору в течение одной минуты с момента запроса необходимо подтвердить
регистрацию добавляемого сервера через Веб-интерфейс администратора Центра
управления Dr.Web Enterprise Security Suite. Для подтверждения выберите пункт
Неподтвержденные станции в меню Администрирование, отметьте сервер и нажмите на
значок
или
.
Через Веб-интерфейс Центра управления можно управлять настройкой конфигурации
компонентов Dr.Web Icap Daemon и Dr.Web Daemon (антивирусного модуля, входящего в
базовый пакет Dr.Web). При запуске какого-либо из компонентов Агент запрашивает
конфигурацию с сервера Dr.Web Enterprise Security Suite.
Для сохранения введенных параметров необходимо нажать кнопку Сохранить.
Для того чтобы иметь возможность управлять параметрами защиты почтового сервера как из
Центра управления Dr.Web Enterprise Security Suite, так и из Веб-интерфейса, необходимо
нажать кнопку
и в появившемся окне выбрать значение Да для параметра Central
protection mode — и сохранить изменения.
После включения для веб-интерфейсов работы в enterprise-режиме локальные
конфигурационные файлы, лежащие в /etc/drweb/, перестают использоваться. Вся работа
ведется с Центром управления через агента — все настройки в этом режиме находятся на ЕСсервере в базе данных. При этом в случае изменения настроек из Центра управления все
изменения отображаются и в Веб-интерфейсе — Веб-интерфейс регулярно опрашивает
Центр управления и синхронизируется с ним.
2.10.2 Настройка запуска сервиса из Центра управления Dr.Web Enterprise Security Suite
Для запуска сервиса через Центр управления необходимо через Веб-интерфейс Центра
управления Dr.Web Enterprise Security Suite в настройках Монитора компонентов
Dr.Web для Unix установить флаги Daemon и ICAP для запуска соответствующих
компонентов комплекса.
Запустить сервис на локальной станции командой /etc/init.d/drweb-monitor start.
Проверить наличие сервиса можно командой ps ax.
Настройка базовых компонентов системы антивирусной защиты
2.11
Базовыми компонентами системы антивирусной фильтрации и ее обновления являются:
1.
непосредственно антивирусное ядро – файл drweb32.dll - и антивирусные базы (файлы
*.vdb). Эти компоненты обычно устанавливаются из пакета drweb-bases
2.
демон антивирусной проверки drwerbd, устанавливаемый из пакета drweb-daemon.
Демон постоянно находится в памяти и занимается обработкой запросов (вызовов) на
проверку и лечение файловых объектов. Тем самым демон является (для всех его
клиентов) высокоуровневым интерфейсом вызова функций ядра или если иначе
сервисом антивирусной проверки. Сама проверка осуществляется путем вызова
функций антивирусного ядра.
3.
программа-клиент антивирусного демона drwebdc. Предназначена для тестовых и
диагностических целей. Обычно применяется в случае необходимости проверки какихлибо тестовых случаев. Например при разработке собственных решений на основе
антивирусного ядра Dr.Web
4.
антивирусный сканер командной строки DrWeb. Предназначен для проверки файловой
системы самого сервера. Непосредственно в работе сервиса фильтрации не участвует
5.
модуль обновления. Предназначен для поддержания компонентов используемого
решения в актуальном состоянии Выполняет обновление (в зависимости от
используемой лицензии) антивирусных баз и ядра, модуля антиспама, а также черных
списков url, используемых для блокировки доступа тех или иных ресурсов.
Вышеописанные компоненты являются базой, но основе которой работают сервисы
фильтрацию. И их настройки непосредственно влияют на скорость самой проверки и
актуальность сервисов. В связи с этим после первоначальной настройки остальных
компонентов используемого решения рекомендуется проверить корректность настроек и
саму работоспособность этих базовых компонентов.
Настройки демона, сканера и модуля обновлений находятся в файле /etc/drweb/drweb32.ini
для Linux и Solaris, или же в /usr/local/etc/drweb для FreeBSD. Сам файл состоит из трех
секций:
1.
[Daemon] – секция содержит настройки для демона drwebd
2.
[Scanner] – секция содержит настройки для сканера командной строки
3.
[Updater] – секция содержит настройки для модуля обновления.
Модуль обновления запускается из системного планировщика crond от имени пользователя
системы DrWeb. Проверить периодичность обновлений можно при помощи crontab или же
непосредственно через /etc/cron.hourly.
В настройках модуля обновления наиболее важны параметры:

Timeout - таймаут на загрузку файла. По умолчанию равен 90. На медленных каналах
значение параметра имеет смысл увеличить

Tries - количество попыток. . По умолчанию равно 3.
В случае работы через прокси необходимо будет задать значение параметра ProxyServer (в
формате адрес:порт) и если прокси требует авторизации, то значения ProxyLogin и
ProxyPassword
В случае возникновения каких-либо проблем и ошибок можно установить необходимый
уровень детальности протокола работы в параметре LogLevel. Некоторым пользователям
также может быть полезной настройка cronsummary которая влияет на вывод процесса
обновления на stdout и затем в cron
В большинстве случаев остальные параметры можно оставить по умолчанию
Поскольку сканер командной строки в процессе работы сервисов фильтрации обычно не
используется, то настройки секции [scanner], где задаются настройки сканера командной
строки, можно оставить без изменений. В случае необходимости в этих настройках
прописываются действия в соответствии с обнаруженными угрозами, уровень детальности
протокола работы, пути к каталогу карантина, к антивирусному ядру и базам (параметр
может использоваться при необходимости проведения проверки с помощью иной версии баз
и ядра. Обычно этот параметр остается без изменений), а также путь к лицензионному ключу.
В настройках сканирования указывается необходимость включения эвристического
анализатора и список шаблонов файлов для случая проверки файлов по типам. Большинство
параметров можно указать ключами командной строки явно, тем самым переопределив
значения в конфигурационном файле.
Проверить работу сканера можно командой:
/opt/drweb/drweb –v
Текущей версией антивирусного сканера является 6.0.2.0, версией ядра 7.0.0.11250.
Итогом запуска в таком режиме должно быть обнаружение и чтение баз
Настройки секции [daemon], где задаются настройки демона drwebd рассмотрим подробнее.
Как и для сканера в секции задается путь к антивирусному ядру и базам, путь к
лицензионному ключу, путь к каталогу карантина, список шаблонов файлов для случая
проверки файлов по типам, уровень протоколирования. Кроме этого секция содержит ряд
специфичных настроек:

User. Параметр определяет от имени какого пользователя демон должен работать в
системе

PidFile. Параметр задает номер процесса и обслуживаемого сокета

ProcessesPool. Для текущей 6.x.x.x версии параметр задает характер порождения и
завершения дочерних процессов drwebd. Для предыдущих версий 5 и 4.xx аналогичные
настройки определяются через maxchildren и prefork.. Значение данного параметра
можно ограничить при работе на слабых или высоконагруженных серверах

Socket. Параметр задает номер сокета, на котором демон будет ожидать соединений от
клиентов. Параметр настраивается в случае наличия распределенной конфигурация с
хостами drwebd в разных сетях.

MailAddressesList и CheckEmailFiles. Параметры нужны для работы сервисами
фильтрации, построенными на базе предыдущей платформы (mailfilters)
Требуют также внимания параметры SocketTimeout (задает таймаут на общение по сокету) и
FileTimeout (задает таймаут на проверку переданного клиентом (и принятого демоном)
объекта). В случае частой проверки больших архивов или сложных файлов значения
параметров имеет смысл увеличить.
В секции также нужно проверить (и возможно изменить под характер проверяемых архивов)
параметры проверки файлов в архивах: MaxCompressionRatio, CompressionCheckThreshold,
MaxFileSizeToExtract, MaxArchiveLevel
Проверить работу демона можно аналогичным образом:
/opt/drweb/drwebd –v
Саму работоспособность демона можно проверить при помощи его клиента drwebdc. В том
числе с помощью этой утилиты (передавая на проверку архивы) можно проверить
разумность выставленных таймаутов.
/opt/drweb/drwebdc -V /tmp/xxxxx.rar
dwlib: set timeout for each scanning session with default to 0 seconds
dwlib: ipc: address default added
dwlib: tcp: connecting to 127.0.0.1:3000 ...
dwlib: tcp: connecting to 127.0.0.1:3000 - done
dwlib: tcp: connecting to 127.0.0.1:3000 ...
dwlib: tcp: connecting to 127.0.0.1:3000 - done
Scan -> Options: 0x80000000 Filename[28]: /tmp/xxxxx.rar
dwlib: tcp: connecting to 127.0.0.1:3000 ...
dwlib: tcp: connecting to 127.0.0.1:3000 - done
Results: daemon return code 0x100000 (after scanning/curing composite
object is clean)
Finally program exitcode=0.
2.11.1 Типичные ошибки и проблемы.



для модуля обновления:

В случае использования прокси-сервера - неверные настройки прокси (неверно
указанные хост, порт или пара логин/пароль). Данная проблема легко
диагностируется по лог-файлам

Ошибки в настройке самого прокси-сервера, в том числе случай, когда прокси
"режет" пользовательские http-заголовки или настроен с указанием слишком
длинных таймаутов.
для демона:

неверно указанный сокет, по которому демон вызываю клиенты

не полностью проведенное обновление (в том числе поверх ранее установленной
версии):

запуск версии 6.0 на конфигурационных файлах от пятой версии.

Запуск drwebd версии до 6.0.2 с антивирусным ядром и базами версии 7

Значительное количество дочерних процессов drwebd на слабых машинах.

Малые таймауты и неверные ограничения на проверку архивов.
общие ошибки

отсутствие поддержки 32битных приложений на 64битных системах.
3

при установке в системах с selinux и прочими расширениями безопасности
отсутствуют изменения, которые необходимо внести в их конфигурацию согласно
документации.

неверно указанные права на запуск компонентов (по умолчанию drwebd и update.pl
работают от имени DrWeb). Так модуль обновления часто по ошибке запукскаю от
root что приводит к созданию файлов которые затем при дальнейшей работе от
имени drweb модуль обновления не может удалить/перезаписать. Кроме этого
модуль обновления при обновлении компонентов отсылает sighup тем
компонентам, чьи базы были обновлены. В связи с этим у него должно быть
достаточно прав

При работе с использованием нескольких ключевых файлов необходимо
убедиться, что ключи прописаны параметром key для соответствующего
компонента в секциях [daemon] и [scanner]

Работа с файлом update.drl как с текстовым, а не бинарным файлом, в результате
модуль обновления лишь "ходит" по тому что указано в /var/drweb/bases/update.drl
Тестирование работоспособности
1.
Проверяем работоспособность антивирусного демона drwebd с помощью drwebdc
/opt/drweb/drwebdc -sv -si
В случае отсутствия проблем демон должен ответить примерно так:
- Version: DrWeb Daemon 6.0
- Description: Dr.Web (R) daemon for Linux v6.0.2.0
Copyright (c) Igor Daniloff, 1992-2012
Engine version: 7.0.0.11250 <API:2.2>
Однако мы можем получить и отчет об ошибке:
Смотрим в файл /etc/hosts
cat /etc/hosts
Для корректной работы drwebdc в файле должен быть прописан
127.0.0.1
localhost.localdomain localhost
В случае иного содержания, например (127.0.0.1
мы можем использовать команду иного вида:
appliance appliance”), для проверки
appliance:~# /opt/drweb/drwebdc -sv -si -n127.0.0.1
Теперь проверяем, обнаруживает ли демон вирусы. Для этого берем тело тестового
вируса eicar (например, вырезаем с помощью grep X5O из документации (файла
/opt/drweb/doc/readme.eicar)) и отдаем ему через клиента на проверку:
grep X5O /opt/drweb/doc/readme.eicar | /opt/drweb/drwebdc -V –
В случае отсутствия ошибок мы должны получить сообщение типа:
dwlib: set timeout for each scanning session with default to 0 seconds
dwlib: ipc: address default added
dwlib: tcp: connecting to 127.0.0.1:3000 ...
dwlib: tcp: connecting to 127.0.0.1:3000 - done
dwlib: tcp: connecting to 127.0.0.1:3000 ...
dwlib: tcp: connecting to 127.0.0.1:3000 - done
dwlib: tcp: connecting to 127.0.0.1:3000 ...
dwlib: tcp: connecting to 127.0.0.1:3000 - done
Results: daemon return code 0x20 (known virus is found)
Finally program exitcode=0x1.
Results: daemon return code 0x20 (known virus is found)
Ошибка типа “Invalid option action on infected (-V?)” говорит нам о том, что демон,
используемый в системе, имеет старую версию. В этом случае используем иной вид
команды:
grep X5O /opt/drweb/doc/readme.eicar | /opt/drweb/drwebdc -n127.0.0.1 –i
В обоих случаях сообщение типа “Results: daemon return code 0x20 (known virus is
found)” говорит о нормальной работе демона.
2.
Проверяем работоспособность интернет-шлюза:
а)
смотрим, запущен ли он, и слушает ли свой сокет:
ps -Af |grep drweb-icapd
netstat -lnp |grep drweb-icapd
В списке вывода должен присутствовать drweb-icapd.real, слушающий свой
127.0.0.1:1344.
В случае отсутствия необходимых процессов переходим к поиску причин
возникновения проблем с помощью логов — разбираемся, почему не были запущены
процессы, и/или почему они не используют нужные сокеты.
б)
проверяем, отвечает ли запущенный процесс:
telnet 127.0.0.1 1344
Видно, что отвечает, выходим — говорим q
в)
убеждаемся, что squid или иной прокси, с которым работает drweb-icapd через модуль
ICAP, сконфигурирован правильно и работает.
Пробуем загрузить вирус с http://eicar.org/download/eicar.com
wget -e "HTTP_PROXY=http://127.0.0.1:3128" -S http://eicar.org/download/eicar.com
при этом адрес прокси и порт нужно проставить корректный.
Необходимо убедиться, что загрузится не eicar.com (файл размером 68 байт), а html с
уведомлением о невозможности доставки (действие по умолчанию).
В случае отсутствия wget можно проверить работу прокси напрямую через telnet:
telnet 127.0.0.1 3128
get http://eicar.org/download/eicar.com http/1.1
HTTP/1.0 200 OK
Date: Tue, 24 Jan 2012 15:31:40 GMT
Server: Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g
4
Тестирование производительности
4.1
Тестирование производительности системы фильтрации интернет-трафика
К сожалению, не существует распространенных утилит, позволяющих произвести надежное
тестирование производительности системы фильтрации интернет-трафика. Все они требуют
развертывания тестовой сети и организации системы загрузки трафика на локальные
машины. В связи с этим в данном тесте мы ограничимся тестированием производительности
самого сервера, то есть определением того количества запросов, который он может
обрабатывать.
Для данного теста наиболее подходит утилита http_load.
Внимание! По умолчанию http_load собирается без поддержки протокола https. Для
обеспечения тестирования необходимо собирать http_load с поддержкой SSL.
Для проведения данного теста необходимо настроить локальную машину, с которой
производится тестирование, на выход в Интернет через Dr.Web для интернет-шлюзов Unix.
Для Linux для этого необходимо выполнить команды:
Route del default
Route add default gw 192.168.1.100
Проверить результат настройки можно через команду route -n
Сервер Dr.Web для интернет-шлюзов Unix должен быть настроен на выход в Интернет
(напрямую, либо через какую-либо машину).
Пример работы команды http_load
http_load –rate 10 –seconds 60 ./http_load_utls
В данном примере:
http_load_utls — файл со списком адресов, по которым производится загрузка.
Рекомендуется указывать несколько адресов, как минимум три.
Результатом работы утилиты будут данные о количестве скачиваемых байт в секунду.
Внимание! Особенности работы антивирусов на системе фильтрации интернет-трафика:
1.
Все файлы проверяются до отдачи их пользователю. Поэтому даже если http_load
оборвет процесс тестирования, не получив файла, то он будет продолжать закачиваться
в сквид. Поэтому повторный запуск http_load может показать более низкую
производительность, так как сервер будет занят предыдущей задачей, об отмене
которой он не знает. Крайним случаем является ситуация, когда http_load вообще не
сможет ничего закачать, так как сервер будет занят до предела предыдущей задачей.
Время тестирования: 40 минут с учетом установки и настройки необходимых утилит.
Тестирование функционирования системы фильтрации интернет-трафика
4.2
Для проведения данного теста необходимо настроить локальную машину, с которой
производится тестирование, на выход в Интернет через Dr.Web для интернет-шлюзов Unix.
Для Linux для этого необходимо выполнить команды:
Route del default
Route add default gw 192.168.1.100
Проверить результат настройки можно через команду route -n
Перед началом тестирования на Dr.Web для интернет-шлюзов Unix необходимо произвести
следующие изменения:
1.
Через Веб-интерфейс Dr.Web для интернет-шлюзов Unix настроить выход в Интернет
(напрямую, либо через какую-либо машину) и применить сделанные изменения.
2.
Указать адрес, по которому будут приходить уведомления о найденных вирусах и/или
спаме. Для этого необходимо зайти на устройство (локально или по ssh) и
отредактировать файл /etc/drweb/drweb_icapd.conf. В данном файле необходимо:
2.1. В секции [Icapd] для параметра Hostmasterl прописать адрес, по которому будут
приходить уведомления.
2.2. Перезапустить сервис фильтрации интернет-трафика с помощью команды
/etc/init.d/drweb-icapd restart.
Для проверки системы функционирования системы фильтрации достаточно скачать на
машину, с которой производится тестирование, какой-либо файл с вирусным кодом.
Например:
ftp http://www.eicar.com/download/eicarcom2.zip
Результатом выполнения данного теста должно стать письмо, пришедшее на адрес,
указанный в параметре AdminMail, с уведомлением о закачке вируса.
Внимание! По умолчанию для тестовой среды доступ в сеть интернет закрыт. В связи с этим
часть вирусов из тестовых коллекций может не обнаруживаться. Для проведения
тестирования на качество детектирования на основе коллекций, содержащих актуальные
вредоносные файлы необходимо либо провести обновление вручную либо при заказе
тестирования указать необходимость доступа в сеть Интернет для проведения обновлений
Время тестирования: 40 минут с учетом установки и настройки необходимых утилит.