DDoS-атака: первые действия

MAATRIX

Сайт лёг, сервер не отвечает, а в логах — шквал запросов с сотен адресов: похоже на DDoS. В такой момент важно не паниковать и действовать по порядку. Ниже — что сделать в первые минуты, как отличить атаку от наплыва посетителей, снять первую нагрузку и понять, справитесь ли вы сами или нужна защита на уровне провайдера.

Сначала убедитесь, что это DDoS

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

Атака выглядит иначе: шквал однотипных запросов, часто к одному и тому же адресу или с одинаковыми заголовками, поток с явно чужих регионов, аномально много обращений с отдельных адресов или подсетей. Если сервер перегружен, но в запросах нет ничего похожего на нормальное поведение людей, — это, скорее всего, атака. Важно определить это точно: меры против DDoS, применённые к реальному наплыву клиентов, отрежут вам живую аудиторию, а это уже вред от собственных рук.

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

Первые действия: без паники, по порядку

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

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

Быстрая диагностика: кто и как атакует

Чтобы защищаться прицельно, поймите характер атаки. Если сервер пускает, посмотрите, сколько и каких соединений на него открыто, и с каких адресов идёт основной поток:

ss -s
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

Вторая команда покажет адреса с наибольшим числом соединений — если несколько IP выделяются на порядок, это кандидаты на блокировку. Загляните и в лог веб-сервера: однотипные запросы к одному пути, одинаковый User-Agent, отсутствие реферера выдают ботов. Характер запросов подсказывает и тип атаки: забит ли канал мусорным трафиком или сервер захлёбывается на «дорогих» запросах к приложению. От этого зависит, что вообще можно сделать на вашей стороне, а что нет.

Немедленные меры на сервере

Если атака не слишком мощная и идёт с ограниченного числа адресов, помогает блокировка на файрволе. Забаньте самые агрессивные адреса или подсети, выявленные при диагностике:

ufw deny from АДРЕС_АТАКУЮЩЕГО

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

Понимаем тип атаки

Атаки принципиально делятся на два класса, и это определяет стратегию защиты. Объёмные атаки на уровне сети (L3/L4) заваливают сервер огромным потоком мусорных пакетов, забивая канал целиком. Их цель — исчерпать пропускную способность, и бороться с ними на самом сервере почти невозможно: когда канал забит, ваши команды уже не проходят. Такие атаки отражаются только выше по течению — на магистральной фильтрации провайдера или в специализированном сервисе очистки трафика.

Атаки на уровне приложения (L7) действуют тоньше: они шлют внешне легитимные запросы к «дорогим» страницам — поиску, корзине, тяжёлым отчётам, — заставляя сервер тратить ресурсы. Объём трафика при этом может быть скромным, но каждый запрос дорого обходится. Против L7 помогают ограничение частоты, кэширование, фильтры по поведению и капча для подозрительных. Понимание, с каким классом вы столкнулись, сразу говорит, справитесь ли вы средствами сервера или нужна внешняя защита.

Что может и чего не может сам сервер

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

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

После атаки: выводы и профилактика

Когда волна спала, не считайте инцидент закрытым — сделайте выводы. Проанализируйте, как именно вас атаковали и что помогло, а что нет, и закройте выявленные слабые места. Настройте заранее то, чего не хватило в горячий момент: правила ограничения частоты, кэширование, автоматические блокировки, готовый план действий. Атака, к которой вы готовы, переживается несравнимо легче импровизации под стрессом.

На будущее держите несколько вещей в порядке. Скрывайте реальный IP сервера за защитным прокси, если проект того стоит, — тогда атаковать напрямую сложнее. Держите запас по ресурсам: сервер с запасом мощности переживёт слабую атаку без падения, тогда как машина на пределе ляжет от малейшего всплеска. И выбирайте провайдера, у которого защита от DDoS и вменяемая поддержка встроены в услугу. Смежные темы диагностики перегрузки разобраны в материалах про высокую нагрузку на процессор и защиту сайта под нагрузкой.

Частые вопросы