Andreyka, у меня тоже этот вопрос возник.
да и что там вообще можно было бы настроить ? сложный алгоритм вытеснения в ядре никто делать не будет, потому как там нужен достаточно простой.
Обычный кеш на основе LRU. Там настраивать нечего.
Есть какие-то параметры, которые играют роль в распределении памяти между программами, свопом, кешем inode и кешем файлов, но для случая раздачи файлов с nginx это вообще не важно. Вся память уходит под кеш файлов.
Размеры ответа, возможно, зависели от ошибок выдаваемых php.
В файле foto_107953.jpg другой мини-шелл, который скачивает и создает уже php-файл 1234567.php. Может быть таким образом скрипт для дампа базы закачали для большего удобства если предыдущий шелл чем-то не устроил.
а этот файл проверили? лучше даже во всех картинках сразу код поискать.
Вот засунули вы папку upload в специальный location, но /favicon.ico/.php ведь им не покрывается?
Стоит разобраться почему cgi.fix_pathinfo = 0 не помог.
Проверьте, например с помощью функции phpinfo() из обычного скрипта действительно ли эта настройка отключается. Может быть php.ini используется не тот, который вы правили или что-то еще нужно перезапустить.
или я уже предлагал третий вариант. но alw ведь типа админ. заказчиком быть западло :)
Но есть довольно много способов неправильно настроить вебсервер. Лучше проверить на практике.
Кстати, попробуйте на короткое время эту настройку включить. Разве не интересно узнать, удалось ли им запустить шелл ?
В некоторых конфигурациях можно вызвать.
Не похоже на шелл, но похоже на тест исполнения. Шелл залили бы потом после проверки. А может даже и залили в другой url.
Вам самим стоит проверить как настроен сервер и исполняет ли этот код:
Снова создайте такой же файл png в том же каталоге с содержимым
123<?php phpinfo(); ?>
Скачайте файл качалкой по тому самому адресу. Просмотреть из браузера его очевидно не получится.
Убедитесь, что php-код внутри скачанного файла не заменился на результат выполнения php.
madoff, я тебя далеко не всегда понимаю. вот и сейчас.
о, воронежские хакеры.
Reise, учитывая код ошибки - 200 и целых 181009 байт в ответе, надо бы проверить внутри файла наличие php-кода в файле /uploads/fotos/foto_110011.png
Убедиться, что сервер не исполняет такие файлы png как php. Тут искали типовую ошибку в галереях.
Соберите другие запросы от этих IP и проанализируйте. Может быть там были и другие типовые уязвимости и какая-нибудь из них все же нашлась и была использована.
что сразу тупее? у них вместо nginx есть lighttpd, varnish и, на худой конец, squid.
нет. гораздо интереснее.
возня с настройкой nginx, его кешем, написанием программ и ошибками в этих программах исключается
Слишком уж поверхностный анализ.
точно скажу : раз диск так сильно занят, то значит не хватает кеша.
Кроме дальнейшего увеличения ОЗУ и дисков в raid, можно еще соорудить кеширующий чтение достаточно большой ssd-диск. Это не очень популярная техника, но могу вам настроить.
