- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
К наиболее популярынм атакам без сомнения можно отнести этот популярный способ, когда веб-сервер переполняется запросами от ботов и не может нормально обслуживать запросы посетителей.
В результате такой атаки сайт становится недоступным, а с сервероной стороны можно наблюдать рост нагрузки на сервер, большое число процессов веб-сервера и конечно, значительный рост соеденений. Если атака будет очень сильной и паразитный трафик превысит пропускную способность канала к серверу, то на него нельзя будет зайти по ssh.
Но столь сильные атаки — редкость, так как 10-20Mbps такого трафика вполне способны свалить неподготовленный сервер.
Как этого избежать
это получится "прощай робот яндекса"?
Познавательно, спасибо.
iptables -t nat -A PREROUTING -p tcp --dport 80 -m string --string "this-is-not-bot" --algo kmp -j REDIRECT --to-ports 8080
1. -m string не страшно на ~20Mbps использовать?
2. пример не "рабочий", правило iptables будет работать если в _каждом_
хорошем TCP пакете будет искомая строка. Так что решение - минимум
не в две строчки ;-)
3. не встречались боты, умеющие кукисы? у Вас еще все впереди :D
4. как минимум, до того как забьют канал - могут скушать все системные
ресурсы. поэтому начинать нужно не с правил файервола, а с ограничения
CPU/памяти/etc для всего доступного извне - апача, mysql, nginx etc
PS:
me думает, что бан на основе тех же критериев (кукисы) в nginx + последующий
бан iptables/ipset на файерволе - будет лучше в плане производительности
myhand добавил 16.10.2009 в 18:32
это получится "прощай робот яндекса"?
предлагается хороших узнать и собрать отдельно в WHITELIST
увы, работает это способ только против атак "школьников". Добавить
нужный _статический_ хидер к запросу бота - не составляет проблемы.
Да, это защита школьного ддос, коих сейчас очень много
Отвратительная идея - искать строки на L3.
На порядок лучше проверять наличие куки nginx-ом, и при наличии - проксировать.
Да, это защита школьного ддос, коих сейчас очень много
реально -m string использовался на 20Mbps?
именно в _это_, думаю, здесь никто не верит
myhand добавил 16.10.2009 в 19:43
Отвратительная идея - искать строки на L3.
проблема еще и в том, что пользователи при этом рубятся. совершенно нормально,
что в TCP пакете от "хорошего" клиента, проставившего кукисы - искомой строки _не_будет_.
проблема еще и в том, что пользователи при этом рубятся. совершенно нормально,что в TCP пакете от "хорошего" клиента, проставившего кукисы - искомой строки _не_будет_.
М-м-м-м... Я тут слегка подумал головой - и что-то мне подсказывает, что эта схема работать не будет вообще :-) А не "пользователи рубятся".
М-м-м-м... Я тут слегка подумал головой - и что-то мне подсказывает, что эта схема работать не будет вообще :-) А не "пользователи рубятся".
_будет_, в какой-то степени...
только часть вполне нормальных TCP-пакетов от обычных пользователей - будет
рубиться. те если заголовки http и данные не будут в одном пакете.
может в реальности дело было сложнее организовано, не в "две строчки",
см. пункт 2 моего поста:
/ru/forum/comment/5642032
_будет_, в какой-то степени...
только часть вполне нормальных TCP-пакетов от обычных пользователей - будет
рубиться. те если заголовки http и данные не будут в одном пакете.
Ну ладно, давай разбирать по пунктами :-)
1. Что делает правило iptables? Правильно, форвардит пакет, содержащий куку, на другой порт.
2. Когда в пакете появляется кука? Правильно, когда браузер отправляет заголовок Cookie:
3. Когда браузер отправляет заголово Cookie? Правильно, после установки tcp-сессии.
4. Как устанавливается tcp-сессия? И тут правильно, syn - syn-acc - acc - data
Внимание, вопрос на сообразительность: какой по счету пакет отфорвардится на порт 8080?
3. Когда браузер отправляет заголово Cookie? Правильно, после установки tcp-сессии.
4. Как устанавливается tcp-сессия? И тут правильно, syn - syn-acc - acc - data
data :)
кстати, да - по этой причине - тоже работать не должно. т.е. минимум нужна
еще какая-то проверка на флаги (SYN, etc..).
PS: вообще, на картинку системы под 20Mbps досом, фильтрующей _каждый_ входящий
TCP-пакет с данными взглянуть любопытно (top, %sy цифирки).