Infowatch vision руководство

Время на прочтение
7 мин

Количество просмотров 24K

«Игорь, у него ДВА сердца!!!»

Анна Попова, руководитель Блока 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, ГК Инфосекьюрити

INFOWATCH VISION Для предотвращения утечки данных DLP‑система собирает и обрабатывает огромный массив информации. Применение правильных инструментов визуализации к этим данным позволяет выйти на качественно новый уровень управления, решать более сложные и разнообразные задачи. Так компании переходят на следующую ступень зрелости, где информационная безопасность становится частью стратегии бизнеса. От скорости, гибкости и наглядности аналитики зависит , насколько полезной для принятия бизнес‑решений окажется информация, которую предоставляет офицер ИБ Сколько усилий вам потребуется приложить для формулировки и верификации гипотезы? Можете ли вы оперативно получить наглядную картину того, что происходит в вашей организации? Как быстро вы можете определить путь распространения информации по каналам коммуникаций?

Embed Size (px)

Text of INFOWATCH VISION · информационной безопасности организаций ….

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.