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