Estimados amigos de Inseguros !!!
En este episodio de hoy vamos a hablar de Honeypots !!! Siii ,no es el primero que publico, creo que llevo ya 15. Puedes leerlos desde esta búsqueda.
Todos los artículos de Honeypots en Inseguros.
Cuando uno quiere aprender sobre una materia, yo siempre aconsejo que lea. No que lea esta u otra página. Esto puede servir para ahorrarte un tiempo, para entender un proceso, o para seguir un procedimiento concreto, pero los libros son los libros. Si quieres introducirte DE VERDAD en el mundo de los honeypots, tendrás que leer los clásicos. Para mi, estos son:
Honeypots: Tracking Hackers
Honeypots for Windows.
Know Your Enemy
Virtual Honeypots
Como es normal, todo el material vale. Recuerdo la primera Navaja Negra con
Pedro Candel y su magistral
introducción a los Honeypots.
Otra persona que le ha dado mucha cera a esto es mi lider
Fran. Un tipo humilde que tiene un gran recorrido en esta materia. Quizás sea de los pocos que conozco que realmente le saca provecho a todo esto. GRANDE FRAN !!!
Siempre que leo post sobre honeypots, aparece el típico manual de Kippo, un honeypot para SSH y una breve aproximación del autor.
La finalidad de los honeypots siempre se menciona, pero luego en las implementaciones o usos que se le dan detecto que se usan como meros recopiladores de direcciones ip de "atacantes", un IoC con muy poco valor. Siempre lo digo en mis charlas sobre Threat Intelligence, una IP no es un dato muy relevante, y mucho menos si es un "ataque" de hace 1 mes... También podríamos discutir un poco de si un portscan es un ataque. Yo prefiero cortarlo y banear un rato por si acaso, al igual que si detecto un user-agent peligroso, pero realmente la información que se obtiene con este tipo de implementaciones es poca.
Que hay bots recorriendo el espacio ipv4 en busca de vulnerabilidades, es muy conocido, basta con tener los sistemas actualizados y listo. Me dirás que te pueden servir para detectar nuevos ataques y zero days, un clásico en la berborrea de las funcionalidades de los honeypots, pero si tienes un honeypots con un ids (basado en firmas CONOCIDAS) y miles de ataques, algunos los detectará el IDS, otros no, ahí van los zero days, y yo me pregunto, vas a revisar todos los logs y capturas de red para detectar ese ataque? Como discriminas los ataques conocidos al Tinymce de Wordpress con nuevos ataque? DIFICIL.
Otra de las "bondades" que leo para usar los honeypots es la distracción. Yo me pregunto, si tienes un servidor por el mundo con un puerto 22 abierto o un web server, que NO tienen vinculación con tu organización o empresa, no estás distrayendo a nadie. Estás recopilando ataques NO DIRIGIDOS con poco o ningún valor. Algo de valor tienen, pero cualquier blacklist que manejes medio decente tendrá estas direcciones, y lo dicho, son ataques muy conocidos y detectados por las soluciones de seguridad.
Para detectar ataques dirigidos debes usar herramientas de seguridad "de verdad" como un SIEM que detecte que tienes un ataque de fuerza bruta, desde la red tor, a varios sistemas ssh de una organización con varias ip públicas, y que está usando un diccionario fragmentado en el que la ip1 se prueba con claves de la A la F, la ip2 se prueba con claves G a M y así sucesivamente, por decir algo....
Después de esta aproximación, llanto, queja o como quieras llamarlo, vamos a hacer algo interesante para mi con un honeypots. En un entorno de pruebas, voy a instalar un servidor web con Modsecurity y voy a redirigir el tráfico malicioso hacia un honeypot. De esta manera SI que estaré distrayendo la atención del atacante ya que el tiempo que invierte en atacar al honeypot lo puedo usar para investigar COMPLETAMENTE sus movimientos.
Lo importante de esta aproximación es que el honeypot debe estar completamente capado a nivel de red del resto del entorno de producción. Yo voy a usar un mismo sistema por comodidad, pero debería ser equipos distintos.
Lo único que voy a hacer es meter una regla básica que detecte un user-agent concreto, en este caso Nikto, y que me haga un redirect a Google:
SecRule REQUEST_HEADERS:User-Agent "Nikto" "phase:1,id:1,log,redirect:http://www.google.es"
--9935a602-A--
[03/Dec/2016:19:51:41 +0100] WEMUPX8AAQEAABu53GIAAABE 192.168.1.242 54461 192.168.1.206 80
--9935a602-B--
GET /administrator/ HTTP/1.1
Host: 192.168.1.206
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36
nikto
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: es-ES,es;q=0.8
If-None-Match: "61-542c580c7d636-gzip"
If-Modified-Since: Sat, 03 Dec 2016 18:48:40 GMT
--9935a602-H--
Message: Access denied with redirection to http://www.google.es using status 302 (phase 1). Pattern match "nikto" at REQUEST_HEADERS:User-Agent. [file "/etc/modsecurity/modsecurity.conf"] [line "226"] [id "130"]
Entonces, tenemos un webserver en producción, con mod_security y este tipo de reglas. Tenemos otra máquina honeypot con tcpdump o similar corriendo. Si quieres meter ahí un IDS me parece bien, pero lo interesante es el contenido completo del tráfico.
Una de las cosas que tenemos que hacer es jugar con la opción
EXEC de las reglas para ejecutar comandos. Sería una buena idea redirigir TODO el tráfico de la ip de origen hacia el honeypot, no solo mediante el redirect a nivel http, comprendes? Me explico:
Si el mod_security detecta un "ataque" en base a una regla, por ejemplo, que has buscado el directorio /administrator/ de un Joomla, podemos hacer el redirect comentado. Imagina que el atacante sigue buscando información pero usa un "zero day" o algo que el Waf no detecta, como no se ejecuta ninguna regla, se procesaría contra el servidor en producción. Si previamente hemos hecho un redirect a nivel TCP/IP en el firewall, TODO el tráfico del atacante pasará hacia el honeypot. Una manera de redirigir el tráfico una vez hemos obtenido la dirección ip del atacante es
mediante este sencillo procedimiento. para el caso de iptables. Esta acción debería hacerse en el firewall que hay delante del webserver, por lo que si es un vps o servidor publicado no hay problema. Si es una DMZ de una empresa, deberíamos hacerlo a nivel del firewall perimetral, no del instalado en el webserver...
**********PEGAS: Cuando usamos la opción EXEC de mod_security podemos usar cualquier lenguaje instalado en el servidor, pero si queremos recoger una variable del log, como en el caso mencionado, la dirección ip de origen del ataque, debemos usar el lenguaje LUA. Esto complica un poco el asunto.
Yo en mis despliegues suelo tener un script.sh "baneador" que pasandole un parámetro IP, se conecta por ssh al firewall y mete la ip en una blacklist. Esto lo puedes hacer en cualquier tipo de firewall. Sin embargo, programar eso en LUA me cuesta. Qué hago? Escribo en lua un log en un fichero, y con eso, ejecuto el script con la ip. Poco elegante pero funcional. Sería algo así...
function main()
local remote_addr = m.getvar("REMOTE_ADDR");
if remote_addr == nil then
return nil
end
local log_file = "/var/log/ñampazampa/modsec_full.log"
file = io.open(log_file,"a")
file:write("IP: "..remote_addr.."\n"..")
file:close()
os.execute("/var/scripts/router_ban.sh "..remote_addr.."'")
end
*******
Podemos "jugar" con la opción de redirect con distintas aproximaciones. Por ejemplo, vamos a hacer una redirect para un recurso concreto si no es de la ip designada:
SecFilterSelective REMOTE_ADDR “!192.168.1.2” chain
SecFilterSelective REQUEST_URI “/wp-login.php” log,deny,redirect:http://www.google.es
Un detalle importante, si controlas el acceso desde httaccess con user-agents, direcciones ip, extesiones o directorios, no se procesa la regla en modsecurity y no se ejecuta el redirect.
Si queremos hacer el redirect con algún tipo extensión podemos hacer algo así:
SecRule REQUEST_LINE "@rx .php" "log,deny,redirect:http://www.google.es'"
No controlo mucho más ModSecurity ni esto es un tutorial al respecto, pero el concepto de introducir el Redirect tanto a nivel conexiones como a nivel http me parece muy interesante para usar con honeypots para realmente distraer y aprender, cualificar un poco más los ataques, y sobre todos, aquellos dirigidos hacia nuestras infraestructuras.
Ahora nos vamos a poner un poco en plan golfo. En España es ILEGAL atacar a nadie, aunque este te esté atacando a ti, pero qué pasaría si ponemos de señuelo un fichero exe con un malware, meterpreter o similar? Que pasaría si hacemos lo mismo con una macro y un password.doc? Sería la risa detectarle el tipo de router y meter un CSRF pero todo esto es Ilegal. Aprovecho tambien para decir que si tu pones un honeypot para que te ataquen, y te consiguen vulnerar el sistema, la ley no te ampara. La ley nunca nos ampara !!! pero al haber incitado al "delito" lo mismo el que te metes en un lio eres tu.
Lo más sencillo y solo para esta prueba, es hacer una redirección al atacante hacia
BEEF, un framework de explotación web que mediante un script "secuestra" el navegador para realizar distintas bondades.
Esto sería un claro ejemplo de atacando al atacante :-)
Gracias a todos por leerme !!!
PD: Este artículo se lo voy a dedicar a Sauron, el señor que todo lo ve. Para mi es una persona de las mas valiosas que hay en este mundillo. Siempre me ha tratado como si fuera importante, me hace sentir importante. Esta cualidad solo la tiene la gente IMPORTANTE de verdad. Gracias por todo. Espero que te guste !!!
