Комментарии 30
synflood-defender.net/docs — хабраефект?
Кажется, дал о себе знать баг. Думал, мой хак решил проблему, но вот нагрузка подскочила и он опять проявился. Обновите страницу через Ctrl+R.
bugs.dokuwiki.org/index.php?do=details&task_id=1698
bugs.dokuwiki.org/index.php?do=details&task_id=1698
НЛО прилетело и опубликовало эту надпись здесь
страница недоконца загружается. pix.am/FHZh/
И правда, пруф
firefox 7.0.1 обновлял много раз, все то же.
А какое отношение tcp_keepalive_* имеют к SYN-flood атаке? Keepalive у TCP отсылается когда соединение установлено и после какого-либо пакета с данными.
В случае SYN-flood — до соединения не доходит.
В случае SYN-flood — до соединения не доходит.
Согласен. Но даже если соединение установлено, зачем ждать два часа перед закрытием, если оно не используется?
Просто непонятно зачем в таком случае делать этот параметр динамическим. Если в нормальном состоянии срипты отдают контент с большой задержкой (больше чем вы динамически 30 секунд выставляете) — то в вашем случае клиенты будут видеть оборванные соединения :(
Имхо, один раз правильно настроить и не трогать.
Имхо, один раз правильно настроить и не трогать.
Зависит от того, какой контент Вы отдаете. Далеко не на каждом сервере есть скрипты, которые работают дольше 30 секунд и результат не кэшируется. Чтобы не возникало споров о цифрах, к скрипту есть конфиг.
>Имхо, один раз правильно настроить и не трогать.
Вопрос динамического изменения параметров вообще спорный, об этом в статье сказано. Но преимущество подхода в том, что Вы сами определяете, какие параметры и какие их значение будут оптимальны для конкретного сервера.
>Имхо, один раз правильно настроить и не трогать.
Вопрос динамического изменения параметров вообще спорный, об этом в статье сказано. Но преимущество подхода в том, что Вы сами определяете, какие параметры и какие их значение будут оптимальны для конкретного сервера.
Спасибо за полезную информацию. Для меня это сейчас актуально.
Reinventing the wheel since 1990!
1. Мне не доводилось встречать подход с динамическим изменением параметров.
2. Я не видел наглядных исследований и графиков влияния значений параметров на длину очереди.
3. Готовый темплейтов для Cacti для мониторинга очереди тоже нет.
Дайте пруф своего утверждения по каждому пункту.
2. Я не видел наглядных исследований и графиков влияния значений параметров на длину очереди.
3. Готовый темплейтов для Cacti для мониторинга очереди тоже нет.
Дайте пруф своего утверждения по каждому пункту.
По первому пункту я подскажу, floodmon.sourceforge.net/
Ты вцепился в SYN-flood, как в единственно возможный тип ДДоС-атаки, ну или, как минимум, как в очень злобную и коварную. Однако же, уже много лет она не является сколь-либо серьезной, все приличные файерволы (да даже ADC) имеют встроенную защиту от SYN-flood, ибо просто она, как три рубля. Поэтому содержимое статьи уже не имеет никакого значения, динамически-фигически, исследования-графики, кактус унылый и т.п. Просто зря потраченное время. Ну, для самообразования, конечно, стоит заниматься такими вещами, но миру пользы от этого никакой, только в топку энтропии дровишки.
Уж прости за резкость.
Уж прости за резкость.
>Ты вцепился в SYN-flood, как в единственно возможный тип ДДоС-атаки
Мне интересно, на основании чего ты сделал такой вывод. Если я чего-то не описал в своей статье, то это не значит, что я этим не занимаюсь. В данной статье рассматривается SYN-flood. Точка.
Троллинг типа унылый кактус или нет, фигически и прочее для меня интереса не представляет и в статье не рассматривается.
Мне интересно, на основании чего ты сделал такой вывод. Если я чего-то не описал в своей статье, то это не значит, что я этим не занимаюсь. В данной статье рассматривается SYN-flood. Точка.
Троллинг типа унылый кактус или нет, фигически и прочее для меня интереса не представляет и в статье не рассматривается.
1. Мне не доводилось встречать подход с динамическим изменением параметров.
2. Я не видел наглядных исследований и графиков влияния значений параметров на длину очереди.
3. Готовый темплейтов для Cacti для мониторинга очереди тоже нет.
интереса не представляет и в статье не рассматривается.
М? Толькто что ты этим гордишься, через минуту уже не представляет для тебя интереса?
Ничего-ничего, списывать критику на троллинг нормально в 14 лет.
А SYN cookies чем вас не устраивают? На графике очередь входящих пакетов ~100pps — это называется синфлуд? На каком потоке syn пакетов проводилось тестирование? ИМХО, игры с таймаутами, длиной очереди и прочее хороши лишь в качестве оптимизации стека, а не защиты от синфлуда.
>А SYN cookies чем вас не устраивают?
Об этом я не говорил. Тесты проводились с включенными SYN cookies. Как видите, тюнинг свой результат дает.
>На графике очередь входящих пакетов ~100pps — это называется синфлуд?
Это не pps. Это длина очереди в данный момент.
>На каком потоке syn пакетов проводилось тестирование?
Тестирований проводилось hping'ом с дефолтным интервалом — одна секунда между пакетами. Но суть не в этом. Можно задать больше, на графике цифры будут больше. Но поведение графика останется.
>ИМХО, игры с таймаутами, длиной очереди и прочее хороши лишь в качестве оптимизации стека, а не защиты от синфлуда.
Мне неясен данный тезис. Synflood — это одна из причин, почему стек стоит оптимизировать. На графике это наглядно видно. Есть свободные места в очереди — нет отказа в обслуживании.
Об этом я не говорил. Тесты проводились с включенными SYN cookies. Как видите, тюнинг свой результат дает.
>На графике очередь входящих пакетов ~100pps — это называется синфлуд?
Это не pps. Это длина очереди в данный момент.
>На каком потоке syn пакетов проводилось тестирование?
Тестирований проводилось hping'ом с дефолтным интервалом — одна секунда между пакетами. Но суть не в этом. Можно задать больше, на графике цифры будут больше. Но поведение графика останется.
>ИМХО, игры с таймаутами, длиной очереди и прочее хороши лишь в качестве оптимизации стека, а не защиты от синфлуда.
Мне неясен данный тезис. Synflood — это одна из причин, почему стек стоит оптимизировать. На графике это наглядно видно. Есть свободные места в очереди — нет отказа в обслуживании.
>>Об этом я не говорил. Тесты проводились с включенными SYN cookies.
Это ключевой момент и нужно было об этом обязательно упомянуть. Иначе выгялядит так, что вы боритесь с синфлудом только за счёт динамического увеличения длины очереди.
>>Это не pps. Это длина очереди в данный момент.
конечно же
Это ключевой момент и нужно было об этом обязательно упомянуть. Иначе выгялядит так, что вы боритесь с синфлудом только за счёт динамического увеличения длины очереди.
>>Это не pps. Это длина очереди в данный момент.
конечно же
>Это ключевой момент и нужно было об этом обязательно упомянуть.
Я бы не сказал. Я показал влияние значений указанных параметров TCP при прочих равных параметрах. SYN cookies были включены во всех трех режимах.
>Иначе выгялядит так, что вы боритесь с синфлудом только за счёт динамического увеличения длины очереди.
Посмотрите раздел «Параметры TCP» в статье — он самый первый. И у Вас сразу пропадет впечатление, что идет речь только о длине очереди.
Я бы не сказал. Я показал влияние значений указанных параметров TCP при прочих равных параметрах. SYN cookies были включены во всех трех режимах.
>Иначе выгялядит так, что вы боритесь с синфлудом только за счёт динамического увеличения длины очереди.
Посмотрите раздел «Параметры TCP» в статье — он самый первый. И у Вас сразу пропадет впечатление, что идет речь только о длине очереди.
Вы увязываете длину очереди net.core.somaxconn с защитой от syn flood (увеличили очередь — больше соединений обработали), при том, что somaxconn — это listen socket queue уже установленных соединений. При включенных syncookies соединение (спуфленное) не будет установлено и соответственно не попадёт в somaxcon. В чём же суть вашей защиты?
>Вы увязываете длину очереди net.core.somaxconn с защитой от syn flood (увеличили очередь — больше соединений обработали), при том, что somaxconn — это listen socket queue уже установленных соединений.
Тонкий момент. Во FreeBSD есть syncache. Там точно задается размер очереди незакрытых соединений — net.inet.tcp.syncache.cachelimit. Про somaxconn пересмотрю. Чтобы ускорить процесс, дайте ссылку, которая подтверждает данную информацию, если есть. Я пока не нашел.
>При включенных syncookies соединение (спуфленное) не будет установлено и соответственно не попадёт в somaxcon. В чём же суть вашей защиты?
В теории да. А на практике незакрытые соединения рубятся не сразу и еще долго висят. Я это говорю чисто из того эксперимента, который проводил. На графиках же видно это.
Тонкий момент. Во FreeBSD есть syncache. Там точно задается размер очереди незакрытых соединений — net.inet.tcp.syncache.cachelimit. Про somaxconn пересмотрю. Чтобы ускорить процесс, дайте ссылку, которая подтверждает данную информацию, если есть. Я пока не нашел.
>При включенных syncookies соединение (спуфленное) не будет установлено и соответственно не попадёт в somaxcon. В чём же суть вашей защиты?
В теории да. А на практике незакрытые соединения рубятся не сразу и еще долго висят. Я это говорю чисто из того эксперимента, который проводил. На графиках же видно это.
man listen (2)
The behavior of the backlog argument on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely established sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for incomplete sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When syncookies are enabled there is no logical maximum length and this setting is ignored. See tcp(7) for more information.
The behavior of the backlog argument on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely established sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for incomplete sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When syncookies are enabled there is no logical maximum length and this setting is ignored. See tcp(7) for more information.
Открытое решение по защите от DDOS атак — в частности synflood
https://github.com/LTD-Beget/syncookied
https://beget.com/ru/articles/syncookied
https://github.com/LTD-Beget/syncookied
https://beget.com/ru/articles/syncookied
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Метод определения и динамической защиты от DDoS типа SYN-flood