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

При блокировании возможности сканирования и работы r-утилит провести успешную атаку становится сложнее, а иногда и абсолютно невозможно. В общем случае на сетевом узле должны блокироваться все входящие пакеты, кроме тех, которые поступают на открытые порты. По адресу www. sans .org/top2 0 .htm можно найти файл, в котором перечислены наиболее важные порты (не только те, доступ к которым следует блокировать, но и те, попытки доступа к которым следует регистрировать). Как будет рассказано в главе 16, “Вопросы архитектуры”, основные возможности обнаружения взлома обеспечиваются на периметре локальной сети.

Читатели этой книги уже у'знали о средствах защиты локальных хостов и использовании списков контроля доступа. Конечно, на каждой системе запускаются различные службы, но часто можно указать компьютеры, которые могут обращаться только к той или иной службе (например, с помощью TCP Wrappers). В этом случае хакеру придется сначала взломать доверенный хост и уже с него запускать программу атаки. В атаке Митника просто использовался IP-адрес доверенного хоста, что намного проще, чем действительно скомпрометировать этот хост.

Даже после начала атаки Митника она может быть остановлена при своевременном обнаружении и правильных ответных действиях. В главе 18, “Ответные действия”, мы рассмотрим методы замедления и даже полного блокирования начатых атак.

Резюме

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

Злоумышленники нередко используют доверительные отношения при организации своих атак. Устанавливают доверительные отношения сами системные администраторы “для удобства”, хотя при этом они и осознают, что своими руками пробивают брешь в системе защиты.

В атаке Митника сознательно обрывалась процедура установки ТСР-соединения, чтобы организовать БУМ-наводнение на одну из сторон доверительных отношений. Этот метод используется во многих атаках и средствах сканирования.

Специально подготовленные пакеты атаки, в которых подменяется 1Р-адрес отправителя, часто имеют сигнатуры, по которым и ^ожно выявить проводимую атаку.

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

Признаком перехвата ТСР-сеанса является изменение 1Р-адресов в течение сеанса при одновременной “правильности” порядковых номеров в поступающих пакетах. Надежное выявление перехвата ТСР-сеанса с помощью одного средства защиты по-прежнему остается недостижимой мечтой для реальной работы в компьютерных сетях.

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

Вопросы архитектуры 1В этой главе обсуждаются свойства систем обнаружения вторжений, возможные альтернативы и проблемы, с которыми могут столкнуться пользователи и разработчики. Здесь больше теоретической информации, чем в других частях книги, но в нее добавлены примеры из реальной жизни. Будет рассмотрена концепция значимых событий (event of interest). Это важное понятие, так как аналитик сетевого трафика добивается лучшего результата при использовании системы обнаружения вторжений, если он понимает, что он ищет. Следовательно, он может правильно настроить систем)' обнаружения вторжений, а не позволять самой этой системе уведомлять его о тех или иных событиях. Кроме того, мы рассмотрим вопрос точности определения атак. Каждое происшествие уникально и должно рассматриваться отдельно. Это давний предмет ожесточенных споров теоретиков о том, где должен быть установлен датчик системы обнаружения вторжений: за или перед брандмауэром. В данной главе рассмотрены этот и другие, вопросы, касающиеся размещения датчиков.

Один из самых известных мифов, которые распространяют производители программного обеспечения для обнаружения взломов, заключается в работе программ в реальном времени. Под работой в реальном времени в данном случае понимается то, что аналитики сетевого трафика будут немедленно реагировать на выдаваемые предупреждения и сигналы тревоги. Конечно, реагирование в реальном времени практически невозможно, по крайней мере для человека, так как скорость передачи пакета сравнима со скоростью распространения света. На рис. 16.1 показано обнаружение атаки непосредственно в реальном времени (сразу же после события). Этот рисунок пригодится вам, если руководство будет акцентировать внимание на времени ответа. В действительности компьютерные системы UNIX и Windows NT не поддерживают ни реагирования в реальном времени, ни даже точно подсчитанных задержек по времени. Мы рассмотрим эти вопросы при сравнении систем доставки и получения сообщений (push and pull architectures). Более того, аналитики сетевого трафика могут применять фильтры для повторного или даже третьего просмотра данных в поисках значимых событий.

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

Рис. 16.1. Реакция системы обнаружения вторжений

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

Значимые события

В главах 13, “Система Snort”, и 14, “Параметры правил Snort”, уже упоминалось, что при написании фильтра необходимо задать условие его “срабатывания”. Допустим, для правила Snort используется параметр content, определяющий поиск шестнадцатеричных значений Oxdead или Oxbeef (стандартный шаблон, который иногда используется нарушителями в их программах). Тогда получение пакета, удовлетворяющего данному шаблону, можно считать потенциально значимым событием. В теории обнаружения взлома значимые события связаны с тремя основными проблемами:

■ баланс между сообщениями о настоящих атаках и ложными тревогами;

■ точная настройка средства обнаружения (датчика) на гарантированное выявление значимого события;

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

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

■ десятичные значения 3133 7 и 666;

■ строка ASCII-символов ski 11 z;

■ шестнадцатеричные шаблоны Oxdead и Oxbeef.

Предположим, нам нужно создать фильтр для выявления шестнадцатеричного значения Oxdead.

alert icmp any any -> 192.168.5.0/24 any \

(msg: "Обнаружена строка шестнадцатеричных симвЬлов Oxdead"; \ content: "DE AD")

Приведет ли использование этого правила к появлению ложных тревог? Безусловно. Если в ICMP-пакете будут содержаться эти шестнадцатеричные символы в указанном порядке, будет выдано предупреждение об атаке. Стоит ли применять это правило для обработки данных в реальном времени? Нет, лучше не надо. С другой стороны, если во многих входящих пакетах будут содержаться Oxdead или Oxbeef, то это может оказаться важным. Для нас одним из самых полезных уроков работы с системой Shadow явилась необходимость применения вторичного анализа. Сохраните пакеты за несколько дней и затем проведите их повторный анализ с целью выявления значимых событий. Вероятнее всего, не стоит обращать внимание на единичное появление значений Oxdead или 666 в данных за несколько дней, но, если будут обнаружены десятки таких значений, то, безусловно, следует внимательно проанализировать полученные пакеты, содержавшие эти строки.

Почти все приведенные в главах 10, “Практический анализ”, и 11, “Необычный трафик”, случаи похожи. Аналитик сетевого трафика, изучая входящие данные, замечал что-то необычное. Когда мы с Джуди совместно работали над анализом сетевого трафика, мы выявляли огромное количество атак. Люди спрашивают, как нам это удавалось. Обычно я отвечаю: “Просто повезло”. Но наши читатели теперь знают больше. Мы старались разделить полученные данные с целью выявления наиболее значимых событий.

Еще одним подходящим сценарием является сбор данных на протяжении недели или около того, и их последующий анализ с целью обнаружения необычного использования возможностей протоколов, как показано, например, в следующем фильтре, not tcp and not udp and not icmp and not igrp and not igmp

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

Итак, мы закончили наше изучение значимых событий, остановившись на рассмотрении общих ограничений систем при обнаружении атак. Начнем с самого важного: важно четко осознавать, что именно требуется найти, и какие события должны иметь значение, потому что нельзя регистрировать или получать отчеты обо всех событиях. На рис. 16.2 изображены как события, которые может “видеть” ваша система обнаружения взлома, так и другие события, которые остаются вне поля зрения.

Рис. 16.2. Источники информации

Ограничения контроля

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

■ События в других сетях. В наше время довольно распространены несанкционированные подключения к сети через потайные ходы. Каждый компьютер с модемом потенциально может предоставлять этот потайной ход. Это явление доказывает несостоятельность рекламных заявлений производителей систем обнаружения взлома хоста наподобие “мы здесь, мы там, мы - везде”.

■ Не работает средство обнаружения. События могут быть очевидными, но система обнаружения может выйти из строя и будет не способна их выявить. Выражение “выйти из строя” в данном случае означает промежуточное состояние между полным отказом (с появлением голубого экрана) и временной невозможностью провести эхо-тестирование. Хорошим показателем надежности системы рбнаружения вторжений может служить время, требующееся для перезагрузки системы, так как это может быть проблемой как для систем под управлением Windows NT, так и для UNIX-систем. Я многократно проверял эту характеристику, работая с Shadow, NFR, NID, Snort и RealSecure. По закону невезения эти системы требуется перезагружать в дождливые дни, и при этом они обязательно находятся в другом здании. Конечно, некоторые из систем надежнее других. А какое самое эффективное средство для удаленного управления Windows NT? Разумеется, автомобиль :-). Если жесткий диск, использующийся для сохранения отчетов, будет заполнен, то сбор данных прекратится.

■ Протоколы SNA и SS7. Невозможно проверять данные протоколов, с которыми не поддерживает работу система обнаружения взлома. А нужна ли система обнаружения взлома, которая способна декодировать пакеты протоколов SS7 или SNA? Для большинства случаев ответ будет отрицательным, но довольно часто мы обнаруживаем пакеты неизвестных протоколов. Например, я знаю людей, которые обнаруживали пакеты протоколов IP Protocol 54, NHRP (Next Hop Routing Protocol - протокол определения адреса следующего перехода) в своих демилитаризованных зонах, и никогда не видел системы обнаружения вторжений, способной декодировать эти пакеты.

■ Превышение максимальной пропускной способности. Интенсивность событий может превысить максимальную пропускную способность для обработки данных средством обнаружения. Тогда датчик начинает пропускать пакеты, и наступает режим, который аналитики сетевого трафика называют статистической выборкой. На вопрос о максимальной скорости поступающей информации поставщики систем обнаружения взлома дают весьма любопытные ответы (от “80 Мбит/с” и до “когда как”). Совет, лучше верить человеку, который отвечает “когда как”, чем тому, кто называет точную цифру, особенно если она превышает скорость передачи данных в канале Т-3 (45Мбит/с). Одним из важнейших факторов для определения верхней границы скорости работы средства обнаружения вторжений является количество активных правил для проверки пакетов. Если обработка конкретного пакета не будет закончена на момент поступления следующего, то последний пакет будет отброшен.

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

■ событие произошло в другой сети;

■ вышла из строя система обнаружения вторжений;

■ нельзя обработать пакеты неизвестного протокола;

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

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

Выявление атаки митника | Обнаружение нарушений безопасности в сетях | Принцип низко висящего плода


Обнаружение нарушений безопасности в сетях



Новости за месяц

  • Октябрь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс