Можно ли ограничить, какие команды php может проходить через exec на уровне ОС?

в настоящее время я принимаю Друпал 6 сайт на машине CentOS. Друпал (CMS) конфигурация содержит несколько десятков сторонних модулей, которые не должны быть раздвоенный как общая лучшая практика кодирования. Однако, некоторые из этих модулей использовать php exec команда для правильной работы.

сайт позволяет администраторам вставлять фрагменты кода php на любую страницу через конфигурацию пользовательского интерфейса, при условии, что они иметь доступ к формату ввода кода php. Мне нужно сохранить этот формат ввода доступным для администраторов, потому что есть несколько узлов (страниц) и панелей, которые используют небольшие, безвредные фрагменты кода php, например, встраивание определенной формы в область содержимого.

проблема в том, что если кто-то скомпрометирует учетную запись администратора, то они могут запускать произвольный php-код на сайте и, таким образом, запускать команды оболочки через php exec, passthru, etc. Быть там в любом случае, с уровня операционной системы, чтобы ограничить, какие команды оболочки php может пройти до машины? Можно ли это сделать, ограничив права доступа к файлам для некоторых программ из php?

Примечание: я не могу использовать PHP.ini disable_functions

5 ответов


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

реальное решение здесь:

  • возможность отправки и запуска произвольного кода изнутри Drupal-это значительный риск, который вы можете уменьшить с помощью не делают. Я настоятельно рекомендую перепроектировать эти "безвредные" биты кода, поскольку они приведут к компромиссу; произвольное выполнение кода - это только один вид эксплойта, и есть много других, о которых нужно беспокоиться.
  • модули, требующие выполнения команд оболочки, также являются значительными уязвимостями безопасности. В некоторых случаях я смог развить / исправить или заменить модули, выполняющие команды, на те, которые этого не делают, но в некоторых случаях (например, кодирование видео) этого нельзя избежать. В этой ситуации я бы создал очень ограниченную бэкэнд-службу, с которой интерфейс может общаться. Это отделяет ваши проблемы и оставляет Drupal делать то, что он должен был: управлять и обслуживать контент.

если ваши учетные записи admininstrator будут взломаны, вы обречены. Вы пытаетесь быть менее обреченными, но это не сработает.

отключение exec ()

это только часть всех функций, которые могут совершать вызовы в систему. Есть еще много, как passthru(), shell_exec(), popen(), proc_open(), оператор backtick, и так далее. Не помочь.

ограничение доступных исполняемых файлов

будет работать только если злоумышленник не может принести его собственные исполняемые. Но!--4--> сможет записать исполняемый файл на жесткий диск, а затем его можно будет вызвать. Тоже не поможет.

PHP не может причинить себе никакого вреда, не так ли?

неправильно. Выполнение материала на сервере через exec() может показаться лучшей идеей, но сам PHP достаточно силен, чтобы нанести ущерб вашему серверу и всему, что связано с ним.

Я думаю, что единственное реальное решение:

не позволяйте вашим учетным записям администратора получить рубивший.

и если они будут взломаны, сможете узнать об этом немедленно. Можно отследить атаку до администратора. Узнайте, что именно злоумышленник сделал с вашей машиной, чтобы вы могли ее отменить. Очень важной частью является реализация регистратора аудиторских следов, который сохраняет данные на другом компьютере.

и вы, вероятно, реализуете более жесткие ограничения на то, кто может войти в систему в качестве администратора в первую очередь. Например, там, вероятно, не нужно позволять всему диапазону IP-адресов миров войти в систему, если вы точно знаете, что один определенный администратор всегда использует диапазон IP своего локального ISP для работы. По крайней мере, позвоните в звонок и сообщите кому-то еще, что логин из Китая происходит, если этого не ожидается (и если вы не работаете в Китае: -)).

и есть два фактора аутентификации. Вы можете отправить SMS на номер телефона с дополнительным кодом входа. Или вы можете быть в состоянии полностью аутсорсинг логин реализация аутентификации Google или Facebook. У этих игроков уже есть инфраструктура для поддержки этого.

и дополнительно, вы получаете более высокое сопротивление против внутренних работ. Люди ценят свои личные логины в социальных сетях выше, чем логин для своего работодателя. Получение чьего-то пароля facebook будет стоить в среднем 30$, но логин компании уже разделен на 8$. Иди разберись...


Это не на уровне ОС, но внутри ядра Drupal есть модуль под названием PHP. Вы можете использовать это как базу и создать пользовательский модуль, который расширяет функциональность этого модуля, а затем просто включить этот модуль в отличие от основного модуля Drupal 6. Однако большая проблема заключается в отключении основного модуля Drupal 6, а затем в включении нового модуля. Я бы протестировал его на установке dev, чтобы убедиться, что предыдущий контент не удален и что новый модуль правильно анализирует сохраненный ввод PHP. Это должно быть хорошо, так как установка модуля имеет только предупреждение об отключении крючка против содержимого PHP, которое теперь отображается в обычном тексте.

Что касается расширения основного модуля, это очень простой модуль для запуска. Вы можете hardcode в списке разрешенных или не разрешенных команд для выполнения. Затем вы можете проверить оператор exec с разрешенными переменными в этом списке и сделать все, что необходимо. Это не идеальный матч против простой блокировки программ на уровне ОС но это лучше, чем ничего. Чтобы жестко закодировать список, вам просто нужно изменить крючок php_filter в нижней части файла модуля и перед выполнением drupal_eval выполните тест.

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


другой подход:

мы считаем, что нам нужно создать тестового пользователя, который имеет доступ только к системе для выполнения telnet на другой машине в сети. Поскольку нам нужно только запустить telnet, нужно ограничить другие команды, доступные в стандартном сеансе bash. Давайте шаг за шагом все настроим.

1) Создаем пользовательский тест

это будет обычный пользователь системы, поэтому мы должны как обычный пользователь. Единственная особенность в том, что мы измените оболочку этого пользователя. По умолчанию обычно используется / bin / bash, и мы установим / bin / rbash. rbash на самом деле является копией bash, но это действительно "ограниченный bash".

shell> adduser --shell /bin/test rbash

2) Создаем файл. Файл

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

if [-f ~/.bashrc]; then
    . ~/.bashrc
fi

PATH = $HOME/apps
export PATH

3)мы избегаем изменений

после создания файла, мы останавливаемся, никто не может внести изменения в файл.

shell> chattr +i /home/test/.bash_profile

4) мы создаем каталог приложений и устанавливаем программы "доступ"

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

shell> mkdir apps
shell> ln-s /usr/bin/telnet /home/test/apps/

5) Мы обнаружили, что работает

теперь вы можете получить доступ к системе и проверить, что она работает правильно.

shell> ssh test@remote
test@remote password:

shell@remote> ls
-rbash: ls: command not found
shell@remote> cd
-rbash: cd: command not found
shell@remote> telnet
telnet>

команда:

вот мой подход.....

Я создал небольшой скрипт со списком принятых команд, и в зависимости от команды выполнение будет контролироваться для избежания проблем. Я не уверен, что это в рамках вопроса. Пример кода имеет команды в Windows, но вы можете использовать его и в Linux...

<?php
ini_set('display_errors',1); 
error_reporting(E_ALL);

function executeCommand($my_command){
    $commandExclusions = array ('format', 'del');

    if (in_array(strtolower($my_command),$commandExclusions)) {
        echo "Sorry, <strong>".$my_command." </strong> command is not allowed";
        exit();
    }
    else{
        echo exec($my_command, $result, $errorCode);
        implode("n", $result);
    }
}
echo "<h3>Is it possible to restrict what commands php can pass through exec at an OS level?</h3><br>";
echo "********************************<br>";
//test of an accepted command
echo "test of an accepted command:<br>";
executeCommand("dir");
echo "<br>********************************<br>";
echo "test of an unaccepted command:<br>";
//test of an unaccepted command
executeCommand("format");
echo "<br>********************************<br>";
?>

выход:

можно ли ограничить, какие команды php может проходить через exec в ОС уровень?


проверка принятой команды: 117 Dir (s) 11,937,468,416 байт бесплатно