Установка IDS

Чтобы использовать IDS по максимуму, необходимо провести большой объем процедур планирования перед непосредственной установкой устройства. Перед созданием соответствующей политики нужно осуществить сбор необходимой информации, провести анализ сети и реализовать задачи по управлению. Как в большинстве комплексных систем, политику необходимо создать, утвердить и протестировать перед применением. При создании политики IDS необходимо выполнить следующие шаги:

  • 1. Определить цели создания IDS.
  • 2. Выбрать объекты мониторинга.
  • 3. Выбрать ответные действия.
  • 4. Установить пороги.
  • 5. Применить политику.

Определение целей применения IDS

Цели использования IDS определяют требования для политики IDS. Потенциально целями применения IDS являются следующие.

  • • Обнаружение атак.
  • • Предотвращение атак.
  • Обнаружение нарушений политики.
  • • Принуждение к использованию политик.
  • • Принуждение к следованию политикам соединений.
  • • Сбор доказательств.

Имейте в виду, что цели использования устройства могут комбинироваться, и конкретные цели применения любой IDS зависят от организации. Набор целей ни в коем случае не ограничивается этим списком. IDS позволяет организации обнаруживать начало проведения атаки и осуществлять сбор доказательств или предотвращение дополнительного повреждения посредством устранения аварийных ситуаций. Разумеется, это не единственная цель, для достижения которой применяется IDS. Так как IDS осуществляет сбор детализованной информации по многим событиям, происходящим в сети и на компьютерах организации, она также может

идентифицировать действия, нарушающие политику, и реальный уровень использования сетевых ресурсов.

Распознавание атак

Распознавание атак является одной из главных целей использования IDS. Система IDS запрограммирована на поиск определенных типов событий, которые служат признаками атак. В качестве простого примера приведем соединение через ТСР-порт 80 (HTTP), за которым следует URL, содержащий расширение .bat. Это может быть признаком того, что злоумышленник пытается использовать уязвимость на вебсервере IIS.

Большую часть атак идентифицировать не просто. Например, до сих пор в интернете широко распространены атаки с угадыванием пароля. Система HIDS может содержать правило, согласно которому после трех неудачных попыток входа через короткие промежутки времени вход в данную учетную запись блокируется. Для этого HIDS должна отслеживать время и число неудачных попыток входа на каждой учетной записи, фиксируемой в журнале, и сбрасывать счетчик в случае успешного входа или истечения времени.

Еще более сложным примером распознавания атак является ситуация, когда злоумышленник пытается угадать пароли на нескольких учетных записях и системах. В данном случае атакующий не будет пробовать войти в одну и ту же учетную запись дважды за короткий промежуток времени, а попытается использовать этот пароль в каждой учетной записи. Если время каждой попытки достаточно велико, счетчики на отдельных учетных записях будут сбрасываться, перед тем как злоумышленник трижды осуществит неудачный вход в систему с использованием данной учетной записи. Единственным способом выявить такую атаку является сопоставление информации из журналов различных систем. Такой анализ осуществляет система HIDS, способная сопоставлять информацию с нескольких компьютеров.

Мониторинг политики

Мониторинг политики - это менее заметный аспект деятельности по обнаружению атак. Целью системы IDS, настроенной на отслеживание политики, является отслеживание выполнения или невыполнения политики организации. В самом простом случае NIDS можно настроить на отслеживание всего веб-трафика вне сети. Такая конфигурация позволяет отслеживать любое несоответствие политикам использования интернета. Если в системе сконфигурирован список вебсайтов, не отвечающий веб-стандартам корпоративного использования, NIDS зафиксирует любые подключения к таким сайтам.

Система NIDS также проверяет соответствие конфигурациям маршрутизатора или межсетевого экрана. В этом случае NIDS настраивается на отслеживание трафика, который не должен проходить через маршрутизатор или межсетевой экран. При обнаружении такого трафика определяется нарушение корпоративной политики межсетевых экранов.

Внимание!

Использование IDS для мониторинга политики может занять очень много времени и потребовать большого количества действий по конфигурированию.

Принуждение к использованию политики

Применение системы IDS в качестве средства принудительного использования политики выводит конфигурацию мониторинга политики на более высокий уровень. При отслеживании политики IDS настраивается на выполнение действий при нарушении политики. В первом примере в разделе "Мониторинг политики" IDS с принуждением к использованию политики не только определит попытку соединения с недоступным веб-сайтом, но и предпримет меры по предотвращению этого действия.

Обработка инцидента

Система IDS может оказаться полезной после обнаружения инцидента. В этом случае с помощью IDS можно собрать доказательства. NIDS можно настроить на отслеживание определенных соединений и ведение полноценного журнала по учету трафика. В то же время можно использовать и HIDS для фиксирования всех записей журнала для определенной учетной записи системы.

Выбор объекта мониторинга

Выбор объекта мониторинга зависит от целей, поставленных перед системой IDS, и от среды, в которой IDS будет функционировать. Например, если цель IDS заключается в обнаружении атак, и IDS расположена в интернете за пределами межсетевого экрана компании, то IDS потребуется отслеживать весь трафик, поступающий на межсетевой экран, для обнаружения входящих атак. В качестве альтернативы IDS можно разместить в пределах зоны, защищаемой межсетевым экраном, для определения только тех атак, которые успешно преодолели межсетевой экран. Исходящий трафик в данном случае может игнорироваться (см. рис. 13.3У В таблице 13.1 приводятся примеры объектов мониторинга при использовании конкретных политик.

Выбор объекта мониторинга определяет расположение датчиков. Датчики могут быть расположены вне межсетевого экрана, внутри сети, на системах с секретной информацией или на системах, используемых специально для сбора и обработки данных журнала. Ключевым моментом, о котором необходимо помнить при вынесении решения по поводу размещения датчика IDS, является то, что датчик должен иметь возможность просмотра интересуемых событий, будь то сетевой трафик или записи журнала. Если интересуемые события не преодолевают межсетевой экран, то не рекомендуется размещать датчик NIDS в области, защищаемой межсетевым экраном. Аналогично, если интересуемые события фиксируются только на главном контроллере домена сети Windows NT, программное обеспечение HIDS должно быть расположено на главном контроллере домена, даже если злоумышленник физически располагается на рабочей станции внутри сети.

Пример выбора объекта мониторинга

Рис. 13.3. Пример выбора объекта мониторинга

Таблица 13.1. Примеры информации, отслеживаемой при наличии

политики IDS

Политика

NIDS

HIDS

Обнаружение

атак

Весь трафик, поступающий на потенциально атакуемые системы (сетевые экраны, веб-серверы,

Неудачные попытки входа. Попытки соединения. Дачный вход с удаленных систем.

серверы приложений и т.д.)

Предотвращение

атак

То же, что и для обнаружения атак

То же, что и для обнаружения атак.

Обнаружение

нарушений

политики

Весь трафик HTTP, формируемый на системах клиентах. Весь трафик FTP, формируемый на системах клиентах

Успешные НТТР-соединения. Успешные FTP соединения. Загружаемые файлы.

Принуждение к использованию политик

То же, что и для обнаружения нарушений политики

То же, что и для обнаружения нарушения политики.

Принуждение к соответствию политикам соединений

Весь трафик,

нарушающий

принудительно

используемую

политику

соединения

Успешные соединения с запрещенных адресов или по запрещенным портам.

Сбор

доказательств

Содержимое всего трафика,

формируемого на системе-цели или атакующей системе

Все успешные подключения, исходящие с атакующей системы. Все неудачные соединения с атакующих систем. Все нажатия клавиш из интерактивных сеансов на атакующих системах.

При размещении датчиков NIDS необходимо руководствоваться еще одним ключевым правилом. Если в сети используются коммутаторы вместо концентраторов, датчик NIDS не будет правильно работать, если он просто подключен к порту коммутатора. Коммутатор будет отправлять только трафик, направленный на датчик, к тому порту, к которому подключен датчик. В случае с коммутируемой сетью существуют два варианта использования датчиков NIDS: применение порта, отслеживающего коммутатор, или применение сетевого разветвителя. На рисунке 13.4 показаны конфигурации обоих типов.

При использовании порта может возникнуть конфликт с персоналом по обслуживанию сети из-за того, что этот порт может использоваться для разрешения проблем, возникающих в сети. Кроме этого, многие коммутаторы позволяют вести мониторинг (некоторыми производителями вместо этого слова используется термин "связывание") только одного порта единовременно. Порт мониторинга, как правило, не позволяет осуществлять мониторинг магистрали коммутатора. Эта функция не будет работать в любом случае, так как магистраль коммутатора передает данные со скоростью в несколько мегабит в секунду, и датчик NIDS использует соединение 100BaseT (скорость 100 мегабит в секунду). Такое соединение не позволяет осуществлять передачу данных NIDS, поэтому в данной конфигурации не представляется возможным прерывание соединений.

Конфигурации датчика сетевой IDS для коммутируемой сети

Рис. 13.4. Конфигурации датчика сетевой IDS для коммутируемой сети

Разветвители - это пассивные проводные соединения между двумя устройствами (например, между маршрутизатором и коммутатором). Как правило, разветвитель подключается к концентратору, к которому также подсоединен датчик NIDS. Это позволяет датчику отслеживать трафик.

Примечание

Разветвитель не позволяет датчику NIDS осуществлять передачу данных, поэтому в данной конфигурации прерывание соединений также недопустимо.

Выбор ответных действий

Аналогично выбору объекта мониторинга, выбор ответных действий зависит от целей, для которых используется система IDS. При возникновении события можно выбрать пассивную обработку (ответное действие, не препятствующее действиям атакующего) или активную обработку (ответное действие, препятствующее действиям злоумышленника). Пассивные ответные действия не обязательно подразумевают разрешение продолжения события, но не допускают выполнение непосредственных операций самой системой IDS. Этот момент необходимо иметь в виду. Также следует взвешенно подойти к выбору автоматической или ручной обработки событий.

Пассивная обработка событий

Пассивная обработка - это наиболее распространенный тип действий, предпринимаемых при обнаружении вторжения. Причина этому проста - пассивные ответные действия обеспечивают меньшую вероятность повреждения легитимного трафика, являясь, в то же время, наиболее простыми для автоматического применения. Как правило, пассивные ответные действия осуществляют сбор большего числа информации или передают уведомления лицам, имеющим право на принятие более жестких мер.

Предотвращение. Предотвращение попытки атаки является сегодня наиболее широко используемым методом обработки события атаки. В большинстве случаев такой метод обработки событий остается установленным по умолчанию после установки в организации подключения к интернету и межсетевого экрана. В дальнейшем, после выполнения всех действий по настройке, организации доверяют защиту от атак из интернета межсетевым экранам.

Данный тип ответных действий может использоваться в более сложных системах IDS. IDS настраивается на игнорирование атак через несуществующие службы или службы, относительно которых межсетевой экран является неуязвимым.

Веским основанием для игнорирования атаки служит тот факт, что системы не чувствительны к рассматриваемому типу атак; например, это относится к атаке Microsoft IIS, направленной на веб-сервер Unix, и к атаке Sendmail на сервер Microsoft Exchange. Ни одна из этих атак не будет успешной, так как их цели не являются уязвимыми для данных конкретных атак.

Совет

С помощью информации, получаемой в результате сканирования уязвимостей, можно определить, какие события можно безопасно игнорировать.

Ведение журналов. При возникновении события любого типа должно генерироваться максимально возможное количество информации для обеспечения детализованного анализа или для помощи в принятии дальнейших мер. Занесение события в журнал является пассивным ответным действием, в рамках которого больше не осуществляется никаких операций. Посредством сбора основных данных (1Р-адреса, дата и время, тип события, идентификаторы процесса, идентификаторы пользователя и т.д.) IDS идентифицирует событие как что-то, требующее дальнейшего внимания.

Ведение дополнительных журналов. Пассивная обработка событий является более эффективной, если осуществляется сбор большего количества данных о фиксируемом в нормальном режиме событии. Например, если обычный журнал настроен на сбор IP-адресов и номеров портов для всех соединений, то в случае обнаружения события может производиться фиксирование пользовательских идентификаторов, идентификаторов процессов или фиксирование всего трафика, проходящего через соединение.

Еще одной разновидностью данного типа обработки события является использование выделенного сервера журналов. В организации может в различных местах сети присутствовать набор систем ведения журналов, которые включаются только в случае обнаружения события. Эти выделенные серверы журналов осуществляют сбор детализованной информации, которая затем используется для изолирования источника трафика, а также в качестве потенциальных доказательств, если происшедшее событие вызовет судебное разбирательство.

Уведомления. В отличие от простой констатации того факта, что событие произошло, уведомления позволяют IDS информировать лиц о происшедшем событии. Уведомление может иметь самые различные формы, начиная от мерцающих окон и звуковых сигналов и заканчивая почтовыми и пейджинговыми сообщениями. В зависимости от обстоятельств тот или иной тип предпочтительней другого. Например, мерцающие окна и сирены не очень полезны, если система IDS ведет круглосуточный мониторинг. Почтовые сообщения отправляются в удаленные места, но могут не дойти до получателя вовремя. Они также могут вызвать большой объем сетевого трафика, в результате чего злоумышленник догадается о присутствии системы IDS. Пейджинговые сообщения приходят вовремя (при условии бесперебойного функционирования спутника), но могут не предоставить достаточно информации для принятия соответствующих мер без предварительного просмотра журналов IDS.

Внимание!

Настройка IDS на отправку уведомления при возникновении события может вызвать проблемы в почтовых или пейджинговых системах, если произойдет большое число событий за очень малый промежуток времени.

Активная обработка событий

Активная обработка события позволяет наиболее быстро предпринять возможные меры для снижения уровня вредоносного действия события. Однако если недостаточно серьезно отнестись к логическому программированию действий в различных ситуациях и не провести должного тестирования набора правил, активная обработка событий может вызвать повреждение системы или полный отказ в обслуживании легитимных пользователей.

Прерывание соединений, сеансов или процессов. Вероятно, самым простым действием для понимания является прерывание события. Оно может осуществляться посредством прерывания соединения, используемого атакующим злоумышленником (это возможно только в том случае, если событие использует TCP-соединение), с закрытием сеанса пользователя или завершением процесса, вызвавшего неполадку.

Определение того, какой объект подлежит уничтожению, выполняется посредством изучения события. Если процесс использует слишком много системных ресурсов, лучше всего завершить его. Если пользователь пытается использовать конкретную уязвимость или осуществить нелегальный доступ к файлам, то рекомендуется закрыть сеанс этого пользователя. Если злоумышленник использует сетевое соединение в попытках изучения уязвимостей системы, то следует закрыть соединение.

Внимание!

Действие по уничтожению может вызвать отказ в обслуживании легитимных пользователей. Разберитесь в потенциальной возможности ложных сигналов тревоги, прежде чем выполнять соответствующую операцию.

Перенастройка сети. Предположим, произошло несколько попыток доступа к компьютерам организации с конкретного IP-адреса, следовательно, есть вероятность того, что с этого IP-адреса осуществлена попытка атаки на информационную систему. В данном случае может понадобиться перенастройка межсетевого экрана или маршрутизатора. Изменение настроек может быть временным или постоянным, в зависимости от IP-адреса и запрограммированных логических действий (прерывание всего трафика между партнером по бизнесу может негативно сказаться на производительности). Новые фильтры или правила могут запретить установку любых соединений с удаленным узлом либо запретить соединение лишь по конкретным портам.

Обманные действия. Наиболее сложным типом активной обработки событий являются обманные действия. Ответ обманом направлен на введение злоумышленника в заблуждение посредством создания впечатления успешного и необнаруженного проведения атаки. В то же время система-цель защищается от атаки злоумышленника либо посредством его перенаправления на другую систему, либо посредством перемещения жизненно важных компонентов системы в безопасное место.

Одним из типов обманных действий является "горшок с медом". Под "горшком с медом" подразумевается система или иной объект, выглядящий для злоумышленника настолько привлекательным, что он не может его пропустить. В то же время за атакующим ведется наблюдение, и все его действия записываются. Разумеется, информация в "горшке с медом" не является актуальной, но внешне этот объект выглядит как наиболее важный компонент информационной системы.

Вопрос к эксперту

Вопрос. Допускается ли встречная атака в качестве ответного действия на вторжение?

Ответ. Проводить встречную атаку настоятельно не рекомендуется. Во- первых, такие атаки в большинстве случае являются нелегальными, и их следствием может стать судебное разбирательство. Во-вторых, источником атаки часто является атакованная система, вследствие чего ответная атака может навредить ни в чем не повинному пользователю.

Автоматический и автоматизированный ответ

Автоматический ответ - это набор предустановленных операций, которые выполняются при возникновении определенных событий. Такие ответные действия, как правило, осуществляются в рамках штатной процедуры, определяющей конкретные триггеры,

инициирующие набор действий. Эти действия могут варьироваться от пассивных до активных. Автоматические ответные действия могут управляться людьми или компьютерами.

В случае если ответ на инцидент полностью контролируется

компьютером без участия человека, такие ответные действия

называются автоматизированными. Этот тип ответных действий должен контролироваться точно определенным, тщательно продуманным и хорошо протестированным набором правил. Так как ответные действия не требуют участия пользователя, они будут выполняться в случае обнаружения соответствия установленному набору правил. Реализовать автоматизированные ответные действия, принудительно уничтожающие сетевой трафик, очень просто.

В таблице 13.2 приведены примеры соответствующих пассивных и активных ответных действий с использованием набора политик, который был определен выше.

Таблица 13.2. Примеры ответных действий, определяемые политикой

IDS

Политика

Пассивные ответные действия

Активные ответные действия

Обнаружение

атак

Ведение журналов Ведение

дополнительных

журналов

Уведомление

Нет ответного активного действия.

Предотвращение

атак

Ведение журналов Уведомление

Закрытие соединения. Завершение процесса. Возможна перенастройка маршрутизатора или межсетевого экрана.

Обнаружение

нарушений

политики

Ведение журналов Уведомление

Нет ответного активного действия.

Принудительное

использование

политик

Ведение журналов Уведомление

Закрытие соединения. Возможно перенастройка прокси.

Принудительное

использование

политик

соединения

Ведение журналов Уведомление

Закрытие соединения. Возможно перенастройка маршрутизатора или межсетевого экрана.

Сбор

Ведение журналов Ведение

дополнительных

Обманные действия.Возможно

журналов

Уведомление

Вопросы для самопроверки

1. Датчик IDS, отслеживающий нелегальные операции, проводимые

приложением, называется_.

2. После определения целей применения IDS следующим шагом

является_.

Определение порогов

Пороговые значения обеспечивают защиту от ложных срабатываний, что повышает эффективность политики IDS. Пороговые значения могут использоваться для фильтрации случайных событий с целью их отделения от тех событий, которые в действительности представляют собой угрозу безопасности. Например, сотрудник может подключиться к веб-сайту, не связанному с деловой активностью, перейдя по ссылке, предоставленной поисковой системой. Сотрудник может выполнять легитимный поиск, но из-за некорректно заданных параметров поиска может отобразиться не относящийся к работе сайт. В данном случае это отдельное событие не вызовет генерацию отчета в системе IDS. Такой отчет попусту занял бы ресурсы при изучении совершенно безобидного действия пользователя.

Аналогично, пороговые значения, обнаруживающие атаки, должны быть настроены на игнорирование зондирования низкого уровня или отдельных событий, связанных со сбором информации. Среди таких событий можно выделить отдельную попытку "фингеринга" (указания) сотрудника. Программа-указатель (фингер), распространенная в системах Unix, как правило, используется для проверки корректного адреса электронной почты или для получения открытых ключей. Тем не менее, попытки фингеринга большого числа сотрудников за небольшой промежуток времени могут являться признаком того, что злоумышленник собирает необходимую информацию для проведения атаки.

Выбор пороговых значений для системы IDS напрямую зависит от типов событий и потенциальных нарушений политики. Невозможно

типов событий и потенциальных нарушений политики. Невозможно идентифицировать конкретный универсальный набор пороговых значений. Тем не менее, возможно определить параметры, которые необходимо принимать в расчет при настройке пороговых значений. Ниже приведены эти параметры.

  • • Опыт пользователя. Если пользователь недостаточно опытен и допускает множество ошибок, может выдаваться слишком много ложных сигналов тревоги.
  • • Скоростные характеристики сети. В сетях с низкими скоростями передачи данных могут выдаваться ложные сигналы о событиях, которые требуют получения определенных пакетов в течение определенного промежутка времени.
  • • Ожидаемые сетевые соединения. Если система IDS настроена на выдачу сигнала тревоги для определенных сетевых соединений, и эти соединения часто имеют место, то будет происходить слишком много ложных срабатываний.
  • • Нагрузка на сотрудника по администрированию или

безопасности. Большой объем работы сотрудников,

ответственных за безопасность, может потребовать установку более высоких пороговых значений для снижения числа ложных срабатываний.

  • • Чувствительность датчика. Если датчик очень чувствителен, может потребоваться установка более высоких пороговых значений, чтобы снизить число ложных срабатываний.
  • • Эффективность программы безопасности. Если программа безопасности организации очень эффективна, она может предусматривать пропуск некоторых атак, пропущенных IDS вследствие наличия в информационной среде других средств защиты.
  • • Имеющиеся уязвимости. Нет причины для выдачи сигнала тревоги в случае атак на отсутствующие в сети уязвимости.
  • • Уровень секретности систем и информации. Чем выше уровень секретности информации, используемой в организации, тем ниже должны быть пороговые значения для выдачи сигналов тревоги.
  • • Последствия ложных срабатываний. Если последствия ложных срабатываний очень серьезны, может понадобиться установка более высоких пороговых значений для выдачи сигналов тревоги.
  • • Последствия несрабатывания. Наоборот, если очень серьезны понадобиться установка более низких пороговых значений. Примечание

Пороговые значения являются строго индивидуальными для каждой организации. Можно иметь в виду основные принципы их определения, но в каждой организации необходимо в отдельном порядке рассматривать конкретную ситуацию и задавать пороговые значения согласно приведенным выше параметрам.

Применение системы

Непосредственное применение политики IDS должно тщательно планироваться, как и сама политика. Следует иметь в виду, что до данного момента политика IDS разрабатывалась на листе бумаги с учетом (хорошо, если это так) реальных тестов и опыта использования. Чтобы подвергнуть хорошо организованную сеть большой опасности, в ней достаточно всего лишь установить неправильно сконфигурированную систему IDS. Следовательно, после разработки политики IDS и определения изначальных пороговых значений необходимо установить IDS согласно конечной политике, с минимальным числом каких-либо активных мер. В течение некоторого времени при оценке пороговых значений следует внимательно следить за работой IDS. Таким образом, политика может быть проверена на практике без повреждения легитимного трафика или прерывания легального доступа пользователей к компьютерам.

Не менее важно во время испытательного или начального срока работы системы тщательно проводить изучение работы IDS по исследованию процессов, происходящих в системе, чтобы оценить степень корректности информации, выдаваемой IDS.

Внимание!

Ошибочное обвинение сотрудника или внешнего пользователя вследствие некорректного определения факта нарушения политики может отрицательно сказаться на впечатлении от функционирования системы и поставить в организации вопрос об эффективности использования программы IDS.

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ   След >