Perigos para dar ao usuário do Apache um shell

Question

tl; dr - Quais são os perigos de dar um shell ao Apache em / etc / passwd?

Estou trabalhando para configurar o mod_evasive com o Apache para combater as tentativas do DOS. Eu uso o DOSSystemCommand para executar um script que adiciona o endereço IP ofensivo a uma cadeia BANNED no iptables.

Descobri que a única maneira de fazer esse processo funcionar é se eu alterar o shell do Apache de /sbin/nologin para /bin/bash . Mas na verdade é apenas uma parte do script que falha ao não ter o shell alterado. Aqui está a linha DOSSystemCommand e o script que é executado:

 DOSSystemCommand    "/usr/bin/sudo /bin/bash /var/www/html/ban_ip.sh %s"

e o script ... (note que estou apenas em testes ... e é por isso que tenho uma saída detalhada e curtos períodos de proibição)

#!/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

Assim, com o Apache tendo um shell de /sbin/nologin , ele adicionará as regras do IPTABLES e criará os at jobs, mas quando recebo um email com o resultado dos jobs at, ele declara que o User is currently unavailable , então as regras do iptables nunca são deletadas. Se eu der o Apache / bin / bash como seu shell, as regras do iptables são adicionadas, as tarefas at são criadas e a exclusão do iptables funciona como esperado no horário designado.

Então, minha pergunta é: De que maneira estou colocando meu servidor em risco, dando ao usuário do Apache um shell?

    

Answer 1

O código relevante está na linha 224 do mod_evasive.c:

        if (sys_command != NULL) {
          snprintf(filename, sizeof(filename), sys_command, text_add);
          system(filename);
        }

Agora, vamos verificar 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.

Podemos ver, então, que o comando especificado está sendo executado dentro de um shell. É certo que a documentação de system(3) é confusa neste ponto, mas certamente podemos ver o que está acontecendo e fazer as inferências apropriadas - ele está sendo executado no shell padrão do usuário, não simplesmente /bin/sh . / p>

A solução correta é relativamente simples: basta substituir a chamada system(3) por fork(2) e execve(2) (ou algo substancialmente similar). Se preferir não fazer isso, você também pode escrever um shell muito pequeno e restritivo para bloquear as coisas apropriadamente.

Coincidentemente, esta questão me levou a verificar novamente, e você ficará satisfeito em saber que um usuário com a capacidade de escrever um arquivo .htaccess não pode assumir a sua caixa apenas em virtude de ser mod_evasive instalado ( RSRC_CONF é a configuração correta, por isso, parabéns ao autor de mod_evasive nesse ponto). No entanto, dado como você descreveu sua configuração, há uma excelente chance de que, no mínimo, qualquer usuário com a capacidade de executar código como Apache (por exemplo, com exceção de mod_su* ou algo semelhante, qualquer um que possa executar PHP, Perl, CGI , etc.), pode banir você do seu próprio servidor usando o IPTables.

    

Answer 2

Por que o apache precisa executar esse script? Parece que você está elevando o apache para root e atribuindo a ele um shell quando você pode simplesmente executar o script como root.

Dar acesso ao apache sudo é muito parecido com trancar todas as portas e janelas de um prédio ... mas também instalar uma porta suspensa para uma doca de despacho e deixá-la aberta. (Em teoria, um usuário só terá acesso a determinadas coisas na baia de embarque ... mas, no entanto, elas ganharam acesso ao prédio e podem começar a procurar mais pontos de entrada.

Dar ao usuário do apache um shell para acessar o dito sudo é muito parecido com deixar um cortador de chaves na referida área de embarque. Com sorte suficiente, um atacante pode fazer as chaves (obter acesso / privilégios) que ele / ela precisa.

link De acordo com a pergunta acima: o shell / bin / nologin impede que alguém faça login como o usuário em questão (consulte: console, ssh, su, etc).

Você também pode dar uma olhada em: link - uma discussão sobre segurança de nologin vs / dev / null como o shell.