iteX

Несколько дней назад на Full Disclosure опубликовали скрипт для доса Apache всех версий. Он малость не работоспособен, но исправить и направить его в работу дело 5 секунд.

Range поле и запрос нужны всяким менеджерам закачек, для того, чтоб не качать весь файл при обрыве связи,  а скачивать файлы с сервера с определенного места.

Скрипт посылает запрос с определенным полем range (Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,<...>,5-1299,5-1300),  апач в ответ на него собирает  из пересекающихся кусочков файла ответ,  постепенно засирая память и процессор. Если включен gzip,  то все многократно усиливается.  Вообщем в несколько запросов можно завалить крупный сервер. Что уже с успехом и делают, сайт нокии и прочие проекты на апаче это уже на себе почуствовали.

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

Как проверить на уязвимость: На сервере должен быть курл. Находим какой нить статический файл, например robots.txt и делаем следующий запрос:
curl -I -H "Range: bytes=0-1,0-2" -s vashsait.com/robots.txt | grep Partial
Если контент выдает Апач с 206 заголовком, то скорей всего сайт подвержен уязвимости.

Как защититься, есть три решения. Все, кроме ограничения длины запроса  и SetEnvIf приводят к тому, что с сайта нельзя будет докачивать статичные файлы после обрыва связи,  клиентам придется закачивать их вновь :

1. Если фронтендом nginx, и она не отдает сам статику, то запрещаем проксировать заголовок Range директивой proxy_set_header Range ""; и proxy_set_header Request-Range ""; в конфиге nginx.
2. В .htaccess прописываем
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
3. В конфигах апача есть несколько решений
   1. Если установлен mod_headers то прописываем директиву
      RequestHeader unset Range
RequestHeader unset Request-Range
      Мод можно включить командой a2enmod headers
   2. Установить лимит на размер заголовков, это может убить другие заголовки, скажем длинные куки, устанавливаем директиву с нужным размером ограничения
      LimitRequestFieldSize 200
   3. Для второй версии апача, для удаления поля, если в нем больше 5 диапазонов, прописываем директиву
      SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
RequestHeader unset Request-Range
CustomLog logs/range-CVE-2011-3192.log common env=bad-range

Вот так, защитились и ждем патчей апача и удачи.

Incoming search terms:

• requestheader unset request-range

Я тут озаботился снижением нагрузки на сервак, чтоб уж совсем все в шоколаде было. У мя фронтендом стоит nginx. Он отдает статику по расширениям картинок, джаваскриптов и тд. Если к этому правилу не подошло и файл не существует, то он отдает дальше на апач и закеширует ответ. Соотвественно апач все как обычно разруливает.

Про php-fpm и php-fastcgi знаю, не подумайте, что совсем дурак)), мне легче использовать апач, чем мучаться, например с редиректами. Время будет, может и улучшу в эту сторону.

В основном использую на сайтах вордпрессы. Соотвественно выделил два решения для снижения нагрузки:
1) Поставить eAccelerator, он сохраняет скомпилированные PHP скрипты в разделяемой памяти и запускает код непосредственно из нее.
2) Поставить на тяжелые вордпрессы плагин Really Static.

Дальше распишу подробнее об установке, php-devel, bzip и тд уже мя стоят.
Следуем этой инструкции.


cd /usr/src
wget http://bart.eaccelerator.net/source/0.9.6/eaccelerator-0.9.6.tar.bz2
tar -jxf eaccelerator-0.9.6.tar.bz2
cd eaccelerator-0.9.6
phpize
./configure --enable-eaccelerator=shared
make
make install
mkdir /var/cache/eaccelerator
chmod 0777 /var/cache/eaccelerator

Если все поставилось, то идем директорию с php.ini, у меня например /etc/php5/apache/php.ini и прописываем настройки акселераторора.

extension="eaccelerator.so"
eaccelerator.shm_size="16"
;папка кеша, с правами на запись
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
;уровень компрессии, чем болше компрессия, тем больше зарузка процессора, но меньше используемая память
eaccelerator.compress_level="5"

Перезапускаем апач и вуаля. У меня, например, нагрузка сильно упала, а использование памяти вордпрессса чуть ли не в десять раз сократилось.

Итак, скрипты кешируются, все в ажуре, но меня и это не остановило. Почему бы не сделать страницы вордпресса статичным, чтоб их отдавал только nginx, не касаясь апача.

Качаем Плагин Really Static. Распаковываем, стандартно ставим, идем в настроки плагина.
Я использую английский язык в вордпрессе, поэтому описание пунктов на инглише.

Во вкладке Source, проставляем урл нашего блога и урл к используемой теме блога.
Во вкладке Destination выбираем work with local filesystem, прописываем путь внутри файловой системы до файлов блога.
В settings можно ничего не менять, я поставил галочку в “Don’t copy any linked file”.
Дальше идем в Manual Refresh и жмем кнопку write all files.

Если выскочит ошибка, то скорей всего нет прав на запись в корень блога или неправильно его указали в настройках файловой системы.
Если все прошло ок, то в корне вашего блога образуются статичные хтмл файлы вордпресса.

Предчувствую, что у многих могут возникнуть проблемы с пермалинками, у меня такой формат “/%category%/%postname%.html”.

Плгин можно использовать что, размещать сайты на которых нет mysql, те мы наполняем блог дома, а потом размещаем статичные файлы на фтп. Из минусов, не будет доступна динамика, например комменты.

Incoming search terms:

• responses to leave a reply name (required) brisbane roofing
• really static
• wordpress eaccelerator
• wordpress nginx static