Comments 42
Протестируем его на youtube или myspace? :)
+2
Позавчера уже было исправлено: www.debian.org/security/2010/dsa-1987
+1
Блинн…
Работает, обновился, спасибо!!!
Работает, обновился, спасибо!!!
0
Еще вчера пререлиз 1.4.26 был с исправлением blog.lighttpd.net/articles/2010/02/03/pre-release-lighttpd-1-4-26rc1-r2710
+1
Еще 3 дня назад эксплоит спрятали
redmine.lighttpd.net/issues/2147#5
Обновлено stbuehler 3 дня назад
Значение slowclient.sh параметра Файл удалено
а Бага с Начало: 06.01.2010
redmine.lighttpd.net/issues/2147#5
Обновлено stbuehler 3 дня назад
Значение slowclient.sh параметра Файл удалено
а Бага с Начало: 06.01.2010
+1
Когда то давной был подобный баг на урове tcp стека фри. Модема хватало чтоб забить все таймаутами и подвесить сервак.
История движется по спирали.
История движется по спирали.
0
Да, господа! Будьте бдительны — используйте nginx!
+1
Опа! Приплыли…
0
А где шутки про эстонских хакеров?
+12
Решето!
-1
Эт ж SlowLoris :)
Странно, но ha.ckers.org/slowloris/ заявляет что проверяли lighttpd и не смогли его тормознуть.
Upd: хм, а тут ha.ckers.org/blog/20090617/slowloris-http-dos/
karavelov Says:
June 19th, 2009 at 11:22 am
I have tested this DOS attach against lighttpd and nginx. Out of the box both servers are vulnerable (despite the note in the announcement that lighttpd is not vulnerable, just use enough number of connections). Nginx could be configured to not be affected by this type of attacks.
Upd2: здесь правда в POST-засылаемом файле баг
Upd3: никто еще deflate не атаковал на отправке серверу? ;) Если он, конечно, бывает
Странно, но ha.ckers.org/slowloris/ заявляет что проверяли lighttpd и не смогли его тормознуть.
Upd: хм, а тут ha.ckers.org/blog/20090617/slowloris-http-dos/
karavelov Says:
June 19th, 2009 at 11:22 am
I have tested this DOS attach against lighttpd and nginx. Out of the box both servers are vulnerable (despite the note in the announcement that lighttpd is not vulnerable, just use enough number of connections). Nginx could be configured to not be affected by this type of attacks.
Upd2: здесь правда в POST-засылаемом файле баг
Upd3: никто еще deflate не атаковал на отправке серверу? ;) Если он, конечно, бывает
+2
Кстати, рекомендую сменить значение server.tag. Я поменял на тег IIS`а, в результате теперь меня сканируют пионеры с типичными сканерами Windows серверов :)
+2
Яндекс еще не обновился? :))))
0
Я бы во всяких апачах ввел кроме таймаута (общего на запрос, а не на интервал между пакетами), минимальную скорость получения/отдачи данных. Не надо бояться рвать соединение, ибо я плохо себе представляю устройство, которое GET отправляет по полминуты (модемщики и GPRS-ники в замкадье — ССЗБ, пусть ставят прокси).
0
экий вы злобный, нельзя так. Но, кстати, модемщики и жопорезники тоже не отправляют GET по полминуты обычно, но уж если связь действительно такая хреновая, то ИМХО интернет становится неюзабельным и таких действительно можно смело рубить. Тут главное найти баланс правильный.
+1
Вот-вот, на сервере каждое соединение — это лишний процесс апача и мегабайты памяти, так что чем быстрее закрыть соединение, тем серверу легче.
0
Вы всё еще выставляете голый апач в интернет? Тогда реверс-прокси идут к вам!
+2
Прокси — это тоже мегабайты памяти, кроме того, я пока не научился nginx ставить :) И на прокси тоже, я считаю, надо ограничивать дительность/минимальную скорость отправки/получения данных.
0
по моим тестам — 24000 конкурентных пустых SSL-соединений в случае с apache2.2 съедают ~12GB памяти, те же 24000 в случае с nginx — 150-200 MB.
Только лишь установив тот же nginx перед индейцем вы уже сэкономите память, а не потратите ее, ибо все ваши пользовательские запросы будут обрабатываться меньшим количеством апачевских воркеров. Если уж совсем хочется память экономить — то проксируйте не к апачу, а к php-fpm, например. Я на линуксовом VDS-е с 64 МБ памяти легко обслуживал несколько десятков (до пары сотен в пиках) одновременных пользователей применяя nginx+php-fpm, правда php-приложение было совсем простое, но не суть. С апачем первая десятка юзеров сжирала все ресурсы по памяти.
>я пока не научился nginx ставить
Это совсем несложно, попробуйте — вам понравится!
Только лишь установив тот же nginx перед индейцем вы уже сэкономите память, а не потратите ее, ибо все ваши пользовательские запросы будут обрабатываться меньшим количеством апачевских воркеров. Если уж совсем хочется память экономить — то проксируйте не к апачу, а к php-fpm, например. Я на линуксовом VDS-е с 64 МБ памяти легко обслуживал несколько десятков (до пары сотен в пиках) одновременных пользователей применяя nginx+php-fpm, правда php-приложение было совсем простое, но не суть. С апачем первая десятка юзеров сжирала все ресурсы по памяти.
>я пока не научился nginx ставить
Это совсем несложно, попробуйте — вам понравится!
+1
Слушайте, спасибо за совет, у меня как раз есть VDS с 256Мб и там даже в спокойном состоянии MySQL с апачем сожрали почти всю память, обязательно попробую, как руки дойдут, у меня сайтики тоже нетяжелые, никаких Друпалов нет.
Насчет php-fpm смущает только то, что там есть сайтик с .htaccess с реврайтами, и придется руками эти реврайты в nginx переносить, но попробовать хочется :)
Э, и еще маленький вопрос — а nginx поддерживает несколько сайтов на одном VDS? Ну вроде virtualHosts в апаче?
Насчет php-fpm смущает только то, что там есть сайтик с .htaccess с реврайтами, и придется руками эти реврайты в nginx переносить, но попробовать хочется :)
Э, и еще маленький вопрос — а nginx поддерживает несколько сайтов на одном VDS? Ну вроде virtualHosts в апаче?
0
а nginx поддерживает несколько сайтов на одном VDS?Да, конечно.
есть VDS с 256Мбобязательно меняйте апач на php-fpm, ну и мускуль тоже тюнить нужно, попробуйте для начала взять из образца, что идет с поставкой mysql (обычно лежит тут: /usr/share/mysql/my-small.cnf) и его немного докручивать. Еще есть полезный скрипт mysql-tuning-primer, попробуйте его использовать.
0
UFO just landed and posted this here
Sign up to leave a comment.
Критическая уязвимость в lighttpd, DoS