Содержание статьи
Snort и прочие IDS — это, конечно, удобно и круто, но некоторые моменты омрачают картину. Особенно ярко проблемы всплывают, когда мы хотим мониторить трафик в облаке. В конечном счете это приводит к отказу от использования NIDS, например в AWS. Но следить за событиями надо, и решения есть!
Snort (EC2)
Как правило, для обнаружения подозрительных паттернов в запросах и в поведении пользователя применяют сетевые системы обнаружения вторжений (NIDS). Наиболее известен среди таких систем Snort, про который в «Хакере» написано множество статей. Но в нашей ситуации он не всегда подходит. Например, если развернуть Snort в EC2, то тогда при зеркалировании трафика произойдет «деление» канала по поллам, так как весь входящий трафик нужно дублировать на инстанс с Snort. Короче этот вариант — «не очень». Будем искать дальше!
Snort (VPC)
Возможен и другой вариант — разместите SNORT’ы, в публичных сегментах VPC, примите трафик (например, роундробином через ELB) и потом перенаправляйте на нижний сегмент, на сам сервер.
Такое решение скажется на производительности приложения, особенно если много тяжелого трафика. Но есть и свои плюсы: связанность, а также то, что SSL можно повесить на сам ELB, который будет его «терминейтить», после чего Snort будет видеть нешифрованный трафик. К сожалению, пока что ELB не умеет зеркалировать трафик, поэтому «параллельное» подключение невозможно, только «последовательное», что и усложняет нам жизнь. Многие разработчики не хотят иметь какой-то там Snort, тормозящий и обрабатывающий трафик перед приложением, не говоря уже про то, что не все используют VPC и ELB. Каждый проект имеет особенную архитектуру, что явно не упрощает процесс внедрения. Тем не менее этот вариант вполне подходящий, если у тебя много различных сервисов (не только web) и надо мониторить весь трафик. Ты просто направляешь с ELB трафик на IDS, а тот перенаправляет его на следующий ELB, который, в свою очередь, раскидывает трафик по сервисам.
Snort (Deamonlogger)
Еще один вариант — использовать Deamonlogger, который можно поставить на все машины, и копировать трафик на общий EBS-раздел, и отдельный инстанс со снортом будет анализировать этот файл. Нагрузки на боевые серверы будут фактически никакие, но зато будет очень много операций I/O, и вырастет сам объем данных. Цена начнет расти пропорционально трафику.
Не то, все не то…
Что делать, если такие минусы тебя не устраивают? К сожалению, придется городить костыли и идти на компромисс. Все зависит от желания. Поговорим про меня — у меня много сервисов, в разных аккаунтах, но все они используют единую «стандартизированную» конфигурацию, софт и AMI. Дополнительно отмечу, что 99% сервисов — это веб. Из них многие имеют фронтенд на Apache или nginx. Таким образом, я уже могу сказать, что большая часть атак и трафика будет направлена на веб-приложения. Так что вполне логично мой взгляд упал на известный плагин — ModSecurity.
ModSecurity
Многие читатели нашего журнала наслышаны о данном WAF (межсетевой экран уровня веб-приложений). ModSecurity распространяется в виде модуля для веб-серверов (Apache/nginx), и он может не только обнаружить атаки по сигнатурам, но и блокировать их. Из плюсов такого решения, по сравнению со снортом, можно отметить, что так как ModSecurity работает в контексте веб-сервера, то он имеет больше оперативной информации о сессии, запросе и ответе, то есть мы можем проще и детальнее анализировать события, а также использовать индивидуальные фильтры, согласно логике нашего веб-приложения.
Второй плюс — если вышел какой-то явный червь-сплоит под веб, а цикл разработки не позволяет обновить софт, не пройдя все стадии, то ModSecurity позволит сделать быстрый hotfix. Единственный минус — при использовании ModSecurity мы теряем контроль над атаками на сам веб-сервер, например на OpenSSL. Однако в последнее время таких атак не очень много. Как говорит мой любимый тим-лид, потому что все стали халтурщиками и только «кавычками ломают» :).
Реализация на коленке
Работая с этой идеей, я понял, что хочу иметь более развитую систему логирования событий для обнаружения атак и прочих нежелательных событий. Я не хочу блокировать какие-то частные случаи средствами ModSecurity, потому что это большая ответственность. Мне ведь нужно сделать конфиг для всех своих серверов, которые имеют разную логику и разный трафик, так что рисковать блокированием легитимных запросов не очень хочется.
Кроме того, атакующий по заблокированным данным может понять, что имеет дело с WAF, и будет искать фильтр. Возможно, он даже сумеет его обойти, и мы в результате потеряем контроль.
Поддержка по инцидентам ИБ мне доступна в режиме 24 х 7, так что интереснее спокойно собирать в логи всю такую активность и генерировать алерт, который тут же будет разобран командой реагирования на инциденты.
Более того, раз уж я контролирую HTTP-данные, то могу собирать больше полезной информации, чем Snort. Таким образом, я решил делать именно систему логирования на основе ModSecurity, по этим логам будут производиться анализ событий и генерироваться алерты или просто уведомления (используя, например, Splunk). Все это уже намного больше, чем голые алерты от Snort. Кроме того, такой универсальный конфиг легко настраивать и распространять (Puppet / подготовленный AMI) среди команд разработчиков.
Да, это не то же самое, что и сетевая IDS, но, учитывая, что у нас только веб-трафик, это вполне себе решение. Единственное, о чем следует подумать, — производительность. Не стоит перегружать ModSecurity убийственными правилами и регекспами, так как эта нагрузка в конечном счете упадет именно на фронтенд, и спасибо никто не скажет.
Кроме того, стоит подумать и о HIDS — мы можем контролировать писать в логи что хотим, не напрягая несчастный сервер, — проверка на чек-суммы файлы, созданных юзеров, процессы и так далее. Правда, сделать такие проверки уникальными для всех проектов немного сложнее, но базовые вещи, типа логи аутентификации SSH и поиск бэкдоров (например, в PHP/htaccess), настроить можно более-менее автоматизировано и универсально. В конечном счете такой проект вырастает не просто в ModSec + HIDS, а в нечто большее — полностью автоматизированную систему контроля ИБ, начиная с патч-менеджмента и контроля соответствия конфигурации и заканчивая IDS и анализом логов. Sin
Эпилог
Тема облаков модная, а тема ИБ в облаках еще моднее. Конечно, есть дорогие и крутые средства защиты, но и с помощью опенсорсных решений любую проблему так или иначе можно решить. Главное — понимать, что ты решаешь и для чего.
