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

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

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

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

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

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

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

Будет работать только в том случае, если злоумышленник не сможет принести свои собственные исполняемые файлы. Но file_put_contents() сможет записать исполняемый файл на жесткий диск, а затем он может быть вызван. Также не поможет.

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

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

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

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

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

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

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

Кроме того, вы получаете более высокое сопротивление против внутренних заданий. Люди действительно ценят свои личные сетевые логины выше, чем логин для своего работодателя. Получение пароля somebook 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) Мы создаем файл. bash_profile

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

 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 Дир (ов) 11,937,468,416 байт бесплатно

тест неприемлемой команды: Извините, формат команды не разрешен