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.
