enable force cgi redirect
Enable force cgi redirect
Использование PHP как двоичного CGI это опция установки, когда, по некоторым соображениям, нет желания интегрировать PHP как модуль в программу-сервер (такую как Apache) или когда PHP будет использоваться с различными видами CGI-оболочек для создания для скриптов безопасной среды chroot и setuid. Такая инсталяция обычно обычно заключается в установке исполняемого файла PHP в директорию cgi-bin web-сервера. CERT advisory CA-96.11 рекомендует не помещать никакие интерпретаторы в директорию cgi-bin. Даже если исполняемый файл PHP используется как самостоятельный интерпретатор, PHP разработан таким образом, чтобы предотвратить атаки при таком варианте установки:
Доступ к системным файлам: https://my.host/cgi-bin/php?/etc/passwd
Информация запроса в url после знака вопроса (?) передаётся интерпретатору как аргументы командной строки CGI-интерфейсом. Обычно интерпретаторы открывают и выполняют файл, специфицированный как первый аргумент командной строки.
При вызове как исполняемый CGI, PHP не выполняет аргументы командной строки.
Доступ к любому web-документу на сервере: https://my.host/cgi-bin/php/secret/doc.html
Перенаправление может быть сконфигурировано в Apache через использование директив AddHandler и Action (см. ниже).
Обычно перенаправление в конфигурации Apache выполняется следующими директивами:
Эта опция была проверена только на сервере Apache и основывается на установке Apache нестандартной переменной окружения CGI REDIRECT_STATUS для перенаправленных запросов. Если ваш web-сервер не поддерживает способ сообщения того, является ли запрос перенаправляемым или прямым, вы не можете использовать эту опцию и обязаны использовать один из других вариантов запуска CGI-версии, из указанных здесь.
Включение активного содержимого, такого как скрипты и исполняемые файлы, в директорию документов web-сервера считается небезопасным. Если, из-за какой-нибудь ошибки конфигурации, не исполняются, а выводятся как обычные HTML-документы, это может привести к потере интеллектуальной собственности или закрытой информации вроде паролей. Поэтому многие sysadmins предпочитают устанавливать другую структуру директорий для скриптов, когда они доступны только для PHP CGI и, следовательно, всегда интерпретируются и не выводятся как текст.
Также, если недоступен метод гарантирования того, что запросы не перенаправляются, как указано в предыдущем разделе, необходимо установить doc_root скриптов, которая отличается от web document root.
user/doc.php приводит к открытию не файла под home-директорией пользователя, а файла, вызываемого
user/doc.php под doc_root (да, директории с именем, начинающимся с тильды [
как первую строку любого файла, содержащего тэги PHP. Вы также должны сделать файл исполняемым. То есть рассматривать его так же, как любой другой CGI-скрипт, написанный на Perl или sh или любом другом языке скриптинга, который использует механизм оболочки замены #! оболочки для запуска самого себя.
Если PHP установлен как CGI
Содержание
User Contributed Notes 16 notes
There was a serious vulnerability in certain CGI-based PHP setups that has gone unnoticed for at least 8 years.
This might seems obvious, but I spent 2 days on this 🙁
To use php-cgi with suexec it will be nice that each virtual host has ist’s own php.ini. This goes with :
SetEnv PHPRC /var/www/server/www.test.com/conf
Better yet, use binfmt_misc: (linux only)
echo :php3:E::php3::/usr/bin/php: > /proc/sys/fs/binfmt_misc/register
Eliminates the need for the #! at the top of the file.
If you care about security, you are better of setting
register_globals = off
enable_track_vars = on (Always on from PHP4.0.3)
Default setting for variable order is
EGPCS
(ENV VARS/GET VARS/POST VARS/COOKIE VARS/SESSION VARS)
Imagine if you are rely on ENV VAR but it was orver written with GET/POST/COOKIE vars?
One of the most common reasons why you get ‘No input file specified’ (AKA ‘the second most useful error message in the world’) is that you have set ‘doc_root’ (in php.ini) to a value which is to the ‘DocumentRoot’ defined in the apache configuration.
This is the same for other webservers. For example, on lighttpd, make sure the ‘server.document-root’ value is the same as what is defined as ‘doc_root’ in php.ini.
In response to grange at club-internet dot fr:
There are a couple of errors in the mod_rewrite directives given. I found that the following works:
I removed the = from the RewriteCond and took out the leading / from the RewriteRule.
A tip for Windows-users
I have setup a guide to installing PHP with SuEXEC in such a way that shebangs (!#/usr/bin/php4) are not needed. Hope this is of some help to you.
Add «php_value doc_root /home/user/html_docs» to each virtual host directive in httpd.conf
PHP CGI with VirtualHosts.
This is what I found out while trying to get php to work as CGI with Apache VirtualHosts.
By enabling ‘force-cgiredirects’, you *must*:
1) set ‘cgi.fix_pathinfo=1’ in php.ini
2) leave doc_root commented out (php.ini also)
If you miss item 1, the apache logs will show ‘unexpected T_STRING’ in the php binary.
If you miss item 2, you’ll only see ‘No input file specified.’, instead of the expected output.
You can then turn on the php support for a particular vhost by defining:
Action php-script /cgi-bin/php
inside the corresponding directive.
PHP works with Apache and suEXEC like this:
(Assuming that suEXEC ist allready installed and working)
Create a Link inside cgi-bin directory to make php-cgi accessable:
cd /usr/local/apache/cgi-bin
ln /usr/local/bin/php php
User exampleuser
Group examplegroup
.
PHP-scripts are now called under the user-id of exampleuser and group-id of examplegroup.
a replacement for suexec is suphp (http://www.suphp.org).
«suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter.» (from the website)
I have noticed that some people have noted that running PHP as a CGI program can run slowly compared with a compiled in module. Some have noted that they want to use FastCGI but are hesitant. I found that using the Apache 2’s CGID module was a great way to speed up performance almost to the same level as an «so»-installed PHP module but you get the added benefit of running each virtual host under it’s own user and group.
In my testing I got 44 pages per second using PHP as a module and I got roughly the same performance (within 5%) running PHP as a CGI program through CGID.
I’m sure that there’s extra RAM used for this method but RAM is as cheap as borscht anyways so it shouldn’t be a major factor when trying to speed up PHP CGI.
Как отключить _force-cgi-redirect_ в компиляции PHP?
Я работаю с PHP 7 (или пытаюсь) и остроумно пытаюсь найти способ отключить сила-CGI-редирект особенность. Неважно, что я пытаюсь PHP-CGI бинарный с этой опцией.
Я попытался добавить следующую строку в оба php.ini-разработка а также php.ini-разработка в каталоге проекта:
Это не сработало — поэтому я также добавил —отключение силы-CGI-редирект к ./ Configure командная строка — и это тоже не сработало.
Я гуглил и гуглил для решения — и не придумал ничего, кроме первой из двух вещей, которые я попробовал, и (когда я стал очень конкретным) и вторую из двух вещей, которые я попробовал.
Я знаю о рисках безопасности, связанных с отключением этой «функции», но контекст, для которого мне нужен PHP 7, не подходит для FastCGI.
Поскольку по умолчанию для сервера используется PHP 5, я могу работать только над PHP 7, если я могу сделать это как скрипт CGI, в котором первая строка:
.. и где PHP 7 находится в этом месте, потому что я скомпилировал его с —префикс = / my / home / directory / local « опция — и мне нужно, чтобы она запускалась после того, как она была вызвана таким же образом, как если бы она была вызвана сервером напрямую.
Тем не менее, я не могу этого сделать, потому что, независимо от того, что я делаю, я не могу отключить сила-CGI-редирект особенность.
Я могу заставить скрипт работать, если он вызывается с / Мой / главная / каталог / местные / бен / PHP переводчик, а не / Мой / главная / каталог / местные / бен / PHP-CGI интерпретатор — но это не помогает мне, так как это решение приводит к тому, что PHP 7 ведет себя в командной строке (небольшие, но важные различия, такие как отсутствие вывода заголовка).
НОТА: В целях тестирования (чтобы я мог видеть, что происходит не так), я также попытался написать скрипт CGI, подобный следующему (скажем, он называется «phptest.cgi»):
Вот как я узнал, что проблема была сила-CGI-редирект особенность — как и прежде, все, что я получил, было туманное уведомление о том, что произошла ошибка сервера.
Избавляемся от стандартных настроек серверов
Содержание статьи
Часто, разворачивая сервер для своего ресурса или настраивая другое ПО, мы оставляем большинство опций в конфигурационных файлах по умолчанию. Потом проект обрастает функционалом, и конфиги все реже удостаиваются внимания, превращаясь в бомбы замедленного действия, которые злоумышленник может успешно использовать. Поэтому сегодня мы рассмотрим параметры безопасности популярного серверного ПО, настройку которых лучше не откладывать в долгий ящик.
Apache
Начнем с конфигурации индейца, завоевавшего место на многих серверах в Сети. Первая настройка, которую желательно сделать, — это лишить злоумышленника возможности узнать версию Apache. Для этого существует две директивы, которые надо установить в следующие значения:
Отдельный пользователь и группа
Вторым пунктом желательно убедиться, что Apache работает под своим отдельным пользователем и группой. Если под этим же пользователем будет работать, например, СУБД, то в случае компрометации веб-сервера злоумышленник сможет получить доступ и к базе данных.
Корневая директория
Затем необходимо убедиться, что файлы, расположенные вне корневой директории, не обрабатываются веб-сервером. Если предположить, что все сайты на сервере находятся в одной директории (допустим, /web ), конфигурация должна выглядеть следующим образом:
Ресурсы и DoS
Ограничение доступа
В случае если развернутый на сервере ресурс предназначен только для определенной подсети, можно ограничить доступ к нему:
Защита настроек
Большинство трудно отлавливаемых проблем (которые могут повлиять и на безопасность) с веб-сервером возникают из-за неправильной конфигурации. На сайте Apache приведен список типичных мисконфигураций, с объяснением проблемы и способом решения.
nginx
Следующим гостем нашего обзора следует веб-сервер nginx. Во-первых, можно, как и в случае с Apache, скрыть тип и версию сервера, это так называемое security through obscurity, которое заставит атакующего потратить дополнительное время. Для этого в файле src/http/ngx_http_header_filter_module.c надо поменять строки
Ограничиваем буферы
Далее, чтобы немного обезопаситься от атак, связанных с переполнением буфера, можно применить следующие настройки:
Фильтруем user-агенты
Конфигурационный файл nginx.conf позволяет достаточно гибко настроить веб-сервер под себя. Например, можно запретить доступ определенным user-агентам — ботам, сканерам, downloader’ам:
Долой хотлинкинг
Еще одна полезная возможность — запрет на хотлинкинг (когда какой-то сторонний ресурс ссылается на изображение или какой-то другой ресурс твоего сервера):
Таким образом можно снизить нагрузку на сервер и расходы на трафик, если у тебя раскрученный ресурс, конечно. Если нет — то ничего страшного, если кто-то сошлется на картинку с твоего сайта.
Ограничение доступа
Еще можно разрешить/ограничить доступ к админке или какой-то другой директории ресурса только для определенных IP-адресов.
Боты под запретом
Бороться с ботами, сканирующими сервер на наличие различных доменов, можно, разрешив запросы только к сконфигурированным виртуальным доменам или reverse-прокси запросы:
Аналогично можно и ограничить число доступных HTTP-методов, например оставив только GET, POST и HEAD:
Реферальный спам
Для борьбы с реферальным спамом, который может негативно отразиться на твоем SEO-ранге, можно использовать подобную конфигурацию:
Географический бан
Запрет на выполнение скриптов
Немного обезопасить свой ресурс можно еще одним способом — запретить выполнение скриптов из определенных директорий. Ведь, как это обычно бывает, веб-шелл заливается атакующим в одну из директорий, предназначенных для upload’а. Чтобы, даже если ему удалось обойти все фильтры и залить шелл вместо аватарки, он не смог им воспользоваться, надо сделать так:
MySQL
Запрет на чтение файлов
Меняем рут
Еще одним неплохим шагом на пути к безопасности будет изменение имени и пароля суперпользователя. По дефолту это обычно пользователь root. Делается это следующими командами:
Чистим историю
Нелишним будет также подчистить историю, куда сохраняется очень много ценной информации (например, паролей), причем в открытом виде. Делается это следующим образом:
По безопасности PHP достаточно много написано как в Сети, так и на страницах нашего журнала, поэтому особенно долго останавливаться на этом не будем. Отметим лишь наиболее значимые параметры, на которые стоит обращать внимание в первую очередь.
Опасные функции
Ошибки и логи
Потом можно отключить вывод ошибок пользователям — display_errors = Off и включить логирование:
Маскировка
Force redirect
Memcached
Современные проекты становятся все сложнее и масштабнее, с ростом числа посетителей растет и нагрузка на сервер. Чтобы бороться с возрастающей нагрузкой, начинают применять кеширование. Наиболее популярным решением является memcached. Очень часто при его развертывании не уделяют должного внимания безопасности. В результате потенциальные дыры могут годами оставаться незамеченными, пока в один прекрасный день какой-нибудь «добрый» человек ее не найдет и не воспользуется. Частенько администраторы забывают о настройке подключения к демону memcached. На хабре есть история о том, как такая бага была найдена на phpclub.ru.
Бороться с этой проблемой достаточно просто — если кеширующий сервис находится на той же машине, что и сам проект, то надо ограничить доступ к нему только с локалхоста. Для этого в конфигурационном файле memcached надо изменить строчку OPTIONS=»» на OPTIONS=»-l 127.0.0.1″ и перезапустить memcached. В случае если кеширующий демон расположен на отдельном сервере, необходимо ограничить доступ к нему при помощи файрвола.
Вредные советы
Обращаясь за советом по настройке к интернету, надо помнить, что не всему, что там написано, стоит верить на слово. Иногда те примеры, которые, в общем-то, работают, могут привести к появлению серьезной бреши в безопасности системы.
BaseAuth
Классический пример такой «медвежьей услуги» связан с Apache и настройкой базовой авторизации, которая применяется для ограничения доступа к какому-либо файлу или части ресурса. Один из типичных примеров, который может попасться в Сети, выглядит следующим образом:
Как правильно
PHP-FPM & nginx
Еще один пример связан с настройкой связки PHP-FPM + nginx. Те, кто настраивал, вполне вероятно могли натыкаться в Сети на код, содержащий следующие строки:
Как правильно
В заключение
На самом деле о безопасной настройке каждого из рассмотренных продуктов можно говорить достаточно долго. Америки мы сегодня не открыли, а лишь освежили в памяти те параметры, на которые следует обращать внимание при настройке своего сервера, чтобы он не стал легкой мишенью для злоумышленников. Также мы снова убедились, что не всем интернет-советчикам стоит верить. Надеюсь, данный материал мотивирует тебя еще раз проверить свои конфиги и убедиться, что с ними все в порядке.
Enable force cgi redirect
Возможные атаки
Использование PHP как бинарного CGI-приложения является одним из вариантов, когда по каким-либо причинам нежелательно интегрировать PHP в веб-сервер (например Apache) в качестве модуля, либо предполагается использование таких утилит, как chroot и setuid для организации безопасного окружения во время работы скриптов. Такая установка обычно сопровождается копированием исполняемого файла PHP в директорию cgi-bin веб-сервера. CERT (организация, следящая за угрозами безопасности) CA-96.11 рекомендует не помещать какие-либо интерпретаторы в каталог cgi-bin. Даже если PHP используется как самостоятельный интерпретатор, он спроектирован так, чтобы предотвратить возможность следующих атак:
Доступ к системным файлам: http://my.host/cgi-bin/php?/etc/passwd
Данные, введенные в строке запроса (URL) после вопросительного знака, передаются интерпретатору как аргументы командной строки согласно CGI протоколу. Обычно интерпретаторы открывают и исполняют файл, указанный в качестве первого аргумента.
В случае использования PHP посредством CGI-протокола он не станет интерпретировать аргументы командной строки.
Доступ к произвольному документу на сервере: http://my.host/cgi-bin/php/secret/doc.html
Согласно общепринятому соглашению часть пути в запрошенной странице, которая расположена после имени выполняемого модуля PHP, /secret/doc.html, используется для указания файла, который будет интерпретирован как CGI-программа Обычно, некоторые конфигурационные опции веб-сервера (например, Action для сервера Apache) используются для перенаправления документа, к примеру, для перенаправления запросов вида http://my.host/secret/script.php интерпретатору PHP. В таком случае веб-сервер вначале проверяет права доступа к директории /secret, и после этого создает перенаправленный запрос http://my.host/cgi-bin/php/secret/script.php. К сожалению, если запрос изначально задан в полном виде, проверка на наличие прав для файла /secret/script.php не выполняется, она происходит только для файла /cgi-bin/php. Таким образом, пользователь имеет возможность обратиться к /cgi-bin/php, и, как следствие, к любому защищенному документу на сервере.
В PHP, указывая во время компиляции опцию —enable-force-cgi-redirect, а таке опции doc_root и user_dir во время выполнения скрипта, можно предотвратить подобные атаки для директорий с ограниченным доступом. Более детально приведенные опции, а также их комбинации будут рассмотрены ниже.
Вариант 1: обслуживаются только общедоступные файлы
В случае, если на вашем сервере отсутствуют файлы, доступ к которым ограничен паролем либо фильтром по IP-адресам, нет никакой необходимости использовать данные опции. Если ваш веб-сервер не разрешает выполнять перенаправления либо не имеет возможности взаимодействовать с исполняемым PHP-модулем на необходимом уровне безопасности, вы можете использовать опцию —enable-force-cgi-redirect во время сборки PHP. Но при этом вы должны убедиться, что альтернативные способы вызова скрипта, такие как непосредственно вызов http://my.host/cgi-bin/php/dir/script.php либо с переадресацией http://my.host/dir/script.php, недоступны.
В веб-сервере Apache перенаправление может быть сконфигурировано при помощи директив AddHandler и Action (описано ниже).
Эта опция, указываемая во время сборки PHP, предотвращает вызов скриптов непосредственно по адресу вида http://my.host/cgi-bin/php/secretdir/script.php. Вместо этого, PHP будет обрабатывать пришедший запрос только в том случае, если он был перенаправлен веб-сервером.
Обычно перенаправление в веб-сервере Apache настраивается при помощи следующих опций:
Вариант 3: использование опций doc_root и user_dir
Размещение динамического контента, такого как скрипты либо любые другие исполняемые файлы, в директории веб-сервера делает его потенциально опасным. В случае, если в конфигурации сервера допущена ошибка, возможна ситуация, когда скрипты не выполняются, а отображаются в браузере, как обычные HTML-документы, что может привести к утечке конфиденциальной информации (например, паролей), либо информации, являющейся интеллектуальной собственностью. Исходя из таких соображений, многие системные администраторы предпочитают использовать для хранения скриптов отдельную директорию, работая со всеми размещенными в ней файлами по CGI-интерфейсу.
В случае, если невозможно гарантировать, что запросы не перенаправляются, как было показано в предыдущем разделе, необходимо указывать переменную doc_root, которая отличается от корневой директории веб-документов.
user/doc.php приводит к выполнению скрипта, находящегося не в домашнем каталоге соответствующего пользователя, а находящегося в подкаталоге doc_root скрипта
user/doc.php (да, имя директории начинается с символа
Но если переменной public_php присвоено значение, например, http://my.host/
user/doc.php, тогда в приведенном выше примере будет выполнен скрипт doc.php, находящийся в домашнем каталоге пользователя, в директории public_php. Например, если домашний каталог пользователя /home/user, будет выполнен файл /home/user/public_php/doc.php.
Вариант 4: PHP вне дерева веб-документов
Также необходимо сделать все файлы скриптов исполняемыми. Таким образом, скрипт будет рассматриваться так же, как и любое другое CGI-приложение, написанное на Perl, sh или любом другом скриптовом языке, который использует дописывание #! в начало файла для запуска самого себя.