martes, 11 de diciembre de 2018

Los 10 mandamientos de un servidor | 9. No consentirás testeos ni accesos impuros

****************************************************************************
1. Los 10 mandamientos de un servidor | 1. Amarás las nuevas máquinas sobre todas las cosas
2. Los 10 mandamientos de un servidor | 2. No tomarás los servicios instalados en vano
3. Los 10 mandamientos de un servidor | 3. Santificarás la arquitectura de tu empresa
4. Los 10 mandamientos de un servidor | 4. Honrarás la configuración de tus servicios
5. Los 10 mandamientos de un servidor |5. Instalarás todos los programas necesarios
6. Los 10 mandamientos de un servidor | 6. No cometerás actos impuros con tus llaves SSH
7. Los 10 mandamientos de un servidor | 7. No te olvidarás de migrar los datos
8. Los 10 mandamientos de un servidor | 8. No te instalarás falsas aplicaciones
9. Los 10 mandamientos de un servidor | 9. No consentirás testeos ni accesos impuros
****************************************************************************

Esta serie llega a su fin, ojalá pasara igual con el poder y los abusos de la Iglesia, pero bueno, algo tiene que ir terminando y parece que será esta serie. Y es que como ya hemos hecho "lo gordo" en la migración de servidores, ahora lo que nos quedaría sería testear que todo lo que hayamos hecho está bien. 


Por supuesto, tendremos que comprobar, si hemos pasado datos, si los permisos y los ownerships están correctos. Esto es importante para evitar casos como los de la Universidad de Extremadura y la filtración de preguntas del examen de selectividad. Y ojo que puede dar muchos problemas por la tontería de escoger Red Hat en lugar de un Debian puro. Porque, como ya os dije, escoger la distro es fundamental.


Porque cuando hablo de testeos, por supuesto tambiénhablo de seguridad. Es que es elemental. Para este post he vuelto a cambiar el puerto del SSH para que esté por default y vemos como lo sacamos. No es que si lo cambiamos ya no lo veamos, no, pues cambiando el comando lo podríamos sacar, pero ya no sería con la ejecución "normal" y básica de nmap.

Tendríamos que ir a páginas como CVE Details para ver si, por ejemplo, nuestra versión de Apache es vulnetrable y existe algún módulo publicado de Metasploit para explotarlo más fácilmente.


Con herramientas como nikto podemos comprobar también si nuestra web tiene alguna vuln conocida, aunque ¡ojo! no detectará 0-days. A pesar de tener herramientas como estas, también debemos checkear lo que salga a mano. Debemos comprobar si, además tiene algún RFI o XSS en la web. Podemos ver si tiene alguna debilidad que permita sacar información que pueda ser útil en, por ejemplo, un ataque dirigido. 


Y empezamos a auditar. Decir que yo voy a poner algunos ejemplo, pero la auditoría que tenemos que pasar tiene que ser exahustiva, no podemos dejar nada sin mirar y no podemos dejar nada sin revisar. No lo voy a comentar, pero ni que decir tiene que tenemos que buscar cosas como, por ejemplo, si es posible sacar direcciones de correo con OSINT. Tenemos que probar si podemos sacar usuarios del Apache. Para esto necesitaremos un diccionario con algunos usuarios, pues qué mejor que crear un script que lance theharvester y esos resultados los corte por "@" obteniendo solamente lo que hay delante del @ y pase ese output editado a un archivo que será nuestro diccionario. Por ejemplo.


Y sé que últimamente estoy muy pesado con el tema de SSH, pero es que veo que hay gente que, realiza configuraciones, pero sin saber el qué y el por qué de esa acción. Ya hablé sobre cómo dar esteroides a nuestro SSH, y ahí ya dejé alguna indirecta. Para mí no sirve de nada habilitar la política de login con par de claves si la política de hacer login sin password no se deshabilita.


Yo no concibo otra configuración idónea que no sea habilitando el login con el par de claves priv/pub y deshabilitando la autenticación con contraseña.



Con esta configuración, un atacante que conozca el usuario y la contraseña, no podría acceder a menos que tenga la clave pública. De lo contrario, si nos realizan un ataque donde logran conocer nuestras credenciales, podrían acceder sin el mayor problema.

Sobre cómo obtener esta información, pues nada, es fácil, podemos empezar enumerando y sacando usuarios ssh y posteriormente tratar de obtener la password mediante, por ejemplo, fuerza bruta, aunque nos encontraremos el problema de que al número de intentos X, nos desconectarán. Ahí entra en que el sysadmin, en el archivo de configuración de más o menos intentos y de la habilidaddel atacante de crear un script automatizado que analice si estás intentando acceder a ssh o no(porque superes el número de intentos) y vuelva a levantar una conexión. Si la empresa no tiene política de iptables, entonces tendremos un escenario bastante favorable para el atacante.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...