Артём Гавриченков, Highloadlab: “Борьба с DDoS-атакой - это игра краплёными картами с профессиональным шулером”

Визитка гостя

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

Окончил кафедру АСВК факультета ВМК МГУ в 2010 году. Убеждён, что смысл существования информационных технологий - в поиске простых инструментов для решения сложных задач. Увлекается автоспортом и старыми видеоиграми, преданный читатель научной фантастики.

Артём, расскажите, пожалуйста, про историю создания вашей компании и сервиса Qrator в частности.

Наша компания сформировалась в МГУ в рамках научно-исследовательского проекта по проблематике DDoS-атак на публичные Web-ресурсы. Миссией проекта было искоренить проблему DDoS-атак в принципе, сделав этот метод борьбы с конкурентами, как минимум, финансово необоснованным.

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

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

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

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

DDoS-атаки можно классифицировать на основе того, на вывод из строя какого уровня сети данная атака рассчитана. Тогда классификация выглядит следующим образом:

Атаки на особенности глобальной маршрутизации и дизайна протокола BGP. Это редко встречающийся и сложный в реализации, однако, эффективный и труднодиагностируемый вид атак. Сейчас мы как раз готовим к релизу продукт, который позволит NOC’ам на основе модели глобальной сети обнаруживать, диагностировать и ликвидировать уязвимости в их политиках маршрутизации.

Атаки сетевого уровня - широкополосные атаки типа UDP flood, ICMP flood и пр., целью которых является исчерпание полосы пропускания сервиса-жертвы. Здесь рецепт может быть только один - иметь резерв по полосе. Для ориентира можно использовать данные Qrator: максимальная атака сетевого уровня на нашего клиента имела мощность в районе 50 Гбит/с. В качестве дополнительной меры можно попытаться применить механизм BGP Flow Spec (RFC 5575), чтобы отсечь трафик тех протоколов, которые не используются в вашей сети.

Атаки транспортного уровня: SYN flood, ACK flood, TCP connection flood, FIN-WAIT-2… Их цель - эксплуатация уязвимых и неэффективных мест в реализации протокола транспортного уровня TCP, например, алгоритма установления TCP-соединения или механизма TCP connection tracking. Атаки этого уровня отражаются с применением ряда методик (например, SYN cookies), нескольких best practices (таких, как, например, разумное ограничение максимального числа открытых TCP-соединений per-IP) и оптимизацией параметров TCP-автомата на защищаемом сервере под конкретную выполняемую задачу (например, /proc/sys/net/** в GNU/Linux).

Я не случайно привёл в пример connection tracking. Многие системные администраторы любят фильтровать входящие пакеты в Linux, используя модули conntrack и state, например, следующим образом:
iptables -A INPUT -m state -state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -dport 80 -j ACCEPT
iptables -A INPUT -j DROP

В условиях атаки через некоторое время их сервер прекращает обслуживать пользователей, а в dmesg оказывается тонна сообщений «nf_conntrack: table full, dropping packet». Размер таблицы connection tracking по умолчанию зависит от нескольких параметров, но, как правило, равен 65536 или 131072, и ботнета в 5-10 тыс. машин достаточно, чтобы переполнить эту таблицу за пару секунд.

Мы рекомендуем с осторожностью относиться к использованию connection tracking и регулярно отслеживать с помощью команды ‘conntrack -L ‘, какие именно соединения попадают в эту таблицу.
Атаки прикладного уровня. Их цель - вывод из строя непосредственно приложения, обрабатывающего запросы пользователя, за счёт, например, многочисленных «тяжёлых» запросов. Здесь нет какого-то универсального метода отражения всего и вся, успешность атаки зависит от мастерства, как нападающего, так и обороняющегося.

Многие атаки могут затрагивать несколько уровней сети сразу. Например, SYN flood с большим packet rate может не только вывести из строя обработчик TCP-протокола на защищаемом сервере, но вдобавок ещё и забить канал перед ним. Другой аналогичный пример - атаки на DNS, использующие большое число легитимных датаграмм-запросов и выводящие из строя, как канальную ёмкость, так и сервер DNS - протокола прикладного уровня.

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

И, наконец, иногда злоумышленник может использовать атаки сразу нескольких видов одновременно, комбинируя, например, ICMP flood и SYN flood с атакой прикладного уровня.

Это действенно по двум причинам:

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

В таких случаях перед тем, как решать проблему, важно предварительно выяснить, в чём же она состоит, даже если на это уйдёт пара лишних минут.

Опираясь на ваш опыт, есть ли какая-то специфика DDoS-атак именно на российские сайты? Вообще, бытует мнение, что именно российские хакеры терроризируют, чуть ли не полмира.

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

Кроме того, бежать впереди собственного рынка для злоумышленников ещё и опасно. Вспомните, какую реакцию пару лет назад вызвало сообщение о DDoS-атаке мощностью 60 Гбит/с, создавшей проблемы даже для Яндекса. Или прошлогодняя атака на slon.ru, в которой принимало участие до 200 тыс. ботов. Такие резонансные случаи могут спровоцировать повышенную активность правоохранительных органов, чего атакующий всеми силами хотел бы избежать.

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

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

Приведу самый драматический пример - выборы 4 декабря 2011 года. Тогда к нам в течение трёх дней пришёл целый ряд популярных СМИ (Эхо Москвы, Новая Газета, телеканал Дождь и другие издания), испытывавших очень серьёзные проблемы. Это и SYN flood в несколько миллионов пакетов в секунду, и UDP flood большого объёма, и пресловутый ботнет в 200 тысяч голов, и всё это осложнялось как повышенным вниманием пользователей к публикациям о ходе выборов, так и отсутствием у нас накопленной истории легитимных запросов для этих сайтов. Подноготную специфику той ситуации каждый может представить себе сам в силу своего воображения.

Говоря о мощности атаки, мы должны понимать, про атаку какого уровня мы говорим. Бессмысленно измерять атаку прикладного уровня мегабитами в секунду, так же как и мерять SYN flood количеством source IP-адресов. По каждому из уровней сети у нас были более мощные атаки и до 4 декабря, и после, но если говорить про суммарную мощность всех компонентов, то день выборов в Госдуму РФ запомнился нам исключительной мощностью DDoS-атак.

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

В итоге ботнет в 135 тыс. ботов был успешно отфильтрован, а голосование прошло успешно. Можно сколько угодно меряться потенциально имеющимися гигабитами, но в конечном итоге главное - это способность оперативно и эффективно помочь клиенту.

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

DDoS-атака сегодня - это в первую очередь метод конкурентной борьбы. Да, месть, вымогательство и самоутверждение школьников - это тоже частые причины атак, но такие атаки, как правило, примитивны. Качественная атака стоит дорого, и платить за неё готов тот, кому она принесёт выгоду.

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

Поэтому наиболее серьёзные DDoS-атаки организовываются на сайты, занимающие свою узкую рыночную нишу или делящие её с одним-двумя конкурентами. Доходит до абсурда: у нас был случай, когда жертва атаки знала заказчика в лицо - у атакуемого магазина был единственный конкурент, больше эта атака никому не была нужна!

Существуют и другие мотивы для мощных атак, но они все так или иначе завязаны на деньги (или политику).

Например, мы уже не раз рассказывали, как DDoS-атаки использовались для прикрытия воровства средств с банковского счёта. Злоумышленник украл деньги через банк-клиент, а потом запустил двухдневную атаку на сервер банк-клиента. В течение двух дней бухгалтер компании, у которой «увели» средства, не мог проверить баланс счёта и не переживал по этому поводу, потому что до отчётного периода было ещё далеко, а банк-клиенты не отличаются стабильностью. Через два дня атака прекратилась, и пропажа была обнаружена, но отследить, куда ушли денежные потоки, уже было невозможно.

Что Qrator представляет из себя сейчас: какое оборудование вы используете, каковы его возможности, какие у вас канальные возможности?

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

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

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

Концепция полного контроля инфраструктуры распространяется и на сетевую топологию - площадки Qrator располагаются в России и Европе в нескольких датацентрах, которые обладают хорошей сетевой связностью и в состоянии предоставить нам чёткие гарантии доступности. Мы непрерывно ведём поиск новых магистральных операторов связи для расширения своего присутствия, но наш список требований слишком велик, чтобы этот процесс был простым.

Имея в распоряжении несколько точек подключения, можно планировать услугу с практически стопроцентной доступностью.

В то время как у каждого отдельного датацентра есть свой «болевой порог» канальной ёмкости, по превышении которого владельцу ДЦ будет дешевле и проще отключить проблемного клиента, чтобы не терпеть убытки и не заставлять других клиентов страдать. Эта политика полностью финансово обоснована, она касается не только небольших хостингов, она применяется абсолютно всеми, только порог у каждого свой. Поэтому защищённый от DDoS-атак сервис нельзя построить в одном-единственном месте; даже если вы купите специализированных железок на миллиард, в какой-то момент вы упрётесь в свой потолок.

Говоря про канальную ёмкость, нужно рассматривать две отдельные составляющие, так называемую пассивную и активную полосу пропускания. Пассивная полоса - это то количество входящего трафика, которое возможно обработать на низших уровнях сети; например, пропускать или игнорировать каждый пакет на основе битовой маски. В рамках же активной полосы можно принять, обработать и проанализировать каждое открытое TCP-соединение. Размер нашей активной полосы постоянно варьируется и в данный момент составляет чуть больше 30 Гбит/с; пассивная полоса имеется, по крайней мере, в 100 Гбит/с, а реально - ещё больше.

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

На сайте нашей системы открыта регистрация для клиентов. Владелец или администратор Интернет-ресурса вводит данные о своей компании, о своём сайте, после чего получает для сайта IP-адрес из префикса, анонсируемого автономной системой Qrator, и прописывает его в A-запись DNS. Вся процедура, как правило, занимает от двадцати минут до часа. При наличии существующей учётной записи в системе добавление нового домена - вообще дело считанных минут.

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

Есть и другой метод подключения - путём BGP-анонса защищаемой сети, но он требует проработки и в авральном режиме не применяется. Тем не менее, при необходимости мы можем взять под защиту всю сеть клиента целиком, и подключение под атакой будет занимать 30 секунд (время перестроения маршрутизации) вместо часа (среднее время обновления записей DNS).

Подключение каждого нового сайта проходит краткий процесс премодерации. Мы не принимаем под защиту ресурсы, нарушающие законодательство РФ, и некоторые отдельные сайты на основе расположенного там контента, но это буквально 1% от всех регистраций, мы стремимся помочь всем. Наша тарифная сетка начинается от 5 тыс. рублей в месяц, это так называемый «страховой тариф» - с клиентами этого тарифа мы работаем едва ли не в убыток себе, чтобы даже ограниченные в средствах люди смогли получить защиту от атак.

Старшие тарифы стоят от 17 тыс. рублей в месяц, и на них доступны более высокие уровни гарантированной доступности (SLA). Важно заметить, что первые сутки работы предоставляются клиенту бесплатно, чтобы он мог оценить уровень сервиса. Впрочем, спустя 24 часа после регистрации уходит лишь небольшая часть клиентов.

Я хотел бы коснуться ещё одной необычной для рынка услуги - защиты от копирования/парсинга информации с защищаемого вами веб-приложения. Насколько популярна эта опция?

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

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

Обсудив ваш сервис, давайте переведем наш взгляд на противоположную сторону фронта. Расскажите немного про ботнет - главного «плохого» персонажа, с которым вы ведете свою борьбу. Я знаю, что ботнеты прошли большую эволюцию, довольно бурно развиваясь и совершенствуясь. Что характеризует современного ботнета, какие их разновидности существуют?

Ботнеты развиваются сразу по нескольким направлениям, главные из них:

- увеличивается число вычислительных единиц. С тех пор, как большинство сайтов стало использовать в качестве HTTP-фронтенда адекватные высоким нагрузкам reverse proxy-серверы наподобие Nginx или HAProxy, атакующим пришлось изрядно нарастить мощности ботнетов, чтобы не потерять рынок. Этот рост продолжается соразмерно эволюции серверных мощностей. Ботнет в 200 тысяч машин - пока скорее редкость, чем правило, но сети в 50-60 тысяч уже стали рядовым случаем;
- совершенствуются методики. Есть ряд отдельных признаков бота, которые используются многими компаниями и системными администраторами для защиты от атак: неумение работать с ECMAScript, неполная реализация протокола HTTP, географическая принадлежность. Такая фильтрация, конечно же, легко обходится злоумышленниками, а дальше начинается игра с алгоритмами обхода сайта, который у каждого ботнета свой. Соответственно, регулярно появляются новые методы мимикрии под легитимного пользователя, исследованием этих методов мы и занимаемся.

Вот чем мы не занимаемся, так это анализом тела ботнета. Это трудоёмкая задача, и актуальна она разве что для антивирусных компаний, потому что понимание внутренней структуры malware уже давно не даёт ничего нового ни в плане анализа поведения HTTP-клиента на сайте, ни даже в плане поиска организатора атаки. Поиск организаторов - это оперативная работа, она осуществляется другими методами и стоит баснословных денег.

Работа по противодействию распределенной DDoS-атаке, это в том числе кооперация усилий различных провайдеров IXP и ISP, как часто они идут навстречу? Какова специфика этого взаимодействия, ведь оно никак не регулируется законодательно и часто носит интернациональный характер?

Так как мы не занимаемся расследованиями, то с провайдерами, как правило, не взаимодействуем. Когда взаимодействуем, ощущаем гордость за нашу бравую техподдержку, которая отвечает на заявки пользователя в течение нескольких минут. Как-то раз мы написали одному ISP про льющуюся с него атаку в 10-12 Гбит/с в пятницу, а ответ получили в понедельник. Это, к сожалению, норма.

Internet Exchange (IX) - это вообще отдельная тема. Мы не используем IX для размещения площадок фильтрации как раз по той причине, что они, хоть и обладают толстым каналом, но никому ничего не гарантируют. В плане широкополосных атак большинство IX абсолютно абузоустойчиво. Один европейский IXP в ответ на письмо на abuse@ с просьбой прекратить атаку, исходящую с размещённых у него серверов, посоветовал нам завернуть весь трафик с IX в блэкхол и был таков. Это замечательный совет! Даже если мы отфильтруем трафик по направлению, он вернётся нам по другому пути. Смысла в таких действиях - никакого.

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

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

Сегодня часто можно услышать, как рядовые специалисты считают, что размещение своего сайта в «облаке» автоматически гарантирует его анти-DDoS защиту. Насколько правомерно такое мнение?

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

И уж точно никуда не годится тезис, что вычислительных мощностей облака заведомо хватит для обработки любой атаки. В списке наших клиентов есть немало контрпримеров. Самая безобидная неприятность, которая может последовать из такого подхода - счёт за использованные ресурсы с шестью нулями. В худшем случае облачный хостинг просто заблокирует сайт-жертву, поскольку, как мы уже говорили, у каждого хостинга есть «болевой порог», по достижении которого обслуживание данного клиента становится нерентабельным. Это правило не знает исключений, потому что любой хостинг - это коммерческая структура, направленная на получение прибыли.

Кроме того, облако решает только те проблемы, которые в принципе решаемы масштабированием. То есть облако - не панацея против просчётов в архитектуре приложения. Мы в таких случаях можем сделать гораздо больше, чем облачный хостинг, хотя, разумеется, тоже не всесильны.

С другой стороны, и нападающие далеко не всегда всемогущи и квалифицированы. Если можно, вспомните примеры из серии «самая глупая DDoS-атака, которую мы видели».

Я говорил, что организатора атаки можно найти только с помощью оперативной работы и административного ресурса? Ну, так вот, мы знаем исключение из этого правила. Летом мы помогли поймать злоумышленника, который использовал для атаки, в числе прочего, анонимные прокси. Некоторые из прокси-серверов любезно передавали нам IP-адрес сервера, принадлежащего организатору, в HTTP-заголовке X-Forwarded-For . Это был большой сюрприз для организатора этой атаки - типичного скрипт-кидди!

Другой забавный пример тоже связан с расследованием инцидентов. Есть такой вид DDoS-атак, как «социальные» атаки с использованием инструментов наподобие LOIC (Low Orbit Ion Cannon), без ботнета. Люди, желающие «положить» определённый сайт, кооперируются, устанавливают себе на ПК соответствующую программу и в заранее определённый момент запускают её, выводя сервер из строя большим числом запросов. Атакующая программа может конфигурироваться каждым участником в отдельности, по желанию. Это, в частности, одна из типичных методик участников группы Anonymous.

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

В заключении, какие общие технические советы вы можете дать обычному сетевому Unix-администратору, который столкнулся с атакой средней/слабой мощности на свой сайт или сеть? И наоборот, чего лучше никогда не делать в ситуации DDoS-атаки?

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

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

Хорошо изучите инструменты, заведомо доступные вам для защиты, научитесь с ними работать и сделайте так, чтобы они всегда были у вас под рукой. Поддерживайте контакты с разработчиками администрируемых сайтов на случай, если атака прикладного уровня будет эксплуатировать их недоработки. Будьте всегда готовы к миграции сайта на другой хостинг в случае, если ваш нынешний решит, что ему не нужен клиент «с проблемами».

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