CC BY
143
АНАЛИЗ СЕТЕВОГО ТРАФИКА КОРПОРАТИВНОЙ СЕТИ ПО ПРОТОКОЛУ SMTP НА ПРЕДМЕТ УТЕЧЕК ИНФОРМАЦИИ
А.И. Спивак
Научный руководитель - д.т.н., профессор Л.Г. Осовецкий
Контроль за почтовым трафиком сети должен осуществлять специалист по защите информации. Существующие системы контроля работают при условии переконфигурирования почтового сервера сети. Представлен продукт, работающий на уровне работы сети, а не на уровне работы почтовой программы.
Введение
Постоянное совершенствование и развитие области информационных технологий вызывает повышение степени сложности данной сферы человеческой деятельности. Это, несомненно, сказывается и на обеспечении безопасности. Большое количество новых технологий уже невозможно контролировать руками одного, а подчас и нескольких человек. Усложнение вызвано не только появлением новых технологий, но и расширением области применения старых. Используемые информационные инфраструктуры в настоящее время включают в себе самые различные механизмы и способы взаимодействия различных систем. Все это позволяет достигать наиболее эффективного решения поставленных перед ними задач, а также быструю адаптацию к решению новых задач. Наравне с плюсами такого построения инфраструктуры есть и сложности. Прежде всего, это учет всех механизмов взаимодействия, которых может быть много в таких гетерогенных системах. Их контроль должен быть таким же тщательным, как и в типовых схемах построения информационных систем. Безопасность в данном случае должна обеспечиваться с применением различных систем. Многие инструменты решения этих задач уже представлены широкой общественности и используются специалистами по защите информации. Но не во всех направлениях обеспечения безопасности имеются необходимые средства. В работе будет представлено средство контроля за сетевым трафиком по протоколу SMTP.
Почтовые сообщения являются одним из широко используемых средств обмена информации между людьми. Контроль за данным каналом обмена информации также должен осуществляться специалистом по обеспечению безопасности. Важно отметить, что существующие в данный момент средства анализа сетевого трафика не обладают необходимым набором функций для удовлетворения всех потребностей для контроля. Сетевые сниферы позволяют только обнаружить факт передачи информации от одного узла сети к другому без дополнительной информации о содержимом данного взаимодействия. Они производят перехват пакетов и вывод информации об адресах и портах узлов, участвующих в передаче. Этого, как правило, недостаточно для принятия решения о безопасности данного взаимодействия. Сложность заключается в отделении потоков, которые представляют собой вполне законные почтовые сообщения, от возможных утечек информации. Для этого необходимо сосредоточить свое внимание только на одном сетевом протоколе и производить доскональный анализ циркулирующей по нему информации.
Методы анализа почтового трафика
Перехват можно осуществлять в нескольких принципиально отличных точках -на уровне работы сети и на уровне работы приложений. В первом случае должен производиться анализ трафика, а во втором необходимо вмешиваться в логику работы почтовой программы с целью реализации механизма проверки почтовых сообщений на предмет утечек информации. Как правило, необходимо переконфигурирование почто-
вого сервера, чтобы он передавал проходящую почту контролирующей программе. При этом надо учитывать, что многие приложения имеют закрытый исходный код и не предоставляют интерфейса, позволяющего каким-либо образом получить доступ к почтовым сообщениям, проходящим сквозь них. Существуют программы с открытым исходным кодом, а также программы с реализацией вышеупомянутого интерфейса. В обоих случаях достаточно сложно реализовать контроль за содержимым почтовых сообщений, так как нужно вмешиваться в работу сторонней программы и учитывать нюансы ее работы. У данного метода существует еще ряд недостатков. Контроль будет осуществляться только за тем почтовым трафиком, который проходит через почтовый сервер с системой анализа. Ведь существует возможность отправки напрямую, минуя почтовый сервер, на котором производится контроль трафика. Правда, этому можно воспрепятствовать, правильным образом сконфигурировав межсетевой экран. Другим недостатком можно назвать зависимость работы всей почтовой системы от работы программы анализа - сбой приведет к остановке функционирования почтового сервиса в рамках всей организации. Существуют у данного метода и достоинства. Это, прежде всего, возможность блокировки отсылки письма, которое вызвало подозрение у системы анализа. Другим плюсом является гарантированная проверка всех писем, проходящих через сервер. Но, несмотря на это, перехват сетевого трафика на уровне работы сети представляется более целесообразным. Преимущества данного метода заключаются в том, что не нужно ориентироваться на логику сторонней программы, а тем более вносить изменения в конфигурацию почтового сервера. Контролирующую машину (если используется выделенная машина для контроля) можно защитить гораздо сильнее, чем почтовый сервер, вплоть до того, что вообще не присваивать ей IP-адрес, чтобы полностью исключить удаленную работу с ней. Кроме того, она требует практически нулевого времени на обслуживание. При необходимости можно исключить доступ даже сотрудников отдела администрирования к серверу мониторинга. При использовании данного метода можно вообще исключить риск потери функциональности почтовой системы в случае любых сбоев в системе контроля. Также немаловажную роль играет возможность внедрения практически в любую точку, где проходит почтовый трафик информационной системы, что позволяет масштабировать и легко переносить рассматриваемую в проекте систему. Недостатком можно назвать невозможность заблокировать отсылку письма, которое можно интерпретировать как утечку информации. В случае использования слабого или сильно загруженного сервера для мониторинга и высокого объема почтового трафика (например, в пиковые моменты), некоторые сообщения могут быть пропущены монитором [1].
Использоваться могут оба рассмотренных метода, и выбор их всецело зависит от условий работы в конкретном случае. Разработанная система анализа почтового трафика является примером сетевого подхода к контролю пересылки корреспонденции.
Самой большой группой продуктов по мониторингу сетевого трафика, выполняющих схожие по функциям действия, являются антивирусы, особенно антивирусы для работы с почтовым трафиком. Использование фильтра Milter позволяет прослушивать SMTP-диалог и модифицировать SMTP-ответы сервера Sendmail. Другой группой являются разнообразные сниферы, работающие под управлением операционной системы Windows и обладающие широким спектром возможностей, в частности, выделение из трафика сообщений электронной почты.
Прямыми коммерческими аналогами являются: InfoWatch Mail Monitor, Дозор-Джет, MIMEsweeper for SMTP. Отличие от разрабатываемой системы у данной группы продуктов одинаковое - необходимость переконфигурирования почтового сервера для перенаправления всего почтового трафика на компьютер с установленной системой мониторинга.
Описание работы программы
Наиболее предпочтительной для разработки операционной системой является Unix за счет стабильности, повсеместного использования в качестве сетевых сервисов, производительности, отказоустойчивости и прозрачности работы, а также наличия исходных текстов самой операционной системы.
Реализацию в среде Unix можно производить, основываясь на нескольких способах перехвата сетевого трафика. Выделим следующие методы: на уровне коммутаторов, bpf, libpcap, RAW-сокеты, divert-сокеты, система протоколирования пакетных фильтров (ULOG), kernel modules. Библиотека libpcap была выбрана для написания программного продукта как наиболее подходящая и удовлетворяющая всем требованиям. Главными можно назвать следующие: работа на пользовательском уровне, для исключения возможности краха системы вследствие ошибки в программе, широкое использование (библиотека использовалась для написания таких известных программ, как tcpdump и snort), отсутствие необходимости реализации многих функций обработки -они уже заложены в саму библиотеку.
Функционирование программы осуществляется в соответствии со схемой (рис. 1).
Рис. 1. Схема работы программы
Рассмотрим подробно каждый компонент программного продукта.
Основываясь на том предположении, что многозадачность в среде UNIX, как правило, реализуется наличием нескольких процессов, данная программа выполнена в виде нескольких демонов.
Программа представляет собой консольное приложение, которому необходимо при запуске передать два параметра: директорию для хранения промежуточных и конечных данных, полученных в ходе перехвата трафика, и файл в этой директории с записанными в нем шаблонами для поиска ключевых слов.
Затем производится создание процесса, который представляет собой демон захвата трафика, для этого выполняется ряд действий. Организуются собственная группа и сеанс, не имеющий управляющего терминала. Это позволяет демону избавиться от сиг-
налов, генерируемых терминалом (SIGINT или SIGHUP), например, при нажатии определенных клавиш или выходе пользователя из системы. Лидером группы и сеанса может стать процесс, если он еще не является лидером. Поскольку, как правило, предыстория запуска данной программы неизвестна, необходима гарантия, что процесс не является лидером группы. Для этого порождается дочерний процесс. Так как его PID уникален, то ни группы, ни сеанса с таким идентификатором не существует, а значит, нет и лидера. При этом родительский процесс немедленно завершает выполнение, поскольку он не нужен. Существует еще одна причина необходимости порождения дочернего процесса. Если демон был запущен из командной строки командного интерпретатора shell не в фоновом режиме, последний будет ожидать выполнения демона, и, таким образом, терминал будет заблокирован. Порождение процесс и завершение выполнение родителя имитируют для командного интерпретатора завершение работы демона, после чего shell выведет свое приглашение. Затем дочерний процесс с помощью системного вызова setsid() становится лидером новой группы, сеанса и не имеет ассоциированного терминала. Далее происходит смена текущего каталога на корневой. Если этого не сделать, а текущий каталог, допустим, находится на примонтированной файловой системе, последнюю нельзя будет размонтировать. Самым надежным выбором является корневой каталог, всегда принадлежащий корневой файловой системе [2]. Здесь же происходит открытие однонаправленного канала обмена между двумя родственными процессами: процессом разбора файла сессии и процессом-анализатором.
В связи с тем, что в программе производится интенсивный ввод-вывод, а также чтение с сетевого интерфейса, блокирование чтения записью приводит к потерям пакетов. При использовании механизмов межпроцессного взаимодействия (каналы, FIFO, очереди сообщений) падение производительности связано с тем, что данные, передаваемые с помощью этих объектов, копируются из буфера передающего процесса в буфер ядра и затем в буфер принимающего процесса. Механизм разделяемой памяти позволяет избавиться от накладных расходов передачи данных через ядро, предоставляя двум или более процессам возможность непосредственного получения доступа к одной области памяти для обмена данными. Безусловно, процессы должны предварительно согласовать правила использования разделяемой памяти. Например, пока один из процессов производит запись данных в разделяемую память, другие процессы должны воздержаться от работы с ней. Задача кооперативного использования разделяемой памяти, заключающаяся в синхронизации выполнения процессов, решается с помощью семафоров.
Примерный сценарий работы с разделяемой памятью выглядит следующим образом.
1. Сервер получает доступ к разделяемой памяти, используя семафор.
2. Сервер производит запись данных в разделяемую память.
3. После завершения записи сервер освобождает разделяемую память с помощью семафора.
4. Клиент получает доступ к разделяемой памяти, запирая ресурс с помощью семафора.
5. Клиент производит чтение данных из разделяемой памяти и освобождает ее, используя семафор.
В связи с необходимостью управления доступом к разделяемой памяти создается группа семафоров.
Для вывода отладочной и иной информации в процессе работы используется вывод в специальный системный журнал с помощью функции syslog(), при этом сообщение от демона получает демон журналирования, работающий в любой операционной системе UNIX. Каждая строчка в системном журнале содержит имя программы и мет-
ки: важности и тип сообщения. В данном случае используется метка INFO, DAEMON указывает на то, что сообщение получено от программы, выполняющейся как демон.
Теперь подробнее коснемся каждого компонента программы. Первым порождается процесс-анализатор. В его функции входит открытие файлов, содержащих результаты работы функции parse, и поиск в этих файлах строк по шаблону. Результат выводится в result.tx, при этом он содержит информацию о шаблоне, файле, в котором найдено соответствие, а также строку, содержащую шаблон. Информацию о файле, в котором необходимо производить поиск, процесс получает из pipe, который был создан в процессе инициализации.
Затем создается процесс записи на диск. Его логика такова, что он в цикле проверяет состояние разделяемой памяти, если там имеется хотя бы одна запись, он ее оттуда выбирает и начинает ее обработку. Разделяемая память выполнена в виде очереди: запись производится сверху очереди, а выборка снизу, при достижении максимального указателя очереди указатель на вершину сбрасывается в нуль для создания кольцевого заполнения сегмента памяти. Такая организация позволяет производить выборку в том же порядке, в котором производилась запись (что невыполнимо при создании очереди в виде стэка), а также избавляет от необходимости двигать элементы очереди, как если бы выборка велась только первого элемента очереди.
Выбираемые из очереди элементы представляют собой перехваченные с сетевого интерфейса пакеты. Пакеты с установленными флагами SYN и ACK, а также FIN не обрабатываются, также пропускаются пустые пакеты, они, как правило, представляют собой подтверждения о доставке. При получении пакета с флагами FIN и ACK производится переименование текущего файла smtp сессии и создание процесса для его обработки.
Процесс обработки не является демоном - он вызывается только в том случае, когда нужно обработать файл smtp сессии, т.е. разобрать его на составляющие, а именно тело письма, текст сессии и вложение. При необходимости вложение подвергается перекодировке. Получается, что для каждой сессии порождается свой процесс обработки, что позволяет повысить производительность системы за счет параллельной работы нескольких процессов. Перед завершением процесса он пишет в pipe имя файла, который нужно проанализировать, это сигнализирует процессу анализатору о необходимости проанализировать файл в соответствии с заданными шаблонами.
Процесс захвата трафика представляет собой функцию, используемую для создания цикла обработки захватываемых пакетов. Одним из параметров является указатель на обработчик каждого поступившего пакета. Он сделан максимально эффективным, так как малейшая задержка в обработке пакета вызовет пропуск последующего, что недопустимо. Поэтому в теле функции-обработчика производится только запись в разделяемую память с использованием семафора. Дальнейшая обработка уже производится процессом записи на диск.
Рассмотрим функционирование на примере обработки одного почтового сообщения.
1. Получение потока данных от сетевого интерфейса.
2. Запись пакетов в разделяемую память процессом захвата трафика.
3. Выборка пакетов из разделяемой памяти процессом записи на диск.
4. Запись потока в файл до достижения признака окончания smtp сессии.
5. Порождение процесса обработки сессии с целью разбора файла на данные сессии, тело письма и вложение.
6. Запись в pipe процессом обработки информации о файлах для анализа.
7. Выборка из pipe имени файла процессом анализатором и анализ содержимого файла на наличие ключевых слов.
8. Запись результатов в файл процессом анализатором.
Заключение
Рассмотренный программный продукт реализован как набор демонов, написанных на языке С и функционирующих под операционной системой UNIX. Данной метод проектирования позволил добиться производительности, расширяемости и стабильности, за счет использования преимуществ выбранной для разработки операционной системы.
Представлено описание алгоритма работы программного продукта, с перечнем компонентов и выполняемых ими функций. Использование высокоскоростных методов взаимодействия между компонентами позволило добиться максимальной производительности продукта в целом.
Дальнейшим развитием рассмотренного в работе продукта может быть добавление функциональных возможностей. Использование некоторого механизма, позволяющего добавлять проверяемые при работе протоколы, несомненно, повысит эффективность. Это можно сделать с помощью языка описания протокола, реализация которого должна быть спроектирована в программе. Кроме того, реализация обратной связи позволит предотвращать обнаруженную утечку информации по заданному протоколу проверки.
Дальнейшее развитие программного продукта позволит специалисту по защите информации получать большее количество информации о трафике контролируемой им корпоративной сети.
Литература
1. Мониторинг электронной почты [Электронный ресурс] / ред. Поляков Я., Режим доступа: http://union.kz/ru/biz/bezop/infosec/monitoringl/pda.shtml, свободный. -Загл. с экрана.
2. Робачевский А. Операционная система UNIX // СПб: БХВ-Петербург, 1997. 528 с.
