El Reto

Reto

Aquí vamos a dar a conocer todos los miembros del grupo la documentación que se hizo en el respectivo reto realizado.

Grupo FREMEN

Tenemos todo documentado por lo que expongo las evidencias.

Entonces proporcionaré a continuación lo mas esencial a lo que se refiere la protección del servidor así como también la defensa del mismo

Acceso al servidor proporcionado.

Hola Juan Carlos,

Soy Miguel Fernández, coordinador del MOOC sobre Hacking Ético de Mondragon Unibertsitatea. Enhorabuena por llegar hasta el reto!

Te paso los datos para que tú y tu equipo podáis empezar a trabajar protegiendo vuestro servidor:Dirección IP del servidor: 159.203.114.175

Contraseña del usuario admin: 135bb504810b136dbf8ef4b1d5e28626

El servidor es una máquina Debian Wheezy de 32 bits en modo solo texto. Para acceder a ella debéis usar SSH (no tiene telnet instalado).

Os recuerdo que, a partir del 27 de septiembre, en la plataforma del curso tenéis las instrucciones y el sistema de puntuación del reto.

Por favor, confírmame que has recibido este mensaje.

Mucho ánimo y que la fuerza os acompañe!

Nota: Por favor, ir rellenando cada uno de los apartados, los cambios realizados en ellos, y antes de tocar, salvar el archivo configuración con un “_bak”. → cp /ruta/archivo /ruta/archivo_bak

INSTRUCCIONES PARA ENTRAR

1. desde putty os conectaís a la IP: 159.203.114.175
2. usuario fremen
3. pass: 1q2w3e4r5t*
4. después, escribís sudo, o su (es preferible sudo que su, es más seguro)
5. y la pass: 135bb504810b136dbf8ef4b1d5e28626

desde Linux:

SSH

Antes de nada, se asegura la última versión de parches en el sistema, con:

• apt-get update ; apt-get upgrade
• 
• El sistema está actualizado!!

Puesto que el ssh está abierto a todo el mundo, y se prohíbe el uso de iptables; se descarta port-knocking. Por tanto, se decide cerrar el acceso a root remoto y se va a poder logar con cuenta local, después se utilizará el su/sudo para realizar tareas administrativas.

• addusr fremen
• Pass: 1q2w3e4r5t*

Probando el usuario fremen como root (para evitar bloquear el servidor cuando se corte el acceso a root por ssh):

• 
• Parece correcto, reiniciamos el servicio ssh: /etc/init.d/ssh restart
• 

Ahora securizamos ssh editando su archivo de configuración:

/etc/ssh/ssh_conf

Securizaremos el nivel de protocolo de cifrado superior o igual a 2, máximo número de intentos a 10 y se bloquea el acceso a root.

• +PermitRootLogin no
• +protocol 2
• +MaxAuthTries 10
• 

Para evitar ataques de fuerza bruta en ssh y ftp, se decide instalar el fail2ban:

• 
• Después, se copia la configuración original de fail2ban sobre la extensión .local sobre la que trabajaremos:
• cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
• Editamos jail.local y cambiamos bantime, y número de intentos por minuto.
• 
• Protegemos el servicio SSH:
• 
• Puesto que está prohibido no nos protegemos de un DDoS de SSH:
• 
• (Confiamos en el fair play, con tal de no sobrecargar servidores virtuales en pro de todo el conjunto del laboratorio).
• Se aplica la configuración: /etc/init.d/fail2ban restart
• 

vsftpd

Puesto que se observa que un usuario puede bajar directorios hasta el directorio raíz y navegar por cualquier parte del disco duro, se restringe que sólo un usuario puede acceder a su home, y a ninguna más.

También se decide evitar el acceso a un usuario no válido dentro del sistema, es decir, deshabilitamos los accesos anónimos.

Por otro lado, habilitamos la escritura en los directorios, para que sea un FTP 100% funcional.

Seguidamente activaremos los certificados para evitar ataques por sniffers de red.

Para ello se descomenta unas líneas, añaden otras… quedándose así:

• Se observa la lista de usuarios deshabilitados:
• root, daemon, bin, sys, sync, games, man, lp, mail.news, uucp, nobody.
• Se les añade:  ftp y anonymous. (Aunque se les deshabilitará quitando anonymous).
• Se añade los usuarios locales al archivo /etc/vsftpd.chroot_list

Se actualiza el archivo de configuración del fail2ban activándolo a enable:

• 

Se aplica las configuraciones:

Apache2+Mysqld+PHP+GitList

Compañeros, quien se encargue de securizar el apache, por favor, que se aproveche del fail2ban (/etc/fail2ban/jail.local): SECCIÓN [apache]: ver imagen

Importante, dentro de este mismo archivo de fail2ban: [mod_security] [php-url-fopen] [lighttpd-fastcgi] y tantos como se estén usando.

------------------------------------------------------

Configuración de seguridad del PHP

1) Deshabilitar expose_php

expose_php es una variable que permite mostrar qué versión de PHP está instalada en el servidor en la cabecera HTML. Por ende debe ir desactivada, así un atacante no podrá conocer qué versión de PHP usas. Debemos desactivar la variable configurándose como se ve a continuación:

expose_php = Off

2) Deshabilitar funciones peligrosas

Hay algunas funciones que pueden llegar a suponer un riesgo para la seguridad del servidor. A no ser que alguna sean necesarias, deberían ser deshabilitadas las siguientes:

disable_functions = "system, system_exec, passthru, shell, shell_exec, exec, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, escapeshellcmd, escapeshellarg, phpinfo"

Yo utilice este comando porque es más conservador:

disable_functions ="system,passthru,escapeshellarg,escapeshellcmd,proc_close,proc_open,ini_alter,popen,show_source,pcntl_exec"

3) Deshabilitar session.use_trans_sid

Con la variable session.use_trans_sid resulta más fácil la programación de aplicaciones que usen sesiones. La desventaja es que cuando está activado puede llegar a ser usado para simular una sesión activa en el server. Para desactivarlo debe quedar así:

session.use_trans_sid = Off

4) Deshabilitar register_globals

register_globals no es una variable peligrosa, sino que lo peligroso es el uso inapropiado de ella, ya que inserta scripts con toda clase de variables, como por ejemplos las que proceden de formularios HTML. Se deshabilita de la siguiente forma:

register_globals = Off

En php 5.3.x ya viene deshabilitada por defecto.

5) Desactivar acceso a URL remotas en funciones de manejo de ficheros

Funciones como include, fopen o file_get_contents permiten, además de hacer llamadas a ficheros locales, llamar a ficheros vía URL, esto puede provocar graves errores de seguridad invocando a scripts maliciosos que se encuentran fuera de nuestro servidor y su ejecución remota. Para desactivar:

allow_url_fopen = Off

6) Safe Mode

Activar safe_mode implica que los scripts PHP únicamente pueden acceder a los ficheros que tienen como propietario el mismo que ellos. De este modo evitamos por ejemplo que tengan acceso de lectura a ficheros de sistema como /etc/passwd entre otros.

safe_mode = On

Efectivamente, esto puede ser un problema en el momento que necesitamos acceder a información generada por otros usuarios en el sistema (ficheros de otras aplicaciones por ejemplo). La solución es la siguiente:

safe_mode = Off
safe_mode_gid = On

Activamos safe_mode_gid en lugar de safe_mode, de modo que en lugar de revisar el usuario se revisa el grupo.

Otro punto a tener en cuenta con safe_mode es que no podremos ejecutar binarios. Únicamente aquellos que ubiquemos en el directorio especificado en la configuración:

safe_mode_exec_dir = /directorio

7) Visualización y registro de errores

display_errors = Off
log_errors = On
error_log = /ruta/fichero/log

Con estas tres directivas, evitamos que cualquier error o warning se muestre por pantalla y hacemos que se registren directamente en un log especificado.

8) Deshabilitar enable_dl

Esta variable se usa solamente en conjunto con el servidor web Apache. Sirve para activar o desactivar la carga dinámica de extensiones PHP con dl() por servidor virtual o directorio. Con la carga dinámica, es posible ignorar todas las restricciones open_basedir. Para desactivarla debe quedar como:

enable_dl = Off

9) open_basedir

open_basedir = /directorio

La directiva open_basedir permite configurar que PHP pueda acceder únicamente a los ficheros de un único directorio (y sus subdirectorios). Es una buena forma de enjaular PHP si realmente sólo necesitamos que acceda a un determinado directorio.

SQL Injection

En su día se utilizaba magic_quotes para limpiar los datos de entrada de un script PHP, pero es una directiva obsoleta a partir de PHP 5.3 así que no merece la pena hablar de ella. En su defecto, si usamos servidor web Apache, se recomienda encarecidamente configurar mod_security y habilitar sus reglas que permiten detectar y parar una gran cantidad de ataques de este tipo, y sino.

Como último apunte, conviene siempre si es posible mantener una versión estable de PHP, libre de bugs y fallos de seguridad.

APACHE

cambie estas configuraciones :

serversignature = off

traceenable=off

ServerTokens=Prod

MySQL

He seguido un manual de buenas prácticas para configurar nuestro mysql, el cual por las pruebas hechas por Victor, era accesible pero no permitía hacer SQL-inyection. Por tanto ya parecía decentemente seguro. No tenemos las contraseñas de ningún usuario, pero me he asegurado de que no existen ninguna de las siguientes sin protección por contraseña (hasta donde he probado no usaría ninguno password por defecto):

• anonymous
• demo-user
• user

Por otro lado he copiado el archivo de configuración my.cnf como my.cnf_bak. Y me he puesto a cambiar cosas.

Las tres líneas nuevas de [mysqld]

local-infile = 0 #Eliminamos la opción de utilizar ficheros de nuestro sistema #(local infile command, que accedería a casi cualquier parte)

bind-address = 127.0.0.1 #Solo será accesible desde el localhost (No dice lo contrario)

skip-networking #No aceptará conexiones tcp-ip

Esto implica que cualquier usuario que tenga acceso será a través del ssh, logeandose como admin...pero si hemos llegado a eso a quien le importa el mysql, estaremos vendidos!

Por otra parte, he cambiado los permisos (únicamente rw de admin) de /var/log/

• mysql.err
• mysql.log
• /mysql/error.log

Teniendo acceso de root al mysql podriamos:

• Cambiar el nombre del root por otro cualquiera, haciéndolo menos identificable. Así como poner un password complejo
• Eliminar una posible base de datos de prueba llamada “test”. Que por lo visto suele tener problemas de seguridad
• Eliminar al menos 3 usuarios inutiles, como podrían ser demo-user y debian-sys-maint

Así que si a alguien se le ocurre bienvenido sea!!

Tras eso he hecho un /etc/init.d/mysql restart, que me ha devuelto un Ok! Así que está funcionando!