Foro de elhacker.net

Hola, estoy usando la última versión de nginx y tengo una duda...

Estoy intentando de crear un sistema de baneo a través de nginx junto a un servicio estadístico de ips baneadas, el tema es que no se como hacerlo.

Lo que hice fue crear una regla muy simple en la configuración de nginx:


Se comprende lo que quiero hacer? :P la idea es que cuando alguien intente acceder a archivos no permitidos termine denegando el acceso y a demás baneandose a traves de iptables, ahora, lo que quiero principalmente es generar un log personalizado muy similar al del nginx pero que indique la razón de porque fue baneado, fecha de baneo, regla de solicitud denegada, etc.

Por eso estaba pensando pasar todo a traves de un único archivo .sh pasándole argumentos y que este se encargue de ejecutar el iptables o apf y que genere este log o que llame a un archivo en python y guarde en una base de datos en mongodb los datos de baneo... pero para lograr todo esto necesito saber si es posible ejecutar un comando sobre la linea comentada antes de retornar el 403, también sería genial que desde el mismo archivo sh se comunique por telnet al router y bloquee la ip por hardware a traves del firewall cisco asa.

Hay alguna manera de lanzar esta ejecución de alguna manera?

La segunda alternativa pero no tan efectiva sería que solamente genere un log personalizado pero tendría que tener un servicio que revise el log cada x segundos y vaya baneando las ips que tengan ciertas reglas, pero eso quiere decir que ya no será baneado sobre la primera solicitud sino cuando el servicio recorra el log, a demás al crecer el log el proceso se hará mas pesado y no es la idea.

Lo unico que se me ocurre es que reescribas la url a un script en php, python o perl. No creo que puedas ejecutar iptables a menos que el que corra el script tenga permisos root.

Puedes darle permisos a www-data para que ejecute un sh como permisos de root, pero solo un sh. Es un poco peligroso, pero si solo le das permisos de escritura a root no hay peligro.

En el fichero sudoers sería algo así:


También puedes usar el permiso sticky bit con:

Mentira, no es el sticky bit lo que hace eso, es el setuid. Se activa de esta forma:


Eso lo que hace es que se ejecuta el fichero con los permisos del usuario propietario aunque no lo sea.

Aunque lo que no se como se pone en nginx para ejecutar un sh en una regla, pero suena interesante.

Edito: Parece que en nginx puedes ejecutar código de Lua, para ejecutar el bash script:


La fuente: http://stackoverflow.com/questions/22891148/nginx-how-to-run-a-shell-script-on-every-request (http://stackoverflow.com/questions/22891148/nginx-how-to-run-a-shell-script-on-every-request)

Suerte.

Si, de hecho intenté hacer un rewrite hacia un cgi/bash pero si la persona está usando un robot para escanear puede cancelar la solucitud y cancelar la ejecución a menos que se cargue sin ninguna redirección como lo hace el mod rewrite de apache

Intentaré lo que dicen, gracias por los tips.

No estoy seguro de como hace el rewrite nginx, pero yo creo que es posible hacer el rewrite sin una respuesta HTTP 30X de por medio. Si vi el tema de lua pero no estaba seguro si puedes enviar parametros, por ejemplo ip. Y no hace falta mencionar... que esos parametros que estes pasando a tu archivo que tiene permisos root pueden representar un riesgo.

Edit: Nginx al parecer no hace uso de ninguna peticion intermediaria con rewrite a menos que tu le indiques.

Asi es, nginx para hacer todo eso lo estoy corriendo como root al igual que snort y squid, estoy haciendo un invento que si resulta bien lo transformaré en un servicio, lo bueno es que no usaré un servidor para varios sitios, usaré un servidor por sitio y ese servidor no tendrá credenciales de ningún tipo y solo harán reverse proxy asi que es muy poco probable que me hackeen el servidor a través de nginx a menos que sea un bug explotable de forma remota pero eso ya es mas difícil, para eso está snort y acciones por iptables de bloqueo preventivo pre procesamiento de datos por parte del servidor web y si lo hackean no expongo nada, con suerte la ip del servidor al que le estoy haciendo el reverse proxy aunque de todas maneras pasará a traves de una vpn configurado a traves del royter y no del sistema operativo, ais que si lo hackean da lo mismo, se levanta una instancia anterior del ec2 y se parcha el bug y listo.

Me tinca mas hacer la redirección, lo que estoy intentando es enviar un header 403 y crear un 403 personalizado en .pl el cual se va a encargar de ejecutar todo, lo único que debe hacer es leer las variables nativas de nginx, asi que todos los que  lean un 403 quedarán baneados :P

Ahora tengo que ver como puedo llevar una variable desde el archivo de configuraciones hasta el archivo perl para obtener el vector de ataque por el cual fue bloqueado.

Si usas FCGI, puedes pasar las variables con fastcgi_params.

http://wiki.nginx.org/FcgiExample

El documento hace mencion a PHP FPM, hay un fcgi para perl pero la verdad nunca he tratado con el.

Bueno, hice funcionar fast cgi wrap pero el binario está compilado para que no se pueda iniciar en modo root :( y el lua está dificil de instalar ya que requiere la instalacion manual de versiones especificas de paquetes y no es bueno si quiero automatizar su instalación.

Lo que hice fue instalar httpd y php y lo hice correr en modo root y desde nginx hice que cuando se produjera un error 403 hiciera un reverse proxy a localhost puerto 81 a la ruta del 403.php :D y php es el encargado de hacer todo, es mas, ahora puedo utilizar mongodb con php directo o migrar a futuro a oracle si es necesario :D y httpd blindado unicamente en localhost.

Me salió muy larga la vuelta que quería hacer pero finalmente fue efectivo, tampoco creo que haya problema de carga con apache ya que las solicitudes se harán unicamente cuando se haga un baneo o algo por el estilo.

Gracias de todas maneras, a futuro buscaré una manera mas facil de hacer todo sin tener que pasar por el httpd y un doble reverse proxy xd

Ahora intentaré hacer lo que dice moikano→@ para no tener que usar todo en modo root sino solo los scripts necesarios.

Saludos.

Agregué al /etc/sudoers la linea:

Ahora ejecuto desde php:

<plaintext>
<?php 
system('id');
system('/var/ban/403.sh');
system('/bin/bash /var/ban/403.sh');
system('sudo /var/ban/403.sh');
system('sudo /bin/bash /var/ban/403.sh');
?>

el archivo 403.sh tiene:


Le di permisos de ejecución con chmod +x 403.sh y nada, solo se ejecuta el primero con id de apache:

Pero el resto nada :( apache está corriendo con permisos de apache y nginx con permisos de nginx, supuse que php al tener permisos de apache podría ejecutar el script de baneo con permisos de root pero nada.

Le acabo de poner:
A sudoers para descartar un problema con la ruta o cosas así y tampoco :-/

Estás seguro que el usuario que ejecuta es apache? en debian suele ser www-data sea apache o nginx.

Aparte de eso, prueba a reinciar el servicio, ya que los permisos de sudo se cargan cuando se reinicia la sesión.

El que me suele funcionar a mi es este :

Pues a mi me funciona en mi consola. ¿Sera open_basedir? ¿O quizas tu SELinux?

Pues no, aplico todos los cambios, reinicio el servidor (es centos 7) y nada, el script me dice que el id es apache y es el httpd el que está ejecutando el script en php, nginx lo único que hace es hacer de reverse proxy nada mas porque la configuración para interactuar con scripts dinámicos es mas complejo, generalmente debes usar servicios paralelos con sockets de comunicación, al final nginx nunca ejecuta finalmente el script sino el servicio de cgi, en ese caso supongo que httpd hace lo mismo pero de manera mas ordenada, nativa y automatizada, por eso mejor dejé ambos instalados.

open_basedir puede se eh, lo revisaré ahora mismo aunque por defecto debería poderse.

¿No te lanza ningun error? Revisa que tengas configurado PHP para lanzar errors. error_reporting y display_errors.

En orden sería:

system('/var/ban/403.sh');
# sh: /var/ban/403.sh: Permission denied
 
system('/bin/bash /var/ban/403.sh');
# /bin/bash: /var/ban/403.sh: Permission denied
 
system('sudo /var/ban/403.sh');
# sudo: unable to open audit system: Permission denied
 
system('sudo /bin/bash /var/ban/403.sh');
# sudo: unable to open audit system: Permission denied

Definitivamente el sudoers no funciona :( , el script en php corre con permisos de "apache" y el sudoers está habilitado para ejecutar cualquier cosa sin contraseña con sudo y nada. Cuando resulte bien dejo habilitado solo los scripts necesarios.

Bueno ya busqué por algunos blogs y definitivamente el problema es el selinux tal como decías.

Intenté hacerle un bypass como se recomendaba en algunos lados pero sin éxito:

Ahora... entiendo que por todos lados está muy restringido que un script via http se ejecute como root desde el mismo servidor hasta los sistemas de protección del mismo sistema operativo, por lo cual podría decirse que no debería hacerlo, pero entonces como lo hago si necesito que dependiendo de ciertas solicitudes http se generen acciones inmediatas a bajo nivel como cambiar la configuración de balanceos de carga, baneos por firewall, etc, no me sirve crear un log y listo, necesito que el sistema sea proactivo y rwactivo, esto quiere decir que si existe una solicitud peligrosa el usuario quede baneado al instante y no esperar a que un daemon barra un log.

En ese caso que sería mas óptimo? crear un servicio que reciba comandos? porque al final igual de todas maneras el servicio web va a tener que gatillar acciones como root, asi que no entiendo como debería hacerse sin arriesgar la seguridad de todo el sistema, no quiero tener que deshabilitar selinux.

O será que esta es una excepción a la regla?

creo que tendré que ir replanteandome si hacer esto via nginx y apache o snort directamente, veré si snort tiene la capacidad de ejecutar cosas dependiendo de cada regla.

Bueno, es que SELinux tiene reglas mucho mas restrictivas. Siempre y cuando sepas lo que estas haciendo y entiendas las consecuencias no hay problema, claro que no siempre es posible prever todo. Yo diria que simplemente le des los permisos adecuados bajo SELinux, no veo razon por la cual no deba permitirte estando configurando propiamente.

Creo tambien que puedes pasar de Enforcing a Permissive con SELinux aunque yo creo que es preferible en enforcing sobre todo por lo que estas haciendo de configurar los contextos adecuadamente con SELinux.

Este comando cambia el type a uno que supuestamente permite apache lanzar el script:

sudo chcon -t httpd_sys_script_exec_t /var/ban/403.sh

Pues si, efectivamente deja ejecutar el script pero manteniendo los permisos de apache, los que se llaman con sudo siguen sin ejecutarse :(

Porque no tienes el setuid puesto:

sudo chmod 4711 /var/ban/403.sh

Si quieres usar sudo en apache vas a necesitar agregar a las politicas el typo de /usr/sbin/sudo o donde quiera que este en centos. No intentes cambiar el tipo al binario de sudo.

Bueno, para ir descartando puse selinux en modo permisivo y reinicié la maquina, ahora ejecuto:


Ahora si efectivamente el sudoers funciona perfectamente, pero el script en php no puede ejecutar el mismo comando a pesar de que tenga el mismo permiso. El log de errores dice:


Será que debo asignarle un bash al usuario apache dentro del /etc/passwd?

Pruebalo con shell_exec en lugar de system.

El mismo mensaje de error y ya agregué /bin/bash al usuario apache desde /etc/passwd y al ejecutar su apache entra directamente al bash, pero aun así quiere funcionar en php, talves sea algo de sudoers.

Vaya yo pense que shell_exec usa una tty pero parece que no (la verdad no se porque pense eso). Aparentemente puedes hacer un bypass de eso con:


Tambien puedes hacerlo por comando aparentemente, revisa aqui:

http://unix.stackexchange.com/questions/79960/how-to-disable-requiretty-for-a-single-command-in-sudoers

No funciono lo del setuid?

eaeaeaaa ahi sii :D pero me funciona con system() no con shell_exec(), no se porque pero ya no es mi prioridad xD

Ahora volveré a habilitar selinux como estaba y configuraré el script para que pueda ser ejecutado por apache para no afectar la seguridad nativa del sistema :P

Bueno, ya está todo ok y funcionando perfectamente :D muchas gracias por el tiempo y la paciencia.

Saludos.