tl; dr - В чем опасность предоставления Apache оболочки в / etc / passwd?
Я работаю над установкой mod_evasive с Apache для борьбы с попытками DOS. Я использую DOSSystemCommand для запуска сценария, добавляющего оскорбительный IP-адрес в ЗАПРЕЩЕННУЮ цепочку в iptables.
Я обнаружил, что единственный способ заставить этот процесс работать - это изменить оболочку Apache с /sbin/nologin к /bin/bash. Но на самом деле только одна часть скрипта терпит неудачу из-за того, что оболочка не меняется. Вот DOSSystemCommand строка и сценарий, который она запускает:
DOSSystemCommand "/usr/bin/sudo /bin/bash /var/www/html/ban_ip.sh %s"
и сценарий ... (обратите внимание, я только тестирую ... поэтому у меня подробный вывод и короткие периоды блокировки)
#!/bin/bash
IP=$1
IPTABLES=/sbin/iptables
sudo $IPTABLES -I BANNED -p tcp -s $IP --dport 443 -j DROP
sudo $IPTABLES -I BANNED -p tcp -s $IP --dport 80 -j DROP
echo sudo $IPTABLES -v -D BANNED -p tcp -s $IP --dport 80 -j DROP | at -m now + 1 minutes
echo sudo $IPTABLES -v -D BANNED -p tcp -s $IP --dport 443 -j DROP | at -m now + 2 minutes
echo rm -fv /tmp/dos-$IP | at -m now + 2 minutes
Итак, с Apache, имеющим оболочку /sbin/nologin, Он добавит правила IPTABLES и создаст at jobs, но когда я получаю электронное письмо с результатом at jobs, в нем говорится, что User is currently unavailable, поэтому правила iptables никогда не удаляются. Если я использую Apache / bin / bash в качестве оболочки, правила iptables добавляются, создаются задания at, а удаление iptables работает, как ожидалось, в назначенное время.
Итак, мой вопрос: каким образом я подвергаю риску свой сервер, предоставляя пользователю Apache оболочку?
Соответствующий код находится в строке 224 файла mod_evasive.c:
if (sys_command != NULL) {
snprintf(filename, sizeof(filename), sys_command, text_add);
system(filename);
}
Теперь давайте проверим man 3 system:
DESCRIPTION
system() executes a command specified in command by calling /bin/sh -c command,
and returns after the command has been completed. During execution of the
command, SIGCHLD will be blocked, and SIGINT and SIGQUIT will be ignored.
Таким образом, мы видим, что указанная команда выполняется в оболочке. По общему признанию, system(3) документация по этому поводу сбивает с толку, но мы, безусловно, можем видеть что происходит, и сделать соответствующие выводы - это выполняется в оболочке пользователя по умолчанию, а не просто /bin/sh.
Правильное решение относительно простое: просто замените system(3) позвонить с fork(2) и execve(2) (или что-то подобное). Если вы не хотите этого делать, вы также можете написать очень маленькую ограничительную оболочку, чтобы заблокировать вещи должным образом.
По совпадению, этот вопрос побудил меня перепроверить, и вам будет приятно узнать, что пользователь, имеющий возможность писать файл .htaccess, не может захватить ваш ящик только в силу установленного mod_evasive (RSRC_CONF это правильная настройка, так что спасибо автору mod_evasive в этом отношении). Однако, учитывая то, как вы описали свою конфигурацию, существует отличный шанс, что, как минимум, любой пользователь, имеющий возможность запускать код как Apache (например, запретить mod_su* или тому подобное, любой, кто может запускать PHP, Perl, CGI и т. д.), может запретить вам доступ к вашему собственному серверу с помощью IPTables.
Зачем apache нужно запускать этот скрипт? Похоже, вы поднимаете apache до root и назначаете ему оболочку, когда вы можете просто запустить скрипт как root.
Предоставление доступа apache sudo во многом похоже на запирание всех дверей и окон в здании ... но также установку верхней двери для грузового дока и оставление ее широко открытой. (Пользователь теоретически будет иметь доступ только к определенным вещам в грузовом отсеке ... но, тем не менее, у него есть доступ к зданию, и он может начать искать дополнительные точки входа.
Предоставление пользователю apache оболочки для работы с указанным доступом sudo во многом похоже на оставление ножа для ключей в указанном отсеке для доставки. Если повезет, злоумышленник может сделать ключи (получить доступ / привилегии), которые ему нужны.
https://unix.stackexchange.com/questions/78985/deleting-users-with-nologin-shell Согласно приведенному выше вопросу: оболочка / bin / nologin не позволяет кому-либо войти в систему как соответствующий пользователь (см .: console, ssh, su и т. Д.).
Вы также можете взглянуть на: https://security.stackexchange.com/questions/5707/recommendations-for-changing-the-default-shell-for-service-accounts - обсуждение безопасности nologin vs / dev / null в качестве оболочки.