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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что касается расширения основного модуля, то это очень простой модуль для запуска. Вы можете жестко запрограммировать список разрешенных или запрещенных команд для выполнения. Затем вы можете проверить инструкцию 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_профиль

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

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 байт свободных

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