Как защититься от DDoS-атак. DDoS-атака: как сделать? Программы для DDoS-атак

Сегодня давайте попытаемся прояснить ситуацию вокруг Ddos-атак на сервер. Все таки данная проблема реально пересекается с темой хостинга как такового.

Штука довольно-таки неприятная. Представьте, установил я вчера новенький плагин на свой wordpress и вдруг через какое-то время, бац! - блог в браузере перестает открываться. Причем другие сайты в то же самое время прекрасно серфятся. Мысли лезут - чего-то напортачил с плагином. Много раз жму на перезагрузку страницы и ничего! Потом, правда заработало, но несколько неприятных минут пришлось пережить.

А сегодня в почте вижу письмецо от техподдержки ТаймВэб. Скрывать не буду, хостинг я там беру. Да и чего скрывать, достаточно ввести адрес сайта в Whois.
Письмо такое:

"Уважаемые пользователи.
Сегодня, 02 декабря 2011 года в 16:32 по Московскому времени, на технологическую площадку TIMEWEB, началась массированная DDOS атака, которая нарушила работу некоторых сайтов и серверов.
Инженеры TIMEWEB взяли ситуацию под контроль и уже к 18:45 стабильная работа площадки была полностью восстановлена. .."

Решил я разобраться откуда берутся Ddos-атаки на сервер и что это, вообще, такое. И вот, что нарыл.

Ddos-атаки на сервер - что это такое?

Во-первых, заглянем в Вики, куда ж без нее:

DOS-АТАКА (от англ. Denial of Service , отказ в обслуживании ) - атака на компьютерную систему с целью довести её до отказа, то есть, до такого состояния, что легитимные (правомерные) пользователи системы не могут получить доступ к предоставляемым системой ресурсам (серверам, сервисам), либо этот доступ затруднён. Отказ «вражеской» системы может быть как самоцелью (например, сделать недоступным популярный сайт), так и одним из шагов к захвату контроля над системой (если во внештатной ситуации ПО выдаёт какую-либо критическую информацию - например, версию, часть программного кода и т. д.).

Если атака выполняется одновременно с большого числа компьютеров, говорят о DDOS-АТАКЕ (от англ. Distributed Denial of Service , распределённая атака типа «отказ в обслуживании» ). В некоторых случаях к фактической DDoS-атаке приводит легитимное действие, например, размещение на популярном интернет-ресурсе ссылки на сайт, размещённый на не очень производительном сервере. Большой наплыв пользователей приводит к превышению допустимой нагрузки на сервер и, следовательно, отказу в обслуживании части из них.

Итак, с одной стороны имеется объект атаки - некий сервер или сайт, а с другой стороны, группа злоумышленников, организующих Ddos-атаку на объект нападения.

Какие цели преследуют организаторы Ddos-атаки?

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

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

Еще, используя метод Ddos-атаки, различные Ddos-группировки могут заявлять о своем существовании или выставлять требования, ультиматумы хозяевам серверов.

Вот некоторые примеры Ddos-атаки на сервер , которые я нашел в Луркоморье:

• ООФР (Организация Объединенных Фагов России), в которую входят следующие мем-группировки: Лепрозорий Суеверный, Падшая часть ЖЖ и во главе, конечно же, Упячка.

Главными жертвами ООФР стали:

www.mail.ru (за проект ЖУКИ),

www.gay.com (за то что гей),

www.4chan.org (за оскорбления бога «Онотоле»),

www.wikipedia.org (за статью про УПЧК, в которой было оскорбление в сторону котов (Котэ), не снятое модератором в течение месяца)

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

ПОДВЕДЕМ НЕБОЛЬШОЙ ИТОГ:

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

Кстати, недавно я устроил TimeWeb еще один простенький тест.

На сегодня о Ddos-атаках все.

Скоро поговорим о том, какие они бывают и как организуется защита от кибер-атак.

Здравствуйте, дорогие друзья и читатели — сайт!

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

Из-за их преступных действий доступ к ресурсу был закрыт.

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

Теперь, когда страсти немного утихли, давайте разберёмся, что такое DDOS атака.

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

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

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

Печально, правда? Им бы Вас защищать, а они просто отрубают больную руку и ждут, когда рана затянется.

Ну, ничего, мы и сами не лыком шиты.

Думаю, что у Вас уже назрел вопрос — «Как сделать DDOS атаку? ».

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

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

Попав в злые и расчётливые руки, луч света стал мечом Архангела, который подключает легион своих последователей, посылает миллионы ложных запросов и вырубает сайты конкурентов.

Эта программа не засекречена и находится в общем доступе сети Интернет. Её скачать можно .

Пользоваться программой LOIC просто. Запускаем LOIC .exe и видим следующее окно:

В двух верхних строчках вписываете URL или IP адрес жертвы и нажимаете Lock on :

После этих действий, в большом окне с надписью NONE появится IP мишени:

В нижнем окне устанавливаем поток (TCP , HTTP или UDP ), количество запросов (по умолчанию стоит 10 ) и передвигаем ползунок скорости передачи:

Закончив настройки, жмём на большую кнопку – :

Это всё, дос атака началась. Остановить процесс можно нажав туже кнопку.

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

Но повторюсь, это неправомерные действия и при сговоре с группой лиц, вызов DDOS атаки уголовно наказуем. Данный материал, только для ознакомительных целей.

Запуск лазерной пушки LOIC:

Защита от DDOS атак.

На сегодняшний день 100% защиты от DDOS атак не существует. Конечно, различные компании за серьёзные деньги предлагают услуги по защите сайтов от дос атак, но всё относительно. Если Ваш ресурс подвергнется мощному натиску, в котором будет задействовано много участников и дос-ботов, то не одна система не устоит.

Поэтому, всё, что Вы можете, это отражать атаки и блокировать IP адреса источника доса.

Кстати, скоро будет объявлен новый конкурс! Не пропустите!

До следующих статей…

P. S.

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

Спасибо за понимание!

С уважением, Денис Черников!

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

Что такое DDoS-атака?

Для начала, пожалуй, стоит разобраться, что собой представляют такие неправомерные действия. Оговоримся сразу, что при рассмотрении темы «DDoS-атака: как сделать самому» информация будет подана исключительно для ознакомления, а не для практического использования. Все действия такого рода уголовно наказуемы.

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

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

Почему возникает угроза?

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

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

На заре возникновения такого явления в основном DDoS-атака своими руками осуществлялась преимущественно самими программистами, которые создавали и тестировали с ее помощью работоспособность систем защиты. Кстати сказать, в свое время от действий злоумышленников, применявших в качестве оружия компоненты DoS и DDoS, пострадали даже такие IT-гиганты, как Yahoo, Microsoft, eBay, CNN и многие другие. Ключевым моментом в тех ситуациях стали попытки устранения конкурентов в плане ограничения доступа к их интернет-ресурсам.

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

Виды DDoS-атак

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

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

DDoS-атака на сайт

Как правило, такая атака связана с конкретным хостингом и направлена исключительно на один заранее заданный веб-ресурс (в примере на фото ниже условно обозначен как example.com).

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

DDoS-атака на сервер

Что касается серверных атак, то здесь они направлены не на какой-то определенный хостинг, а именно на провайдера, который его предоставляет. И неважно, что из-за этого могут пострадать владельцы сайтов. Главная жертва - именно провайдер.

Приложение для организации DDoS-атак

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

Как получить в своем распоряжение IP-адрес жертвы, по этическим соображениям мы сейчас рассматривать не будем. Исходим из того, что начальные данные у нас есть.

Для запуска приложения используется исполняемый файл Loic.exe, после чего в двух верхних строках с левой стороны вписываются исходные адреса, а затем нажимаются две кнопки «Lock on» - чуть правее напротив каждой строки. После этого в окне появится адрес нашей жертвы.

Снизу имеются ползунки регулирования скорости передачи запросов для TCP/UDF и HTTP. По умолчанию значение выставлено на «10». Увеличиваем до предела, после чего нажимаем большую кнопку «IMMA CHARGIN MAH LAZER» для начала атаки. Остановить ее можно повторным нажатием на ту же кнопку.

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

Защита от DDoS-атак

С другой стороны, каждый, кто пытается предпринять попытку DDoS-атаки, должен понимать, что на «той» стороне тоже не дураки сидят. Они запросто могут вычислить адреса, с которых такая атака производится, а это чревато самыми печальными последствиями.

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

Вместо послесловия

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

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

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

Правильные ингредиенты

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

1. Отказаться от Windows Server

Практика подсказывает, что сайт, который работает на винде (2003 или 2008 - неважно), в случае DDoS обречен. Причина неудачи кроется в виндовом сетевом стеке: когда соединений становится очень много, то сервер непременно начинает плохо отвечать. Мы не знаем, почему Windows Server в таких ситуациях работает настолько отвратно, но сталкивались с этим не раз и не два. По этой причине речь в данной статье будет идти о средствах защиты от DDoS-атак в случае, когда сервер крутится на Linux. Если вы счастливый обладатель относительно современного ядра (начиная с 2.6), то в качестве первичного инструментария будут выступать утилиты iptables и ipset (для быстрого добавления IP-адресов), с помощью которых можно оперативно забанить ботов. Еще один ключ к успеху - правильно приготовленный сетевой стек, о чем мы также будем говорить далее.

2. Расстаться с Apache

Второе важное условие - отказ от Apache. Если у вас, не ровен час, стоит Apache, то как минимум поставьте перед ним кеширующий прокси - nginx или lighttpd. Apache’у крайне тяжело отдавать файлы, и, что еще хуже, он на фундаментальном уровне (то есть неисправимо) уязвим для опаснейшей атаки Slowloris, позволяющей завалить сервер чуть ли не с мобильного телефона. Для борьбы с различными видами Slowloris пользователи Apache придумали сначала патч Anti-slowloris.diff, потом mod_noloris, затем mod_antiloris, mod_limitipconn, mod_reqtimeout… Но если вы хотите спокойно спать по ночам, проще взять HTTP-сервер, неуязвимый для Slowloris на уровне архитектуры кода. Поэтому все наши дальнейшие рецепты основываются на предположении, что на фронтенде используется nginx.

Отбиваемся от DDoS

Что делать, если пришел DDoS? Традиционная техника самообороны - почитать лог-файл HTTP-сервера, написать паттерн для grep (отлавливающий запросы ботов) и забанить всех, кто под него подпадет. Эта методика сработает… если повезет. Ботнеты бывают двух типов, оба опасны, но по-разному. Один целиком приходит на сайт моментально, другой - постепенно. Первый убивает все и сразу, зато в логах появляется весь полностью, и если вы их проgrepаете и забаните все IP-адреса, то вы - победитель. Второй ботнет укладывает сайт нежно и осторожно, но банить вам его придется, возможно, на протяжении суток. Любому администратору важно понимать: если планируется бороться grep’ом, то надо быть готовым посвятить борьбе с атакой пару дней. Ниже следуют советы о том, куда можно заранее подложить соломки, чтобы не так больно было падать.

3. Использовать модуль testcookie

Пожалуй, самый главный, действенный и оперативный рецепт этой статьи. Если на ваш сайт приходит DDoS, то максимально действенным способом дать отпор может стать модуль testcookie-nginx , разработанный хабрапользователем @kyprizel. Идея простая. Чаще всего боты, реализующие HTTP-флуд, довольно тупые и не имеют механизмов HTTP cookie и редиректа. Иногда попадаются более продвинутые - такие могут использовать cookies и обрабатывать редиректы, но почти никогда DoS-бот не несет в себе полноценного JavaScript-движка (хотя это встречается все чаще и чаще). Testcookie-nginx работает как быстрый фильтр между ботами и бэкендом во время L7 DDoS-атаки, позволяющий отсеивать мусорные запросы. Что входит в эти проверки? Умеет ли клиент выполнять HTTP Redirect, поддерживает ли JavaScript, тот ли он браузер, за который себя выдает (поскольку JavaScript везде разный и если клиент говорит, что он, скажем, Firefox, то мы можем это проверить). Проверка реализована с помощью кукисов с использованием разных методов:

• «Set-Cookie» + редирект с помощью 301 HTTP Location;
• «Set-Cookie» + редирект с помощью HTML meta refresh;
• произвольным шаблоном, причем можно использовать JavaScript.

Чтобы избежать автоматического парсинга, проверяющая кукиса может быть зашифрована с помощью AES-128 и позже расшифрована на клиентской стороне JavaScript. В новой версии модуля появилась возможность устанавливать кукису через Flash, что также позволяет эффективно отсеять ботов (которые Flash, как правило, не поддерживают), но, правда, и блокирует доступ для многих легитимных пользователей (фактически всех мобильных устройств). Примечательно, что начать использовать testcookie-nginx крайне просто. Разработчик, в частности, приводит несколько понятных примеров использования (на разные случаи атаки) с семплами конфигов для nginx.

Помимо достоинств, у testcookie есть и недостатки:

• режет всех ботов, в том числе Googlebot. Если вы планируете оставить testcookie на постоянной основе, убедитесь, что вы при этом не пропадете из поисковой выдачи;
• создает проблемы пользователям с браузерами Links, w3m и им подобными;
• не спасает от ботов, оснащенных полноценным браузерным движком с JavaScript.

Словом, testcookie_module не универсален. Но от ряда вещей, таких как, например, примитивные инструментарии на Java и C#, он помогает. Таким образом вы отсекаете часть угрозы.

4. Код 444

Целью DDoS’еров часто становится наиболее ресурсоемкая часть сайта. Типичный пример - поиск, который выполняет сложные запросы к базе. Естественно, этим могут воспользоваться злоумышленники, зарядив сразу несколько десятков тысяч запросов к поисковому движку. Что мы можем сделать? Временно отключить поиск. Пускай клиенты не смогут искать нужную информацию встроенными средствами, но зато весь основной сайт будет оставаться в работоспособном состоянии до тех пор, пока вы не найдете корень всех проблем. Nginx поддерживает нестандартный код 444, который позволяет просто закрыть соединение и ничего не отдавать в ответ:

Location /search { return 444; }

Таким образом можно, например, оперативно реализовать фильтрацию по URL. Если вы уверены, что запросы к location /search приходят только от ботов (например, ваша уверенность основана на том, что на вашем сайте вообще нет раздела /search), вы можете установить на сервер пакет ipset и забанить ботов простым shell-скриптом:

Ipset -N ban iphash tail -f access.log | while read LINE; do echo "$LINE" | \ cut -d""" -f3 | cut -d" " -f2 | grep -q 444 && ipset -A ban "${L%% *}"; done

Если формат лог-файлов нестандартный (не combined) или требуется банить по иным признакам, нежели статус ответа, - может потребоваться заменить cut на регулярное выражение.

5. Баним по геопризнаку

Нестандартный код ответа 444 может пригодиться еще и для оперативного бана клиентов по геопризнаку. Вы можете жестко ограничить отдельные страны, от которых испытываете неудобство. Скажем, вряд ли у интернет-магазина фотоаппаратов из Ростова-на-Дону много пользователей в Египте. Это не очень хороший способ (прямо скажем - отвратительный), поскольку данные GeoIP неточны, а ростовчане иногда летают в Египет на отдых. Но если вам терять нечего, то следуйте инструкциям:

Подключите к nginx GeoIP-модуль (wiki.nginx.org/HttpGeoipModule).

Выведите информацию о геопривязке в access log.

Далее, модифицировав приведенный выше шелл-скрипт, проgrepайте accesslog nginx’а и добавьте отфутболенных по географическому признаку клиентов в бан.

Если, к примеру, боты по большей части были из Китая, то это может помочь.

6. Нейронная сеть (PoC)

Наконец, вы можете повторить опыт хабрапользователя @SaveTheRbtz, который взял нейронную сеть PyBrain, запихал в нее лог и проанализировал запросы (habrahabr.ru/post/136237). Метод рабочий, хотя и не универсальный:). Но если вы действительно знаете внутренности своего сайта - а вы, как системный администратор, должны, - то у вас есть шансы, что в наиболее трагических ситуациях такой инструментарий на основе нейронных сетей, обучения и собранной заранее информации вам поможет. В этом случае весьма полезно иметь access.log до начала DDoS’а, так как он описывает практически 100% легитимных клиентов, а следовательно, отличный dataset для тренировки нейронной сети. Тем более глазами в логе боты видны не всегда.

Диагностика проблемы

Сайт не работает - почему? Его DDoS’ят или это баг движка, не замеченный программистом? Неважно. Не ищите ответа на этот вопрос. Если вы считаете, что ваш сайт могут атаковать, обратитесь к компаниям, предоставляющим защиту от атак, - у ряда анти-DDoS-сервисов первые сутки после подключения бесплатны - и не тратьте больше время на поиск симптомов. Сосредоточьтесь на проблеме. Если сайт работает медленно или не открывается вообще, значит, у него что-то не в порядке с производительностью, и - вне зависимости от того, идет ли DDoS-атака или нет, - вы, как профессионал, обязаны понять, чем это вызвано. Мы неоднократно были свидетелями того, как компания, испытывающая сложности с работой своего сайта из-за DDoS-атаки, вместо поиска слабых мест в движке сайта пыталась направлять заявления в МВД, чтобы найти и наказать злоумышленников. Не допускайте таких ошибок. Поиск киберпреступников - это трудный и длительный процесс, осложненный самой структурой и принципами работы сети Интернет, а проблему с работой сайта нужно решать оперативно. Заставьте технических специалистов найти, в чем кроется причина падения производительности сайта, а заявление смогут написать юристы.

7. Юзайте профайлер и отладчик

Для наиболее распространенной платформы создания веб-сайтов - PHP + MySQL - узкое место можно искать с помощью следующих инструментов:

• профайлер Xdebug покажет, на какие вызовы приложение тратит больше всего времени;
• встроенный отладчик APD и отладочный вывод в лог ошибок помогут выяснить, какой именно код выполняет эти вызовы;
• в большинстве случаев собака зарыта в сложности и тяжеловесности запросов к базе данных. Здесь поможет встроенная в движок базы данных SQL-директива explain.

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

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

8. Анализируйте ошибки

Проанализируйте объем трафика, время ответа сервера, количество ошибок. Для этого смотрите логи. В nginx время ответа сервера фиксируется в логе двумя переменными: request_time и upstream_response_time. Первая - это полное время выполнения запроса, включая задержки в сети между пользователем и сервером; вторая сообщает, сколько бэкенд (Apache, php_fpm, uwsgi…) выполнял запрос. Значение upstream_response_time чрезвычайно важно для сайтов с большим количеством динамического контента и активным общением фронтенда с базой данных, им нельзя пренебрегать. В качестве формата лога можно использовать такой конфиг:

Log_format xakep_log "$remote_addr - $remote_user [$time_local] " ""$request" $status $body_bytes_sent " ""$http_referer" "$http_user_agent" $request_time \ $upstream_response_time";

Это combined-формат с добавленными полями тайминга.

9. Отслеживайте количество запросов в секунду

Также посмотрите на число запросов в секунду. В случае nginx вы можете примерно оценить эту величину следующей shell-командой (переменная ACCESS_LOG содержит путь к журналу запросов nginx в combined-формате):

Echo $(($(fgrep -c "$(env LC_ALL=C date --date=@$(($(date \ +%s)-60)) +%d/%b/%Y:%H:%M)" "$ACCESS_LOG")/60))

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

10. Не забывайте про tcpdump

Многие забывают, что tcpdump - это обалденное средство диагностики. Я приведу пару примеров. В декабре 2011-го был обнаружен баг в ядре Linux, когда оно открывало TCP-соединение при выставленных флагах TCP-сегмента SYN и RST. Первым багрепорт отправил именно системный администратор из России, чей ресурс был атакован этим методом, - атакующие узнали об уязвимости раньше, чем весь мир. Ему, очевидно, такая диагностика помогла. Другой пример: у nginx есть одно не очень приятное свойство - он пишет в лог только после полной отработки запроса. Бывают ситуации, когда сайт лежит, ничего не работает и в логах ничего нет. Все потому, что все запросы, которые в данный момент загружают сервер, еще не выполнились. Tcpdump поможет и здесь.

Он настолько хорош, что я советовал людям не использовать бинарные протоколы до того, как они убедятся, что все в порядке, - ведь текстовые протоколы отлаживать tcpdump’ом легко, а бинарные – нет. Однако сниффер хорош как средство диагностики - в качестве средства поддержания production’а он страшен. Он легко может потерять сразу несколько пакетов и испортить вам историю пользователя. Смотреть его вывод удобно, и он пригодится для ручной диагностики и бана, но старайтесь ничего критичного на нем не основывать. Другое любимое многими средство «погрепать запросы» - ngrep - вообще по умолчанию пытается запросить в районе двух гигабайт несвопируемой памяти и только потом начинает уменьшать свои требования.

11. Атака или нет?

Как отличить DDoS-атаку, например, от эффекта рекламной кампании? Этот вопрос может показаться смешным, но эта тема не менее сложная. Бывают довольно курьезные случаи. У одних хороших ребят, когда они напряглись и основательно прикрутили кеширование, сайт слег на пару дней. Выяснилось, что в течение нескольких месяцев этот сайт незаметно датамайнили какие-то немцы и до оптимизации кеширования страницы сайта у этих немцев со всеми картинками грузились довольно долго. Когда страница начала выдаваться из кеша моментально, бот, у которого не было никаких тайм-аутов, тоже начал собирать их моментально. Тяжело пришлось. Случай особенно сложный по той причине, что если вы сами изменили настройку (включили кеширование) и сайт после этого перестал работать, то кто, по вашему и начальственному мнению, виноват? Вот-вот. Если вы наблюдаете резкий рост числа запросов, то посмотрите, например, в Google Analytics, кто приходил на какие страницы.

Тюнинг веб-сервера

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

12. Лимитируем ресурсы (размеры буферов) в nginx

Про что нужно помнить в первую очередь? Каждый ресурс имеет лимит. Прежде всего это касается оперативной памяти. Поэтому размеры заголовков и всех используемых буферов нужно ограничить адекватными значениями на клиента и на сервер целиком. Их обязательно нужно прописать в конфиге nginx.

• client_header_buffer_size_ _ Задает размер буфера для чтения заголовка запроса клиента. Если строка запроса или поле заголовка запроса не помещаются полностью в этот буфер, то выделяются буферы большего размера, задаваемые директивой large_client_header_buffers.
• large_client_header_buffers Задает максимальное число и размер буферов для чтения большого заголовка запроса клиента.
• client_body_buffer_size Задает размер буфера для чтения тела запроса клиента. Если тело запроса больше заданного буфера, то все тело запроса или только его часть записывается во временный файл.
• client_max_body_size Задает максимально допустимый размер тела запроса клиента, указываемый в поле «Content-Length» заголовка запроса. Если размер больше заданного, то клиенту возвращается ошибка 413 (Request Entity Too Large).

13. Настраиваем тайм-ауты в nginx

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

• reset_timedout_connection on; Помогает бороться с сокетами, зависшими в фазе FIN-WAIT.
• client_header_timeout Задает тайм-аут при чтении заголовка запроса клиента.
• client_body_timeout Задает тайм-аут при чтении тела запроса клиента.
• keepalive_timeout Задает тайм-аут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера. Многие боятся задавать здесь крупные значения, но мы не уверены, что этот страх оправдан. Опционально можно выставить значение тайм-аута в HTTP-заголовке Keep-Alive, но Internet Explorer знаменит тем, что игнорирует это значение
• send_timeout Задает тайм-аут при передаче ответа клиенту. Если по истечении этого времени клиент ничего не примет, соединение будет закрыто.

Сразу вопрос: какие параметры буферов и тайм-аутов правильные? Универсального рецепта тут нет, в каждой ситуации они свои. Но есть проверенный подход. Нужно выставить минимальные значения, при которых сайт остается в работоспособном состоянии (в мирное время), то есть страницы отдаются и запросы обрабатываются. Это определяется только тестированием - как с десктопов, так и с мобильных устройств. Алгоритм поиска значений каждого параметра (размера буфера или тайм-аута):

Выставляем математически минимальное значение параметра.

Запускаем прогон тестов сайта.

Если весь функционал сайта работает без проблем - параметр определен. Если нет - увеличиваем значение параметра и переходим к п. 2.

Если значение параметра превысило даже значение по умолчанию - это повод для обсуждения в команде разработчиков.

В ряде случаев ревизия данных параметров должна приводить к рефакторингу/редизайну сайта. Например, если сайт не работает без трехминутных AJAX long polling запросов, то нужно не тайм-аут повышать, а long polling заменять на что-то другое - ботнет в 20 тысяч машин, висящий на запросах по три минуты, легко убьет среднестатистический дешевый сервер.

14. Лимитируем соединия в nginx (limit_conn и limit_req)

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

Предположим, что на сайте есть разделы с говорящими названиями /download и /search. При этом мы:

• не хотим, чтобы боты (или люди с чересчур ретивыми рекурсивными download-менеджерами) забили нам таблицу TCP-соединений своими закачками;
• не хотим, чтобы боты (или залетные краулеры поисковых систем) исчерпали вычислительные ресурсы СУБД множеством поисковых запросов.

Для этих целей сгодится конфигурация следующего вида:

Http { limit_conn_zone $binary_remote_addr zone=download_c:10m; limit_req_zone $binary_remote_addr zone=search_r:10m \ rate=1r/s; server { location /download/ { limit_conn download_c 1; # Прочая конфигурация location } location /search/ { limit_req zone=search_r burst=5; # Прочая конфигурация location } } }

Обычно имеет прямой смысл установить ограничения limit_conn и limit_req для locations, в которых находятся дорогостоящие к выполнению скрипты (в примере указан поиск, и это неспроста). Ограничения необходимо выбирать, руководствуясь результатами нагрузочного и регрессионного тестирования, а также здравым смыслом.

Обратите внимание на параметр 10m в примере. Он означает, что на расчет данного лимита будет выделен словарь с буфером в 10 мегабайт и ни мегабайтом более. В данной конфигурации это позволит отслеживать 320 000 TCP-сессий. Для оптимизации занимаемой памяти в качестве ключа в словаре используется переменная $binary_remote_addr, которая содержит IP-адрес пользователя в бинарном виде и занимает меньше памяти, чем обычная строковая переменная $remote_addr. Нужно заметить, что вторым параметром к директиве limit_req_zone может быть не только IP, но и любая другая переменная nginx, доступная в данном контексте, - например, в случае, когда вы не хотите обеспечить более щадящий режим для прокси, можно использовать $binary_remote_addr$http_user_agent или $binary_remote_addr$http_cookie_myc00kiez - но использовать такие конструкции нужно с осторожностью, поскольку, в отличие от 32-битного $binary_remote_addr, эти переменные могут быть существенно большей длины и декларированные вами «10m» могут скоропостижно закончиться.

Тренды в DDoS

Непрерывно растет мощность атак сетевого и транспортного уровня. Потенциал среднестатистической атаки типа SYN-флуд достиг уже 10 миллионов пакетов в секунду.

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

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

Доля ботов, оснащенных полноценным браузерным движком с JavaScript, все еще невелика, но непрерывно растет. Такую атаку сложнее отбить встроенными подручными средствами, поэтому Самоделкины должны с опасением следить за этим трендом.

готовим ОС

Помимо тонкой настройки nginx, нужно позаботиться о настройках сетевого стека системы. По меньшей мере - сразу включить net.ipv4.tcp_syncookies в sysctl, чтобы разом защитить себя от атаки SYN-flood небольшого размера.

15. Тюним ядро

Обратите внимание на более продвинутые настройки сетевой части (ядра) опять же по тайм-аутам и памяти. Есть более важные и менее важные. В первую очередь надо обратить внимание на:

• net.ipv4.tcp_fin_timeout Время, которое сокет проведет в TCP-фазе FIN-WAIT-2 (ожидание FIN/ACK-сегмента).
• net.ipv4.tcp_{,r,w}mem Размер приемного буфера сокетов TCP. Три значения: минимум, значение по умолчанию и максимум.
• net.core.{r,w}mem_max То же самое для не TCP буферов.

При канале в 100 Мбит/с значения по умолчанию еще как-то годятся; но если у вас в наличии хотя бы гигабит в cекунду, то лучше использовать что-то вроде:

Sysctl -w net.core.rmem_max=8388608 sysctl -w net.core.wmem_max=8388608 sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608" sysctl -w net.ipv4.tcp_wmem="4096 65536 8388608" sysctl -w net.ipv4.tcp_fin_timeout=10

16. Ревизия /proc/sys/net/**

Идеально изучить все параметры /proc/sys/net/**. Надо посмотреть, насколько они отличаются от дефолтных, и понять, насколько они адекватно выставлены. Linux-разработчик (или системный администратор), разбирающийся в работе подвластного ему интернет-сервиса и желающий его оптимизировать, должен с интересом прочитать документацию всех параметров сетевого стека ядра. Возможно, он найдет там специфические для своего сайта переменные, которые помогут не только защитить сайт от злоумышленников, но и ускорить его работу.

Не бояться!

Успешные DDoS-атаки изо дня в день гасят e-commerce, сотрясают СМИ, c одного удара отправляют в нокаут крупнейшие платежные системы. Миллионы интернет-пользователей теряют доступ к критичной информации. Угроза насущна, поэтому нужно встречать ее во всеоружии. Выполните домашнюю работу, не бойтесь и держите голову холодной. Вы не первый и не последний, кто столкнется с DDoS-атакой на свой сайт, и в ваших силах, руководствуясь своими знаниями и здравым смыслом, свести последствия атаки к минимуму.

Главная цель хакеров - это сделать атакуемый ресурс недоступным для пользователя. Для этого на него направляется огромное количество ложных запросов, которые сервер не в состоянии обработать, в результате ресурс "падает". Это можно сравнить с тем, как неподготовленному человеку под видом гантелей на привычные ему 3 кг внезапно дали такие же по виду, но по 9 кг каждая. Разумеется, он не справится. То же происходит с сайтом - и вместо привычной страницы пользователь видит "заглушку" с сообщением об ошибке.

Для генерации зловредного трафика, который по сути и является DDoS-атакой, чаще всего используется большое количество устройств, имеющих доступ к Интернет, зараженных специальным кодом. Эти устройства (ПК, смартфоны, "умные вещи", серверы) объединяются в ботнеты, которые посылают запросы на адрес жертвы. Иногда источником мусорного трафика могут быть соцсети, где размещена ссылка на сайт-жертву. Помимо прочего, в Интернете есть сервисы-стрессеры, с помощью которых любой желающий может устроить ddos-атаку.

Как выглядит DDoS-атака на графике с интерфейса, через который проходит атакующий трафик

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

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

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

Скрипты и фаерволы

Допустим, что на условный сайт n.ru идет ддос-атака. По логам (истории) видно, что большое количество GET-запросов идет на главную страницу. В этом случае можно воспользоваться редиректом javascript, например:

window.location = "n.ru/index.php"

После этого легитимные пользователи, у которых не отключен javascript в браузере, перенаправляются на index.php.

Но тут возникает проблема - боты поисковых систем (Яндекса, Google) не оборудованы js-интерпретаторами и не будут перенаправлены, как и атакующие. Это негативно скажется на позициях сайта в выдаче. Чтобы этого избежать, можно написать небольшой скрипт, который будет считать количество коннектов с определенного IP адреса, и банить его. Определить бота можно, например, проверив его host.

Существует бесплатный скрипт DDoS Deflate - это своего рода сигнализация, которая использует команду «netstat» для обнаружения флуда (одного из видов DDoS), после чего блокирует подозрительные IP-адреса вредителей с помощью межсетевого экрана iptables (либо apf).

Настройки параметров Apache

Чтобы предотвратить DDoS, можно еще изменить настройки параметров Apache:

KeepAliveTimeout - нужно снизить ее значение или полностью выключить эту директиву;

TimeOut - установить как можно меньшее значение для данной директивы (веб-сервера, который подвержен DDoS-атаке).

Директивы LimitRequestBody, LimitRequestFieldSize, LimitRequestFields, LimitRequestLine, LimitXMLRequestBody должны быть настроены на ограничение потребления ресурсов, вызванных запросами клиентов.

Самый радикальный способ остановить DDoS-атаку - это блокировать все запросы из страны, откуда начал идти "мусорный" трафик. Однако это может доставить большие неудобства реальным пользователям из этих стран, т.к. им придется воспользоваться proxy для обхода блокировки.

И тут мы подходим к вопросу, почему вышеперечисленные способы не могут в полной мере обеспечить защиту от DDoS-атак. Дело в том, что бывает очень сложно отличить легитимные запросы от зловредных. Например, нашумевший червь заставлял видеорегистраторы посылать запросы по протоколу TCP, которые выглядели как легитимные, из-за чего не сразу удалось остановить DDoS-атаку. На сегодняшний день существует более 37 типов DDoS-атак, каждый из которых имеет свои особенности. Кроме того, велика вероятность отсеять вместе с зловредными запросами часть легитимных, т.е. потерять реальных пользователей.

Способы защиты от DDoS-атак

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

Чтобы разобраться самостоятельно, потребуется масса времени, поэтому мы решили написать небольшой гид по современным видам защиты от DDoS-атак.

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

В первую группу входят следующие виды защиты от распределенных атак:

1. reverse proxy (обратное проксирование). Провайдер защиты выдает ресурсу, который надо защитить, новый IP-адрес - его необходимо внести в А-запись. После изменения А-записи входящий трафик будет идти сначала на очистку в сеть провайдера по новому IP-адресу, а после этого, уже очищенный, поступать на реальный адрес. При этом ресурс может оставаться на прежнем хостинге. Это самая доступная защита от DDoS: подходит сайтам различной посещаемости, подключение и настройка занимает не более 20 минут, требует минимальных знаний от вебмастера.

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

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

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

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

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

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

Чтобы исправить последнее, поставщики оборудования разработали гибридную схему: трафик свыше лимита, который уже не может обработать физический фильтр, передается на очистку в "облако". Однако недавно хакеры нашли уязвимость в этой системе, связанную с тем, что на передачу данных в "облако" требуется определенное время, и разработали алгоритм DDoS-атаки, который выводит гибридную защиту из строя. Такие атаки называют Pulse Wave, прочитать о них можно здесь.

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

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

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

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

Кроме того, если Вы не имеете в штате подкованных опытных айтишников, которые сами всё настроят, то Вам понадобится помощь техподдержки. Большим плюсом будет, если саппорт компании, предоставляющей сервис по защите от DDoS, работает 24/7 и говорит на одном языке с заказчиком.

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