Добро пожаловать в Gene Office ! 

Сайт

Контакты

      Обновлено 25.12.2011 г.

1. SNORT - сетевая система обнаружения вторжений (IDS)\система предотвращения вторжений (IPS), работа которой основана на анализе сетевого трафика в реальном времени путем сравнения полученных данных с набором предопределенных отпечатков (сигнатур) на основе заранее определенных правил. В зависимости от заданных параметров система может регистрировать полученные отпечатки и блокировать трафик, который содержит определенные отпечатки. Описание сигнатур и необходимые действия при их обнаружении содержатся в наборе файлов определенного формата, называемых правилами (rules). Конфигурация SNORT описывается файлом параметров snort.conf и может содержать самые разнообразные команды по указанию путей, подгружаемым модулям и библиотекам на языке С, используемым правилам, режиму работы, загрузке и выводу информации. Здесь - http://ru.wikipedia.org/wiki/Snort - общие сведения о SNORT.
   
   Зачем нужен SNORT вообще - для обнаружения аномальных отклонений от стандартов сетевого обмена, их классификации и реакции в зависимости от результатов классификации. Зачем нужен SNORT в KERIO - для расширения возможностей встроенного инспектора протокола с целью активного противодействия попыткам деструктивного воздействия на конкретные сетевые сервисы. Пример: инспектор протокола не способен обнаружить и блокировать активное сканирование веб-сервиса на уязвимости потому, что получаемые им пакеты полностью соответствуют принятым стандартам, а содержимое пакета им не может быть проанализировано. SNORT на основе имеющихся правил обнаружит и, если указано, блокирует пакеты с неразрешенными данными.
   
   Кому он нужен, этот SNORT - всем, кто занимается защитой информационных ресурсов, но в разной степени: кому-то для безоговорочной защиты конкретных сервисов, кому-то для проведения исследований, кому-то для получения подтверждающих материалов о недобросовестных действиях конкурентов, а кому-то для поиска и отлова "кульных хацкеров". Все эти задачи SNORT в сочетании с KERIO способен решить, НО - в зависимости от решаемой задачи должны быть определены и допустимые пределы в детализации настроек SNORT - количество правил, открытый исходный код и возможность произвольно изменять содержание правил, их весьма непонятный вид и очень странная терминология могут привести к совершенно негативному результату - блокировке нужного трафика, отсутствию реакции на угрозы, полному поглощения времени и ненужным трудозатратам оператора, работающего с системой.
   Определение допустимых пределов детализации состоит, в основном, в определении источника, разрабатывающего правила для SNORT, и способа поддержки правил в актуальном состоянии.

2. 
   Источник правил для SNORT один - компания-разработчик SNORT Sourcefire http://www.sourcefire.com/ - ее правила единственно правильные и сертифицированные, доступные как за деньги, так и бесплатно на сайте http://www.snort.org/snort-rules. Есть разные сообщества любителей SNORT, вот российское - http://www.snortgroup.ru/dl. Официальные правила SNORT - первый вариант актуализации собственных правил. Просто, малопонятно, зато надежно и не так уж дорого, а с задержкой на месяц - вообще бесплатно.
   Но никто и никому не запрещает самостоятельно создавать как отдельные правила для SNORT, так и классифицировать наборы этих и сторонних правил по своему желанию. Вот пример: разработчики прикладной программы предлагают пользователям внести в базу новое правило IDS\IPS - http://sunbeltblog.blogspot.com/2006/09/snort-signature-for-vml-exploit-works.html.
   Учитывая, что количество правил, придуманных для SNORT исчисляется тысячами, надо быть очень большим любителем с феноменальной памятью, чтобы самостоятельно вести собственную базу с правилами для SNORT, поэтому вот этот второй вариант актуализации правил для большинства конечных потребителей неприемлем. Но, как и в любом вопросе, есть сообщества любителей, располагающие необходимыми ресурсами для выполнения такой работы, как поддержка набора правил SNORT. Отличие таких сообществ от официального разработчика - отсутствие сертификатов на продукт (и ответственности), собственные учетные данные по сигнатурам, многочисленные правила, интересные только их разработчикам. Различие таких сообществ между собой - в надежности, солидности и стабильности.
   Конечному потребителю надо выбрать - кому доверить собственные наборы правил, это третий и почти лучший вариант актуализации информации.
   
   Как устроен SNORT в KERIO:
   первое - взят бесплатный пакет производителя SNORT и усечены все опции, не требующиеся в конкретном случае - исключены некоторые препроцессоры, модули и библиотеки, скорректирован конфигурационный файл и сделана система, предотвращающая существенные изменения в конфигурации SNORT для его работы с KERIO (все усечения и ограничения вполне восстановимы при желании), т.е. исполняемому модулю SNORT заданы конкретные параметры по взаимодействию с KERIO. Все эти условия указаны в файле шаблона %Kerio_Foldger%\snort\templates\snort.tpl, файл можно редактировать, изменения эффективны только при старте службы KERIO, при отключении и включении SNORT из административной консоли параметры не перечитываются.
   второе - взят бесплатный и свободно распространяемый набор правил одного из ведущих сообществ - Еmerging Threats - http://www.emergingthreats.net/
   третье и самое важное - полученный набор правил перетасован\урезан\дополнен в соответствии с понятиями специалистов KERIO  по восьми странным категориям, полученные наборы и используются в качестве правил для средства IDS\IPS в Kerio Control. Т.е. - пользователи конечного продукта Kerio Control поставлены в жесткие рамки по выбору способа актуализации правил SNORT: только набор фирмы KERIO без вариантов.

3. 
   Что же предлагается фирмой KERIO  в качестве эксклюзивного набора правил для работы интегрированной IDS\IPS-системы на базе SNORT:
   - контроль (с возможностью блокировки) доступа от\к группам конкретных IP-адресов на основе черных списков распространителей вредоносного кода, спама и прочего мусора. Поставщиков черных списков шесть - ведущие компании, анализирующие сетевую активность. Это большой плюс.
   - упомянутые выше восемь групп правил, сформированные по очень странному признаку - степени серьезности опасности. Предлагается такая классификация: высокая\средняя\низкая опасность. Каждая категория разделяется на две части - правила, которые могут блокировать трафик, и правила, которые трафик блокировать не могут ни при каких обстоятельствах (Т.е. часть правил из группы серьезности "высокая" не может блокировать трафик, а часть правил из группы "низкая" - может....). Есть еще группа правил, серьезность которых в фирме KERIO определить затруднились.
   - ведение журнала работы системы IDS\IPS SNORT в формате и с интеграцией в административную консоль.
   Для исключения всяких дополнительных проблем правила для SNORT формируются из упомянутых правил Еmerging Threats, перезаписывая файл правил SNORT при каждом запуске KERIO Control.
   
   Как работает SNORT с KERIO:
   - файловая структура SNORT после инсталляции соответствует типовой и расположена в папке %Kerio_Foldger%\snort. Структура дополнена папкой %Kerio_Foldger%\snort\templates\, в которой хранятся скорректированные файлы конфигурации препроцессоров для обработки действий SNORT при обнаружении угроз, шаблон файла конфигурации SNORT, набор файлов с группами правил и некоторые служебные файлы;
   - при запуске службы Kerio Control считываются:

4. * файлы описаний правил препроцессоров из папки ..\preproc - эти правила создаются и меняются крайне редко, их обновление обычно связано с обновлением всего Snort, поэтому о них далее говорить не будем, уяснив, что это статические особые (как бы Конституция) правила.
   * файлы, содержащие правила для выявления принадлежности к черным спискам адресов:
   emerging-dshield.rules
   emerging-compromised.rules
   emerging-botcc.rules
   emerging-rbn.rules
   emerging-drop.rules
   emerging-tor.rules
   * файлы формата kerio-*-drop.rules и kerio-*-alert.rules, содержащие правила для групп серьезности угроз - high, medium, low. Правила, размещенные в файлх kerio-*-alert.rules не могут блокировать трафик даже при выборе в администартивной консоли действия "Запись в журнал и сброс" для соответствующей группы.
   - из файлов формата kerio*.rules при КАЖДОМ запуске службы Kerio Control (а не старта IDS\IPS из консоли) формируется файл правил для собственно SNORT - %Kerio_Foldger%\snort\rules\used.rules. Файл может содержать как инструкции alert, так и drop для определения реакции самого SNORT на обнаружение некоторых сигнатур вне зависимотси от классификации по правилам KERIO. При работе SNORT не следует править этот файл вручную и даже открывать на чтение в каком-либо редакторе не рекомендуется во избежание аварийной остановки службы IDS\IPS.
   - при обнаружении какой-либо из перечисленных в файле used.rules угрозы SNORT передает ее регистрационный номер в поток KERIO, который по этому номеру определяет принадлежность (физическое расположение) этого правила какому-либо из файлов формата kerio*.rules, на основе имени файла определяет серьезность угрозы и возможность блокирования трафика, в зависимости от выбранного действия для данной группы серьезности формирует информационное сообщения для записи в лог и, если указано и применимо, блокирует трафик.
   - при обновлении с сайта KERIO скачиваются или только перечисленные выше файлы и файл с номером версии обновления; или специально сформированный файл с дополнениями и изменениями в правилах. Эта опция доступна только при выполнении обновления через административную консоль, т.е. только для обладателей лицензий на продукт. SNORT не обновляется.
   - параметры SNORT могут быть кардинально отредактированы в файле шаблона %Kerio_Foldger%\snort\templates\snort.tpl.
   
   Что из этого следует:
   - для корректной работы и, особенно, отображения информации в логе необходима идентичность информации в файлах kerio*.rules и used.rules. Любое расхождение в содержании этих файлов вызовет как минимум некорректную информацию о трафике, дублирование даже одного правила в разных файлах kerio*.rules вызовет аварийную остановку IDS\IPS;
   - три группы правил по степени серьезности угрозы - искусственно придуманное разделение, конкретное содержание каждой группы - перечень отнесенных к ней правил - может быть изменено произвольным образом при соблюдении требований по уникальности каждого правила;
   - возможно подключение набора правил сторонних производителей, в т.ч. - официальных правил производителя SNORT.
   
   Т.е. - если наполнить исходные файлы с описанием правил (файлы типа kerio*.rules) необходимым набором правил, отличных от полученных с сайта KERIO, то смысл работы IDS\IPS не изменится. При подключении дополнительных правил в файле шаблона информативность IDS\IPS только увеличится (KERIO вообще не использует правила для защиты СУБД, ограничения доступа к порносайтам, пиринговыым сетям и проч. - целесообразность такого расширения функционала определяет для себя конечный пользователь).
   
   Таким образом, имеется три возможности избавиться от навязчивости KERIO:
   1. из стандартных правил SNORT сформировать необходимые группы, придуманные KERIO, и настроить действия по ним.
   2. использовать правила производителя Еmerging threats, сформировав из них необходимые группы.
   3. вообще не использовать механизм, разработанный KERIO, ограничившись отображением обнаруженных угроз, описание которых может быть получено из любого источника и активировано в SNORT через указание модулей в файле шаблона SNORT.
   Выбор способа определяется тем, насколько можно доверять IDS\IPS по блокировке трафика и какие ресурсы можно затратить на поддержку IDS\IPS в течение длительного периода.
   Любая автоматическая блокировка какого-либо трафика должна быть многократно проверена и обоснована. Производитель SNORT в качестве безусловных рекомендует всего лишь с десяток правил, Еmerging threats - около сотни, а KERIO - более тысячи. Вообще, выбор правил для блокировки должен быть очень избирательным - например, одно из правил, блокирующее пинг в сети, может парализовать работу провайдера ....). Для пользователей, которые не нуждаются в детальном анализе трафика, использование правил, блокирующих трафик, целесообразно минимизировать, дополняя их сугубо конкретно на основе собственных наблюдений. У каждого производителя правил для SNORT есть свой особый набор правил для автоблокировки, как правило - это сетевые атаки, их количество ограничено, это и надо использовать с максимальной осторожностью и принимая во внимание, что KERIO как межсетевой экран сам реализует очень многие функции по блокировке ненужного трафика и простое дублирование этих функций средствами IDS\IPS приведет только в снижению производительности системы в целом. KERIO - защита системы, IDS\IPS - защита сервисов, каждый из этих компонентов должен решать только свою задачу.
   
   Создадим собственный набор правил для использования SNORT с KERIO.
   Сайт производителя Еmerging threats http://www.emergingthreats.net предоставляет для этого все возможности:
   https://rules.emergingthreats.net/ - меню загрузки, где предлагаются наборы правил для разных версий Snort;
   https://rules.emergingthreats.net/version.txt - версия последнего обновления правил.
   
   Отличие от групп KERIO, как уже упоминалось - в подборе правил по собственным критериям.
   KERIO формирует собственные группы следующим образом:
   
   Файл kerio-high-drop.rules объединением содержания следующих файлов Еmerging threats:
   emerging-exploit.rules
   emerging-attack_response.rules
   emerging-malware.rules
   emerging-virus.rules
   
   Файл kerio-medium-drop.rules объединением содержания следующих файлов Еmerging threats:
   emerging-voip.rules
   emerging-game.rules
   emerging-current_events.rules
   emerging-dos.rules
   emerging-web_specific_apps.rules
   emerging-user_agents.rules
   emerging-web_server.rules
   emerging-web_client.rules
   emerging-policy.rules
   
   Файл kerio-low-drop.rules объединением содержания следующих файлов Еmerging threats:
   emerging-scan.rules
   
   Не включены в классификаторы kerio файлы Еmerging threats:
   emerging-p2p.rules
   emerging-inappropriate.rules
   emerging-activex.rules
   emerging-chat.rules
   emerging-deleted.rules
   emerging-dns.rules
   emerging-ftp.rules
   emerging-icmp.rules
   emerging-icmp_info.rules
   emerging-imap.rules
   emerging-misc.rules
   emerging-netbios.rules
   emerging-pop3.rules
   emerging-rpc.rules
   emerging-shellcode.rules
   emerging-smtp.rules
   emerging-snmp.rules
   emerging-sql.rules
   emerging-telnet.rules
   emerging-tftp.rules
   
   Файлы kerio-*-alert.rules содержат не включенные в отдельные файлы Еmerging threats правила, присутствующие в общем перечне правил, а также произвольным образом перемещенные туда специалистами KERIO по совершенно неясной логике из файлов kerio-*-drop.rules.
   
   Использованы без изменений файлы Еmerging threats с черными списками:
   emerging-dshield.rules
   emerging-compromised.rules
   emerging-botcc.rules
   emerging-rbn.rules
   emerging-drop.rules
   emerging-tor.rules
   
   
   Таким образом, скопировав с https://rules.emergingthreats.net необходимые файлы и объединив их по указанному принципу, получим практически полный аналог обновлений KERIO без ненужных групп, которые не допускают блокировку трафика (kerio-*-alert.rules). Файлы типа kerio-*-alert.rules должны присутствовать на диске и не должны иметь нулевой размер, т.е. содержать несколько закомментированных знаков.
   Если разделение по группам серьезности угроз не требуется, то скопировав отсюда  все правила в одном файле и переименовав этот файл в, например, kerio-medium-drop.rules, получим одну группу серьезности с возможностью полной блокировки трафика, а переименовав файл в kerio-low-alert.rules получим другую группу серьезности без возможности блокировать трафик.
   Если стандартные правила SNORT объединить по гркппам в указанные файлы KERIO, то IDS\IPS будет работать аналогично примененным KERIO правилам.

Примененный метод интеграции SNORT в межсетевой экран устраняет предпоследнее препятствие для сертификации KERIO по нормам ФСТЭК для второго класса, но создает огромную дыру в безопасности из-за простоты воздействия на системный сервис SNORT с уязвимостью "отказ в обслуживании". Кроме того, конфигурация этого модуля не отвечает требованиям ФСТЭК по самовосстановлению межсетевого экрана после сбоев в полном функционале. Подробнее см. здесь.

Сайт

Контакты