Здравствуйте, 0K, Вы писали:
0K>Кто-нить может поделиться опытом противостояния ddos-атакам?
Вообще это больше маркетинг — обычно DDOS атака кладет твой канал, поэтому, если провайдер не обеспечит фильтрацию, то на своей стороне ничего не отбить. Так что самое правильное — это искать провайдера, который предоставляет услугу по защите от DDoS.
Здравствуйте, DOOM, Вы писали:
0K>>Кто-нить может поделиться опытом противостояния ddos-атакам? DOO>Вообще это больше маркетинг — обычно DDOS атака кладет твой канал, поэтому, если провайдер не обеспечит фильтрацию, то на своей стороне ничего не отбить. Так что самое правильное — это искать провайдера, который предоставляет услугу по защите от DDoS.
Я думаю, положить HTTP-сервер на пару порядков проще, чем канал. Поэтому если ваш сервер способен отрабатывать запросы на скорости канала, вы уже относительно защищены, по сравнению с другими. Заддосить вас будет возможно, но желание должно превышать сложность реализации.
Здравствуйте, 0K, Вы писали:
0K>Кто-нить может поделиться опытом противостояния ddos-атакам?
0K>Какой-нибудь ценный материал или еще чего?
Правило первое: общего метода нет.
Правило второе: защита от DDoS реализуется тогда, когда проверять запрос на "нормальность" его источника проще, чем отрабатывать запрос. Например, возьмём совершенно крайний случай — допускаются только запросы из локалки, в которой вредителей нет. Тогда пакетный фильтр, отрезающий запросы из интернета, является успешной защитой;)) Разумеется, это утрировано. Или можно сравнить с киоском хотдогов на улице. Если каждый второй прохожий будет минут по 10 расспрашивать о качестве продуктов и ничего не покупать — через полчаса продавец закидает всех кетчупом и уйдёт, это и будет успешный DDoS:) Критерий успеха при нём — именно качество предварительной фильтрации перед отработкой.
Ну а дальше — ну а что толку, что я расскажу, как избавился от почтового DDoS зафильтровав на сутки несколько наиболее обширных DSL'ей (и не получив за это ни одной жалобы)? Или ещё несколько похожих случаев? Это ведь мой случай, а Ваш не поможет...
Но, пожалуй, есть несколько типичных приёмов, помогающих в достаточном количестве случаев.
1. Надо опознать, есть ли возможность разделить источники на своём уровне доступа. В типичном случае есть один канал к провайдеру. Тогда, если источник виден за одним линком провайдера, можно уговорить его на фильтр. Если не получается (это значительно чаще) — этот метод не проходит.
2. Сервисы поверх TCP и UDP фильтруются совершенно по-разному. В случае TCP, важно установление соединения, тогда запросы с фиктивных адресов отрезаются простейшим SYN cookies. В случае UDP, надо отвечать сразу — тогда такая фильтрация не проходит (в этом смысле UDP хуже защищён).
3. В случае HTTP и аналогов и атаки игрой в молчанку со множества источников (или кривыми запросами), помогает очень легковесный прокси на входе, который способен отделить корректные и полезные запросы.
4. Часто помогает разделение анонсов DNS в разные стороны (например, зная, что руководящий центр живёт в США — отдать другой IP в американские сети).
В среднем сейчас самые эффективные методы — из серии сигнатурного анализа IP потока. Но это уже достаточно высокий пилотаж.
Pzz>Я думаю, положить HTTP-сервер на пару порядков проще, чем канал.
Ну, вопрос какой сервер и какой канал... Если речь о серьезных конторах, то серверов у них в ферме достаточно
Кстати, то, что современные решения по защите от DDoS от всяких цисок и Arbor смогут адекватно противостоять атаке бот сети у меня вызывает определенные сомнения — протестировать это не так просто в лабораторных условиях, поэтому предпочитают и не тестировать
А этот функционал был бы наиболее интересен, потому что чтобы отбить всякий детский сад типа SYN флуда никакие железки за несколько сот килобаксов не нужны