Системы обнаружения сетевых вторжений в облачных сервисах

Защита сети по периметру часто включает в свой состав системы обнаружения вторжений из сети (network intrusion detection systems, NIDS), например такие, как Snort1, которые осуществляют мониторинг локального трафика с целью выявления всего, что выглядит нестандартным или просто необычным. В качестве примеров нестандартного трафика можно привести:

± попытки сканирования портов (Port scans);

± атаки по типу Denial-of-Service (DoS-атаки);

± попытки использования эксплойтов, эксплуатирующих известные уязвимости.

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

Предназначение сетевых систем обнаружения вторжений в облачных сервисах

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

1 Snort — это свободная сетевая система предотвращения вторжений (Intrusion Prevention System, IPS) и сетевая система обнаружения вторжений (Intrusion Detection System, IDS) на основе открытого исходного кода (Open Source), способная выполнять регистрацию пакетов и в реальном времени осуществлять анализ трафика в IP-сетях.

Подробнее см. http://www.snort.org/, http://ru.wikipedia.org/wiki/Snort. — Прим. перев.

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

СКАНИРОВАНИЕ ПОРТОВ И ОБЛАЧНАЯ СРЕДА AMAZON

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

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

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

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

Как и в случае со сканированием портов, сетевые системы обнаружения вторжений Amazon активно выявляют атаки по типу "отказ в обслуживании " (Denial-of- Service, DoS) и, скорее всего, выявят попытки осуществления такой атаки намного раньше, чем ваша собственная программная система обнаружения вторжений.

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

ВНИМАНИЕ!

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

1 NESSUS — программа для автоматического поиска известных уязвимостей в защите информационных систем. Она способна обнаружить наиболее часто встречающиеся виды уязвимостей, включая наличие уязвимых версий сервисов, ошибки в конфигурации, наличие паролей по умолчанию, пустых или слабых паролей и т. д. Подробнее см. http://www.nessus.org/nessus/, http://blog.tenablesecurity.com/, http://www.securitylab.ru/analytics/216317.php. — Прим. перев.

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

Реализация системы обнаружения сетевых вторжений в облачной среде

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

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

Рис. 5.4. Сетевая система обнаружения вторжений, осуществляющая мониторинг трафика на балансировщике нагрузки

Поскольку на балансировщике нагрузки работают только программная система NIDS и сервер Apache, профиль атаки на балансировщике нагрузки будет очень низок. Компрометация сервера NIDS требует наличия уязвимости в программном обеспечении NIDS или сервера Apache (в предположении того, что защита всех остальных компонентов системы надлежащим образом усилена, и ни один из реальных сервисов не выполняет прослушивания других портов, открытых для Web в целом).

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

тупность системы.

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

Как я уже упоминал ранее, я не являюсь сторонником использования сетевой системы обнаружения вторжений в облачной среде Amazon1. В отличие от традиционной инфраструктуры, здесь нет особо значимых поводов для использования NIDS. Вы просто не сможете разработать такую архитектуру NIDS, которая обеспечивала бы вашей системе NIDS возможность "видеть" весь трафик, направляющийся к вашим экземплярам. Лучшее из того, что вы можете предпринять, заключается в создании такой реализации, когда NIDS развертывается на каждом из серверов вашей инфраструктуры, чтобы иметь возможность "видеть" весь трафик, который Amazon пропускает в группу безопасности, к которой принадлежит конкретный экземпляр. У вас будут минимальные возможности, доступные для превентивного уведомления, а основным преимуществом будет защита от вредоносного содержимого сетевых пакетов. Но, если вы шифруете весь трафик, даже это преимущество будет сведено к минимуму. С другой стороны, присутствие NIDS

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

серьезно снизит производительность этих серверов и создаст единый вектор атаки на все хосты в вашей инфраструктуре.

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100