Доступен (http://www.apache.org/dist/httpd/Announcement2.2.html) релиз Apache 2.2.20 (http://www.apache.org/dist/httpd/), в котором устранена уязвимость (http://www.opennet.me/opennews/art.shtml?num=31582), позволяющая удаленно инициировать отказ в обслуживании из-за исчерпания всей доступной памяти. Кроме того, в новой версии устранены (http://www.apache.org/dist/httpd/CHANGES_2.2.20) недоработки в mod_filter, mod_authnz_ldap и mod_reqtimeout.
Приводившая к DoS-уязвимости ошибка связана с тем, что при обработке запроса, содержащего большое число диапазонов (например, "Range:bytes=0-,5-1,5-2,5-3,...,5-1000") в сочетании с использованием gzip-сжатия отдаваемого контента, расходуется слишком много памяти. Например, если в заголовке Range передана тысяча диапазонов, то Apache пытается отдельно сжать каждый диапазон, выделяя для каждой операции избыточный по размеру буфер. Решение проблемы реализовано довольно спорным способом: если сумма всех диапазонов больше оригинального файла, заголовок Range игнорируется и отправляется полный файл.
URL: http://www.apache.org/dist/httpd/Announcement2.2.html
Новость: http://www.opennet.me/opennews/art.shtml?num=31640
Эээ... Это значит если я найду где-то N-мегабайтный файл, то по-прежнему можно получить проблемы?
Это значит, что к _выкачиванию порна эта уязвимость совершенно не относится.
Ну почему же, если попросить 99.9% порнофайла - проверка не сработает, а вот тормознуть апач видимо получится. Так что у админа тоже будет порно, только с серваком в главной роли.
Одмин раздающий avi/wmv через сжатие gzip-ом на ходу в апаче... уже делает что-то не так.
И это они называют устранением DoS-уязвимости?
> И это они называют устранением DoS-уязвимости?А patch же. Ж-J Пластырем залепили и ладно.
> И это они называют устранением DoS-уязвимости?Учтя что опач на раз выносится их же собственным ab2 до состояния "форкаю 1000 процессов, пытаясь в перерывах хоть кого-то обслужить" - им к DoS явно не привыкать :)))
>> И это они называют устранением DoS-уязвимости?
> Учтя что опач на раз выносится их же собственным ab2 до состояния
> "форкаю 1000 процессов, пытаясь в перерывах хоть кого-то обслужить" - им
> к DoS явно не привыкать :)))Вообще-то у него в настройках есть параметры, регулирующие кол-во процессов. И эти параметры надо крутить до тех пор, пока апач не перестанет выноситься их же собственным ab2...
> Вообще-то у него в настройках есть параметры, регулирующие кол-во процессов.Зарегулировали, допустим. Теперь ab2 (ну или кто там еще) просто заузурпирует себе всех доступных воркеров (если качать в час по чайной ложке, можно узурпировать воркера в персональное рабство на длительный срок). Сервак может и не упадет по OOM, но пользователи все-равно на сайт не попадут, только на этот раз уже потому что им воркеров не достанется.
Скажите, а вас как пользователя сильно утешит что апач на вас забил не потому что ему памяти не хватило, а потому вам воркеров не досталось? :)
Да. Потому что ssh есть в таком случае. Ну и всякие mod_qos как и лимиты фаервола никто не отменял. И, кстати, nginx + php (fcgi) поведет себя схожим образом, не вижу тут проблем апача.
> Да. Потому что ssh есть в таком случае.И чем он тут поможет? Юзерам по нему содержимое сайта не отдашь и мерзостные свойства апача под нагрузкой - не улучшишь.
> Ну и всякие mod_qos как и лимиты фаервола никто не отменял.
Ваш щит - из картона. И протыкается простым карандашом. Ну вот например простой карандаш для борьбы с тупыми админиами: просто и брутально, "torify ab2". Одна строка. Две программы. По зубам любому пятиклашке способному загрузиться с ливцд. Куда после этого идут ваши лимиты на фаере и как вы вон те 100 конекций отличите от 100 легитимных хомяков?
> И, кстати, nginx + php (fcgi) поведет себя схожим образом, не вижу тут проблем
> апача.Ну как бы он на случай опы умеет довольно грамотное кеширование, так что если жизнь прижала, школьнички наглеют или вы просто попали под хабраслэшдотлорэффект - можно подзаморочиться кешированием и во многих случаях избавиться от дергания пыха на каждый пшик. А вот в таком режиме оно и гигабит влегкую прогрузит. Тут уже школьничек как максимум канал себе прогрузит, но серваку все это будет фиолетово. Все-равно у сервака в ДЦ около какого-нибудь из IXов канал лучше чем у большинства школьников вот так сходу доступно без существенных затрат ;).
>Ну вот например простой карандаш для борьбы с тупыми админиами: просто и брутально, "torify ab2". Одна строка. Две программы. По зубам любому пятиклашке способному загрузиться с ливцд. Куда после этого идут ваши лимиты на фаере и как вы вон те 100 конекций отличите от 100 легитимных хомяков?Для (Максим - тут жестко - но правда!) - для _ТУПЫХ_ салаг - например ты увидишь что один основная нагрузка идёт с одного IP.
Тупые админы как спали - так и спят потому как таких прыщавых хацкеров обрабатывают тупые же скрипты :) Одмины просыпаются когда что то серьёзное приходит, а не ты :)PS: Это не значит что индеец сам по себе вас защитит. Ну дык и nginx применённый безмозгло "только и может что 502 ошибку показывать" :)
> Для (Максим - тут жестко - но правда!) - для _ТУПЫХ_ салаг
> - например ты увидишь что один основная нагрузка идёт с одного
> IP.
> Тупые админы как спали - так и спят потому как таких прыщавых
> хацкеров обрабатывают тупые же скрипты :) Одмины просыпаются когда что то
> серьёзное приходит, а не ты :)
> PS: Это не значит что индеец сам по себе вас защитит. Ну
> дык и nginx применённый безмозгло "только и может что 502 ошибку
> показывать" :)Вот да, + много. У меня есть, в частности, скрипты которые постоянно анализируют посетителей и если поведение явно отличается от нормального - добавляет его стоп-лист на некоторое время.
> постоянно анализируют посетителей и если поведение явно отличается от нормального -
> добавляет его стоп-лист на некоторое время.Дон Кихот, залогиньтесь!
>> постоянно анализируют посетителей и если поведение явно отличается от нормального -
>> добавляет его стоп-лист на некоторое время.
> Дон Кихот, залогиньтесь!Я, в отличии от вас залогинен. Надеюсь, мой рабочий email asamorukov at ebay.com даст вам понимание степени никомуненужности сайтов с которыми я работаю. Привет )
> Для (Максим - тут жестко - но правда!) - для _ТУПЫХ_ салаг
> - например ты увидишь что один основная нагрузка идёт с одного IP.Так при помощи же указанного выше tor (продайте штаны, купите очки) или там уймы публично доступных проксиков даже салага из третьего класса может спокойно превратить свой 1 айпи в сотни разных (внезапно!). Если что, идея с размазыванием через tor была подсмотрена на примере реальной атаки каким-то додиком на ветряную мельницу^W^W апач. Когда его по ипу накрыли - он пришел через TOR с пачки айпи сразу, в пересчете на 1 айпи активность мизерная. А вот банить все tor exit nodes уже гораздо более интересно и неплохо учит всяких недоумков скиллам администрирования. Или оставляет их с трупиком опача на неопределенный срок, на усмотрение атакующего :). В принципе бан именно tor exit nodes еще можно как-то автоматизировать. От проксей - уже сложно. И любой ламер может надергать список из 100500 публичных прокси, просто спросив у гугла про это :). Ну будет не "torify ab2" а что-то типа "socksify ab2". Вам сильно легче станет? :)). Впрочем такой же эффект достигается и вполне добронамеренной публикацией ссылки на популярном ресурсе. Если приходит много народа, апач традиционно умирает.
> Тупые админы как спали - так и спят потому как таких прыщавых хацкеров
> обрабатывают тупые же скрипты :) Одмины просыпаются когда что то
> серьёзное приходит, а не ты :)Ну поскольку я к вам с атаками не приходил (я вообще относительно мирное существо, которое обычно на другой стороне баррикад) - оставим ваши понты и домыслы на вашей совести. Тем не менее, я имею наглость полагать что если я возжелаю завалить апача не подпертого целой фермой мощных серверов - скорее всего ему придется туго.
Вообще, организовать относительно много запросов на сервер с разных адресов - не так уж и сложно. Любая дырка на популярном сайте позволяющая свой JS и вот уже толпа хомяков пинает вас в цикле. Если вам сотни хомяков начнут в цикле запросы лупить, апач форкающий по процессу на хомяка просто умрет :).
> PS: Это не значит что индеец сам по себе вас защитит.
Он бы себя для начала защищал. А то наоборот мне почему-то его защищать приходится вечно. За что он и снискал несимпатии. Неповоротливый утюг, довольно неэффективно жрущий ресурсы.
> Ну дык и nginx применённый безмозгло "только и может что 502 ошибку показывать" :)
Хаха, нжинкс не виноват в подыхании бэкэнда :). Чаще всего с таким сообщением откидывает коньки опять же апач за оным. А нжинкс как раз живой - он это сообщение и выдает :)
> Хаха, нжинкс не виноват в подыхании бэкэнда :). Чаще всего с таким
> сообщением откидывает коньки опять же апач за оным. А нжинкс как
> раз живой - он это сообщение и выдает :)Сегодня же первое сентября! Откройте для себя, наконец:
1) Чем отличается динамика от статики.
2) Сравните производительность apache + mod_php и nginx + fastcgi php
3) откройте для себя, что у индейца более одного mpm. И тредовый не плодит по форку на каждый чайлд (сюрприз!!) и тоже работает с пхп через mod_fastcgi.
4) Для разных решений - разные инструменты. Например, постройте-ка svn+http сервер на нжингс. Или вебдав шару. Или много чего еще подобного. Тот же security context per host.
5) От того, что "нжинкс не виноват в подыхании бекенда" - пользователю не легче. Если система не сбалансирована - fastcgi сервер точно так же ляжет, и от 502 таймаут пользователь совершенно не обрадуется, ога.Ну и да, от вашей "несимпатии" как-то апачу не холодно ни жарко. Как и нжинсксу, впрочем.
> 1) Чем отличается динамика от статики.Внезапно, большая часть динамики запросто становится статикой. Хотя-бы временно. Есть сильно некоторые случаи когда это не так но они специфичны и там это отдельная головная боль.
> 2) Сравните производительность apache + mod_php и nginx + fastcgi php
Первое - напрочь сольется на статике, если не защищать костылями. А на динамике будет более-менее однохренственно, плюс-минус лапоть (пых и в африке пых). Только у нжинкса еще есть довольно читерский кеш, которым можно попробовать сделать динамику немного похожей на статику при ее отдаче :)
Дубовый пример. Пусть скрипт показывает время hh:mm в момент генерации страницы. Часы, типа. Динамика? Вероятно. Кешируется перманентно влобовую? Нет - время начнет завирать! Пусть на сайт пришло 100 пользователей в секунду. Зачем на всех 100 дергать скрипт и системные вызовы "сколько время?!" 100 раз за секунду, если можно 1 за минуту дернуть скрипт и сисколы для 1 юзера, а остальным целую минуту из кеша готовую пагу как статику отдать, с идентичным результатом? Главное чтобы кеш вовремя аннулировался - тогда никто и не заметит подвоха :)
> 3) откройте для себя, что у индейца более одного mpm. И
> тредовый не плодит по форку на каждый чайлд (сюрприз!!)Насколько я помню, он треды дергает на каждый запрос вместо процесса. Это чуть полегче, но принципиально картина не меняется (тред вместо процесса - шило на мыло). Да еще какие-то проблемы были. Насколько я понял оно вообще какое-то полуэкспериментальное, чтоли. И сто лет таковым и остается. А нжинкс вообще тредами не злоупотребляет - это машина состояний. Поэтому ему до фени сколько там пользователей: на их запросы по треду или процессу не заводится, и на запрос по треду и процессу не выделяется. Для статики такой подход вообще единственно разумный, имхо.
> и тоже работает с пхп через mod_fastcgi.
Я его с этим позравляю, правда я так и не понял - в каком месте наступает epic win. C нжинксом момент наступления оного ощущается очень хорошо :)
> 4) Для разных решений - разные инструменты. Например, постройте-ка svn+http сервер на нжингс.
Не страдаю некрофилией, извините. В смысле, мне не нужен SVN. Ни с апачем, ни без апача. Потому что git гораздо удобнее, быстрее, содержит полную копию репа локально и не зависит от какого-то центрального сервака. Да еще если на соседнюю новость посмотреть, можно заметить что у него есть отличный плюс: даже если все сломали злые хакеры, затолкать в git что-то задним числом - нельзя, а новым коммитом - паливно. SVN на фоне git выглядит столь же архаично как деревянная повозка на фоне последнего концепт-кара.
> Или вебдав шару.
Вебдав в нжинксе *есть*. Правда, модуль довольно урезанный, да. В случае чего есть lighttpd, наконец :). Тоже легкий, быстрый и машина состояний :P. И webdav там вполне нормально вроде реализован. А таскать статичные файлы апачем, что с вебдавом что без - затея для мазозистов.
> Или много чего еще подобного. Тот же security context per host.
Не заморачивался таковым, ничего не скажу. Реалистичный пример использования можно в студию? Чтобы можно было прикинуть - а почему, собственно, это так нереально, и было понятно - какая цель преследуется.
> 5) От того, что "нжинкс не виноват в подыхании бекенда" - пользователю
> не легче. Если система не сбалансирована - fastcgi сервер точно так
> же ляжет, и от 502 таймаут пользователь совершенно не обрадуется, ога.С нжинксом в половине случаев можно "дешево и сердито" кеш воткнуть и fastcgi сервер вздохнет свободно. А опач не умеет такой умный кешинг, внезапно. И вообще тормозной утюг при отдаче статики.
> Ну и да, от вашей "несимпатии" как-то апачу не холодно ни жарко.
> Как и нжинсксу, впрочем.Капитан, это вы?!
>> Да. Потому что ssh есть в таком случае.
> И чем он тут поможет? Юзерам по нему содержимое сайта не отдашь
> и мерзостные свойства апача под нагрузкой - не улучшишь.Тем, что позволит администратору "принять меры".
>> Ну и всякие mod_qos как и лимиты фаервола никто не отменял.
> Ваш щит - из картона. И протыкается простым карандашом. Ну вот например
> простой карандаш для борьбы с тупыми админиами: просто и брутально, "torify
> ab2". Одна строка. Две программы. По зубам любому пятиклашке способному загрузиться
> с ливцд. Куда после этого идут ваши лимиты на фаере и
> как вы вон те 100 конекций отличите от 100 легитимных хомяков?Тиоретег. 1) если уж через тор вас можно задосить то вам уже никакой веб сервер не поможет. 2) вы не читали man на mod_qos. 3) запросы от тупых ботов вроде аб благополучно детектируются и сливаются в /dev/null не доходя до http сервера динамики. 4) настоящий дос делает не школота с хабров, а ботнетами и там, по большому счету, часто вообще наплевать какой у вас http сервер )
>> И, кстати, nginx + php (fcgi) поведет себя схожим образом, не вижу тут проблем
>> апача.
> Ну как бы он на случай опы умеет довольно грамотное кеширование, так
> что если жизнь прижала, школьнички наглеют или вы просто попали под
> хабраслэшдотлорэффект - можно подзаморочиться кешированием и во многих случаях избавиться
> от дергания пыха на каждый пшик."хаброэффект", слова то какие. Наверное еще и на рейтинг д..е, гг.
>А вот в таком режиме
> оно и гигабит влегкую прогрузит. Тут уже школьничек как максимум канал
> себе прогрузит, но серваку все это будет фиолетово. Все-равно у сервака
> в ДЦ около какого-нибудь из IXов канал лучше чем у большинства
> школьников вот так сходу доступно без существенных затрат ;).Доооо. Вот расскажи мне школьнег про кеширование динамического контента в баннерной сети или e-магазине. Обычно там максимум, что возможно - это грамотное application level caching, ну или как возможный вариант - сборка страницы с разных бекендов тем же nginx. И давай, давай, расскажи про гиг динамики с одной ноды.
Еще раз - принципиальной разницы _для динамики_ в использовании nginx + php-fpm или апаче + mod_php нет. А до них все равно лучше ставить какой либо reverse proxy, тот же nginx или варниш. Последний для этих целей (имхо) много удобнее, так как конфигурация намного читаемей выходит из-за особенностей работы varnish.
> Тем, что позволит администратору "принять меры".Так это, по хорошему предотвращать пи---ц хорошо бы слегка до того как он уже наступил.
>> с ливцд. Куда после этого идут ваши лимиты на фаере и
>> как вы вон те 100 конекций отличите от 100 легитимных хомяков?
> Тиоретег. 1) если уж через тор вас можно задосить то вам уже
> никакой веб сервер не поможет.Чего - тиоретег? Я как раз такую атаку и видел не так давно. Просто как топор, и выкашивает апача на обычном серваке к чертям собачьим. Валится шитец через тор от стандартных утилсвов - кто-то явно освоил их запуск через torify :). Там много траффика не надо - главное соединения занять. А это даже через тор или вечно перегруженные проксики катит.
> 2) вы не читали man на mod_qos.
С нжинксом это нахрен не надо: ему такое до балды и без всяких костылей и их манов. Ну вот вы и читайте маны на костыли для апача.
> 3) запросы от тупых ботов вроде аб благополучно детектируются и
> сливаются в /dev/null не доходя до http сервера динамики.Круто, круто. А если воткнуть нжинкс с кешированием - то там и вообще сервер динамики вздохнет свободнее, даже если это будет 100500 хомяков ака "хабр-лор-слэшдот-аэффект". А нагрузочная способность апача настолько дрянь что анонимусы обнаглели настолько что топчут его почти голыми руками, просто запустив в браузере js-loic, который честно долбит опач запросами. Судя по тому что они это сделали - апач даже столь ламерским методом валится. По сути несколько обезьян F5 на сайте зажимают, примерно то же самое по смыслу :)
> 4) настоящий дос делает не школота с хабров,
> а ботнетами и там, по большому счету, часто вообще наплевать какой у вас http сервер )Ну если ботнет большой и способен засрать гигабит - то да, попадос. Но такое внимание еще надо чем-то заслужить. Это требует затрат заметных бабла и/или палит ботнет. Тем не менее, почему-то ряд сайтов будучи досанутыми до состояния почти незагружабельности - резко меняли опач на нжинкс и тут же оживали. Просто наблюдение :).DoS бывают разные. На апача часто делают именно атаку нацеленную на исчерпание ресурсов. Это в 100500 раз проще чем гигабит прислать и делается на коленке из подручных средств любым пионером. Тогда как ботнет способный влить гигабит флуда и всерьез положить канал в ДЦ рядом с IX - на дороге не валяется.
> "хаброэффект", слова то какие. Наверное еще и на рейтинг д..е, гг.
С ником анонимуса? На рейтинг? Лол! :)))
> Доооо. Вот расскажи мне школьнег про кеширование динамического контента в баннерной сети
Ыыы :)) Может вы и баннеры отдаете апачем? Ну озвучьте адреса этой помойки? Надеюсь школьнички потестируют на ваших опачах указанные командочки [не люблю тех кто срет в сети] :)
> или e-магазине.
Не вижу особых проблем закешировать бОльшую часть типичного магазина на поблочном уровне или типа того. Все вообще - разумеется не выйдет. Но действий когда реально надо генерить динамику в интернет-магазинах, дергать БД и прочая - не так уж много. И их можно отсечь от ботов например потребовав регистрацию для работы с корзиной и прочая и просто заворачивая нерегистренных юзеров с такими запросами. Что сделает жизнь ботов намного менее скучной, если их целью было нагрузить сервер динамики и БД :)
А сам по себе список товаров и прочее - относительно статичная сущность, например. Кеширование на допустим минуту никто и не заметит, а вот запрос на перегенерацию страницы раз в минуту - куда лучше чем запрос на перегенерацию страницы 100500 юзерами сразу, одним махом.
> разных бекендов тем же nginx. И давай, давай, расскажи про гиг
> динамики с одной ноды.Да зачем вам гиг динамики? Оставить тяжелые операции доступные только реганым юзерам, если уж вас атакуют ;). Если под каким-то аккаунтом наглеж - ну вынести аккаунт. А нереганым вообще урезать тяжелые операции. Пусть с кешом побольше общаются.
Могу зато рассказать как видел как досили интернет магазины ламерскими кучками запросами к апачу и они падали. После чего конторы почему-то резко втыкали нжинкс и сайты оживали. Всего лишь наблюдение за жизнью сайтов ;)
> Еще раз - принципиальной разницы _для динамики_ в использовании nginx + php-fpm
> или апаче + mod_php нет. А до них все равно лучше ставить какой либо reverse
> proxy, тот же nginx или варниш.Нжинксу не требуется реверс перед ним. Он сам отличный реверс и отгружалка статики, собссно. А настройка и майнтенанс (nginx + php) выглядит как-то симпатичнее чем (frontend + apache + php). В каких-то дико нагруженных системах может некий лоадбалансинг и будет иметь смысл но тогда наверное логично его делать сразу DNSом например, чтоб юзеры размазались по фронтэндам и грузили их все равномерно.
> Последний для этих целей (имхо) много удобнее, так как конфигурация намного
> читаемей выходит из-за особенностей работы varnish.Ничего не скажу особо, т.к. не пробовал. Могу лишь отметить что на читаемость конфига нжинкса я не жалуюсь, как по мне - и читаемо и удобоваримо вполне :). И админить один нжинкс + пых к нему как-то попроще чем фронт+апач+пых, что очевидно просто глядя на число компонентов цепочки. Ну и внедрежка нжинкса на большой числе нагруженных сайтов как бы намекает что он не лыком шит :)
p.s. очередные лучи ненависти вордфильтру. Я так и не понял что за слово его смущает.
>> Вообще-то у него в настройках есть параметры, регулирующие кол-во процессов.
> Зарегулировали, допустим. Теперь ab2 (ну или кто там еще) просто заузурпирует себе
> всех доступных воркеров (если качать в час по чайной ложке, можно
> узурпировать воркера в персональное рабство на длительный срок). Сервак может и
> не упадет по OOM, но пользователи все-равно на сайт не попадут,
> только на этот раз уже потому что им воркеров не достанется.Поставьте nginx фронтендом и не парьте людям мозг. Работа сайта при правильной настройке будет упираться в процессор, а не память и кол-во воркеров. Апач делает только свою часть работы по отдаче динамики и делает её хорошо.
> Поставьте nginx фронтендом и не парьте людям мозг.Lol! Я его поставил вообще ВСЕМ. Мне нравится.
> Работа сайта при правильной настройке будет упираться в процессор,
Epic fail! При _правильной_ настройке упираться будет в I/O скорее. В основном в дисковое, особенно если вы не Рокфеллер и потому SSD во все ддыры еще не закупились.
> а не память и кол-во воркеров.
Сдуру можно и кое-что сломать. А с какого рожна, собственно, должно в проц упираться? Особенно если включить мозг и кеширование сделать?
> Апач делает только свою часть работы по отдаче динамики и делает её хорошо.
Это спорно. В смысле, с порно, судя по новостям :))). Вообще, динамику можно и без апача как-бы отдавать. Хоть тем же нжинксом. И конфигурить 1 сервер определенно проще чем 2 разнотипных. При том второй еще и неповоротливый утюг, авторы которого к тому же выбирают какой-то очень странный метод затыкания дыр, вызывающий вопрос "что вы там курите, господа?".
>> Поставьте nginx фронтендом и не парьте людям мозг.
> Lol! Я его поставил вообще ВСЕМ. Мне нравится.Спасибо за информацию...
>> Работа сайта при правильной настройке будет упираться в процессор,
> Epic fail! При _правильной_ настройке упираться будет в I/O скорее. В основном
> в дисковое, особенно если вы не Рокфеллер и потому SSD во
> все ддыры еще не закупились.Мы тут вроде про динамику говорим, иначе зачем нам вообще апач сдался?
>> а не память и кол-во воркеров.
> Сдуру можно и кое-что сломать. А с какого рожна, собственно, должно в
> проц упираться? Особенно если включить мозг и кеширование сделать?Это уже зависит от контента, он может и не предполагать возможности кэширования. Ключевым в моём посте было указание на отсутствие жёсткой зависимости от кол-ва памяти.
> Мы тут вроде про динамику говорим, иначе зачем нам вообще апач сдался?А динамики на самом деле не так уж много. И значительная ее часть сводится кешированием до статики. Не говоря уж о кешировании скриптов в компиленом виде и прочая.
> Это уже зависит от контента, он может и не предполагать возможности кэширования.
Контента который реально динамический и не терпит даже 1 секунды кеширования в природе не так уж и много.
> Ключевым в моём посте было указание на отсутствие жёсткой зависимости от
> кол-ва памяти.Практика почему-то показыват что атакующие часто выносят апачи именно выжрав всю память или заняв все воркеры. Это проще всего, не требует крутых ресурсов у атакующего и доступно даже совсем малобюджетному школьнику, поэтому под такую атаку можно попасть даже "для лулзов" или "потому что Васе не нравится этот сайт".
>> Мы тут вроде про динамику говорим, иначе зачем нам вообще апач сдался?
> А динамики на самом деле не так уж много. И значительная ее
> часть сводится кешированием до статики. Не говоря уж о кешировании скриптов
> в компиленом виде и прочая.дадада. Вот расскажите мне, расскажите. online аукцион или магазин несомненно можно эффективно закешировать нжинксом.
>> Это уже зависит от контента, он может и не предполагать возможности кэширования.
> Контента который реально динамический и не терпит даже 1 секунды кеширования в
> природе не так уж и много.Дохрена. Аякс запросы, например. Другой пример из жизни - поисковик на сетевом ресурсе по доставке еды - адресов бесконечность, повторяются они крайне редко а время жизни информации - крошечное. В итоге хит-мисс у вас будет практически нулевой. Вы вообще работали на хайлоад проектах или только на опеннете сидим?
>> Ключевым в моём посте было указание на отсутствие жёсткой зависимости от
>> кол-ва памяти.
> Практика почему-то показыват что атакующие часто выносят апачи именно выжрав всю память
> или заняв все воркеры. Это проще всего, не требует крутых ресурсов
> у атакующего и доступно даже совсем малобюджетному школьнику, поэтому под такую
> атаку можно попасть даже "для лулзов" или "потому что Васе не
> нравится этот сайт".Я уже писал вам сходу кучу задач где без апача не обойтись. Что не отменяет nginx перед ним. То, что вы говорите - это тупые скрипт кидди, и обрубается это тысячей способов - от mod_security до реверс проксей поумнее. Серьезный дос делается совсем не так, ога.
> дадада. Вот расскажите мне, расскажите. online аукцион или магазин несомненно можно эффективно
> закешировать нжинксом.Значительные куски - можно. А почему, собственно, нет? Ну вот например при просто браузинге списка товаров - страница как правило не меняется. Зачем, спрашивается, генерить ее 1000 раз в секунду? Она 1000 юзеров покажется одинаковая :).Ну и так далее. Если задействовать мозг - окажется что довольно много всего можно сбагрить на сервер отдающий статику/кеш.
> Дохрена. Аякс запросы, например.
С этими да, все сложнее. Хотя опять же - и в этом случае кеши могут быть полезны.
> Другой пример из жизни - поисковик на сетевом ресурсе по доставке
> еды - адресов бесконечность, повторяются они крайне редко
> а время жизни информации - крошечное. В итоге хит-мисс у вас
> будет практически нулевой.Да, именно поиск такого плана кешировать - дохлый номер ;). Только вот поисковые запросы типа поиска в магазине/на форуме на большинстве сайтов считаются тяжелыми и потому специально огораживаюься, т.к. кроме всего прочего надолго затыкают базу. Можно конечно сделать как у гугля распределенно все - тогда хрен его такое заткнешь, но это уже для очень больших и кастомных актуально.
> Вы вообще работали на хайлоад проектах или только на опеннете сидим?
Именно на крупных - нет. Хотя было бы жутко интересно. А несколько обычных серверов зашивающихся под нагрузкой на раз пришли в себя путем быстрой и сердитой замены апача на нжинкс + немного кеширования. Я бы не сказал что это какой-то жуткий hi-load, скорее просто удачная оптимизация довольно средних серваков. А вы занимаетесь крупными проектами и хайлоадом? И чем для вас так хорош оказался апач, собственно?
> Я уже писал вам сходу кучу задач где без апача не обойтись.
В каком месте в постановке задачи написано "требуется апач"? Не вижу. Вон гугл по всей планете ищет. Без апача почему-то.
> Что не отменяет nginx перед ним.
Тоже вариант. Правда как по мне - админить 2 сервака менее прикольно чем 1.
> То, что вы говорите - это тупые скрипт кидди,
Как ни странно, апач в его родном дефолтном виде и без костылей типа фронтэндов на раз выносится таковыми. Более того - даже у не сильно глупых админов с довольно мощным сервером вынести апач не составляет особой проблемы. Что хуже - тупое свойство опача побуждает админов которым надо грузить жирные файлы лимитировать число соединений до совершенно тупых значений.
> и обрубается это тысячей способов - от mod_security до реверс проксей
> поумнее. Серьезный дос делается совсем не так, ога.На серьезный надо бабки тратить. А этот делается десяткой обезьян зажавших в браузере F5, ну или пнувших JS-LOIC. Небольшая такая разница в цене атаки получается. Никто не будет гигабит в секунду лить бесплатно. А F5 в браузере вдавить десяток-другой дятлов может и просто для прикола, равно как и ab2 пнуть, даже с пропуском через проксики или тор (для этого ума и денег тоже особо не надо). И, внезапно, я видел массу атак ориентированных именно на исчерпание ресурсов апачем (или полное выюзывание пула его воркеров, в зависимости от степени тупизны админа). Таким манером на моей памяти почему-то неоднократно валили интернет магазины и прочая (после чего у них внезапно появлялся нжинкс, как минимум фронтэндом, хаха).
> Поставьте nginx фронтендом и не парьте людям мозг. Работа сайта при правильной
> настройке будет упираться в процессор, а не память и кол-во воркеров.
> Апач делает только свою часть работы по отдаче динамики и делает её хорошо.Или лайти. Или Squid as reverse proxy. Или Varnish (-этот просто зверь!) или ещё 100500 вариантов.
Но только вот ведь какое дело - кому надо давно сделали (лет тому же креведко не намного меньше чем индейцу). а плачь школоты есть неизбежность процесса обучения. Как говорится пока пуд корок не съешь .... :-)
> расходуется слишком много памяти.По-моему, в случае апача с его форками на каждое соединение это и без всяких range та еще проблема. Можно просто открыть кучу соединений но ничего по ним не качать особо, что требует очень немного ресурсов у атакующего хоста. А апач будет держать для вас сотни процессов, кушая при этом дофига памяти. Ну или при лимитировании числа процессов - он забьет на обслуживание других пользователей, т.к. все воркеры будут заниматься держанием соединений, что тоже неплохо. Какая разница, как именно положить апач - съев всю память или заняв на себя все воркеры? Для юзеров результат одинаков: сайт недоступен.
А вы и статику mpm_prefork'ом обслуживаете? Ню-ню.
> А вы и статику mpm_prefork'ом обслуживаете? Ню-ню.Нет, конечно - я нжинксом все делаю. Но почему-то 90% виденых сайтов на опаче нисколько не стесняются так отдавать чуть ли не исошки, не говоря о многомеговых фотках или чем там еще. И порой очень хочется придушить админов сайтов за чебурашью скорость скачки, лимиты на число соединений, тормозные ответы сервака и прочие костыли и тупняки нацеленные на то чтобы апач не сыграл окончательно в ящик.
т.е. по вашему мнению недоступность сервиса и выполнение кода злоумышленника на сервере это одно и тоже?
> т.е. по вашему мнению недоступность сервиса и выполнение кода злоумышленника на сервере
> это одно и тоже?Не понял где вы хоть слово про выполнение кода нашли вообще. Что в новости, что в коментах.
> если сумма всех диапазонов больше оригинального файлаО, то-есть, если я попрошу только 99% от файла, даже огромного, мне за это ничего не будет? Делаем ставки через сколько минут появятся доработанные варианты скриптов обходящих такую грамотную "защиту" :)))
>> если сумма всех диапазонов больше оригинального файла
> О, то-есть, если я попрошу только 99% от файла, даже огромного, мне
> за это ничего не будет? Делаем ставки через сколько минут появятся
> доработанные варианты скриптов обходящих такую грамотную "защиту" :)))Защита на самом деле грамотная. Суть DoS в том, что можно было попросить 100500 копий файла сразу, т.е. заставить апач сбуферизовать и отдать пару гиг из килобайтного файла. Это fail. А то, что можно из легитимного файла попросить 99% тысячей range - это на расход памяти с предложенным и внедренным патчем уже не особо влияет, и по трафику вполне эквивалентно запросу 99% одним range, и даже меньше запроса целого файла. Так что все нормально.
Такое впечатление, что кто-то немного суть уязвимости не понял. Расход памяти на обработку range - это была вторичная проблема, первичная - в возможности заставить апач отдать 100500 копий одного файла. Кстати, у того же nginx (если он конечно Range поддерживает согласно стандарту, и если он не "чистый proxy"), может обнаружиться такая же проблема - надо пробовать. К сожалению, сам уже не попробую - со всех площадок вынес его, и заменил на минималистичную сборку Apache с mpm_worker - поддержка keepalive на прокси-соединениях оказалась нужнее.
Т.е., теперь если запросить по отдельности 99 байт файла из 100, то не породится 99 форков Апача?