Таксономия атак на системы обнаружения вторжений

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

Алексей Леонов, alexey.leonov@mail.ru

В настоящее время системы обнаружения вторжений (intrusion detection systems, IDS) получают все большее распространение среди компаний различного масштаба. Они бывают разные – сетевые и хостовые, для серверов и рабочих станций, для архитектур Fast Ethernet и Gigabit Ethernet, для обнаружения и предотвращения атак. Самыми популярными по праву считаются сетевые решения, контролирующие сразу множество узлов в сети. Именно эти системы обладают широким спектром возможных применений - их используют на периметре и в демилитаризованной зоне, в сегменте IP-телефонии и в беспроводных сетях, для защиты баз данных и Web-серверов, и т.д. Но все эти варианты объединены одной целью – обнаружение и предотвращение атак. Однако, к сожалению, эти системы, призванные идентифицировать и отражать нападения хакеров, сами могут быть подвержены несанкционированным воздействиям, которые могут нарушить работоспособность этой системы, что не позволит ей выполнять поставленные перед ней задачи. Знать про такие атаки надо каждому специалисту по информационной безопасности и в своей статье я хотел бы систематизировать эти знания и привести единую классификацию (таксономию) атак на системы обнаружения вторжения.

Что обычно атакуют в первую очередь? Разумеется сенсор. Поэтому начнем с него. Из каких основных компонентов состоит сенсор системы обнаружения атак? Подсистема, получающая доступ к некоему источнику информации, в качестве которого может выступать сетевой трафик, журнал регистрации или системные вызовы. Затем данные попадают на механизм предварительной фильтрации, отсеивающий то, что сенсор не может анализировать. Например, если речь идет о сетевом сенсоре, то отсеиваться может трафик IPX/SPX, который неподвластен современным системам обнаружения атак. После фильтра в цепочку включается модуль распознавания атак и затем модуль реагирования. Но сенсор этими компонентами не ограничивается. Ведь сенсор – это не просто софт, устанавливаемый на компьютер с какой-то осью. Сенсор – это та же ось, и железо компьютера. А, следовательно, работа сенсора невозможна без ОС, сетевого драйвера и сетевой карты.

Итак, рассмотрим возможные атаки на сенсор, начиная с самого «низа».

1. Сетевая карта. Этот компонент задействуется для двух целей – получение доступа к сетевому трафику, в котором ищутся следы атак (если речь не идет о специальных платах обнаружения атак, вставляемых в шасси коммутатора или маршрутизатора, или специальном ПО обнаружения атак для маршрутизатора), а также для передачи на консоль управления сигналов тревоги. В общем случае эти 2 сетевых интерфейса отличаются друг от друга для реализации так называемого stealth-режима, повышающего защищенность сенсора. Если речь идет о хостовой системе обнаружения атак, то в ней задействуется только одна сетевая карта – для получения управляющих команд и сигнализации об атаках. Можно ли реализовать атаки на сетевую карту? Теоретически, да. На практике я о таких атаках не слышал, но это не значит, что их быть не может. А учитывая различные возможности по удаленному управлению сетевыми картами (RMON, DMI, ACPI, WfM и т.д.) можно предположить, что атаки очень даже возможны.
2. Сетевой драйвер. Ну с этим компонентов все понятно без слов. Неправильная реализация сетевого стека, коим страдала в свое время Microsoft, позволяет посылать на сенсор определенным образом сформированные пакеты, что приводит к падению «в синий экран».
3. ОС. Про дыры в ОС написано не мало – поэтому я эту тему опускаю. Замечу только, что через этот компонент атаки на IDS более чем реальны.
4. Модуль захвата данных.
   1. Если он оперирует сетевыми пакетами, то достаточно послать на него либо нестандартные (т.е. несоответствующие RFC) пакеты, либо организовать лавину трафика, которую неспособен обработать сенсор.
   2. Если он оперирует журналом регистрации, то и тут не все гладко – можно переполнить этот журнал и старые события будут перезаписаны новыми. Хотя для систем анализа журналов регистрации на данном уровне «бояться» надо меньше, чем сетевым IDS.
   3. С системными вызовами тоже есть свои проблемы. Опоссум на страницах сайта уже касался этой темы.
5. Фильтр. Я не слышал об атаках на этом уровне, но теоретически это возможно. Достаточно включить фильтрацию тех атак, которые реализует злоумышленник, и они не будут обнаружены, чего и хочет добиться нарушитель.
6. Подсистема обнаружения атак. Здесь как раз все просто – у «сигнатурных» IDS (а именно их на рынке большинство) есть одно серьезное ограничение – стоит изменить один байт в коде атаки и она уже не будет обнаружена. Этой теме я надеюсь посвятить отдельную статью; поэтому сейчас ее подробно расписывать не буду. Кроме бесконечного числа модификаций атак, можно направить свое внимание на шаблон, который используется системой обнаружения атак в своей работе. В нем прописаны как атаки, которые будут обнаруживаться сенсором, так и варианты реагирования на них. А т.к. обычно этот шаблон представлен в виде некоего текстового файла, то можно попробовать изменить отдельные строки и поля в нем. И вот уже сенсор либо не «ловит» нужные нарушителю атаки, либо в шаблоне отключены «правильные» варианты реагирования. Наконец, можно очистить лог сенсора и ему нечего будет передавать на консоль.
7. Подсистема реагирования. Даже если IDS обнаружила атаку, то достаточно не дать ей прореагировать на нападение и эффективность системы обнаружения вторжений будет сведена к нулю. Какие варианты реагирования существуют в современных IDS? Уведомление на консоль, генерация SNMP или e-mail, разрыв соединения, реконфигурация МСЭ или роутера, ну и еще по мелочи. В принципе все эти варианты реагирования можно заблокировать «затопив» порт, с которого он реализуется, или «подвесить» сервисы, осуществляющие отправку почты или SNMP. А можно, получив доступ к ОС, задействовать встроенный в нее персональный межсетевой экран. Есть и другие варианты, но их мы рассмотрим ниже.

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

С базой, хранящей события, тоже все просто. Кроме блокирования ее взаимодействия с сервером управления, можно попытаться ее переполнить, затопив ложными сигналами тревоги. А еще базу, как и любой другой компоненты IDS, можно попытаться попросту «завалить» DoS-атакой.

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

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

Сетевое оборудование тоже может стать мишенью для хакеров, что приведет к нарушению взаимодействия между компонентами IDS. Например, можно отключить порт, к которому подключен любой из компонентов системы обнаружения атак. В организации, в которой я проработал долгое время, в течение последних 7 с лишним лет не менялся пароль администратора коммутатора (этот пароль был задан по умолчанию производителем). Как следствие, сенсор не сможет либо сигнализировать об атаке, либо на него не попадет трафик для анализа. Получив доступ к сетевому оборудованию, можно реконфигурировать SPAN-порт, к которому подключен сенсор, а можно «разнести» компоненты IDS по разным VLAN, блокируя возможность их взаимодействия.

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

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

Вот в таком вот аспекте, как говорилось в каком-то художественном фильме. А где примеры, - воскликнет особо ретивый читатель. А их и не будет. Я не даю готовых рецептов. И не собираюсь показывать, как на практике можно вывести системы обнаружения вторжения из строя. У меня обратная задача – показать возможные направления приложения сил со стороны «плохих парней». Древние латиняне говорили «Praemonitus praemunitus», что по-русски будет звучать тоже красиво «Кто предупрежден, тот вооружен». Теперь вы знаете слабые места систем обнаружения атак, которые получают все большее распространение в России, а, следовательно, будут все чаще и чаще атаковываться. И зная эти уязвимости, можно заранее предусмотреть и методы их защиты. Описанной информации достаточно для этого.

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