Hola de nuevo, aquí estamos con otra entrada. A decir verdad, me cuesta un poco la manera de catalogarla si como un ataque en sí mismo o bien como como un ataque que sirva de pantalla a otro. Bueno, principio quieren las cosas, así que vamos a ello.
Vamos a dejar momentáneamente las cuestiones técnicas a un lado para charlar un poco de otros conceptos. Cuando se trata de auditar o realizar un test de penetración no siempre hemos de ir directos contra nuestro objetivo. Esto es, quizás debemos comprometer primero un equipo o sistema y luego desde éste, dirigirnos al objetivo en cuestión. ¿Qué es lo que quiero decir con esto? Que muchas veces deberemos dar un “rodeo” o dar pasos “intermedios” para conseguir nuestro fin. Este es el concepto número 1.
Una vez dentro de ese proceso de “pentesting” una premisa es hacer el menor “ruido” posible para no ser descubierto ya que eso mismo es lo que trataría de hacer un atacante. Un atacante, procurará ser sigiloso, discreto, cauto, no sólo para no levantar sospechas sino para que las distintas medidas y equipos de seguridad no hagan saltar alarmas y delaten su presencia. Obviamente, no empleará configuraciones “por defecto” sino que modificará los parámetros, campos, según sus necesidades. Sin embargo, esto no tiene por qué ser siempre así. Me explico. La idea es que no te detecten, pero esto también puede lograse haciendo mucho ruido y colándote entre la multitud. Imaginemos a un ladrón que ha conseguido burlar las medidas de seguridad de un banco; se hace con el botín; tira una bomba de humo o gas lacrimógeno y hace que todos los clientes entren en “modo pánico” y salgan despavoridos de la oficina, entre ellos, el ladrón. Este es el concepto número 2.
Bueno, se me olvidaba. Para que el ladrón burle las medidas de seguridad una buena opción podría ser suplantar la identidad (spoofear) de algún miembro del personal del banco. Este es el concepto número 3.
Vale, vale, tanto rollo ¿para qué? ¿Qué tiene que ver esto con Syslog? Venga va, ahora sí nos metemos con las cuestiones técnicas.
Syslog es un protocolo con el que podemos hacer que un equipo o sistema (cliente) envíe a un servidor mensajes que informen sobre eventos en él. Entre otras cosas, podría ser:
1.- Acceso correcto o incorrecto al sistema.
2.- Anomalías de algún tipo.
3.- Cambios en las configuraciones.
4.- Errores en los sistemas.
5.- Otros…
Existen servidores de pago y también algunas versiones gratuitas como Free Kiwi Syslog Server u otros que podréis encontrar en Sourceforge. Iros allí y buscar por la palabra, como es lógico, Syslog.
Para esta entrada voy a tener 3 equipos. Un router virtualizado con GNS3, un servidor Syslog con el software Free Kiwi Syslog Server y un equipo con Kali Linux. Estos últimos en máquinas virtuales.
Aquí os dejo una muestra de lo que sería mensaje de un login del usuario “netadmin” al router.
Deshabilitar y habilitar de la interfaz Fastethernet 1/1.
El tipo de mensaje que recibamos irá en función del nivel de aviso que queramos que se nos comunique. A más nivel, mayor control de lo que pasa pero también tendremos más cantidad de mensajes y, dependiendo el número de equipos, que tengamos pues puede llegar a ser un poco caótico.
Esto es yendo a buenas pero ¿qué pasaría si alguien intentase lanzar un ataque para ganar acceso a nuestro equipo mediante la herramienta THC-Hydra?
Por cada intento de conexión recibiremos un aviso.
Una de las posibilidades que nos puede ofrecer el software de servidor Syslog es que cada aviso que recibamos podremos enviarlo a su vez por correo electrónico, lo cual puede llegar a ser de gran utilidad si creamos una cuenta específica para el servidor y recibimos los avisos a nuestro correo. Lo digo no para dar más trabajo sino para esos puestos que requieran hacer guardias o disponibilidad 24×7, etc.
Sin embargo, ¿son todo ventajas? Tal vez no, puede haber algún inconveniente. Eso lo dejamos para la próxima….