Codigo, ¡¡¡¡eres libre!!!!

Como comenté en la anterior post, hace tiempo escribí como utilizar los elementos de red: proxy-web y DNS interno, como herramientas (otra más) para minimizar las infecciones por malware. Más concretamente para minimizar la efectividad de los denominados "downloaders".

En la solución propuesta comenté que el DNS interno de la solución sólo debería resolver las peticiones de resolución del/de los dominio/s internos, y que las peticiones de resolución de dominios externos que le lleguen debería ir a un DNS "fake" que respondiera con la dirección IP de un servidor web que recibiera las posteriores comunicaciones (HoneyPot) y las reenviara a un OSIM.

Bueno, pues después de tanto tiempo, hoy toca mostrar los códigos ... , aunque antes pasaré a describir puntos importantes de la solución desarrollada:

1.- En mi caso, la funcionalidad de DNS "fake", así como la de HoneyPot se ubican en el mismo servidor (Linux, por supuesto).

2.- Ambos script se desarrollaron en python ... ¿por qué no?

3.- Los mensajes informativos sobre el comportamiento de los scripts, como por ejemplo, la información sobre las IPs que han solicitado resolver algún dominio externo a los dominios que se gestionan en el servidor DNS interno, así como, las IPs y URLs que se comunican con el HoneyPot, son almacenadas en los logs del sistema. Estos logs son enviados a través de "syslog" a una herramienta OSIM, que permitirá su almacenamiento y su correlación.

4.- El servicio "syslog", realmente es "rsyslog" (por el aporte de seguridad dado), por lo que se  debe instalar en el servidor, si no lo estuviera ya.

NOTA: No se habla sobre este proceso en este post por considerarlo fuera de los objetivos del susodicho post. Existe mucha información en Internet sobre su instalación

Bueno ahora, definitivamente se pasa a mostrar el código del: DNS "fake" (fakeDNS.py).

Código generado del script denominado: FakeDNS.py.

Y se sigue con el código del: HoneyPot  (MiniHoneyPot.py).

Código generado como: MiniHoneyPot.py.

MEJORAS QUE SE IMPLEMENTARÓN

1.- El HoneyPot admite un parámetro que se corresponde con el puerto a abrir, en mi caso, creé un lanzador (¡la imaginación al poder!) que permite abrir los puertos incluidos en un fichero con la intención de controlar otros posibles medios de comunicación, no sólo el puerto 80/TCP (HTTP).

Un ejemplo de los puertos que se pueden levantar en el HoneyPot.

2.-  Los scripts generados han sido incluidos dentro del servidor como servicios/demonios, para que se ejecuten siempre que la máquina se reinicie y sin necesidad de validarse dentro del sistema.

Hasta aquí todo, y recuerda ... lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia.