HoneyPot Easy. Parte II
En anteriores entradas comenzamos esta seria sobre los Honeypots y demás.
Donde configuramos el Honeypot?. Hay mucha literatura sobre donde colocar el honeypot y las herramientas de monitorización. Como todo en esta vida, depende del "hierro" o hardware que tengas, porque no siempre tenemos routers y firewalls libres para canalizar las conexiones como nos gustaría.
Una configuración avanzada podría ser colocar el honeypot dentro de nuestra red de producción, otra configuración podría ser usando switch gestionables que te permitan el Mirroring port. Físicamente se conecta al switch la máquina que hace de honeypot y se conecta en otra boca la máquina que monitoriza. De esta manera, tendremos todo el tráfico que entra al honeypot replicado en nuestra máquina de monitorización. También se me ocurre que en switch´s baratos/viejos, sin capacidad gestionable, realizar un ataque interno ARP SPOOF para desviar todo el tráfico hacia una ip distinta a la original, y así poder monitorizar desde otro pc, pero los switch modernos detectan ataques ARP FLOOD y puede que se ponga en modo hub, y ya no podamos realizar el Snnifing.Otra ubicación, creo que lá más sencilla, es colocar nuestro honeypot en una DMZ, que bien puede ser configurada por un firewall, un router, o caseramente con dos máquinas haciendo de routing. El bastionado de esta configuración es muy importante, ya que debemos aislar por completo el tráfico desde el honeypot hacia la intranet. Si aislamos el tráfico, debemos ir al honeypot físicamente a recolectar los log´s.
Podríamos habilitar una conexion ssh para poder acceder al server, pero de esta manera tenemos un vector de ataque en el caso de que el atacante consiga comprometer el honeypot. Una idea interesante podría ser utilizar Port Knocking ( J. Federico Hernandez Scarso,Luis A. Floreani) para levantar el servicio cada vez que lo deseemos, pero esto tiene dos pegas importantes. Si cae el servicio que nos brinda el Port Knocking, perdemos la conexión al honeypot. También se me ocurre que si el atacante consigue comprometer el honeypot, e instala un servicio de monitorización por su cuenta, detecte que no hay conexiones de salida, y que tras un icmp, un tcp sym al puerto 500, otro al 1000, y otro al 3000....se establece una conexión SSH hacia una máquina en producción...
Mas cuestiones a tener en cuenta. Máquina física o máquina virtual?
Lo más fácil creo que sería dedicar una máquina física para esto, pero no siempre se cuenta con el recurso, y tiene una pega. En caso de que el atacante comprometa la máquina por completo, restaurar el sistema honeypot requiere volver a instalar/configurar todo.
Si instalamos el honeypot en una máquina virtual, tenemos que tener varias consideraciones. Por ejemplo: no instalar las "Guest Additions" que sin duda revelaría información al atacante sobre un servidor virtualizado. Tambien sería interesante cambiar la Mac por la de un vendedor conocido, por ejemplo si queremos imitar el comportamiento de un router Cisco, o un servidor Hp xD.
Tanto si decidimos implementar una máquina fisica o virtual, tenemos que tener en cuenta que el s.o sobre el cual corre el honeypot debe sufrir un proceso de hardening o refuerzo, para evitar que el atacante no se centre en el "caramelo" que le hemos puesto con un servicio SSH vulnerable, sino en el s.o base.
Tener actualizado el sistema al máximo es imprescindible. Cambiar la cuenta de invitado y administrador de nombre, y poner a ambas una clave robusta. Reforzar los permisos ntfs (en caso de instalarlo en un sistema win) y sobre todo, los de ficheros como:
Format, edit, bootcfg, cacls, csscript,wscript, debug,diskpart,edlin,exe2bin,expand,ftp,mshta,progman, regsvr32, replace,rsh,runas,taskill, etc etc...
Parar los servicios innecesarios en el s.o. y cambiar la cuenta de servicio con la que se inicia.
Reforzar la pila stacks para preveer ataques de D.O.S es vital.Por ejemplo, en windows 2003 se recomienda cambiar estas opciones dentro del registro (2008). Por ejemplo, cambiar el valor para la gestión de puertas de enlace de reserva. Lo que hacemos con este valor del registro es deshabilitar esta opción, para evitar que se cambie la puerta de enlace por una de reserva en caso de problemas de conexion ( D.O.S. del gateway).
Os recomiendo que si vais a trabajar sobre un sistema operativo Ms, busquéis el proceso de como realizar el hardening para esa versión.
Cualquier otro proceso de hardening del sistema operativo que conozcamos deberá ser empleado para garantizar al máximo la seguridad del sistema operativo base. ***Otro día podemos discutir los procesos de consolidación de estos sistemas***
Hay muchas aspectos a tener en cuenta al montar nuestros honeypots, e incluso los expertos en la materia discuten sobre distintas configuraciones y recomendaciones.
Durante la seria de articulos sobre los honeypots iremos viendo mas cosas, pero creo que por hoy ya está bien.
Para la próxima entrega trabajaremos con las máquinas, es decir, pondremos en marcha distintos honeypots, que se qué lo que mas os gusta son los comandos y los hackeos xD.
Un aperitivo... que divertido "juackear" esta máquina !!! xD
Gracias por leerme.
Donde configuramos el Honeypot?. Hay mucha literatura sobre donde colocar el honeypot y las herramientas de monitorización. Como todo en esta vida, depende del "hierro" o hardware que tengas, porque no siempre tenemos routers y firewalls libres para canalizar las conexiones como nos gustaría.
Una configuración avanzada podría ser colocar el honeypot dentro de nuestra red de producción, otra configuración podría ser usando switch gestionables que te permitan el Mirroring port. Físicamente se conecta al switch la máquina que hace de honeypot y se conecta en otra boca la máquina que monitoriza. De esta manera, tendremos todo el tráfico que entra al honeypot replicado en nuestra máquina de monitorización. También se me ocurre que en switch´s baratos/viejos, sin capacidad gestionable, realizar un ataque interno ARP SPOOF para desviar todo el tráfico hacia una ip distinta a la original, y así poder monitorizar desde otro pc, pero los switch modernos detectan ataques ARP FLOOD y puede que se ponga en modo hub, y ya no podamos realizar el Snnifing.Otra ubicación, creo que lá más sencilla, es colocar nuestro honeypot en una DMZ, que bien puede ser configurada por un firewall, un router, o caseramente con dos máquinas haciendo de routing. El bastionado de esta configuración es muy importante, ya que debemos aislar por completo el tráfico desde el honeypot hacia la intranet. Si aislamos el tráfico, debemos ir al honeypot físicamente a recolectar los log´s.
Podríamos habilitar una conexion ssh para poder acceder al server, pero de esta manera tenemos un vector de ataque en el caso de que el atacante consiga comprometer el honeypot. Una idea interesante podría ser utilizar Port Knocking ( J. Federico Hernandez Scarso,Luis A. Floreani) para levantar el servicio cada vez que lo deseemos, pero esto tiene dos pegas importantes. Si cae el servicio que nos brinda el Port Knocking, perdemos la conexión al honeypot. También se me ocurre que si el atacante consigue comprometer el honeypot, e instala un servicio de monitorización por su cuenta, detecte que no hay conexiones de salida, y que tras un icmp, un tcp sym al puerto 500, otro al 1000, y otro al 3000....se establece una conexión SSH hacia una máquina en producción...
Mas cuestiones a tener en cuenta. Máquina física o máquina virtual?
Lo más fácil creo que sería dedicar una máquina física para esto, pero no siempre se cuenta con el recurso, y tiene una pega. En caso de que el atacante comprometa la máquina por completo, restaurar el sistema honeypot requiere volver a instalar/configurar todo.
Si instalamos el honeypot en una máquina virtual, tenemos que tener varias consideraciones. Por ejemplo: no instalar las "Guest Additions" que sin duda revelaría información al atacante sobre un servidor virtualizado. Tambien sería interesante cambiar la Mac por la de un vendedor conocido, por ejemplo si queremos imitar el comportamiento de un router Cisco, o un servidor Hp xD.
Tanto si decidimos implementar una máquina fisica o virtual, tenemos que tener en cuenta que el s.o sobre el cual corre el honeypot debe sufrir un proceso de hardening o refuerzo, para evitar que el atacante no se centre en el "caramelo" que le hemos puesto con un servicio SSH vulnerable, sino en el s.o base.
Tener actualizado el sistema al máximo es imprescindible. Cambiar la cuenta de invitado y administrador de nombre, y poner a ambas una clave robusta. Reforzar los permisos ntfs (en caso de instalarlo en un sistema win) y sobre todo, los de ficheros como:
Format, edit, bootcfg, cacls, csscript,wscript, debug,diskpart,edlin,exe2bin,expand,ftp,mshta,progman, regsvr32, replace,rsh,runas,taskill, etc etc...
Parar los servicios innecesarios en el s.o. y cambiar la cuenta de servicio con la que se inicia.
Reforzar la pila stacks para preveer ataques de D.O.S es vital.Por ejemplo, en windows 2003 se recomienda cambiar estas opciones dentro del registro (2008). Por ejemplo, cambiar el valor para la gestión de puertas de enlace de reserva. Lo que hacemos con este valor del registro es deshabilitar esta opción, para evitar que se cambie la puerta de enlace por una de reserva en caso de problemas de conexion ( D.O.S. del gateway).
Cualquier otro proceso de hardening del sistema operativo que conozcamos deberá ser empleado para garantizar al máximo la seguridad del sistema operativo base. ***Otro día podemos discutir los procesos de consolidación de estos sistemas***
Hay muchas aspectos a tener en cuenta al montar nuestros honeypots, e incluso los expertos en la materia discuten sobre distintas configuraciones y recomendaciones.
Durante la seria de articulos sobre los honeypots iremos viendo mas cosas, pero creo que por hoy ya está bien.
Para la próxima entrega trabajaremos con las máquinas, es decir, pondremos en marcha distintos honeypots, que se qué lo que mas os gusta son los comandos y los hackeos xD.
Un aperitivo... que divertido "juackear" esta máquina !!! xD
