>и затруднит диагностику и сопровождение
Как? Вы занимаетесь поддержкой серверов? Неужели ориентируетесь на заголовок Server? Не вижу никаких трудностей, связанных с этим.
>Не проще ли озаботиться обновлением собственно версии ПО (все вэб-серверы которые вы перечислили более-менее активно развиваются), в которой устраняются указанные неисправности?
Это вещи не взаимозаменяемые. Никто не мешает обновляться с двумя дополнительными строчками в конфиге, подменяющими Server.
>П.С. Хотя наверно после перекомпиляции вэб-серверов из сорцов либо установки всех модулей действо с обновление для вас перестает быть тривиальным…
Не совсем понял, что вы хотите сказать. В статье как раз расказано, как изменить Server без перекомпиляции, хотя в сети бытует мнение, что для этого она обязательно нужна.
С завидной периодичностью появляются и эксплоиты. Так какой смысл всем объявлять, под какой веб-сервер и под какую его версию искать эксплоит? Мало того, что по умолчанию включена полная информация в заголовке Server, так еще и нет в документации конкретных инструкций, как это отключить.
А «круто, бизипасна» достигается не одним действием, а комплексом действий, в который по желанию можно включать и подмену Server.
Интересно, почему такая разница между данными графика и базой delegated-extended. Здесь написано, что график обновляется каждую неделю. Не особо верится, чтобы менее, чем за неделю. раздали 4445512 адресов. Да и вот сейчас даже запустил два раза скрипт Ваш. Результат:
2012-03-15 09:20:41
41958536
2012-03-15 09:36:18
41764488
За 15 минут 194048 адресов. И в самом файле данных смущает фраза:
# This is an experimental publication. Our intention is to publish accurate
# details about «available» resources, but at this stage there's no guarantee
# about completeness or correctness.
>Ты вцепился в SYN-flood, как в единственно возможный тип ДДоС-атаки
Мне интересно, на основании чего ты сделал такой вывод. Если я чего-то не описал в своей статье, то это не значит, что я этим не занимаюсь. В данной статье рассматривается SYN-flood. Точка.
Троллинг типа унылый кактус или нет, фигически и прочее для меня интереса не представляет и в статье не рассматривается.
>Вы увязываете длину очереди net.core.somaxconn с защитой от syn flood (увеличили очередь — больше соединений обработали), при том, что somaxconn — это listen socket queue уже установленных соединений.
Тонкий момент. Во FreeBSD есть syncache. Там точно задается размер очереди незакрытых соединений — net.inet.tcp.syncache.cachelimit. Про somaxconn пересмотрю. Чтобы ускорить процесс, дайте ссылку, которая подтверждает данную информацию, если есть. Я пока не нашел.
>При включенных syncookies соединение (спуфленное) не будет установлено и соответственно не попадёт в somaxcon. В чём же суть вашей защиты?
В теории да. А на практике незакрытые соединения рубятся не сразу и еще долго висят. Я это говорю чисто из того эксперимента, который проводил. На графиках же видно это.
>Это ключевой момент и нужно было об этом обязательно упомянуть.
Я бы не сказал. Я показал влияние значений указанных параметров TCP при прочих равных параметрах. SYN cookies были включены во всех трех режимах.
>Иначе выгялядит так, что вы боритесь с синфлудом только за счёт динамического увеличения длины очереди.
Посмотрите раздел «Параметры TCP» в статье — он самый первый. И у Вас сразу пропадет впечатление, что идет речь только о длине очереди.
>А SYN cookies чем вас не устраивают?
Об этом я не говорил. Тесты проводились с включенными SYN cookies. Как видите, тюнинг свой результат дает.
>На графике очередь входящих пакетов ~100pps — это называется синфлуд?
Это не pps. Это длина очереди в данный момент.
>На каком потоке syn пакетов проводилось тестирование?
Тестирований проводилось hping'ом с дефолтным интервалом — одна секунда между пакетами. Но суть не в этом. Можно задать больше, на графике цифры будут больше. Но поведение графика останется.
>ИМХО, игры с таймаутами, длиной очереди и прочее хороши лишь в качестве оптимизации стека, а не защиты от синфлуда.
Мне неясен данный тезис. Synflood — это одна из причин, почему стек стоит оптимизировать. На графике это наглядно видно. Есть свободные места в очереди — нет отказа в обслуживании.
1. Мне не доводилось встречать подход с динамическим изменением параметров.
2. Я не видел наглядных исследований и графиков влияния значений параметров на длину очереди.
3. Готовый темплейтов для Cacti для мониторинга очереди тоже нет.
Зависит от того, какой контент Вы отдаете. Далеко не на каждом сервере есть скрипты, которые работают дольше 30 секунд и результат не кэшируется. Чтобы не возникало споров о цифрах, к скрипту есть конфиг.
>Имхо, один раз правильно настроить и не трогать.
Вопрос динамического изменения параметров вообще спорный, об этом в статье сказано. Но преимущество подхода в том, что Вы сами определяете, какие параметры и какие их значение будут оптимальны для конкретного сервера.
Ага, особенно незнание нужных тегов.
Ушли от ответа, попутно обозначив собеседника rookie. Но главное, что теги нужные знаете. Похвально.
Как померять процент?
>и затруднит диагностику и сопровождение
Как? Вы занимаетесь поддержкой серверов? Неужели ориентируетесь на заголовок Server? Не вижу никаких трудностей, связанных с этим.
Это вещи не взаимозаменяемые. Никто не мешает обновляться с двумя дополнительными строчками в конфиге, подменяющими Server.
>П.С. Хотя наверно после перекомпиляции вэб-серверов из сорцов либо установки всех модулей действо с обновление для вас перестает быть тривиальным…
Не совсем понял, что вы хотите сказать. В статье как раз расказано, как изменить Server без перекомпиляции, хотя в сети бытует мнение, что для этого она обязательно нужна.
А «круто, бизипасна» достигается не одним действием, а комплексом действий, в который по желанию можно включать и подмену Server.
2012-03-15 09:20:41
41958536
2012-03-15 09:36:18
41764488
За 15 минут 194048 адресов. И в самом файле данных смущает фраза:
# This is an experimental publication. Our intention is to publish accurate
# details about «available» resources, but at this stage there's no guarantee
# about completeness or correctness.
Также неплохо б написать софт под Android… Такое есть в планах?
Мне интересно, на основании чего ты сделал такой вывод. Если я чего-то не описал в своей статье, то это не значит, что я этим не занимаюсь. В данной статье рассматривается SYN-flood. Точка.
Троллинг типа унылый кактус или нет, фигически и прочее для меня интереса не представляет и в статье не рассматривается.
Тонкий момент. Во FreeBSD есть syncache. Там точно задается размер очереди незакрытых соединений — net.inet.tcp.syncache.cachelimit. Про somaxconn пересмотрю. Чтобы ускорить процесс, дайте ссылку, которая подтверждает данную информацию, если есть. Я пока не нашел.
>При включенных syncookies соединение (спуфленное) не будет установлено и соответственно не попадёт в somaxcon. В чём же суть вашей защиты?
В теории да. А на практике незакрытые соединения рубятся не сразу и еще долго висят. Я это говорю чисто из того эксперимента, который проводил. На графиках же видно это.
Я бы не сказал. Я показал влияние значений указанных параметров TCP при прочих равных параметрах. SYN cookies были включены во всех трех режимах.
>Иначе выгялядит так, что вы боритесь с синфлудом только за счёт динамического увеличения длины очереди.
Посмотрите раздел «Параметры TCP» в статье — он самый первый. И у Вас сразу пропадет впечатление, что идет речь только о длине очереди.
Об этом я не говорил. Тесты проводились с включенными SYN cookies. Как видите, тюнинг свой результат дает.
>На графике очередь входящих пакетов ~100pps — это называется синфлуд?
Это не pps. Это длина очереди в данный момент.
>На каком потоке syn пакетов проводилось тестирование?
Тестирований проводилось hping'ом с дефолтным интервалом — одна секунда между пакетами. Но суть не в этом. Можно задать больше, на графике цифры будут больше. Но поведение графика останется.
>ИМХО, игры с таймаутами, длиной очереди и прочее хороши лишь в качестве оптимизации стека, а не защиты от синфлуда.
Мне неясен данный тезис. Synflood — это одна из причин, почему стек стоит оптимизировать. На графике это наглядно видно. Есть свободные места в очереди — нет отказа в обслуживании.
2. Я не видел наглядных исследований и графиков влияния значений параметров на длину очереди.
3. Готовый темплейтов для Cacti для мониторинга очереди тоже нет.
Дайте пруф своего утверждения по каждому пункту.
>Имхо, один раз правильно настроить и не трогать.
Вопрос динамического изменения параметров вообще спорный, об этом в статье сказано. Но преимущество подхода в том, что Вы сами определяете, какие параметры и какие их значение будут оптимальны для конкретного сервера.
bugs.dokuwiki.org/index.php?do=details&task_id=1698