собственно вопрос возникает из:
http://habrahabr.ru/post/116056/
http://code.google.com/p/slowhttptest/wiki...llationAndUsage

slowhttptest -c 1000 -B -g -o my_server_stats -i 110 -r 200 -s 8192 -u http://youserver -x 20 -p 3

или его друх

slowhttptest -c 1000 -g -o my_server_stats -i 110 -r 200 -u http://youserver -x 20 -p 3

от первой 8.5.2 ложится напрочь (7-ка тоже)
от второй - икает и закрывает все соединения (в кол-ве 1000)

варианты защиты:
-анализ заголовков/штатные ср-ва домины - я не исследовал
-фронтэнд в виде nginx
-...

 

Подозреваю, что второе
Вопрос только в одном - насколько ModSecurity даст Домине вообще работать?

 

-фронтэнд в виде nginx

по первой ссылке расписано что nginx не спасает

лично не проверял, но что-то мне подсказывает что правильное указание таймаутов решает всё
Timeouts
HTTP persistent connections: Disabled
Maximum requests per persistent connection: 1
Persistent connection timeout: 30 seconds
Request timeout: 5 seconds
Input timeout: 10 seconds
Output timeout: 60 seconds
CGI timeout: 60 seconds

 

по первой ссылке расписано что nginx не спасает

если не читать каменты
на самом деле любую дефолтную домину можно так положить и тема актуальна

 

поигрался с параметрами, как и предполагал - серьёзного влияния на ситуацию они не оказывают

 

поигрался с параметрами, как и предполагал - серьёзного влияния на ситуацию они не оказывают

указал везде по 1сек и не помогло?

 

неа - и по логике (если прочитать тултипы) - не должно
ведь реквесты передаются просто между чанками есть задержки

Добавлено: вернее так - сервер будет быстрее сбрасывать соединения, но недоступность будет на уровне 30 сек
цель не сбросить соединения а работать, но игнорить медленные передачи
при таких настройках как 1 сек нормальная работа клиентов невозможна - будут обрывы и всякая хня
а эффективность крайне мала

 

Добавлено: вернее так - сервер будет быстрее сбрасывать соединения, но недоступность будет на уровне 30 сек
цель не сбросить соединения а работать, но игнорить медленные передачи
при таких настройках как 1 сек нормальная работа клиентов невозможна - будут обрывы и всякая хня
а эффективность крайне мала

а 5 сек будет нормальная эффективность?

 

еще раз повторю - сервак уходит в аут и сбрасывает соединения в теч. более 35 сек
уходит в аут - это не в состоянии обслуживать никакие др. соединения!

Wed Apr 10 20:16:50 2013:slow HTTP test status on 30th second:
initializing: 0
pending: 0
connected: 60
error: 0
closed: 940
service available: NO

 

увеличь количество сессий до 20К и погляди дальше

 

пойми - это архитектурная невозможность
не сессия надо увеличивать, а ограничивать время на передачу данных (все параметры выше - это мимо)
пример для nginx
http://nginx.org/ru/docs/http/ngx_http_cor...ody_buffer_size

синтаксис: client_body_timeout время;
умолчание:

client_body_timeout 60s;

контекст: http, server, location

Задаёт таймаут при чтении тела запроса клиента. Таймаут устанавливается не на всю передачу тела запроса, а только между двумя последовательными операциями чтения. Если по истечении этого времени клиент ничего не передаст, то клиенту возвращается ошибка 408 (Request Time-out).

 

пойми - это архитектурная невозможность
не сессия надо увеличивать, а ограничивать время на передачу данных (все параметры выше - это мимо)
пример для nginx
http://nginx.org/ru/docs/http/ngx_http_cor...ody_buffer_size

ну вот и указать в домино не 60сек - за которые можно тысячу таких запросов нагенерить а 5 сек - не успел клиент передать - его проблема

 

ToxaRat яж тебе сказал - такой настройки я не знаю, в домине, перечисленные выше поля за др. фичи отвечают

 

что можно сделать...
ставим nginx, создаем конфиг для сайта в nginx/sites-available
скажем mysite
симлинк в nginx/sites-enable
в никсах это sudo ln -s /etc/nginx/sites-available/mysite /etc/nginx/sites-enabled/
содержимое файла mysite

server {
listen *:80; ## listen for ipv4
server_name frontendserver;
access_log /var/log/nginx/access.log;
# Перенаправление на back-end
location / {
proxy_pass http://backendserver;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_connect_timeout 120;
proxy_send_timeout 120;
proxy_read_timeout 180;
}
}

передергиваем nginx
не рассмотренные особенности:
-https
-ssl сертификаты для сайта
-редайректы - домина направляет запрос на БД конфига (док сервера), при обращении к руту сайта, дык вот ... - в такой конфиге не сработает (nginx покажет свою страницу)
все это допилить несложно, но мне было лень
итого имеем

Fri Apr 12 15:35:26 2013:slow HTTP test status on 15th second:
initializing: 0
pending: 0
connected: 1000
error: 0
closed: 0
service available: YES
Fri Apr 12 15:35:31 2013:slow HTTP test status on 20th second:
initializing: 0
pending: 0
connected: 1000
error: 0
closed: 0
service available: YES
^CFri Apr 12 15:35:35 2013:
Using:
test type: SLOW BODY
number of connections: 1000
URL: http://frontend.domain.com/Applications/xp...MaskedInput.xsp
verb: POST
Content-Length header value: 8192
follow up data max size: 22
interval between follow up data: 110 seconds
connections per seconds: 200
probe connection timeout: 3 seconds
test duration: 240 seconds
using proxy: no proxy
Fri Apr 12 15:35:35 2013:Test ended on 23th second
status: Cancelled by user

здесь мне надоело и я прервал - ибо сайт доступен и проблем с этой атакой нет.
Др. словами - сайт не сбрасывает коннекты, а просто их игнорит 60сек (дефолтное ожидания между чанками, в теле)
сайт полностью доступен (см. кол-во соединений и статус)
ЧТД

 

Т.е. реверс прокси спасает?

 

Т.е. реверс прокси спасает?

именно

Добавлено: сравниваем с прежним поведением, но еще раз оговорюсь - я не знаю доминошных способов (может что-то в ини можно покрутить) и в паблике я не встречал защиты...
пробовал нек. публичные сервера домины (хотя это и не совсем правильно ), не знаю что их защищает, но они тупо сбрасывают соединения (правда, оставаясь доступными)
такое поведение считаю неправильным! соединения просто не должны мешать (как будто их нет)
на своих (корпоративных) порталах стоят ИИС и у них поведение подобно как с реверспрокси (не сбрасывают соединения), но хуже по картинке... хотя они может прикрыты балансировщиками (реверспроксями)

 

ngnix, апач в качестве реверса лег

 

дефолтный апач плохо держит внештатные нагрузки, апач в основном для исторически сложившихся приложений...
для меня nginx предпочтителен, да и изначально он замышлялся как легкий фронтэнд (в отличии от апача)

 

наверное, я сходу не нашел пример реверса виртуальных серверов с ssl без привязки к ip.
Придется искать)
З.Ы. мдя...лучше надо было искать) http://nginx.org/en/docs/http/configuring_https_servers.html

 

с ssl есть нек. особенности...
-если ставим nginx как фронтэнд для неск. серверов - надо сайт сертификат, кот. нужно всосать в кажный домино
-если ставим самоподписанный - надо конвертить доминошные сертификаты в "нормальные", либо изначально создавать нормальные, а их всасывать в домину

Добавлено: из домины надо так http://labs.groupwave.be/index.php/2009/08...ate-for-apache/
по второму варианту завести кол-во сайтов равных кол-ву бэкэнндов, и фронтэнды должны иметь название такое же (хоста), как и бэкэнд