InfoWatch Traffic Monitor Руководство по установке и конфигурированию
I N F O WAT C H T R A F F I C M O N I TO R
Руководство по установке и
конфигурированию
© ЗАО "ИнфоВотч"
Тел. +7 (495) 229-00-22 • Факс +7 (495) 229-00-22
http://www.infowatch.ru/
Дата редакции: март 2009 года
СОДЕРЖАНИЕ
ВВЕДЕНИЕ.............................................................................................................................................................................. 6
Аудитория........................................................................................................................................................................... 6
Структура руководства..................................................................................................................................................... 6
Дополнительная документация ...................................................................................................................................... 6
Условные обозначения .................................................................................................................................................... 7
ГЛАВА 1. ВВЕДЕНИЕ В INFOWATCH TRAFFIC MONITOR ............................................................................................ 8
1.1. Основные сведения о Системе ............................................................................................................................... 8
1.2. Состав Системы......................................................................................................................................................... 8
1.3. Транспортные режимы InfoWatch Traffic Monitor................................................................................................... 9
1.4. Информация о лицензии .......................................................................................................................................... 9
ГЛАВА 2. ПОДГОТОВКА К УСТАНОВКЕ.......................................................................................................................... 10
2.1. Схема развертывания Системы............................................................................................................................ 10
2.2. Аппаратные и программные требования ............................................................................................................. 11
2.2.1. Traffic Monitor Server. Транспортные режимы: нормальный, прозрачный, обычная копия .................. 11
2.2.2. Traffic Monitor Server. Транспортный режим: SPAN-копия......................................................................... 12
2.2.3. Сервер СУБД Oracle........................................................................................................................................ 14
2.2.4. Management Console ....................................................................................................................................... 15
ГЛАВА 3. УСТАНОВКА СИСТЕМЫ ................................................................................................................................... 17
3.1. Схема базы данных ................................................................................................................................................. 17
3.1.1. Подготовка к созданию схемы базы данных ............................................................................................... 17
3.1.2. Рекомендации по созданию схемы базы данных ....................................................................................... 17
3.1.3. Создание схемы базы данных ....................................................................................................................... 18
3.2. Traffic Monitor Server. Транспортные режимы: нормальный, прозрачный, обычная копия .......................... 23
3.2.1. Состав Traffic Monitor Server........................................................................................................................... 23
3.2.2. Рекомендации по установке........................................................................................................................... 24
3.2.3. Установка и настройка .................................................................................................................................... 24
3.3. Traffic Monitor Server. Транспортный режим SPAN-копия.................................................................................. 27
3.3.1. Рекомендации по установке........................................................................................................................... 27
3.3.2. Установка и настройка Sniffer......................................................................................................................... 30
3.3.3. Установка и настройка Traffic Monitor Server ............................................................................................... 31
3.3.4. Установка и настройка Forwarder .................................................................................................................. 33
3.4. Подсистема загрузки объектов в удаленную базу данных ............................................................................... 34
3.4.1. Настройка подсистемы на стороне сервера – загрузчика объектов........................................................ 35
3.4.2. Создание копии подсистемы на стороне сервера – загрузчика объектов.............................................. 37
3.4.3. Настройка подсистемы на стороне сервера – перехватчика объектов .................................................. 39
3.4.4. Настройка протоколирования работы сценариев....................................................................................... 41
3.5. Management Console ............................................................................................................................................... 41
3.5.1. Рекомендации по установке........................................................................................................................... 42
3.5.2. Описание установки ........................................................................................................................................ 42
3.5.3. Дополнительная настройка для отправки рапорта .................................................................................... 42
3.6. Лицензирование....................................................................................................................................................... 43
3.6.1. Особенности использования лицензионного ключа .................................................................................. 43
3.6.2. Установка лицензионного ключа ................................................................................................................... 44
3.6.3. Замена лицензионного ключа........................................................................................................................ 44
4 InfoWatch Traffic Monitor
ГЛАВА 4. НАСТРОЙКА СИСТЕМЫ................................................................................................................................... 46
4.1. Режимы работы Transparent Proxy при перехвате HTTP-трафика .................................................................. 46
4.2. Сбор информации о пользователях, выполняющих HTTP-запросы............................................................... 47
4.3. Настройка файла tm.conf........................................................................................................................................ 48
4.3.1. Секция [GENERAL] .......................................................................................................................................... 48
4.3.2. Секция [AUTO_RESTART] .............................................................................................................................. 49
4.3.3. Секция [SMTPD] ............................................................................................................................................... 49
4.3.4. Секция [MESSED] ............................................................................................................................................ 50
4.3.5. Секция [DELIVERD].......................................................................................................................................... 51
4.3.6. Секция [SNIFFER] ............................................................................................................................................ 51
4.3.7. Секция [QUEUE]............................................................................................................................................... 51
4.3.8. Секция [PROXY] ............................................................................................................................................... 52
4.3.9. Секция [PROXY_ICQ] ...................................................................................................................................... 52
4.3.10. Секция [PROXY_HTTP] ................................................................................................................................. 53
4.3.11. Секция [PROXY_SMTP] ................................................................................................................................ 55
4.3.12. Секция [FORWARDER] ................................................................................................................................. 55
4.3.13. Секция [CAS]................................................................................................................................................... 56
4.3.14. Секция [DBLOADER] ..................................................................................................................................... 57
4.3.15. Секция [FILTER] ............................................................................................................................................. 57
4.3.16. Секция [ORACLE]........................................................................................................................................... 57
4.3.17. Секция [EXPRESSD]...................................................................................................................................... 57
4.3.18. Секция [DEVMON].......................................................................................................................................... 58
4.3.19. Секция [EXTRACTOR]................................................................................................................................... 58
4.3.20. Секция [UPDATER] ........................................................................................................................................ 58
4.3.21. Секция [SNMPD]............................................................................................................................................. 58
4.3.22. Секция [LDAP]................................................................................................................................................. 59
4.4. Настройка расширенного протоколирования...................................................................................................... 59
4.5. Обработка архивов и вложений. Настройка файла Detector.conf.................................................................... 59
4.6. Настройка интеграции с Postfix.............................................................................................................................. 60
4.7. Перенаправление HTTP-трафика в нормальном и прозрачном транспортном режимах............................ 62
4.7.1. Настройка iptables для передачи HTTP-трафика через Transparent Proxy............................................. 62
4.7.2. Настройка пользовательских компьютеров для работы по протоколу HTTP ........................................ 64
4.8. Перенаправление ICQ-трафика в нормальном и прозрачном транспортном режимах............................... 64
4.8.1. Настройка iptables для передачи ICQ-трафика через Transparent Proxy................................................ 64
4.8.2. Настройка пользовательских компьютеров для работы по протоколу ICQ ........................................... 66
ГЛАВА 5. ОБНОВЛЕНИЕ СИСТЕМЫ ............................................................................................................................... 67
5.1. Порядок обновления Системы .............................................................................................................................. 67
5.1.1. Подготовка к обновлению Системы.............................................................................................................. 67
5.2. Обновление схемы базы данных .......................................................................................................................... 67
5.3. Обновление Traffic Monitor Server ......................................................................................................................... 69
ГЛАВА 6. УДАЛЕНИЕ СИСТЕМЫ...................................................................................................................................... 71
6.1. Удаление схемы базы данных............................................................................................................................... 71
6.1.1. Подготовка к удалению схемы базы данных............................................................................................... 71
6.1.2. Описание процесса удаления........................................................................................................................ 71
6.2. Удаление Traffic Monitor Server .............................................................................................................................. 72
6.3. Удаление Management Console............................................................................................................................. 73
ПРИЛОЖЕНИЕ A. РЕКОМЕНДАЦИИ ПО УСТАНОВКЕ СУБД ORACLE.................................................................... 74
A.1. Сервер СУБД Oracle ............................................................................................................................................... 74
A.1.1. Рекомендации по установке сервера СУБД Oracle.................................................................................... 74
Содержание 5
A.1.2. Подготовка к установке................................................................................................................................... 74
A.1.3. Установка сервера СУБД Oracle ................................................................................................................... 76
A.2. Клиент СУБД Oracle ................................................................................................................................................ 86
A.2.1. Рекомендации по установке клиента СУБД Oracle на платформу Linux................................................ 86
A.2.1.1. Подготовка к установке........................................................................................................................... 87
A.2.1.2. Установка клиента СУБД Oracle............................................................................................................ 88
A.2.2. Рекомендации по установке клиента СУБД Oracle на платформу Microsoft Windows ......................... 89
A.2.3. Настройка параметров соединения с сервером СУБД Oracle ................................................................. 89
A.2.4. Проверка взаимодействия между клиентом и сервером Oracle.............................................................. 90
ПРИЛОЖЕНИЕ B. РАЗРЕШЕНИЕ ПРОБЛЕМ ................................................................................................................ 91
B.1. Проблемы со схемой базы данных....................................................................................................................... 91
B.2. Проблемы с Traffic Monitor Server ......................................................................................................................... 94
ГЛОССАРИЙ......................................................................................................................................................................... 95
УКАЗАТЕЛЬ .......................................................................................................................................................................... 98
ВВЕДЕНИЕ
InfoWatch Traffic Monitor (далее InfoWatch Traffic Monitor или Система) – это распределенная многоком-
понентная система, предназначенная для контроля над различными видами трафика (SMTP, HTTP, ICQ),
а также над данными, поступающими от системы InfoWatch Device Monitor.
В настоящем руководстве вы можете найти сведения по установке и настройке InfoWatch Traffic Monitor.
Аудитория
Информация, содержащаяся в руководстве, предназначена для пользователей, выполняющих установку
и настройку InfoWatch Traffic Monitor.
Руководство рассчитано на пользователей, знакомых с основами работы в среде той операционной сис-
темы, в которой выполняется установка компонентов InfoWatch Traffic Monitor (Linux, Microsoft Windows).
InfoWatch Traffic Monitor взаимодействует с базой данных, находящейся под управлением СУБД Oracle.
Поэтому при настройке Системы также необходимы навыки администрирования СУБД Oracle.
Структура руководства
В состав руководства входят следующие разделы:
• Глава 1. Введение в InfoWatch Traffic Monitor (стр. 8).
Содержит общие сведения о Системе.
• Глава 2. Подготовка к установке (стр. 10).
Описывает требования к аппаратному и программному обеспечению, необходимому для работы
Системы; порядок установки компонентов Системы.
• Глава 3. Установка системы (стр. 17).
Содержит рекомендации по установке компонентов Системы и описание установки. Также здесь
описываются правила получения и установки лицензионного ключа.
• Глава 4. Настройка системы (стр. 46).
В разделе рассматриваются вопросы, связанные с настройкой Системы (настройка конфигураци-
онных файлов, организация взаимодействия между компонентами Системы и пр.).
• Глава 5. Обновление системы (стр. 67).
В разделе содержится информация по обновлению компонентов Системы.
• Глава 6. Удаление системы (стр. 71).
Приводятся сведения по удалению компонентов Системы.
• Приложение A. Рекомендации по установке СУБД Oracle (стр. 74).
Содержит рекомендации по установке серверной и клиентской части СУБД Oracle. Также здесь
приводятся рекомендации по настройке взаимодействия между базой данных и другими компонен-
тами Системы.
• Приложение B. Разрешение проблем (стр. 91).
В приложении описываются проблемы, которые могут возникнуть в процессе установки и настрой-
ки Системы, а также способы их разрешения.
Дополнительная документация
Сведения по некоторым дополнительным вопросам вы можете найти в следующих документах:
• «InfoWatch Traffic Monitor. Руководство пользователя».
Введение 7
В документе описывается работа с InfoWatch Traffic Monitor (настройка конфигурации, экс-
порт/импорт данных, правила составления сценария обработки объектов).
• «InfoWatch Device Monitor. Руководство пользователя»
Содержит описание принципов работы системы InfoWatch Device Monitor.
В настоящем руководстве не рассматриваются вопросы установки и настройки СУБД Oracle. За получе-
нием необходимых сведений вы можете обратиться к соответствующей документации.
Условные обозначения
Для наглядности в тексте документации используются различные стили оформления. Области примене-
ния стилей указаны в таблице 1.
Таблица 1. Стили оформления
Стиль оформления Область применения
Полужирный шрифт Названия программ (при первом упоминании), эле-
ментов графического пользовательского интер-
фейса. Выделение терминов, определений
Курсив Названия документов, оглавление в начале разде-
лов и подразделов документа. При описании таб-
лиц – названия и значения атрибутов. Выделение
некоторых элементов текста (если не предусмот-
рены другие стили оформления)
Шрифт Courier New Имена файлов, примеры текста программ. При
описании конфигурационных файлов – значения
параметров, примеры настройки
ШРИФТ COURIER NEW (ВЕРХНИЙ РЕГИСТР) Названия переменных, параметров (при описании
конфигурационных файлов), ключевые слова SQL,
инструкции PL/SQL, типы данных, привилегии
В таблице 2 приводятся условные обозначения, используемые при описании командной строки.
Таблица 2. Условные обозначения для командной строки
Условное обозначение Расшифровка
Шрифт Courier New Команды и параметры
Шрифт Courier New (курсив) Значения, вводимые пользователем
[Параметр] Необязательные параметры
Значение 1 | Значение 2 Набор, из которого нужно указать одно значение
ГЛАВА 1. ВВЕДЕНИЕ В INFOWATCH TRAFFIC
MONITOR
В этой главе содержится следующая информация:
• Основные сведения о Системе (п. 1.1 на стр. 8).
• Состав Системы (п. 1.2 на стр. 8).
• Транспортные режимы InfoWatch Traffic Monitor (п. 1.3 на стр. 9).
• Информация о лицензии (п. 1.4 на стр. 9).
1.1. Основные сведения о Системе
Назначение InfoWatch Traffic Monitor заключается в контроле над информационными потоками, которые
передаются по протоколам SMTP, HTTP, ICQ. Кроме того, в Системе осуществляется анализ данных,
полученных от InfoWatch Device Monitor.
Основные функции InfoWatch Traffic Monitor:
• перехват трафика данных, передаваемых по протоколам SMTP, HTTP, ICQ (OSCAR);
Примечание!
При использовании перехватчика ICQ-трафика передача файлов по протоколу ICQ не поддержи-
вается.
• анализ содержимого перехваченного трафика с целью выявления нарушений корпоративной поли-
тики безопасности;
• фильтрация трафика путем выдачи разрешения/запрещения на доставку определенных данных;
• анализ данных (теневых копий файлов), полученных от системы InfoWatch Device Monitor с целью
выявления нарушений корпоративной политики безопасности.
1.2. Состав Системы
Компоненты, входящие в состав InfoWatch Traffic Monitor, перечислены в таблице 3.
Таблица 3. Компоненты InfoWatch Traffic Monitor
Компонент Назначение
Traffic Monitor Server Контроль и анализ трафика, передаваемого по
протоколам SMTP, HTTP, ICQ.
включает в себя отдельные подсистемы для: кон-
троля SMTP-трафика; доставки и анализа объектов Анализ теневых копий файлов, передаваемых от
InfoWatch Device Monitor; контроля HTTP- и ICQ- InfoWatch Device Monitor.
трафика (Transparent Proxy)
Контентный анализ текстовых данных,
а также подсистемы анализа: Decision and Analysis
Принятие решения о дальнейших действиях над
Engine (DAE) (интегрирована с подсистемами кон-
объектами, прошедшими анализ.
троля), Content Analysis Server (CAS)
Загрузка информации в локальную или удаленную
и подсистему загрузки объектов в удаленную базу
базу данных
данных
Management Console Управление Системой
Введение в InfoWatch Traffic Monitor 9
Компонент Назначение
CreateSchemaWizard Создание/обновление/удаление схемы базы дан-
ных
1.3. Транспортные режимы InfoWatch Traffic
Monitor
Система InfoWatch Traffic Monitor имеет три транспортных режима: нормальный, прозрачный и режим ко-
пии. Условия, в соответствии с которыми определяется транспортный режим для различных объектов
(SMTP-писем, HTTP-запросов и др.), задаются при обработке объектов в Системе.
Различие между режимами работы заключается в особенностях транспортировки объектов.
Нормальный режим. Перехват, анализ и дальнейшая транспортировка объектов выполняется посред-
ством InfoWatch Traffic Monitor. В этом режиме возможность доставки объекта получателям зависит от
результатов анализа объекта.
Прозрачный режим. Отличается от предыдущего режима только тем, что доставка объекта получате-
лям осуществляется всегда (т.е. вне зависимости от результатов анализа).
Режим копии. В данном режиме InfoWatch Traffic Monitor получает копии объектов. Отличие режима ко-
пии от двух других заключается в том, что транспортировка объектов выполняется без участия Системы.
Таким образом, задачей Системы является только анализ объектов. В Системе поддерживаются две
разновидности этого режима: обычная копия и SPAN-копия.
Режим обычной копии поддерживается только для SMTP-трафика. При этом копия трафика поступает от
корпоративного почтового сервера.
В режиме SPAN-копии передача трафика осуществляется через коммутатор CISCO. Копия трафика, про-
ходящего через коммутатор, перехватывается компонентом Sniffer и затем передается на анализ.
1.4. Информация о лицензии
Функциональность Системы зависит от выбранной лицензии. Лицензированию подвергаются компонен-
ты, отвечающие за перехват трафика SMTP, HTTP, ICQ, а также за прием объектов от системы InfoWatch
Device Monitor.
При выборе лицензии необходимо определить следующее:
• какой трафик будет перехватываться Системой;
• нужно ли принимать данные от InfoWatch Device Monitor.
Прием и, как следствие, фильтрация объектов может осуществляться только лицензированными пере-
хватчиками.
Важная информация!
Прием тех видов трафика, которые не подлежат контролю, должен осуществляться минуя Систему.
Для ознакомления с Системой предусмотрен пробный период длительностью 30 дней. В течение этого
времени Система может эксплуатироваться без установки полной лицензии. Однако если вы планируете
продолжить эксплуатацию Системы, то вам нужно установить лицензию на используемые перехватчики.
В противном случае, по истечении пробного периода работа всех нелицензированных перехватчиков бу-
дет остановлена.
Информация по использованию лицензионного ключа приводится в п. 3.6 на стр. 43.
ГЛАВА 2. ПОДГОТОВКА К УСТАНОВКЕ
В этой главе содержится следующая информация:
• Схема развертывания Системы (п. 2.1 на стр. 10).
• Аппаратные и программные требования (п. 2.2 на стр. 11).
2.1. Схема развертывания Системы
Шаг 1. Подготовка к созданию базы данных
Перед развертыванием Системы необходимо выполнить установку сервера СУБД Oracle. Рекомендации
по установке сервера базы данных приводятся в приложении A.1 на стр. 74.
К началу развертывания Системы сервер СУБД Oracle должен быть установлен и запущен.
Шаг 2. Проверка аппаратных и программных требований к Системе
Перед тем как устанавливать Систему убедитесь, что для каждого компонента соблюдены необходимые
аппаратные и программные требования (п. 2.2 на стр. 11).
Шаг 3. Проверка характеристик канала передачи данных (только для работы с
удаленной базой данных)
Если перехваченные объекты необходимо загружать в удаленную базу данных (п. 3.4 на стр. 34), то убе-
дитесь, что канал передачи данных удовлетворяет характеристикам, приведенным в таблице 4.
Таблица 4. Требования к каналу для загрузки объектов в удаленную базу данных
Характеристика канала связи Требования
Минимальная скорость передачи данных 128 Кбит/с
Протокол TCP/IP
Шаг 4. Настройка коммутатора CISCO (только для работы с SMTP, HTTP- и ICQ-
трафиком в режиме SPAN-копии)
Передача трафика в режиме SPAN-копии должна осуществляться через коммутатор Cisco Catalyst 2960
Series.
Примечание:
Допускаются и другие модели коммутаторов с поддержкой функции SPAN.
Требования к дополнительному аппаратному обеспечению, необходимому для работы в режиме SPAN-
копии, приводятся в п. 2.2.2 на стр. 12.
Чтобы организовать передачу SMTP, HTTP- и ICQ-трафика в режиме SPAN-копии, Traffic Monitor Server
должен быть подключен к коммутатору CISCO через SPAN порт. Поэтому после установки и настройки
коммутатора CISCO вам нужно инициализировать SPAN порт (рекомендации по инициализации приво-
дятся в руководстве по установке и настройке коммутатора CISCO).
Шаг 5. Развертывание Системы
Развертывание Системы выполняется в следующем порядке:
1. Создание схемы базы данных (п. 3.1 на стр. 17).
2. Установка Traffic Monitor Server (п. 3.2 на стр. 23).
Подготовка к установке 11
• транспортный режим нормальный, прозрачный или обычная копия (п. 3.2 на стр. 23);
• транспортный режим SPAN-копия (п. 3.3 на стр. 27).
3. Только при необходимости загружать перехваченные объекты в удаленную базу данных: на-
стройка подсистемы загрузки объектов в удаленную базу данных (п. 3.4 на стр. 34).
4. Установка лицензионного ключа (п. 3.6 на стр. 43).
5. Только при контроле HTTP-трафика в нормальном или прозрачном транспортном режиме: На-
стройка режима работы Transparent Proxy (п. 4.1 на стр. 46).
6. Только при контроле HTTP- или ICQ-трафика в нормальном или прозрачном транспортном ре-
жиме. Настройка перенаправления трафика через Transparent Proxy:
• перенаправление HTTP-трафика (п. 4.7 на стр. 62);
• перенаправление ICQ-трафика (п. 4.8 на стр. 64).
7. Установка Management Console (п. 3.5 на стр. 41).
2.2. Аппаратные и программные требования
В настоящем подразделе приводятся требования к аппаратному и программному обеспечению для каж-
дого компонента Системы:
• Traffic Monitor Server. Транспортные режимы: нормальный, прозрачный, обычная копия (п. 2.2.1 на
стр. 11).
• Traffic Monitor Server. Транспортный режим: SPAN-копия (п. 2.2.2 на стр. 12).
• Сервер СУБД Oracle (п. 2.2.3 на стр. 14).
• Management Console (п. 2.2.4 на стр. 15).
2.2.1. Traffic Monitor Server. Транспортные режимы:
нормальный, прозрачный, обычная копия
Типовая конфигурация Traffic Monitor Server при скорости трафика 50 Мбит/с:
• Сервер: HP DL360 Intel Xeon.
• Процессор: Intel Xeon x86 с частотой 3 ГГц. Требуются 2 процессора с 4 ядрами каждый.
• Оперативная память: 2 Гб.
• Жесткий диск: 160 Гб.
При более высоких скоростях трафика рекомендуется использовать кластеры Traffic Monitor Server. Один
кластер может содержать до 50 экземпляров Traffic Monitor Server включительно. Не рекомендуется ис-
пользовать более 4 кластеров.
Требования к программному обеспечению:
• Операционная система: Red Hat Enterprise Linux ES 4 update 3 x86-32, Red Hat Enterprise Linux
AS 4 update 3 x86-32, Red Hat Enterprise Linux 4 update 5 x86-32.
Важная информация!
При установке операционной системы необходимо выбрать английскую локализацию.
Для корректной работы InfoWatch Traffic Monitor, установите в составе операционной системы сле-
дующие пакеты:
− e2fsprogs,
− glibc,
− iptables,
12 InfoWatch Traffic Monitor
Примечание:
Установка iptables выполняется в тех случаях, когда необходим перехват HTTP- и/или ICQ-
трафика в нормальном или прозрачном транспортном режиме.
− krb5-libs,
− libgcc,
− libstdc++,
− libxml2,
− openldap,
− zlib,
− gzip,
− bzip2,
− unzip,
− lha,
− tar.
• Архиваторы: unrar версии 3.6.8, arj версии 3.10.
• Клиент СУБД Oracle версии 11g R1 (11.1.0.6.0).
• Только для контроля SMTP-трафика в режимах: нормальный и прозрачный, обычная копия.
Почтовый сервер: Postfix (входит в состав дистрибутива Red Hat Enterprise Linux 4).
Для загрузки перехваченных объектов в удаленную базу данных (см. п. 3.4 на стр. 34) необходимо
также программное обеспечение, поддерживающее работу по ftp-протоколу:
• Nc FTP Client версии 3.1.6.
Устанавливается на стороне Traffic Monitor Server, расположенного удаленно от базы данных.
• FTP сервер. Допускается использование сервера vsftpd из дистрибутива операционной системы
либо другого FTP-сервера, совместимого с установленной операционной системой.
Устанавливается на стороне Traffic Monitor Server, отвечающего за прием объектов от других эк-
земпляров Traffic Monitor Server и загрузку принятых объектов в базу данных.
2.2.2. Traffic Monitor Server. Транспортный режим:
SPAN-копия
Передача трафика в режиме SPAN-копии должна осуществляться через коммутатор Cisco Catalyst 2960
Series.
Примечание:
Допускаются и другие модели коммутаторов с поддержкой функции SPAN.
При работе в режиме SPAN-копии требуется несколько экземпляров Traffic Monitor Server, выполняющих
различные функции:
• Sniffer. Для приема SPAN-копии трафика.
• Traffic Monitor Server. Для анализа SPAN-копии трафика.
• Forwarder. Используется при наличии нескольких экземпляров Sniffer для распределения трафика
между ними.
Аппаратное и программное обеспечение Traffic Monitor Server описано в п. 2.2.1 на стр. 11.
Аппаратное обеспечение, необходимое для работы Sniffer и Forwarder, указано в таблицах 5 – 7.
Подготовка к установке 13
Таблица 5. Sniffer: Требования к процессору, оперативной памяти и жесткому диску
Оборудование Минимальные требования (при скорости трафика 100 Мбит/с)
Процессор Core 2 DUO E6750 (частота 2,66 ГГц
Оперативная память 2 Гб
Типовая конфигурация Sniffer при скорости трафика 300 Мбит/с:
• Сервер: HP DL360 Intel Xeon.
• Процессор: Intel Xeon x86 с частотой 3 ГГц. Требуются 2 процессора с 4 ядрами каждый.
• Оперативная память: 2 Гб.
• Жесткий диск: 160 Гб.
Таблица 6. Forwarder: Требования к процессору, оперативной памяти и жесткому диску
Оборудование Минимальные требования
Процессор Pentium IV с частотой 3 ГГц и выше
Оперативная память 1 Гб
В таблице 7 приводятся требования к сетевым картам для Sniffer и Forwarder. Необходимое количество
сетевых карт зависит от конфигурации вашей системы:
• На Forwarder одна сетевая карта используется для приема копии трафика от коммутатора CISCO.
Кроме того, нужны дополнительные сетевые карты для каждого экземпляра Sniffer, с которым
взаимодействует Forwarder.
• На Sniffer должны быть установлены две сетевые карты. Одна – для приема копии трафика от
коммутатора CISCO (или от Forwarder). Другая – для взаимодействия с прочими объектами сети. В
частности, вторая сетевая карта используется для передачи трафика на Traffic Monitor Server или
для взаимодействия с базой данных (если Sniffer и Traffic Monitor Server установлены на одном
компьютере).
Таблица 7. Требования к сетевым картам для Sniffer и Forwarder
Общие требования Рекомендуемые модели сетевых карт
Поддержка NAPI и режима Promiscuous mode.
Intel Corporation 82540EM Gigabit Ethernet Controller
Допускается использование сетевых карт серии
Broadcom Corporation NetXtreme II BCM5708 1Gb
Intel PRO/1000 GT
Требования к программному обеспечению
Sniffer:
• Операционная система: Red Hat Enterprise Linux ES 4 update 5 x86-32. Необходимо установить яд-
ро Linux с патчем PF_RING. Ядро поставляется в виде rpm-пакета вместе с дистрибутивом Систе-
мы. Установка ядра описывается в п. 3.3.3 на стр. 31.
Важная информация!
При установке операционной системы необходимо выбрать английскую локализацию.
Если Sniffer и Traffic Monitor Server функционируют на одном компьютере, то потребуется дополнитель-
ное программное обеспечение:
• пакеты в составе операционной системы:
− e2fsprogs,
− glibc,
− krb5-libs,
14 InfoWatch Traffic Monitor
− libgcc,
− libstdc++,
− libxml2,
− openldap,
− zlib,
− gzip,
− bzip2,
− unzip,
− lha,
− tar.
• Архиваторы: unrar версии 3.6.8, arj версии 3.10.
• Клиент СУБД Oracle версии 11g R1 (11.1.0.6.0).
Дополнительное программное обеспечение для загрузки объектов в удаленную базу данных (см.
п. 3.4 на стр. 34):
• Nc FTP Client версии 3.1.6.
Устанавливается на стороне Traffic Monitor Server, расположенного удаленно от базы данных.
• FTP сервер. Допускается использование сервера vsftpd из дистрибутива операционной системы
либо другого FTP-сервера, совместимого с установленной операционной системой.
Устанавливается на стороне Traffic Monitor Server, отвечающего за прием объектов от других эк-
земпляров Traffic Monitor Server и загрузку принятых объектов в базу данных.
Forwarder:
• Операционная система: Red Hat Enterprise Linux ES 4 update 5 x86-32. Необходимо установить яд-
ро Linux с патчем PF_RING. Ядро поставляется в виде rpm-пакета вместе с дистрибутивом Систе-
мы. Установка ядра описывается в п. 3.3.4 на стр. 33.
Важная информация!
При установке операционной системы необходимо выбрать английскую локализацию.
2.2.3. Сервер СУБД Oracle
Для корректной работы InfoWatch Traffic Monitor необходимо установить сервер СУБД Oracle версии
11.1.0.6.0 с обновлением (Patch Set) 11.1.0.7.
Требования к аппаратному и программному обеспечению
Требования к аппаратному обеспечению, необходимому для установки сервера СУБД Oracle, приведены
в таблице 8.
Подготовка к установке 15
Таблица 8. Аппаратное обеспечение сервера СУБД Oracle
Оборудование Рекомендуемые требования
Процессор Xeon с частотой 2.4 ГГц и выше
Оперативная память 4 Гб
Жесткий диск Аппаратный RAID-контроллер (уровень 1 и выше).
Емкость RAID-массива должна составлять не ме-
нее 200 GB (в зависимости от объема трафика пи-
сем, которые будут храниться в базе данных)
Требования к программному обеспечению
Операционная система: Red Hat Enterprise Linux Server release 5.2 x86-32.
В составе операционной системы должны быть установлены следующие пакеты:
• binutils-2.17.50.0.6-2.el5,
• compat-libstdc++-33-3.2.3-61,
• elfutils-libelf-0.125-3.el5,
• elfutils-libelf-devel-0.125,
• gcc-4.1.2-42,
• gcc-c++-4.1.2-42,
• glibc-2.5-24,
• glibc-common-2.5-24,
• glibc-devel-2.5-24,
• glibc-headers-2.5-24,
• libaio-0.3.106,
• libaio-devel-0.3.106,
• libgcc-4.1.2-42,
• libstdc++-4.1.2-42,
• libstdc++-devel-4.1.2-42,
• make-3.81-3,
• sysstat-7.0.2,
• unixODBC-2.2.11,
• unixODBC-devel-2.2.11.
2.2.4. Management Console
Требования к аппаратному обеспечению, необходимому для работы Management Console, перечислены в
таблице 9.
Таблица 9. Аппаратное обеспечение Management Console
Оборудование Минимальные требования Рекомендуемые требования
Процессор Celeron с частотой 1.7 ГГц и выше Pentium IV с частотой 3 ГГц и выше
Оперативная память 512 Мб 1 Гб
16 InfoWatch Traffic Monitor
Оборудование Минимальные требования Рекомендуемые требования
Жесткий диск 1 Гб свободного пространства 1 Гб свободного пространства
Виртуальная память не менее 2 Гб не менее 2 Гб
Требования к программному обеспечению:
• Операционная система: Microsoft Windows XP Service Pack 2;
• Microsoft .Net Framework 2.0;
• Клиент СУБД Oracle версии 11g R1 (11.1.0.6.0).
ГЛАВА 3. УСТАНОВКА СИСТЕМЫ
В этой главе содержится следующая информация:
• Схема базы данных (п. 3.1 на стр. 17).
• Traffic Monitor Server. Транспортные режимы: нормальный, прозрачный, обычная копия (п. 3.2 на
стр. 23).
• Traffic Monitor Server. Транспортный режим SPAN-копия (п. 3.3 на стр. 27).
• Подсистема загрузки объектов в удаленную базу данных (п. 3.4 на стр. 34).
• Management Console (п. 3.5 на стр. 41).
• Лицензирование (п. 3.6 на стр. 43).
3.1. Схема базы данных
Перед установкой Traffic Monitor Server необходимо создать схему базы данных. Информация по созда-
нию схемы базы данных содержится в следующих разделах:
• Подготовка к созданию схемы базы данных (п. 3.1.1 на стр. 17).
• Рекомендации по созданию схемы базы данных (п. 3.1.2 на стр. 17).
• Создание схемы базы данных (п. 3.1.3 на стр. 18).
Примечание:
Если у вас имеется установленная схема базы данных, то вы можете выполнить обновление до текущей
версии (см. главу 5 на стр. 67).
3.1.1. Подготовка к созданию схемы базы данных
Для создания схемы базы данных предназначен компонент Traffic Monitor Create Schema Wizard (далее
также или инсталлятор схемы базы данных).
Перед запуском Traffic Monitor Create Schema Wizard необходимо убедиться в том, что:
• запущен сервер СУБД Oracle;
• на компьютере, с которого будет выполняться установка схемы базы данных, установлен и на-
строен клиент СУБД Oracle версии 11g R1 (11.1.0.6.0).
Примечание:
Рекомендации по установке и настройке клиента СУБД Oracle приводятся в приложении A.2 на
стр. 86.
Для создания схемы базы данных необходимо знать имя и пароль учетной записи, обладающей правами
SYSDBA.
Перед созданием схемы необходимо убедиться, что имя, которое будет назначено владельцу схемы ба-
зы данных, уникально в пределах базы данных. Это означает, что в базе данных не должно быть схемы
базы данных и табличного пространства с таким же именем.
3.1.2. Рекомендации по созданию схемы базы данных
Процесс создания схемы базы данных включает в себя создание табличных пространств (основного и
ежедневных), необходимых для работы Системы. Ежедневные табличные пространства предназначены
для хранения объектов (SMTP-писем, HTTP-запросов и пр.), поступающих в Систему. В основном таб-
личном пространстве хранятся данные, необходимые для обработки поступающих данных. При настрой-
ке параметров схемы базы данных вам будет предложено указать ряд параметров, связанных с создани-
18 InfoWatch Traffic Monitor ем табличных пространств. Настройка параметров для ежедневных табличных пространств (количество файлов данных, начальный размер файла данных) выполняется с учетом суммарного объема суточного трафика объектов, проходящего через Систему. Для оптимальной настройки данных параметров реко- мендуется оценить максимальный и минимальный объем суточного трафика в пределах определенного интервала (например, недели). Оценка выполняется только для тех типов трафика, которые отслежива- ются Системой. Если, например, у вас не установлен HTTP-монитор, то оценку НTTP-трафика проводить не нужно. Выбор интервала для оценки зависит от того, насколько постоянен этот объем. Пусть, к приме- ру, трафик имеет различный объем в пределах недели. Тогда рекомендуется оценить минимальный и максимальный объем суточного трафика на протяжении одной недели. При определении количества файлов данных необходимо учитывать, что максимальный размер одного файла данных составляет 30 Гб. Тогда количество файлов данных определяется максимальным объе- мом трафика. Например, при максимальном объеме суточного трафика 65 Гб необходимо задать значе- ние данного параметра равным 3. Начальный размер файла данных можно определить, рассчитав среднесуточный объем трафика за ис- следуемый период. При этом необходимо учитывать следующее. Если колебания в объеме трафика в разные периоды времени велики, то часть пространства, выделяемого для файлов данных, может ока- заться неиспользованной. В то же время, если начальный объем файла данных будет значительно меньше суточного объема трафика, то потребуется приращение файла данных, что приведет к снижению производительности Системы. Количество приращений будет зависеть от заданного размера прираще- ния. Ежедневные табличные пространства могут храниться либо в одном каталоге, либо распределенно (в разных каталогах или на разных физических дисках). Примечание: Для того чтобы увеличить надежность хранения данных, рекомендуется размещать ежедневные таблич- ные пространства на разных физических дисках. Распределенное хранение данных возможно при условии, что используются циклические файловые сис- темы. Каждый каталог или физический диск, на который могут быть сохранены ежедневные табличные пространства, является отдельной циклической файловой системой. При создании схемы базы данных задается количество циклических файловых систем и местоположение файлов данных в каждой такой системе. Циклические файловые системы используются поочередно. Например, если задано 3 цикличе- ских файловых системы, то данные будут размещаться следующим образом: Первый день – ежедневное табличное пространство создается в файловой системе 1. Второй день – ежедневное табличное пространство создается в файловой системе 2. Третий день – ежедневное табличное пространство создается в файловой системе 3. Четвертый день – ежедневное табличное пространство создается в файловой системе 1. … Если распределенное хранение данных не требуется, то необходимо установить количество циклических файловых систем равным 1. В этом случае все табличные пространства будут располагаться в одной директории. 3.1.3. Создание схемы базы данных Подготовка к созданию схемы базы данных описывается в пп. 3.1.1 – 3.1.2 на стр. 17 – 17. Примечание: Часть параметров, которые нужно указать при создании схемы базы данных, отмечены символом «*». Такие параметры заполняются в обязательном порядке. Шаг 1. Запуск инсталлятора схемы базы данных На диске с дистрибутивом Системы откройте каталог CreateSchemaWizard. В данном каталоге найдите и запустите файл Setup.exe. Вы также можете скопировать инсталлятор в папку, расположенную на жестком диске, и запускать ин- сталлятор из этой папки.
Установка системы 19
Важная информация!
Инсталлятор схемы базы данных не может быть запущен из сетевой папки.
После этого на экран будет выведено окно Мастер работы с БД.
Шаг 2. Выбор типа установки
В окне Мастер работы с БД выберите вариант Установка новой схемы БД и нажмите на кнопку OK.
После этого на экран будет выведено окно мастера установки схемы БД.
Шаг 3. Настройка параметров соединения с сервером базы данных
В окне мастера установки схемы БД (см. рис. 1) укажите параметры соединения с сервером базы данных:
• Database. Псевдоним сервера, на котором установлена база данных (псевдоним выбирают из пе-
речисленных в файле tnsnames.ora).
• SYSDBA. Имя учетной записи, обладающей правами SYSDBA (например, SYS).
• SYSDBA password. Пароль учетной записи SYSDBA.
Рисунок 1. Параметры соединения с сервером базы данных
Нажмите кнопку Вперед.
Шаг 4. Настройка параметров учетной записи владельца схемы БД
Укажите параметры, необходимые для создания учетной записи владельца схемы базы данных (см.
рис. 2):
• Владелец схемы БД. Имя учетной записи владельца схемы базы данных.
Важная информация!
Имя владельца базы данных должно быть уникальным в пределах базы данных. Это означает, что
в базе данных не должно быть схемы базы данных и табличного пространства с таким же именем.
Если схема базы данных с таким именем уже существует, то установить новую схему с этим же
именем можно, только если будет установлен флажок в поле Удалить, если существует. При
этом сначала удаляется существующая схема базы данных и табличное пространство, а затем
создается новая схема базы данных и новое табличное пространство с таким же именем.
20 InfoWatch Traffic Monitor
Важная информация!
Устанавливать флажок в поле Удалить, если существует нужно только в том случае, если ранее
схема базы данных была создана некорректно.
• Пароль владельца схемы БД, Подтвердить пароль. Пароль учетной записи.
Примечание:
Пароль задается в соответствии с указаниями документации для СУБД Oracle.
Рисунок 2. Настройка учетной записи владельца схемы базы данных
Нажмите кнопку Вперед.
Шаг 5. Настройка параметров учетной записи администратора пользователей
Для первой настройки Management Console используется учетная запись администратора пользовате-
лей, имеющая ограниченный набор прав.
Примечание:
Информация о функциях администратора пользователей приводится в документе «InfoWatch Traffic Moni-
tor. Руководство пользователя».
Укажите параметры, необходимые для создания учетной записи администратора пользователей (см.
рис. 3):
• Администратор пользователей. Имя учетной записи администратора пользователей. (К имени
администратора пользователей рекомендуется добавить суффикс _ADM.)
Важная информация!
Имя учетной записи администратора пользователей должно быть уникальным в пределах базы
данных. Это означает, что в базе данных не должно быть схемы базы данных с таким же именем.
• Пароль администратора пользователей, Подтвердить пароль. Пароль учетной записи.
Установка системы 21
Рисунок 3. Настройка учетной записи администратора пользователей
Нажмите кнопку Вперед.
Шаг 6. Настройка параметров основного табличного пространства
Настройте параметры файла данных для основного табличного пространства (см. рис. 4):
• путь к файлу данных для основного табличного пространства.
• начальный размер файла данных (в Мб);
• размер приращения – величину, на которую будет расширяться файл данных (в Мб).
Рисунок 4. Параметры основного табличного пространства
Нажмите кнопку Вперед.
Шаг 7. Настройка параметров ежедневных табличных пространств
Настройте параметры для ежедневных табличных пространств (см. рис. 5):
• число файлов данных, которые будут содержаться в одном табличном пространстве.
• начальный размер файла данных (в Мб);
22 InfoWatch Traffic Monitor
• размер приращения – величину, на которую будет расширяться файл данных (в Мб).
• лаг времени (в днях) – дополнительный интервал, для которого будут созданы ежедневные таб-
личные пространства. Каждый день в базе данных создаются табличные пространства на текущий
и на следующий день. Лаг времени позволяет задать дополнительный интервал, для которого бу-
дут созданы ежедневные табличные пространства. Например, если лаг времени составляет 1
день, то будут созданы ежедневные табличные пространства на текущий день и на два после-
дующих дня (т.е. табличные пространства, необходимые для работы в течение 3 дней).
Рисунок 5. Параметры ежедневных табличных пространств
Нажмите кнопку Вперед.
Шаг 8. Настройка параметров файловой системы
Укажите параметры циклических файловых систем (см. рис. 6):
• количество циклических файловых систем (максимальное количество 10 файловых систем).
• местоположение файлов данных (отдельно для каждой файловой системы).
Примечание:
Если количество файловых систем превышает 5, то нажмите кнопку Вперед и укажите путь к остальным
файловым системам.
Установка системы 23
Рисунок 6. Параметры циклических файловых систем
Нажмите кнопку Вперед. Чтобы начать установку, нажмите кнопку Старт.
3.2. Traffic Monitor Server. Транспортные
режимы: нормальный, прозрачный, обычная
копия
В разделе содержится информация, необходимая для установки Traffic Monitor Server:
• Состав Traffic Monitor Server (п. 3.2.1 на стр. 23).
• Рекомендации по установке (п. 3.2.2 на стр. 24).
• Установка и настройка (п. 3.2.3 на стр. 24).
3.2.1. Состав Traffic Monitor Server
Traffic Monitor Server включает в себя ряд подсистем, к которым, в частности, относятся:
• Подсистема контроля SMTP-писем (нормальный и прозрачный транспортный режим). Включает в
себя демоны iw_smtpd, iw_messed (интегрированный с DAE), iw_deliverd.
• Transparent Proxy. Прокси-сервер, предназначенный для контроля HTTP-запросов и ICQ-
сообщений (в любом транспортном режиме). Для работы с каждым типом объектов запускается
отдельный экземпляр Transparent Proxy (демон iw_proxy с интегрированным DAE).
• Подсистема анализа теневых копий файлов, полученных от InfoWatch Device Monitor. Включает в
себя демон iw_expressd, интегрированный с DAE.
Decision and Analysis Engine (DAE) – подсистема анализа и принятия решения. В задачи DAE входит ана-
лиз объектов и последующая обработка объектов по результатам анализа. В состав Traffic Monitor Server
входит несколько экземпляров DAE. Каждый экземпляр DAE интегрирован с одним из демонов, прини-
мающих объекты. Таким образом, количество экземпляров DAE определяется количеством установлен-
ных перехватчиков.
Для проведения контентного анализа в состав Traffic Monitor Server входит Content and Analysis Server
(CAS). Задачей CAS является контентный анализ текста. В процессе обработки объекта DAE отправляет
текст, содержащийся в объекте (например, текст SMTP-письма) на CAS. Результат контентного анализа
возвращается подсистеме DAE.
Загрузка объектов в базу данных выполняется посредством демона iw_dbloader.
24 InfoWatch Traffic Monitor
Примечание:
Описание процессов Traffic Monitor Server приводится в документе «InfoWatch Traffic Monitor. Руково-
дство пользователя».
3.2.2. Рекомендации по установке
Важная информация!
Traffic Monitor Server и Сервер СУБД Oracle должны быть установлены на разных компьютерах.
Для корректной работы Системы необходимо выполнить ряд предварительных настроек на том компью-
тере, на который будет установлен Traffic Monitor Server, а именно:
• установить клиентское программное обеспечение СУБД Oracle версии 11g R1 (11.1.0.6.0) (реко-
мендации по установке приводятся в приложениях A.2.1 – A.2.4 на стр. 86 – 90);
• в случае интеграции с почтовым сервером Postfix установить соответствующее программное обес-
печение (о настройке интеграции с Postfix рассказывается в п. 4.6 на стр. 60).
Примечание:
Другие почтовые сервера (Microsoft Exchange и пр.), функционирующие в корпоративной почтовой
системе, должны быть настроены как промежуточные relay-сервера.
• убедиться, что для компьютера, на который будет устанавливаться Traffic Monitor Server, задано
полное имя домена. Проверить наличие этого имени можно командой:
hostname –f
Если полное имя домена не определено, то необходимо задать это имя до начала установки Traf-
fic Monitor Server.
3.2.3. Установка и настройка
Примечание:
Если у вас имеется установленная версия Traffic Monitor Server, то вы можете установить более новую
версию путем обновления (см. главу 5 на стр. 67).
Если предыдущая версия Traffic Monitor Server была удалена, то в этом случае часть информации, необ-
ходимой для работы Системы, сохраняется и после удаления (см. п. 6.1 на стр. 71). Если вы устанавли-
ваете новую версию Traffic Monitor Server, но при этом не планируете использовать данные из предыду-
щей версии, то в этом случае вам нужно вручную удалить содержимое папки /usr/local/infowatch.
Шаг 1. Установка Traffic Monitor Server
Установите пакет iwtm-x.x.x-x.i386.rpm (здесь x.x.x-x номер версии InfoWatch Traffic Monitor). Для
этого:
1. Зарегистрируйтесь в операционной системе от имени учетной записи пользователя root:
su – root
2. Выполните команду:
rpm -i /путь_к_пакету_iwtm/iwtm-x.x.x-x.i386.rpm
Например:
rpm -i /u01/iwtm-3.1.0-1.i386.rpm
Установка пакета будет выполнена в каталог:
/usr/local/infowatch/tm3
Шаг 2. Настройка и запуск Traffic Monitor Server
Запустите сценарий setup.sh:
Установка системы 25
/usr/local/infowatch/tm3/setup.sh
В процессе работы вам будет предложено указать ряд параметров:
1. Enter user name to be used as an owner of InfoWatch Traffic Monitor
Укажите локальную учетную запись пользователя – владельца Traffic Monitor Server, от имени ко-
торого будут запускаться процессы. По умолчанию создается учетная запись iwtm.
Важная информация!
На всех экземплярах Traffic Monitor Server, входящих в подсистему загрузки объектов в удаленную
базу данных, имя владельца должно быть одинаковым.
2. Enter group name to be used as an owner of InfoWatch Traffic Monitor
Укажите группу, в состав которой будет включен пользователь – владелец InfoWatch Traffic
Monitor. Рекомендуется включить пользователя в группу владельца инсталляции клиента СУБД
Oracle (по умолчанию это группа oinstall) . В этом случае решается проблема недостатка прав
при работе с СУБД Oracle.
3. Select ip-addresses for IW SMTP Server
Выберите IP-адрес, который будет использоваться демоном iw_smtpd для получения входящей
почты. Вы можете выбрать одно из следующих значений:
• один из IP-адресов, того компьютера, на который выполняется установка Traffic Monitor Server
(выводятся все IP-адреса по количеству установленных сетевых карт);
• 127.0.0.1 – получение почты от демона, запущенного на локальном компьютере (данное зна-
чение рекомендуется выбирать при интеграции с Postfix);
• 0.0.0.0 – подразумевается любой IP-адрес (значение по умолчанию).
Примечание:
Если передача SMTP-трафика ведется только в режиме копии, то вы можете выбрать любой вари-
ант.
4. Select a port to be listened
Укажите порт, на котором будет запущен процесс прослушивания входящих писем демоном
iw_smtpd. Значение по умолчанию (2025) используется при интеграции с Postfix.
5. Select a type of IW SMTP Server MTA installation
Выберите тип почтового агента. Возможны два варианта:
• relay to a Postfix instance running on localhost – почтовый сервер Postfix уста-
новлен на том же компьютере, что и Traffic Monitor Server (значение по умолчанию);
• relay to another smtp-server – интеграция с Postfix отсутствует или выполнена частично.
6. Настройте параметры исходящей почты. Настройки зависят от типа почтового агента, выбранного
на шаге 5.
Если был выбран первый вариант, т.е. Traffic Monitor Server и Postfix находятся на одном компью-
тере, то нужно указать параметры:
• Hostname of this mashine
Доменное имя компьютера, на который будет установлен Traffic Monitor Server. По умолчанию
указано имя того компьютера, с которого был запущен сценарий setup.sh.
• Enter a port number used by target smtp-server
Порт почтового relay-сервера, на который будет выполняться отправка писем (значение по
умолчанию 2020).
Если был выбран второй вариант, т.е. интеграция с Postfix отсутствует или выполнена частично, то
нужно указать параметры:
• Enter a hostname or ip-address of target smtp-server.
- Введение
- Функциональные возможности InfoWatch Traffic Monitor 7.3
- 2.1. Функциональные возможности продукта и решаемые задачи
- Архитектура InfoWatch Traffic Monitor 7.3
- 3.1. Контролируемые каналы и протоколы
- 3.2. Управление инцидентами
- 3.3. Возможности анализа содержимого документов (контентный анализ)
- Системные требования InfoWatch Traffic Monitor 7.3
- 4.1. Требования к аппаратной конфигурации сервера для InfoWatch Traffic Monitor
- 4.2. Возможности интеграции со смежными системами
- 4.3. Соответствие требованиям по информационной безопасности
- Новые возможности и улучшения InfoWatch Traffic Monitor 7.3
- Применение новых возможностей InfoWatch Traffic Monitor 7.3
- 6.1. Автоматизированное обучение DLP-системы
- 6.2. Перехват файлов добавляемых в архив
- 6.3. Интеграция с облачными сервисами
- 6.4. Установка и эксплуатация системы в крупных организациях
- 6.5. Защита данных DLP-системы
- 6.6. Визуальная аналитика в InfoWatch Vision
- 6.7. Предиктивный анализ данных DLP-системы (UBA)
- Выводы
Введение
InfoWatch Traffic Monitor — отечественная DLP-система, присутствующая на рынке более 18 лет. За это время сильно изменились и бизнес-контекст, и технологический ландшафт: если в начале пути в мире DLP всё решало количество каналов, которые перехватывал и блокировал тот или иной продукт, то в современном мире, как считает вендор, всё стало гораздо интереснее.
С массовым переходом в «цифру», гибридным характером работы и возросшей ценой критически важной информации успех внедрения DLP-системы определяется её возможностями по быстрому реагированию на изменяющиеся процессы, типы документов и данных, по выявлению рисков, которые сложно идентифицировать без корреляции разнородных и часто по отдельности неприметных событий.
В этом материале мы подробно рассмотрим обновлённую версию DLP-системы InfoWatch Traffic Monitor 7.3 от компании InfoWatch. Ранее мы публиковали обзор одной из предыдущих версий продукта — InfoWatch Traffic Monitor 6.7; с тех пор прошло более четырёх лет, и за это время он значительно изменился. Сфокусируем внимание на возможностях и улучшениях обновлённой версии продукта.
Функциональные возможности InfoWatch Traffic Monitor 7.3
Функциональные возможности продукта и решаемые задачи
InfoWatch Traffic Monitor предназначен для решения следующих задач:
- Контролировать распространение информации как внутри компании, так и за её пределы, в том числе в условиях гибридной работы, когда часть сотрудников работает удалённо, с личных устройств и с облачной инфраструктурой.
- Предотвращать утечки конфиденциальной информации путём блокировки её пересылки или передачи, включая защиту персональных данных: несмотря на кажущуюся очевидность и длительную историю вопроса, надёжная защита ПДн остаётся трудноразрешимой задачей для большинства DLP-систем.
- Выявлять и расследовать инциденты в информационной безопасности, в том числе собирать доказательства для дальнейших судебных разбирательств.
- Выявлять внутренние нарушения, нелояльное поведение сотрудников, мошеннические схемы и злоупотребления.
- Прогнозировать возможные риски в информационной безопасности на основе поведенческого анализа (UBA).
Архитектура InfoWatch Traffic Monitor 7.3
InfoWatch Traffic Monitor 7.3 представляет собой модульную систему, в которой комбинация используемых модулей может изменяться и масштабироваться в зависимости от потребностей компании.
Рисунок 1. Архитектура InfoWatch Traffic Monitor 7.3
Система собирает разнообразные данные на конечных точках и на сетевом уровне; частично обработка данных происходит там же (на конечных точках), что даёт возможность предотвратить утечки, например, в случае если компьютер отключён от корпоративной сети, но основная часть обрабатывается сервером InfoWatch Traffic Monitor.
Агенты на конечных точках собирают данные о движении информации и действиях сотрудников, на сетевом уровне обрабатываются почтовый и веб-трафик, а также трафик с интегрированных систем. Например, InfoWatch Traffic Monitor интегрирован с Microsoft Teams: если сотрудник работает с личного устройства из дома, то все коммуникации на этой платформе происходят вообще вне корпоративного периметра, но за счёт интеграции с Microsoft Teams такие коммуникации тоже контролируются системой.
Модуль Data Discovery сканирует файловые ресурсы и рабочие станции в целях анализа и классификации хранимой информации, чтобы выявить факты ненадлежащего хранения данных или обнаружить конкретные документы, которые имеют отношение к какому-либо инциденту.
InfoWatch Activity Monitor — модуль для контроля действий пользователей. Собирает данные о действиях сотрудников для анализа их рабочей активности, использования ими приложений, позволяет восстановить последовательность действий и понять контекст нарушения при расследовании.
InfoWatch Vision — BI-модуль визуального анализа данных DLP-системы в режиме реального времени. Представляет данные DLP-системы Traffic Monitor в виде статистики и графа связей. Обеспечивает быстрый поиск на графе сопряжённых с инцидентом событий, позволяет исследовать коммуникации сотрудников и пути перемещения документов, анализировать круг общения подозреваемых, производить мониторинг статистики в поисках инцидентов и аномалий даже в «серой зоне» и выгружать отчёты. Особенностью InfoWatch Vision является его высокая производительность: граф связей может отображать до 50 тысяч узлов одновременно и быстро перестраиваться при изменении фильтров. Это делает инструмент пригодным для интерактивного анализа данных и коммуникаций; вендор добился такой скорости за счёт использования технологий применяемых при разработке компьютерных игр.
InfoWatch Prediction — инструмент для предиктивного анализа собираемых DLP-системой Traffic Monitor данных. С помощью технологий искусственного интеллекта модуль строит профили пользователей, а затем ищет отклонения от привычного поведения и выявляет подозрительные паттерны, состоящие из набора событий, которые, может быть, остались бы вне зоны внимания по отдельности. InfoWatch Prediction автоматически формирует рейтинг сотрудников в соответствии с количеством и оценкой аномалий, привлекая внимание специалиста по ИБ к наиболее значимым рискам.
Коннекторы — набор модулей перехвата для интеграции со сторонними системами для сбора данных и интеграции в инфраструктуру (например, коннекторы к SIEM-системам).
Консоль управления — веб-интерфейс администрирования системы для настройки политик и управления инцидентами.
Отметим, что InfoWatch Traffic Monitor 7.3 поддерживает распределённую схему внедрения с централизованным сбором статистики по филиалам для контроля сотрудников ИБ на местах. Это актуально, когда руководителю ИБ в головном офисе необходимо проводить мониторинг оперативной обстановки по всей компании, а также контролировать работу специалистов по ИБ на местах. В данном случае руководитель ИБ получает статистику по всей компании и каждому филиалу в отдельности. При необходимости он может перейти в подробности конкретного события.
Таким образом, единое информационное пространство InfoWatch Traffic Monitor 7.3 упрощает контроль настроенных политик в филиалах, делегирование расследований специалистам на местах, эскалацию сложных кейсов на руководство в головном офисе.
Контролируемые каналы и протоколы
Каналы перехвата:
- Почта: SMTP / ESMTP, MIME / S/MIME, POP3, IMAP4, IBM Domino.
- Веб-ресурсы: HTTP / HTTPS, FTP / FTPS, веб-почта, блоги / форумы / соцсети, облачные хранилища, форумы на php, IP.Board, vBulletin.
- Мессенджеры: WhatsApp, Telegram, Skype, Jabber (XMPP), Microsoft Lync (SIP), SMS, Facebook Messenger, «ВКонтакте», Cisco Messenger.
- Облачные хранилища: Dropbox, OneDrive, «Яндекс.Диск», Google Drive, «Облако Mail.ru», Box. При этом за счёт универсальной технологии перехвата файлов разработчик готов за несколько дней поддержать любой файлообменник без необходимости перевыпуска продукта.
- Облачные сервисы Microsoft (Teams, Exchange, Office 365).
- Хранилища данных: FTP, рабочие станции, файловые хранилища, Microsoft SharePoint.
- Средства видеокоммуникации: Zoom, Express, Cisco WebEx, TeamViewer.
Контроль рабочих станций охватывает печать на локальных и сетевых принтерах, Bluetooth, IrDA, подключение к сетям Wi-Fi, запуск приложений (белые и чёрные списки), контроль буфера обмена, создание снимков экрана, сетевые подключения и работу с облачными сервисами.
Есть также контроль удалённого подключения: Microsoft RDP, Citrix XenApp и TeamViewer.
Каналы блокировки на основе полноценного контент-анализа:
- Почта SMTP и MAPI, веб-почта.
- Интернет-трафик (социальные сети и др.).
- Облачные хранилища, FTP.
- Съёмные носители, MTP-устройства.
- Буфер обмена, перенос файлов через терминальные соединения и сетевые папки.
InfoWatch Traffic Monitor может блокировать файловые операции по результатам лингвистического анализа содержания файлов. Он анализирует содержимое файла в момент, когда его пытаются переместить. Можно блокировать таким образом перемещения файлов между рабочей станцией и съёмными носителями, сетевыми папками, FTP или облачными хранилищами. Такой подход обеспечивает не только контроль отправки документов за периметр компании, но и блокировку нарушений политик хранения и использования документов внутри компании.
Управление инцидентами
Рисунок 2. Список событий с цветовой дифференциацией по уровню нарушений InfoWatch Traffic Monitor 7.3
На основании настроенных политик безопасности специалист по ИБ увидит перехваченные события в удобном для анализа виде. События маркируются цветом в соответствии с уровнем нарушения. Доступна информация о времени, отправителе, получателе, политиках, категориях, объектах защиты, сработавших технологиях анализа, а также о характере действий, повлёкших за собой срабатывание политик: буфер обмена, интернет-активность, обмен файлами, печать, отправка или получение фотографий, электронная почта, мессенджер, хранение файлов. Просматривая подсвеченные системой события, специалист по ИБ может принимать оперативные решения и собирать информацию для расследования и анализа инцидентов, а также помечать события в соответствии с вердиктом — «решение не принято», «нарушение», «нет нарушения», «требуется дополнительная обработка».
Возможности анализа содержимого документов (контентный анализ)
Возможности контентного анализа очевидным образом определяют результативность DLP-системы: чем точнее удастся классифицировать документ, то есть отнести его к той или иной категории конфиденциальных, тем точнее отработают политики. Тем меньше будет вероятность пропустить важный документ, и тем меньше ложноположительных срабатываний порождает система, то есть ИБ-специалист будет эффективнее тратить время на их обработку.
InfoWatch исторически уделяла особое внимание контент-анализу и сейчас в своём арсенале имеет широкий спектр разнообразных технологий такого рода. Перечислим их.
Перехват текста:
- Лингвистический анализ — поиск документов определённой тематики и содержания. Система включает в себя словари по 289 категориям на 42 языках. Из них 20 языков — с поддержкой морфологии. Кроме того, новый словарь для определения документов любой новой или специфической тематики можно создать автоматически. Для формирования собственного словаря в InfoWatch Traffic Monitor есть инструмент «Автолингвист», который работает на основе методов ИИ и позволяет создать словарь «под ключ» силами заказчика, без привлечения специалистов и необходимости передачи конфиденциальных документов кому-либо.
- Детектор выгрузок из баз данных — поиск цитат из заданной базы; выгрузками из БД могут быть персональные данные, данные клиентов, номенклатура, складские остатки, прайс-листы и пр. Технология позволяет на порядок точнее детектировать такие данные за счёт контроля движения конкретного набора данных из конкретной БД вместо использования регулярных выражений. Например, в любом электронном письме содержится подпись, которая при использовании регулярных выражений определится как персональные данные и окажется ложноположительным срабатыванием. В случае использования технологии контроля выгрузок из БД под политику попадут не любые Ф. И. О., а только те, которые содержатся в заданной БД.
- Детектирование цифровых отпечатков — поиск фрагментов текста, принадлежащих к заранее заданным эталонным документам.
- Детектирование заполненных бланков — поиск бланков установленного шаблона. Бланками могут быть различные анкеты, квитанции и пр. Система также детектирует бланки заполненные от руки.
- Детектор текстовых объектов — поиск текстовых объектов, соответствующих заданным шаблонам: номера кредитных карт, СНИЛС, другие стандартизованные реквизиты. Для более точного определения в регулярных выражениях используются верифицирующие функции: так, например, номера кредитных карт проверяются с помощью алгоритма «Луна».
Перехват графики:
- Детектор графических объектов — технология распознаёт предустановленные графические объекты и осуществляет поиск изображений, которые соответствуют какой-либо из категорий: паспорта, кредитные карты, карты геологоразведки и пр. Если в компании появляются новые специфические конфиденциальные изображения, не подходящие ни под одну из категорий «из коробки», новую категорию можно создать автоматически. Для этого в InfoWatch Traffic Monitor есть инструмент наподобие «Автолингвиста», позволяющий создать новую категорию защищаемых изображений силами заказчика, без привлечения третьих лиц и без передачи данных на сторону.
- Детектирование растровых цифровых отпечатков — поиск фрагментов растровых изображений, принадлежащих к заранее заданным эталонным изображениям.
- Детектирование векторных цифровых отпечатков — поиск фрагментов схем и чертежей в векторном формате, принадлежащих к заранее заданным эталонным CAD-файлам. В отличие от бинарных цифровых отпечатков, учитываются характеристики и соотношение отдельных элементов чертежей, что позволяет детектировать даже часть конфиденциального чертежа, а также учитывать изменение масштаба, повороты и отражения.
- Детектирование печатей — поиск изображения печати установленного вида: круглые и треугольные, независимо от угла поворота, смещения, масштаба, яркости изображения и наличия на ней шумов (текст, краска, потёртости и т. д.).
- OCR — мгновенное распознавание текста в изображениях, благодаря чему возможен контроль процессов печати и сканирования документов, перемещения отсканированных копий внутри организации (со сканера на ПК, с ПК на принтер) и за её пределы (отправка отсканированных копий по электронной почте, через сервисы мгновенных сообщений и пр.).
Система позволяет комбинировать несколько технологий анализа в рамках одной политики, что снижает трудоёмкость настройки. Например, для детектирования паспортных данных можно использовать регулярные выражения, графические объекты и OCR.
Технологии анализа применяются как на уровне сетевого шлюза, так и на конечных точках. Это помогает сразу блокировать несанкционированные действия.
Системные требования InfoWatch Traffic Monitor 7.3
Требования к аппаратной конфигурации сервера для InfoWatch Traffic Monitor
Требования к аппаратной конфигурации сервера для InfoWatch Traffic Monitor определяются на основании типа установки, предполагаемой нагрузки на InfoWatch Traffic Monitor и параметров сети, в которой происходит развёртывание системы. Поэтому спецификация оборудования для каждого случая рассчитывается отдельно.
Приведём рекомендованную конфигурацию для InfoWatch Traffic Monitor Enterprise (табл. 1).
Таблица 1. Рекомендуемая конфигурация для InfoWatch Traffic Monitor Enterprise
|
Серверная часть |
Менее 10 ГБ/день |
От 10 до 50 ГБ/день |
Более 50 ГБ/день |
|
Дисковая подсистема |
RAID-массив с отказоустойчивостью: 600 ГБ |
RAID-массив с отказоустойчивостью |
RAID-массив с отказоустойчивостью |
|
Процессор |
2 ЦП по 8 ядер + гиперпоточность (Intel Xeon E5-2640 v3 — частота 2,6 ГГц) |
2 сервера с 2 ЦП по 10 ядер |
Рассчитывается по запросу |
|
Оперативная память |
24 ГБ |
32–48 ГБ на каждый из серверов |
От 32 ГБ на каждый из серверов |
Гибкая схема лицензирования InfoWatch Traffic Monitor предлагает заказчикам выбирать только те модули, в которых имеется потребность, с возможностью последующего наращивания функциональности системы. Продукт лицензируется по учётным записям и модулям.
Возможности интеграции со смежными системами
Открытый API позволяет интегрировать InfoWatch Traffic Monitor со внешними системами; такие интеграции делают как сама InfoWatch, так и независимые вендоры, в частности по запросам своих клиентов.
Внешние системы:
- Загрузка и постоянное обновление эталонных документов в Traffic Monitor через API из ERP (SAP), CRM и других бизнес-систем для поддержки актуальности политик безопасности.
- С SOC и SIEM-системами — для централизованной обработки инцидентов (PT MaxPatrol, RuSIEM, NeuroDAT, «Комрад», HP ArcSight ESM, Security Vision, Phishman Awareness Center, R-Vision).
- С инфраструктурой заказчика — с прокси-серверами Check Point, UserGate, FortiGate, Squid, Aladdin eSafe WSG, Cisco IronPort WSA для перехвата HTTP- и HTTPS-трафика по ICAP.
- С системами для контроля печати, защиты рабочих станций, системами защищённого документооборота (MFlash, АРТИ Print Xpert, Crosstech DSS).
- С системами EMM-класса (WorksPad) — для контроля корпоративных данных, используемых сотрудниками на личных мобильных устройствах.
- С почтовыми серверами Postfix, «Мой Офис Почта», UserGate, CommuniGate, Kerio, Zimbra, Sendmail, Exim, Microsoft Exchange, Lotus Notes, Office 365.
- С облачными сервисами и мессенджерами Office 365, Exchange Online, Cisco WebEx Teams, Microsoft Teams, eXpress, Tada, Chat2desk, Viber, WhatsApp и др.
Соответствие требованиям по информационной безопасности
Все продукты InfoWatch работают на отечественных операционных системах и соответствуют требованиям импортозамещения.
InfoWatch Traffic Monitor имеет сертификат ФСТЭК России № 4340 (действителен до 16.12.2025) на соответствие требованиям документов:
- По 5-му классу защищённости СВТ от НСД «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищённости от несанкционированного доступа к информации» (Гостехкомиссия России, 1992).
- Требования к уровням доверия по 4-му уровню доверия (УД4) «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2018).
- Требования к средствам контроля съёмных машинных носителей информации по 4-му классу защиты СКН (ИТ.СКН.П4.ПЗ) «Профиль защиты средств контроля подключения съёмных машинных носителей информации четвёртого класса защиты» (ФСТЭК России, 2014).
Кроме того, InfoWatch Traffic Monitor включён в реестр отечественного ПО и обеспечивает соответствие ряду законодательных и регуляторных требований:
- Федеральный закон № 149-ФЗ «Об информации, информационных технологиях и о защите информации»;
- Федеральный закон № 152-ФЗ «О персональных данных»;
- Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»;
- требования по защите коммерческой тайны (98-ФЗ);
- требования по защите инсайдерской информации (224-ФЗ);
- требования по защите данных в Национальной платёжной системе (161-ФЗ, ПП-584, 382-П и другие);
- приказы ФСТЭК России № 17 (ГИС), № 21 (ИСПДн), № 239 (КИИ).
Новые возможности и улучшения InfoWatch Traffic Monitor 7.3
По сравнению с предыдущей рассматриваемой версией (6.7) продукт претерпел ряд важных изменений и улучшений, которые направлены на повышение уровня защиты конфиденциальных данных от утечек:
- Автоматическое обучение DLP-системы с помощью технологий искусственного интеллекта.
- Универсальный перехватчик файлов, нечувствительный к изменению проприетарных протоколов системы, способа шифрования, специфики передачи данных веб-сервиса. При этом возможна доработка под любое приложение за несколько часов.
- Визуальный анализ данных DLP для ускорения расследований, мониторинга инцидентов, исследования коммуникаций и путей перемещения документов.
- Предиктивный анализ данных для управления рисками.
- Блокировка файловых операций по результатам лингвистического анализа содержания файлов между рабочей станцией и съёмными носителями, сетевыми папками, FTP или облачными хранилищами.
- Установка, обновление и разграничение прав доступа для нужд больших территориально распределённых организаций.
- Повышена безопасность данных самой DLP-системы.
Применение новых возможностей InfoWatch Traffic Monitor 7.3
Далее опишем несколько вариантов использования InfoWatch Traffic Monitor 7.3 на практике.
Автоматизированное обучение DLP-системы
Если стоит задача защищать документы определённой тематики, например всё относящееся к тендерам, или к пожарной безопасности, или к любой другой области, достаточно предъявить системе пару десятков документов этой тематики, и она автоматически сформирует «словари», на основании которых будет впоследствии классифицировать вновь поступающие похожие документы как относящиеся к данной тематике.
«Словарь» тут взят в кавычки, потому что в случае InfoWatch Traffic Monitor это — не просто набор терминов, словари InfoWatch учитывают относительную частоту использования слов, что повышает точность детектирования. Для изготовления такого словаря раньше нужно было привлекать профессиональных лингвистов, на создание одного словаря может уйти несколько дней. «Автолингвист» не требует специальных навыков и справляется с задачей за минуты. Таким образом, заказчик может самостоятельно обучить систему и, к тому же, никто посторонний не получает доступа к конфиденциальным документам компании.
То же относится и к графическим данным: систему можно обучить детектировать однотипные изображения, характерные для конкретного заказчика, будь то схемы бизнес-процессов, карты геологоразведки или другие документы в графическом формате.
Разработчик планирует идти в этом направлении дальше, уже анонсировал и теперь «пилотирует» новую разработку — технологию, которая анализирует вообще все документы компании, объединяет их в группы по тематикам, а затем в полуавтоматическом режиме создаёт правила для защиты нужных групп.
Рисунок 3. Схема обучения новым категориям документов в InfoWatch Traffic Monitor 7.3
Схема обучения новым категориям документов в InfoWatch Traffic Monitor 7.3 вполне проста. На вкладке «Автолингвист» создаём новую категорию.
Рисунок 4. Создание новой категории в InfoWatch Traffic Monitor 7.3
Далее загружаем в неё коллекцию документов, которые содержат информацию, по которой необходимо в дальнейшем делать фильтрацию.
Рисунок 5. Загрузка образцов документов в «Автолингвист» InfoWatch Traffic Monitor 7.3
После загрузки InfoWatch Traffic Monitor 7.3 обрабатывает коллекцию документов при помощи технологий искусственного интеллекта.
Рисунок 6. Процесс обучения системы InfoWatch Traffic Monitor 7.3
Аналогичным образом процесс обучения выглядит и с графическими объектами.
Рисунок 7. Схема обучения графического классификатора новым категориям изображений в InfoWatch Traffic Monitor 7.3
Перехват файлов добавляемых в архив
Универсальный перехватчик файлов обеспечивает перехват выгрузки файлов из проприетарных приложений и любого облачного хранилища.
Для контроля передачи файлов через приложение нужно, чтобы вендор поддержал перехват этого приложения. При изменении протокола приложения перехват может перестать работать, и это потребует от вендора доработок и выпуска обновления.
Универсальный перехватчик файлов InfoWatch Application Monitor не зависит от протокола и способа шифрования — в частности, не нарушает шифрование по ГОСТ и не чувствителен к специфике передачи данных того или иного веб-сервиса. Например, AWS, Google, Microsoft Azure могут передавать файлы через WebSocket — протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени. При таком способе передачи файлов стандартный перехват веб-трафика бесполезен. InfoWatch Application Monitor будет работать в любом случае. Любое новое приложение можно поддержать за очень короткое время, и это не потребует обновления DLP-системы.
С помощью технологии InfoWatch Application Monitor реализована возможность перехватывать файлы добавляемые в архив через программы 7Zip или WinRAR, что позволяет автоматически проанализировать и выявить конфиденциальную информацию в зашифрованных архивах.
Этот кейс полезен, если нужно посмотреть, что сотрудник решил спрятать на своём рабочем месте, какие документы решил поместить в зашифрованный архив.
На практике, как обычно бывает, сотрудник за несколько недель до увольнения начинает архивировать документы, а в последний день (за полчаса до конца рабочего дня) — массово копировать на флешку. InfoWatch Traffic Monitor 7.3 позволяет предотвратить такие виды утечек, обращая внимание офицера информационной безопасности на подозрительные действия сотрудника с конфиденциальной информацией, т. е. предотвратить инцидент в ИБ на ранней стадии.
Если говорить о контроле действий с файлами, то у InfoWatch Traffic Monitor помимо стандартного для всех DLP-систем контроля почты, мессенджеров, облачных сервисов, съёмных носителей и вывода на печать предусмотрен контроль за перемещениями файлов между рабочими станциями и файловыми ресурсами. InfoWatch Traffic Monitor может блокировать файловые операции по результатам лингвистического анализа содержания файлов. Таким образом можно, например, реализовать политику, при которой доступ к определённым файлам будут иметь конкретные сотрудники компании.
Интеграция с облачными сервисами
Тема крайне актуальна в условиях гибридной работы, когда сотрудники часть времени проводят удалённо и работают с личных устройств; в этом случае данные могут перемещаться вообще вне корпоративного периметра — из облака на личные неконтролируемые устройства. Единственный выход — интеграция с облачным сервисом напрямую.
Ранее была сделана интеграция с сервисами Microsoft Teams, Exchange Online и Office 365 Business. Сейчас разработчик активно занимается интеграциями с отечественными сервисами, интерес к которым очевидным образом возрос в современных реалиях.
Рисунок 8. Перехват данных из Microsoft Teams в InfoWatch Traffic Monitor 7.3
Установка и эксплуатация системы в крупных организациях
Обновлены инсталлятор серверных компонентов и механизмы распространения агентов, благодаря чему установка и обновление системы даже в очень больших компаниях ускорились в несколько раз. Переработанный графический интерфейс инсталлятора уменьшает риск ошибки из-за человеческого фактора, удобен, в том числе при установке компонентов продукта на разных серверах, что особенно важно при территориально распределённых внедрениях продукта. Также это позволяет масштабировать инсталляцию продукта — например, добавлять серверы, обеспечивающие перехват трафика.
Агенты устанавливаются на рабочие станции параллельно благодаря использованию множественных точек распространения с учётом топологии сети, что позволяет выйти на показатели установки в 10 000 агентов не более чем за 5 рабочих дней.
Обновлена система управления правами доступа, что позволяет необходимым образом ограничивать права подразделений и отдельных пользователей, сохраняя общий контроль. Кроме того, всё чаще данные DLP-систем становятся востребованными другими подразделениями, например отделом кадров. В InfoWatch Traffic Monitor 7.3 им можно дать права доступа к структуре коммуникаций, метаданным, данным об активности сотрудников, но, например, закрыть доступ к содержимому переписки.
Защита данных DLP-системы
Поскольку DLP-система — сама по себе огромное хранилище конфиденциальной информации, существуют риски опасных действий с ней со стороны привилегированных пользователей (злоупотребление полномочиями специалиста по ИБ, сокрытие инцидентов, предоставление доступа непрофильным сотрудникам).
Для эффективной работы департамента ИБ необходимо распределить обязанности. Чтобы сотрудники видели только нужные им данные, руководителю ИБ требуется настроить роли и определить для них права доступа.
Для минимизации указанных рисков в InfoWatch Traffic Monitor 7.3 реализованы:
- расширенный аудит действий сотрудников ИБ — политик, запросов, событий, объектов защиты, элементов настройки технологий и периметров,
- разграничение прав доступа специалистов по ИБ для разделения полномочий и разграничение доступа к срезам событий,
- защита от подбора пароля согласно рекомендациям ФСТЭК России.
Подробный журнал аудита позволяет выявить все действия сотрудников ИБ.
Рисунок 9. Расширенный аудит действий сотрудников ИБ в InfoWatch Traffic Monitor 7.3
Кроме того, система разграничения доступа позволяет гранулярно настроить права доступа к ресурсам InfoWatch Traffic Monitor 7.3 для сотрудников ИБ.
Рисунок 10. Гранулярная настройка прав доступа к ресурсам InfoWatch Traffic Monitor 7.3 для сотрудников ИБ
Визуальная аналитика в InfoWatch Vision
Для предотвращения утечек InfoWatch Traffic Monitor 7.3 ежедневно собирает миллионы событий. InfoWatch Vision является Bl-системой для анализа этих данных.
InfoWatch Vision позволяет визуализировать карту коммуникаций компании, подразделений или отдельных персон, маршруты перемещения конкретных файлов или выбранных типов конфиденциальной информации, предоставлять сводную статистику по компании и моментально погружаться (drill-down) до подробностей событий, проводить расследования на основании неполных данных и т. д.
Рисунок 11. Панель мониторинга в InfoWatch Vision
Граф взаимосвязей визуализирует коммуникации сотрудников и информационные потоки. С помощью этого инструмента можно определить маршрут перемещения информации определённых категорий (например, персональных данных) и конкретных файлов, построить карту коммуникаций для групп сотрудников, выявить неочевидные связи и подозрительные взаимодействия.
Рисунок 12. Граф взаимосвязей в InfoWatch Vision
Цифровое досье накапливает информацию о сотруднике и автоматически пополняется данными о событиях DLP-системы с его участием; любую другую информацию можно вносить вручную.
Рисунок 13. Цифровое досье в InfoWatch Vision
С помощью фильтров можно найти любые события, перехваченные InfoWatch Traffic Monitor.
Рисунок 14. Список событий в InfoWatch Vision
Выбрав событие, можно увидеть его подробности в InfoWatch Traffic Мonitor.
Предиктивный анализ данных DLP-системы (UBA)
Предиктивная аналитика InfoWatch Prediction помогает заметить среди миллионов событий наиболее подозрительные. Инструмент выявляет паттерны потенциально опасного поведения сотрудника за счёт технологий машинного обучения и позволяет эффективно работать с группами риска.
В InfoWatch Prediction есть предустановленные группы риска: «Подготовка к увольнению», «Аномальный вывод информации», «Нетипичные внешние коммуникации», «Отклонение от бизнес-процессов», «Нелояльные сотрудники».
Система анализирует сотни параметров и сравнивает поведение каждого сотрудника с его же поведением в прошлом и ищет отклонения, т. е. не используется некое заранее прописанное вручную «эталонное» поведение сотрудника; это позволяет оценивать реальную, а не «сферическую» обстановку. Учитывается не только то, как работает сотрудник, но и то, как работают его коллеги; это позволяет снизить количество ложноположительных срабатываний.
Анализируются все перехваченные DLP-системой события по всем каналам (почта, мессенджеры, кейлогер, съёмные устройства, облачные хранилища и т. д.); это даёт возможность не пропустить важные события в цепочке. Учитываются не только происшествия, на которые сработали политики, но и события в «серой зоне», что позволяет существенно снизить зависимость от качества исходной настройки DLP-системы.
В итоге специалист по ИБ своевременно получает данные для принятия конкретных решений, а не абстрактную характеристику сотрудника.
Вначале анализируется совокупность данных из DLP-системы InfoWatch Traffic Monitor.
Рисунок 15. Анализ аномального поведения всех сотрудников компании в InfoWatch Prediction
Далее проводится анализ отдельных аномалий или их совокупности, а также последовательных цепочек связанных событий.
Рисунок 16. Анализ аномалий поведения конкретного сотрудника в InfoWatch Prediction
Подозрительное поведение сотрудника часто сигнализирует о готовящемся нарушении. Это может быть единичная аномалия, а может быть и целая цепочка неочевидных событий. Технологии машинного обучения позволяют анализировать и то и другое. Порознь события незаметны и неподозрительны. В совокупности — чёткая картина.
Затем осуществляется автоматическое формирование групп риска.
Прогнозирование рисков не сказывается на отделе ИБ дополнительной нагрузкой.
Выводы
InfoWatch Traffic Monitor 7.3 с помощью технологий искусственного интеллекта предотвращает утечку конфиденциальной информации, в автоматизированном режиме актуализирует политики безопасности и помогает прогнозировать риски в ИБ.
InfoWatch Traffic Monitor 7.3 учитывает тенденцию к переносу инфраструктур в облако и к дистанционной работе сотрудников в эпоху пандемии с использованием личных устройств, а также даёт возможность мониторинга коммуникаций сотрудников даже вне периметра компании. Это достигается при помощи интеграции продукта по API.
Новые перехватчики в InfoWatch Traffic Monitor нечувствительны к изменению проприетарных протоколов, способов шифрования и специфики передачи данных веб-сервиса. Реализованная возможность перехвата файлов добавляемых в архив позволяет предотвращать утечки на ранней стадии.
Интерактивный инструмент визуализации (InfoWatch Vision) отображает весь ландшафт коммуникаций в компании на графе, даёт возможность выявить подозрительные связи и отобразить движение информации между сотрудниками либо за периметр, помогает в расследованиях.
Кроме того, учитывая, что современный рынок DLP-систем движется в сторону анализа больших данных и старается эффективнее управлять рисками, наличие в экосистеме продуктов InfoWatch инструмента предиктивной аналитики (UBA), который тесно интегрируется с InfoWatch Traffic Monitor 7.3, позволяет последнему в автоматическом режиме предупреждать об аномальном поведении сотрудников.
Наличие технологий искусственного интеллекта повышает качество и скорость работы InfoWatch Traffic Monitor. Например, автоматическое обучение DLP-системы новым категориям документов и графическим объектам позволяют специалисту по ИБ сделать контентные фильтры самостоятельно, без привлечения лингвистов вендора, примерно за несколько минут.
Достоинства:
- Полностью российский продукт для защиты от утечек информации, работающий на отечественных Linux-системах.
- Наличие сертификата соответствия требованиям ФСТЭК России.
- Готовые базы контентной фильтрации, которые оптимизированы под потребности конкретных сегментов рынка.
- Интерактивный визуальный анализ данных.
- Универсальный перехватчик файлов, который нечувствителен к протоколу веб-сервиса.
- Автоматическое обучение DLP-системы новым категориям документов и изображений.
- Поддержка большого числа протоколов для перехвата и блокировки передачи данных.
- Широкие возможности интеграции со сторонними продуктами и сервисами (множество готовых кейсов по интеграции).
Недостатки:
- Отсутствие поддержки операционной системы macOS.
Время на прочтение
7 мин
Количество просмотров 25K
«Игорь, у него ДВА сердца!!!»
Анна Попова, руководитель Блока DLP ГК Инфосекьюрити, продолжает делиться своими впечатлениями от использования разных DLP-систем. В прошлой статье она рассказала о плюсах и минусах решения КИБ SearchInform. Сегодня, как и было обещано, поговорим про линейку продуктов InfoWatch. Только давайте сразу определимся, что на объективное сравнение мы не претендуем.
Вообще сложно понять, что такое объективное мнение о системе. Объективные характеристики – это соответствие DLP-системы техническим требованиям заказчика, требованиям ФСТЭК и т.п., а также соотнесение их с необходимыми мощностями. Все прочее – субъективно, ибо реальность такова, что функциональность, которая у одного клиента «взлетела», у другого упадет. И уж тем более не приходится говорить об объективном превосходстве одной системы над другой, если речь идет о её эксплуатации аналитиками. Кому-то нравится один интерфейс, кому-то другой, кому-то не нравится выгрузка событий, кому-то она не важна.
Про продукт DLP от компании InfoWatch сказано много; много копий сломано вокруг него. Мнения встречаются самые разнообразные – от самых полярных до нейтральных. С течением времени и компании, и продукту довелось пройти долгий и тернистый путь развития, отрастить не одну полезную функцию и даже попасть в «магический квадрант» Gartner. Так попробуем же разобраться, чего удалось достигнуть продукту, так ли он хорош (или плох), как о нём говорят.
Архитектура (who is who)
Прежде всего нужно понять, с чем мы работаем. Программный комплекс InfoWatch Traffic Monitor состоит из следующих компонентов:
InfoWatch Traffic Monitor – основной компонент, отвечающий за сетевой перехват и анализ перехваченных данных (собранных по сети и с агентов). Работает на RHEL/CentOS 6. Также отвечает за отрисовку веб-интерфейса, который является основной точкой входа для офицера ИБ при работе с системой.
InfoWatch Device Monitor – этот компонент отвечает за управление агентами (в том числе за агентские политики). Работает на Windows Server. Имеет отдельную консоль управления, которую можно инсталлировать на любую машину с Windows – главное, чтобы был открыт сетевой доступ до сервера Device Monitor.
InfoWatch Crawler – модуль, дающий возможность сканирования указанных пользовательских каталогов и сетевых директорий. Работает на Windows Server (может быть установлен на машину с сервером Device Monitor), но интерфейсно интегрируется в веб-консоль Traffic Monitor и управляется оттуда же.
InfoWatch Vision – опциональный компонент, позволяющий существенно упростить процесс расследования инцидентов ИБ за счёт визуализации. Представляет события из Traffic Monitor в виде автоматически перестраиваемых интерактивных графиков. Работает на Windows Server и базируется на платформе QlikSense.
InfoWatch Person Monitor – также опциональный модуль, предоставляющий функционал контроля рабочего времени. Работает на Win Server, берёт свои корни от легендарной, в некотором роде, системы «Стахановец».
Функционал блокировки
Так как система носит гордый статус DLP (что, напомним, означает Data Leakage Prevention – предотвращение утечки данных), в первую очередь рассмотрим «классический» функционал для таких систем – предотвращение. Что же может предложить нам рассматриваемый программный комплекс?
Даже в минимальной инсталляции (Traffic Monitor, Device Monitor) функционал достаточно богат: возможна блокировка почты, предотвращение записи на съёмные носители по результатам контентного анализа или по белым спискам носителей, запрет запуска приложений, запрет использования FTP. С подключением модуля Person Monitor функционал несколько расширяется: добавляется возможность очистки буфера обмена, запрет загрузки файлов в интернет.
Неподготовленному пользователю будет сперва непросто разобраться во всём многообразии различных консолей управления: так, одной из особенностей при работе с системой является необходимость «включения» некоторых каналов перехвата в Device Monitor.
В целом, функционал предотвращения не вызывает вопросов, здесь есть, где разгуляться; хотя самым требовательным клиентам, наверное, всё же придётся обратиться к более гибким конкурирующим продуктам. Что касается функционала учета рабочего времени, то в IWTM он реализован оригинальным, но достаточно удобным способом.
Функционал контроля рабочего времени
Рынок DLP, особенно в странах СНГ, сегодня не ограничивается исключительно функционалом предотвращения. Системы DLP мало-помалу вбирают в себя функционал другого класса продуктов – систем мониторинга рабочей деятельности сотрудников.
Рассматриваемый продукт не стал исключением и тоже вобрал кое-что. Насколько качественно?
Контролировать сотрудников можно при помощи модуля Person Monitor – начиная с кейлогера и заканчивая видео с рабочего стола, а также контролем веб-камеры и звука с микрофона. Однако не всё так радужно. Выше упомянуто, что данный модуль является интерпретацией нашумевшего «Стахановца». Отсюда и минусы – например, абсолютное отсутствие интеграции с остальными модулями комплекса и гарантированное покрытие «полным контролем» лишь пятидесяти машин. Особое умиление доставила защита БД – шифрование не нужно, данные в базе хранятся всего лишь в изменённой кодировке. «Чтобы никто не догадался!..»
Кстати, касательно умилений: при первом открытии веб-интерфейса Person Monitor предупреждает, что соединение не зашифровано (обычный http, то бишь) и предлагает ссылку на мануал, по которому каждый может сам себе настроить https. Почему этого было не сделать «из коробки» – неясно.
Ещё есть очень интересная функция распознавания голоса в текст. Реализовано это через API Google, что для многих заказчиков будет проблемой: во-первых, требуется подключение сервера к интернету, а во-вторых, не каждый согласится передавать свою конфиденциальную информацию третьей стороне.
При проведении расследований по собранной Person Monitor’ом информации мы испытывали дискомфорт, потому что привыкли работать со всей доступной информацией со всех доступных каналов и по всем сотрудникам. К тому же местный поиск по насниффанным кейлогером данным обладает лишь самым базовым функционалом – например, есть морфология, но интересные и сложные правила текстового поиска построить не удастся. Тем не менее, на небольших объёмах трафика и в малых компаниях с этим всем вполне можно жить.
С технической точки зрения Person Monitor состоит из агента, собирающего данные с рабочей станции пользователя, сервера с БД (MSSQL), где эти данные потом хранятся, и Apache для Windows, отрисовывающего веб-интерфейс системы. По запросу пользователя составляется SQL-запрос, и его результат предстаёт перед юзером в виде html-страницы отчёта.
Говоря о малых и больших компаниях, плавно переходим к ещё одному модулю – Vision. Он был словно создан по нашему заказу – позволяет упорядочить перехваченные Traffic Monitor’ом данные для наглядного представления и помимо этого даёт возможность на лету перестраивать запросы. Всё это возможно не в последнюю очередь благодаря платформе QlikSense, оперирующей вытянутыми из Traffic Monitor событиями в оперативной памяти сервера Vision.
События нужно подгружать раз в определённый промежуток времени – например, каждую ночь, поскольку выгрузка больших объёмов данных занимает продолжительное время.
Общее впечатление
Рассматриваемая система, как и любая другая, не лишена недостатков. К сожалению, до сих пор остаются некоторые «детские болячки», тянущиеся с ранних версий (например, перечисленные проблемы Person Monitor’а); некоторые решения выглядят спорно – не всегда понятно, баг это или фича (разобщённость консолей и использование разных БД для хранения событий). Если вам необходим упор на какой-то конкретный функционал, а не комплексное решение, рекомендуется продолжить изучение рынка DLP.
Когда-то мы начали изучение рынка DLP именно с InfoWatch Traffic Monitor, поэтому минусы сразу бросились в глаза:
- даже при минимальной инсталляции требуется два сервера — Traffic Monitor, Device Monitor — на системах разных семейств;
- при максимальной инсталляции требуется установка двух агентов на рабочую станцию сотрудника;
- пользователь системы вынужден применять в работе не одну консоль, а от двух до пяти (Traffic Monitor, Device Monitor, Person Monitor, консоль настроек Person Monitor, Vision);
- при всём вышеизложенном интеграции Person Monitor с остальным комплексом просто нет – ощущение, что работаешь в отдельной системе.
Однако, продолжив изучать рынок дальше, обнаружили множество плюсов (воистину, всё познаётся в сравнении):
- стабильность работы;
- простота и быстрота раскатки. В наличии имеется kickstart-образ Traffic Monitor’а, а Windows компоненты устанавливаются по паттерну «Далее – Далее – Готово»;
- гибкость системы. Освоившись с интерфейсом всех консолей, можно накручивать достаточно сложные правила срабатывания, которые будут применены сразу же при поступлении трафика;
- скорость проведения расследования. Несмотря на то, что Vision ещё молод и не оброс достаточным для нас количеством функций, его скорость и наглядность это компенсируют. При работе с прошлыми крупными заказчиками он бы нам очень пригодился в составе боевой системы.
При подготовке статьи мы опросили своих коллег – практикующих аналитиков, какое впечатление на них произвела система DLP от InfoWatch. Суммируя все сказанное, выделим несколько плюсов и минусов.
Минусы:
- несвязность консолей;
- нефункциональное разграничение доступа (вроде есть, но не всегда можно настроить, как хочется — например, дашборд);
- один из модулей вообще собирает информацию, которую ядро анализировать не может;
- используется аж два агента, некоторые функции включены в оба;
- данные нужно перегонять между базами;
- в один сервер полный функционал поместить невозможно даже в самом минимальном внедрении;
- логика работы PM (оперирование не событиями, а отчетами) не позволяет комфортно использовать его для всей зоны покрытия, а исключительно «точечно».
Плюсы:
- готовность реализовывать функционал, если нужно;
- простота в установке (кикстарт);
- масштабируемость;
- много видит, много понимает – большой выбор каналов, работа с мобильным трафиком, большой выбор методов детектирования конфиденциальных данных;
- относительно быстрый поиск и удобный предпросмотрщик с подсветом различных объектов разными цветами;
- подробное описание технологий и объектов защиты;
- автоматическое определение критичности, разгрузка офицера и т.п.;
- много внимания уделяется визуализации собранной информации. Одно из лучших решений на рынке.
Из минусов – да, увы, это многоконсольность и не всегда логичное разделение функционала между ними. Это не только неудобно, но и совсем неэффективно, когда нужно собрать доказательную базу для расследования, а данные в разных базах, и привести их к одному виду средствами самой системы никак нельзя. Много лишней ручной работы аналитика или безопасника.
Нас порадовало стремление вендора реализовывать доработки для потенциальных клиентов, т.е. без наличия обязывающих договорных отношений. Это абсолютно реальный пример: через полгода после обсуждения кучи доработок, заявленных нами на пилоте в одном из клиентов, мы увидели их в реализованном функционале, что было крайне приятно.
Причем, IW один из немногих вендоров, который внимательно относится к обсуждению таких проблем, не отфутболивает по тегу – а зачем это нужно, вы первые, кто спрашивает об этом и т.п. (Саша Клевцов, передаем тебе отдельный привет и самые лучшие пожелания :)).
В сухом остатке имеем достаточно сбалансированную систему, закрывающую большинство требований самых занудных заказчиков и не обладающую завышенными системными требованиями. InfoWatch последовательно «прокачивает» свой комплекс, добавляя новые крутые функции. Остаётся только аккуратно сшить их между собой :).
Анна Попова, руководитель Блока DLP, ГК Инфосекьюрити
Никита Шевченко, руководитель группы инженерного сопровождения Блока DLP, ГК Инфосекьюрити
Исследования в Гимназии №1505
You are here
Home » Полное руководство к системам InfoWatch Traffic Monitor и Device Monitor
28 Oct 2018 22:10
KVDmitrieva
https://kb.infowatch.com/#all-updates
Источник информации относится к исследованию:
Корпоративная защита от внутренних угроз безопасности
- Log in to post comments
107061, Москва, ул 2-Пугачевская, 6А
+7 (495) 963-76-77
Обратная связь
Время на прочтение
5 мин
Количество просмотров 3K
Что делать, если мощности одного сервера не хватает для обработки всех запросов, а производителем ПО не предусмотрена балансировка нагрузки? Есть много вариантов – от покупки балансировщика нагрузки до ограничения числа запросов. Какой из них правильный, нужно смотреть по ситуации, принимая во внимание существующие условия. В этой статье мы расскажем, что можно сделать, если бюджет ограничен, а в наличии имеется свободный сервер.
В качестве системы, для которой необходимо было уменьшить нагрузку на один из серверов, мы выбрали DLP (система предотвращения утечки информации) от InfoWatch. Особенностью реализации стало размещение функции балансировщика на одном из «боевых» серверов.
Одна из проблем, с которой мы столкнулись, – невозможность использования Source NAT (SNAT). Для чего это было нужно и как проблема была решена, мы расскажем далее.
Итак, первоначально логическая схема существующей системы выглядела следующим образом:
Трафик ICAP, SMTP, события с компьютеров пользователей обрабатывались на сервере Traffic Monitor (TM). При этом сервер базы данных легко справлялся с нагрузкой после обработки событий на TM, а вот нагрузка на сам TM была большой. Это было видно по возникновению очереди сообщений на сервере Device Monitor (DM), а также по загрузке процессора и памяти на TM.
На первый взгляд, если в эту схему добавить еще один сервер TM, то на него можно было бы переключить либо ICAP, либо DM, но такой способ мы решили не использовать, т. к. снижалась отказоустойчивость.
Описание решения
В процессе поиска подходящего решения мы остановились на свободно распространяемом ПО keepalived совместно с LVS. Поскольку keepalived решает задачу создания отказоустойчивого кластера, а также может управлять балансировщиком LVS.
То, к чему мы хотели прийти (снизить нагрузку на TM и сохранить текущий уровень отказоустойчивости), должно было работать по следующей схеме:
При проверке работоспособности выяснилось, что установленная на серверах кастомная сборка RedHat не поддерживает SNAT. В нашем случае мы планировали использовать SNAT для того, чтобы входящие пакеты и ответы на них отправлялись с одного и того же IP-адреса, иначе мы бы получили следующую картину:
Это неприемлемо. Например, прокси-сервер, отправив пакеты на Virtual IP (VIP) адрес, будет ожидать ответ с VIP, но в данном случае он придет с IP2 для сессий, отправленных на backup. Решение было найдено: потребовалось создать еще одну таблицу маршрутизации на backup и соединить два сервера TM отдельной сетью, как показано ниже:
Настройки
Реализуем схему из двух серверов с сервисами ICAP, SMTP, TCP 9100 и установленным на одном из них балансировщиком нагрузки.
Мы имеем два сервера RHEL6, из которых удалены стандартные репозитории и часть пакетов.
Сервисы, которые нам необходимо балансировать:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Сервис передачи трафика от DM – tcp 9100.
Для начала нам надо спланировать сеть.
Виртуальный IP-адрес (VIP):
• IP: 10.20.20.105.
Сервер TM6_1:
• External IP: 10.20.20.101;
• Internal IP: 192.168.1.101.
Сервер TM6_2:
• External IP: 10.20.20.102;
• Internal IP: 192.168.1.102.
Затем включаем IP forwarding на двух серверах TM. Как это сделать на RedHat описано здесь.
Решаем, какой из серверов у нас будет главный, а какой – резервный. Пусть master – это TM6_1, backup – TM6_2.
На backup создаем новую таблицу маршрутизации balancer и правила маршрутизации:
[root@tm6_2 ~]echo 101 balancer >> /etc/iproute2/rt_tables
[root@tm6_2 ~]ip rule add from 192.168.1.102 table balancer
[root@tm6_2 ~]ip route add default via 192.168.1.101 table balancerВышеописанные команды работают до перезагрузки системы. Чтобы маршруты сохранились после перезагрузки, можно их вписать в /etc/rc.d/rc.local, но лучше через файл настроек /etc/sysconfig/network-scripts/route-eth1 (обратите внимание: здесь используется другой синтаксис).
Устанавливаем keepalived на оба сервера TM. В качестве источника дистрибутива мы использовали rpmfind.net:
[root@tm6_1 ~]#yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/keepalived-1.2.13-5.el6_6.x86_64.rpmВ настройках keepalived назначаем один из серверов master, другой – backup. Затем задаем VIP и сервисы для балансировки нагрузки. Файл настроек обычно расположен тут: /etc/keepalived/keepalived.conf.
Настройки для сервера TM1
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state MASTER
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 151
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}
virtual_server 10.20.20.105 1344 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 25 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 9100 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
}Настройки для сервера TM2
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}Устанавливаем на master LVS, который будет балансировать трафик. Для второго сервера не имеет смысла устанавливать балансировщик, т. к. в конфигурации у нас всего два сервера.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmУправлять балансировщиком будет keepalived, который мы уже настроили.
Для полноты картины добавим keepalived в автозапуск на обоих серверах:
[root@tm6_1 ~]#chkconfig keepalived onЗаключение
Проверка результатов
Запустим keepalived на обоих серверах:
service keepalived startПроверка доступности виртуального адреса VRRP
Убедимся, что VIP находится на master:
А на backup нет VIP:
С помощью команды ping проверим доступность VIP:
Теперь можно выключить master и снова запустить команду ping.
Результат должен остаться таким же, а на backup мы увидим VIP:
Проверка балансировки сервисов
Возьмем, к примеру, SMTP. Запустим одновременно два подключения к 10.20.20.105:
telnet 10.20.20.105 25На master мы должны увидеть, что оба подключения активны и соединены на разные сервера:
[root@tm6_1 ~]#watch ipvsadm –Ln
Таким образом, мы реализовали отказоустойчивую конфигурацию сервисов TM c установкой балансировщика на один из серверов TM. Для нашей системы это снизило нагрузку на TM в два раза, что позволило решить проблему отсутствия горизонтального масштабирования средствами системы.
Данное решение в большинстве случаев реализуется быстро и без дополнительных затрат, но иногда существует ряд ограничений и сложностей в настройке, например при балансировке UDP-трафика.