шутите? пришел пакет с syn, там строки нет - мы на него забили?
Ага. Пользователь включил поддержку кукисов - а его все-равно 50/50 банят. Нафиг
такую "защиту" - проще уж --dport 80 -j DROP
Чтобы решение со string было хоть чуть рабочим - как минимум, HTTP-запросы
небольшими должны быть. POST, HTTP keepalive, да и простые GET - будут резаться.
string пробовал (не для защиты от ddos, но объем фильтруемого трафика
был сопоставим), потому и не верю в такой способ защиты на 20Mbps
проще в nginx проверять кукисы - а потом банить ipset. 20Mbps - вовсе не проблема,
скрытых граблей нет.
-m state тут совершенно непричем - необходимость фильтрации пакетов в
ESTABLISHED для 80-го порта это не отменяет :) Просто -j ACCEPT для них - нельзя, Вам
понятно почему?
у вас поиск строки как раз в ESTABLISHED должен происходить :D Так доускоряетесь, nginx с
апачем за файерволом помрут.
тут недавно пробегало предположение, что под его ником минимум
двое постят.
тем не менее, даже в 3-4 строки это не решить: залез HTTP запрос
в TCP пакет вместе с хидерами - хорошо. Нет - его зарезали.
а вы пробовали?
а с --state NEW, например, что предлагается делать?
хорошо, а как насчет пакетов с данными, где нужного http-хидера - нет?
сумеете обойти это еще в одну строку?
пугают не 20мбит, а идея сканирования на вхождение строки у _каждого_ входящего
TCP пакета с данными.
моя думал, идея в том, что вся эта "защита" со string - крутилась на
обычном выделенном сервере :(
в общем, автору незачет. пока не объяснит принцип работы
второй строки. и сколько дополнительных строк (напр, правил iptables) для этого
использовалось :D
data :)
кстати, да - по этой причине - тоже работать не должно. т.е. минимум нужна
еще какая-то проверка на флаги (SYN, etc..).
PS: вообще, на картинку системы под 20Mbps досом, фильтрующей _каждый_ входящий
TCP-пакет с данными взглянуть любопытно (top, %sy цифирки).
_будет_, в какой-то степени...
только часть вполне нормальных TCP-пакетов от обычных пользователей - будет
рубиться. те если заголовки http и данные не будут в одном пакете.
может в реальности дело было сложнее организовано, не в "две строчки",
см. пункт 2 моего поста:
/ru/forum/comment/5642032
реально -m string использовался на 20Mbps?
именно в _это_, думаю, здесь никто не верит
myhand добавил 16.10.2009 в 19:43
проблема еще и в том, что пользователи при этом рубятся. совершенно нормально,
что в TCP пакете от "хорошего" клиента, проставившего кукисы - искомой строки _не_будет_.
дык это апач ему говорит (или что у вас там на бакенде), смотрите лог бакенда.
как называется скрипт в директории /usr/html/upload/
?
myhand добавил 16.10.2009 в 22:42
да, похоже, что это nginx таки выдает - т.е. не проксирует @test
у меня конфиг отличается только тем, что _не_используются_ именованные location:
http { [...] upload_progress proxied 1m; server { [...] upload_store /tmp 1; upload_set_form_field "${upload_field_name}_name" "$upload_file_name"; upload_set_form_field "${upload_field_name}_content_type" "$upload_content_type"; upload_set_form_field "${upload_field_name}_path" "$upload_tmp_path"; upload_pass_form_field "^submit$"; location = /upload { upload_pass /internal; track_uploads proxied 30s; } location = /internal { proxy_pass http://localhost:8080; } location ^~ /progress { # report uploads tracked in the 'proxied' zone report_uploads proxied; } } }
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
увы, работает это способ только против атак "школьников". Добавить
нужный _статический_ хидер к запросу бота - не составляет проблемы.
