Pericoli per dare all'utente Apache una shell

tl; dr – Quali sono i pericoli di dare a Apache una shell in / etc / passwd?


Sto lavorando per get mod_evasive impostato con Apache per combattere i tentativi di DOS. Utilizzo DOSSystemCommand per eseguire uno script che aggiunge l'indirizzo IP offensivo a una catena BANNED in iptables.

Ho scoperto che l'unico modo in cui posso fare questo process è quello di cambiare la shell di Apache da /sbin/nologin a /bin/bash . Ma è solo una parte dello script che non riesce a non modificare la shell. Ecco la linea DOSSystemCommand e lo script che viene eseguito:

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

e lo script … (noto che sto solo sperimentando … ecco perché ho un'output verbosa e brevi brevi periodi)

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

Quindi, con Apache che ha un shell di /sbin/nologin , aggiungerà le regole IPTABLES e creerà i posti at lavoro, ma quando ricevo un'e-mail con il risultato dei lavori in atto, afferma che l' User is currently unavailable , quindi le regole iptables non vengono mai eliminate. Se faccio Apache / bin / bash come shell, vengono aggiunte le regole iptables, vengono creati i processi e l'eliminazione di iptables funziona come previsto a loro volta.

Quindi la mia domanda è: in che modo posso mettere il mio server a rischio dando all'utente Apache un shell?

  • Come posso installare i repository principali per RHEL6
  • Perché l'utilizzo di RAM è così alto su un server inattivo?
  • "Notifica di limite di potenza" che entra in contatto con i server Dell da 12G con RHEL6
  • RHEL 6 iSCSI LUN
  • Il riavvio non riesce su RHEL 6.1 dopo l'aggiornamento del kernel su Amazon EC2
  • NTPD perde tempo quando non è necessario
  • Come installare java-1.7.0-openjdk-devel su RHEL Server 6.3?
  • Come posso utilizzare SELinux per limitare gli script PHP?
  • 2 Solutions collect form web for “Pericoli per dare all'utente Apache una shell”

    Il codice corrispondente è alla linea 224 di mod_evasive.c:

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

    Ora, controlliamo il 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. 

    Possiamo quindi vedere che il command specificato viene eseguito all'interno di una shell. Certo, la documentazione del system(3) è confusa su questo punto, ma possiamo certamente vedere cosa sta succedendo e fare le inferenze appropriate: viene eseguito nella shell predefinita dell'utente, non semplicemente /bin/sh .

    La soluzione corretta è relativamente semplice: sostituire semplicemente la chiamata del system(3) con una fork(2) e un execve(2) (o qualcosa di sostanzialmente simile). Se preferisci non farlo, puoi anche scrivere una shell molto piccola e restrittiva per bloccare le cose in modo appropriato.

    Per caso, questa domanda mi ha spinto a controllare due volte e sarai lieto di sapere che un utente con la possibilità di scrivere un file .htaccess non può assumere la tua casella solo in virtù della mod_evasive essere installato ( RSRC_CONF è il corretto impostazione, in modo da kudos all'autore di mod_evasive su quel punto). Tuttavia, dato che hai descritto la tua configuration, c'è un'ottima possibilità che alless un utente con la possibilità di eseguire il codice come Apache (ad esempio, block mod_su* o simili, chiunque possa eseguire PHP, Perl, CGI, ecc.), può vietare il tuo server utilizzando IPTables.

    Perché apache deve eseguire questo script? Sembra che stai elevando apache alla radice e assegnandoti una shell quando potresti semplicemente eseguire lo script come root.

    Dare l'accesso apache sudo è molto simile a bloccare tutte le porte e windows di un edificio … ma anche installare una port di sovrapposizione per un bacino di spedizione e lasciandola aperta. (Un utente in teoria avrà solo accesso a determinate cose nella baia di navigazione … ma hanno comunque accesso less all'edificio e possono iniziare a chiedere ulteriori punti di accesso.

    Dare all'utente di apache una shell per andare con tale accesso sudo è molto simile a lasciare una taglierina chiave in detta bay di spedizione. Con abbastanza fortuna un attaccante può fare le chiavi (guadagno accesso / privilegi) di cui ha bisogno.

    https://unix.stackexchange.com/questions/78985/deleting-users-with-nologin-shell Come per la domanda precedente: la shell / bin / nologin impedisce a chiunque di accedere come utente in questione (vedere: console, ssh, su, ecc).

    Puoi anche dare un'occhiata a: https://security.stackexchange.com/questions/5707/recommendations-for-changing-the-default-shell-for-service-accounts – una discussione sulla sicurezza di nologin vs / dev / null come shell.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.