Manual de clonezilla: creación de imágenes del disco duro

Como algunos ya sabréis, clonezilla es un programa que nos permite crear imágenes de nuestro disco duro, de modo que después podamos volcarlas en el mismo equipo (a modo de copia de seguridad del sistema) o en otro con iguales características (para tener varios equipos instalados con el mismo software).

Es un sistema muy usado cuando queremos, por ejemplo, instalar el mismo software en una sala de ordenadores de iguales o similares características. Pensemos en un aula de informática de un instituto; la idea sería instalar todos los sistemas operativos y software que queramos en un equipo, para después poder replicarlo en el resto de equipos del aula.

Existe numeroso software para realizar esta tarea, desde alguno comercial como Norton ghost, a otros programas libres como g4l -ghost for linux- (del cuál tenéis múltiples manuales en el enlace anterior) y el que hoy nos ocupa clonezilla (tras las pruebas que hemos hecho el más rápido y completo de todos).

Por supuesto podremos subir la imagen (es un fichero resultado de comprimir todo el software qaue hayamos instalado en un equipo y que después llevaremos al resto para replicar todas las instalaciones) de múltiples maneras: a un disco usb externo, a otro disco duro, a un servidor nfs, a un servidor samba (o una carpeta compartida de windows), a un servidor ssh,...; para iniciar la instalación también tenemos múltiples maneras: desde un cd, desde un usb, arrancando desde la red mediante un servidor drbl.

En este post en concreto, voy a explicar cómo subir una imagen desde un equipo que ha sido arrancado desde una imagen de clonezilla en cd o usb a un servidor ssh para después desplegarla desde el mismo a otro equipo. El proceso es casi igual para un servidor samba o nfs.

Los únicos requisitos son tener un cd o usb de arranque con el sistema clonezilla y un servidor ssh instalado y accesible.

Seleccionamos en nuestra bios el arranque desde el cd/usb que habremos preparado previamente con clonezilla.

1. Nos aparece el menú inicial dónde seleccionamos qué tipo de interfaz preferimos:
2. Seleccionamos el idioma entre los disponibles: inglés, francés, chino,..
3. Seleccionamos el teclado: (sino vais a emplear la línea de comandos no es necesario que lo cambiéis al castellano, podéis dejar el inglés que trae por defecto).
4. Escogemos entre línea de comandos o interfaz "gráfica" : lo más sencillo es el modo gráfico
5. Seleccionamos qué tipo de imagen vamos a realizar, de disco a imagen o de disco a disco. Seleccionamos de disco a imagen.
6. Dónde vamos a subir la imagen: a un disco local, a un servidor nfs, ssh,.... Seleccionamos "ssh server"
7. Seleccionamos el modo de configurar la ip del equipo que queremos clonar. Si tenemos un servidor de DHCP en nuestra red seleccionamos "dhcp", en otro caso seleccionamos "static" y en la siguiente pantalla introduciríamos la ip que debe estar dentro del rango de ips de nuestra red. Yo selecciono "dhcp" de modo que tomará la dirección automáticamente del servidor.
8. Dirección ip del servidor ssh a dónde subiremos nuestra imagen del equipo que estamos clonando.
9. puerto en el que escuch a el servidor ssh, "22" por defecto:
10. Nombre (login) del usuario con permiso de escritura en el directorio del servidor ssh dónde vamos a subir el fichero de imagen, p.e. "root":
11. Directorio del servidor ssh en dónde grabaremos el fichero de nuestra imagen: "/imagen"
12. Nos advierte de que tendremos que introducir la contraseña del usuario previamente introducido
13. Debemos aceptar la llave del servidor ssh, para ello tecleamos "yes"
14. Introducimos la clave del usuario
15. Seleccionamos el modo que vamos a emplear: salvar la imagen de todo el disco, restaurar la imagen de todo el disco, salvar una partición, restaurar una partición,... Yo selecciono "savedisk" para subir la imagen completa de todos los discos y particiones del equipo:
16. Le damos un nombre al fichero que albergará nuestra imagen
17. Seleccionamos, de los disponibles, el disco duro del que queremos crear la imagen
18. Seleccionamos las aplicaciones con las que vamos a clonar los discos, suelo seleccionar la primera:
19. Seleccionamos algunas opciones adicionales (suelo dejar las marcadas por defecto)
20. Compresión a emplear en el fichero, suelo emplear "lzo"
21. Tamaño del fichero o ficheros que constituyen la imagen, en caso de darnos igual (no lo vamos a grabar en un cd, dvd o usb) dejaremos "0", de modo que tan sólo creará un único fichero que contendrá toda la información:
22. Qué hacer cuándo ha finalizado la clonación: no hacer nada (lo que suelo seleccionar para saber si todo ha ido bien), reiniciar el equipo ó apagarlo.
23. Última pregunta de confirmación antes de comenzar a subir la imagen respondemos "y"
24. si todo ha ido bien...

Restaurar la imagen previamente creada con clonezilla:


En este caso, lo que vamos a hacer es volcar una imagen que habremos creado con el método anterior en un nuevo equipo de iguales características (o en el mismo en caso de fallo). Para ello partiremos de la situación anterior en la que tenemos el servidor ssh funcionando y con, al menos, una imagen previamente creada.

hasta el punto 14 de la guía anterior sería exactamente igual:

15.- En este caso vamos a restaurar una imagen completa de un disco duro, por lo que seleccionamos "restoredisk"16. Seleccionamos de entre todas las imágenes disponibles en el directorio del servidor ssh aquella que queremos volcar en nuestro equipo (en este caso yo sólo dispongo de una)
17. Seleccionamos el disco duro de destino en el que vamos a volcar la imagen (en este caso sólo tengo un disco)
18. Opciones adicionales (dejo las marcadas por defecto)
19. Qué hacer con la tabla de particiones: emplear la de la imagen, redimensionar,...
20. Qué hacer cuándo ha finalizado la clonación: no hacer nada (lo que suelo seleccionar para saber si todo ha ido bien), reiniciar el equipo ó apagarlo.
21. Nos advierte de que en caso de continuar eliminaremos todos los datos de nuestro disco duro, si queremos continuar pulsamos "y".

POR SUPUESTO ESTE TUTORIAL ES MERAMENTE INFORMATIVO Y NO ME HAGO RESPONSABLE DE NINGUNA PERDIDA DE DATOS PRODUCIDA COMO CONSECUENCIA DE SU USO.

Enlaces relacionados:

Instalar y configurar un servidor drbl para cargar y volcar clonezilla mediante red: servidor drbl.

Manual de Honeyd (VI). Honeyd

d.- Honeyd

La instalación en Ubuntu de honeyd es muy sencilla, simplemente ejecutaremos:

apt-get install honeyd

y el sistema instalará la lista de paquetes necesarios incluyendo algunos ficheros de configuración básicos. 

Una vez hecho podemos echarle un vistazo al directorio /etc/honeypot dónde nos encontraremos un fichero de configuración de ejemplo junto con los ficheros de firmas de nmap, p0f y xprobe. Los ficheros de firmas los empleará honeyd para engañar a escaneos activos y pasivos cuando otros sistemas traten de averiguar el sistema operativo que está simulando. El fichero de configuración “honeyd.conf” puede servirnos de guía para crear nuestro propio fichero dónde simularemos nuestra red. 

En mi caso he decidido simular tres máquinas en el mismo rango de red que la de producción, los equipos y servicios, tal y cómo se puede ver en la primera imagen del guión son: windows2003 server, windows XP y Suse 8.0 (no todos los puertos están redirigidos desde fuera). El fichero de configuración será el siguiente:

### Máquina Windows 2003

create win2k

set win2k personality "Microsoft Windows Server 2003 Standard Edition"

set win2k default tcp action reset

set win2k default udp action reset

set win2k default icmp action reset

set win2k uptime 3867

set win2k droprate in 13

add win2k tcp port 80 "/usr/share/honeyd/scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport"

add win2k tcp port 110 "/usr/share/honeyd/scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport"

add win2k tcp port 143 "/usr/share/honeyd/scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport"

# Ejemplo de una plantilla para Windows Xp

create template

set template personality "Microsoft Windows XP Professional SP1"

set template uptime 1728650

set template maxfds 35

# Servidor web

add template tcp port 80 "/usr/share/honeyd/scripts/web.sh"

add template tcp port 22 "/usr/share/honeyd/scripts/test.sh $ipsrc $dport"

# Debian-specific (use nobody = 65534 instead of 32767)

set template uid 32767 gid 32767

### Plantilla Linux Suse 8.0

create suse80

set suse80 personality "Linux 2.4.7 (X86)"

set suse80 default tcp action reset

set suse80 default udp action block

set suse80 default icmp action open

set suse80 uptime 79239

set suse80 droprate in 4

add suse80 tcp port 21 "/usr/share/honeyd/scripts/unix/linux/suse8.0/proftpd.sh $ipsrc $sport $ipdst $dport"

add suse80 tcp port 22 "sh /usr/share/honeyd/scripts/unix/linux/suse8.0/ssh.sh $ipsrc $sport $ipdst $dport"

add suse80 tcp port 25 "/usr/share/honeyd/scripts/unix/linux/suse8.0/sendmail.sh $ipsrc $sport $ipdst $dport"

add suse80 tcp port 79 "sh /usr/share/honeyd/scripts/unix/linux/suse8.0/fingerd.sh $ipsrc $sport $ipdst $dport"

add suse80 tcp port 80 "/usr/share/honeyd/scripts/unix/linux/suse8.0/apache.sh $ipsrc $sport $ipdst $dport"

add suse80 tcp port 3128 "sh /usr/share/honeyd/scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport"

add suse80 tcp port 8080 "sh /usr/share/honeyd/scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport"

add suse80 udp port 514 "/usr/share/honeyd/scripts/unix/linux/suse8.0/syslogd.sh $ipsrc $sport $ipdst $dport"

create default

set default default tcp action block

set default default udp action block

set default default icmp action block

bind 192.168.0.22 suse80

bind 192.168.0.23 win2k

bind 192.168.0.24 template

bind 192.168.0.25 template

bind 192.168.0.26 template

Los pasos para crear y configurar cada una de las máquinas que simulará son los siguientes:

1. Empleamos “create” para crear una máquina a simular y darle un nombre.
2. Elegimos que tipo de equipo vamos a simular con “set nombre personality “Sistema operativo” ”. Para elegir el sistema operativo podemos elegir uno de los listados en el fichero /etc/honeypot/
3. Podemos seguir estapleciendo una serie de parámetros con la opción set, como pueden ser, las acciones a realizar cuando reciba paquetes, udp, tcp, icmp, tiempo que lleva activa la máquina, cambiar los permisos de ejecución de honeyd,...
4. Añadimos los protocolos y puertos que tendrá abiertos la máquina e incluso el script que queremos que ejecute cuando llegue un paquete, lo que permitirá simular determinados servicios.
5. Vinculamos cada máquina creada a una ip con bind: bind “ip” “nombre_máquina”

Una vez creado el fichero lo ponemos en marcha indicándole: que no demonice el servicio y que muestre por pantalla información detallada (“-d”), la interfaz en la que queremos que escuche (-i eth2) los ficheros de firmas que ha de emplear para búsqueda de huellas del sistema operativo dependiendo del programa de reconocimiento que emplee el atacante (nmap.prints, xprobe2.conf y pf.os) indicamos dónde buscar las asociaciones de sistemas operativos (nmap.assoc), finalmente almacenará todos los logs en /var/log/honeypot/honeyd.log; incluiré las opciones de inicialización en un fichero ejecutable llamado arrancar_honeyd:

honeyd -d -i eth2 -f /etc/honeypot/honeyd_uned.conf -p /etc/honeypot/nmap.prints –x /etc/honeypot/xprobe2.conf -0 /etc/honeypot/pf.os -a /etc/honeypot/nmap.assoc -l /var/log/honeypot/honeyd.log

vemos que se conecta sin problemas y lanza el script web.sh que simula un servidor web, el cliente vería la siguiente imagen, ya que para comprobar que funciona nos conectamos, por ejemplo al servidor web de nuestra red:

Además los scripts también tienen sus ficheros de log como podemos ver en el siguiente punto.

e.- Ficheros de registro de la actividad.

En resumen, con la configuración previa habremos recogido información en los siguientes lugares:

• logs “genéricos”

• /var/log/syslog: honeypot vuelca su información en este lugar además del fichero que le marquemos
• /var/log/iptables: conexiones que se ajustan a las reglas que he configurado en iptables
• logs de honeyd
  • /var/log/honeyd/honeyd.log: fichero dónde se registran todas las conexiones a nuestro “tarro de miel”.
  • Logs de scripts:
    • /var/log/honeyd.txt para los servicios vnc, finger, proftpd, exchange-pop3, exchange-imap
    • /var/log/honeypot/iis.log para el servicio web iis.sh
    • para cada uno de los servicios un fichero en el directorio /var/log/honeypot
    • /var/log/ftp-dirección_ip_del_atacante: log servicio ftp
• Logs de snort: /var/log/alert
• logs de iptables: he creado dentro de /var/log/honeypot/ un fichero para cada uno de los servicios del honeypot además del genérico en /var/log/iptables.
• Contenido de los paquetes grabados con wireshark: almacenado en ficheros también dentro de /var/log/honeypot.

  3.- Tráfico capturado.

  Las primeras muestras de que hay alguien escaneando nuestros sistemas nos las ofrece honeyd desde la propia consola:

  en la imagen podemos ver cómo desde la 83.61.252.186 han solicitado conexión a los puertos 21, 80,110 y 8080, tras comprobar que están abiertos comienzan a ejecutarse los scripts asociados a esos puertos de manera reiterada. Normalmente esto indicará que estamos sufriendo un escaneo de puertos seguido de una comprobación automatizada de vulnerabilidades de esos puertos (como el que suele realizar, por ejemplo Nmap o Nessus.

  
  Para obtener más información y comprobar a modo de sumario de ataques, si esto es así, acudimos a los ficheros de log. Por ejemplo en /var/log/honeypot/honeyd.log

  

  en el mismo podemos ver varias cosas, en primer lugar que es un escaneo automatizado por las inexistentes diferencias de tiempo entre cada test (primer campo de cada lína) además

  • el segundo campo nos indica el protocolo, tcp, udp, o icmp
  • el tercer campo puede ser una S (indica inicio de nueva conexión), E (end) final de conexión o “-” si el paquete no pertenece a ninguna conexión. En el caso de E, además nos marca la cantidad de datos recibidos y enviados al final de cada línea
  • los siguientes cuatro campos indican: ip y puerto de origen e ip y puerto de destino
  • Para los paquetes que no forman parte de una conexión honeyd muestra el tamaño del paquete y los Flags TCP
  • Finalmente se añaden comentarios al final como idetinficación pasiva del sistema operativo.

  Teniendo esto en cuenta, es bastante probable que se trate de escaneos realizados desde un programa tipo nmap o nessus que se esté ejecutando desde Windows

  Esto se verá corroborado accediendo también al fichero /var/log/honeyd.txt dónde viendo una parte de las entradas podemos comprobar cómo ha intentado las conexiones con el usuario anónimo para el ftp y contraseñas para distintos servicios, finalmente vemos que ha empleado nmap para realizar los escaneos con los scrpits incluidos en nmap.

  USER anonymous
  USER anonymous
  --ENDMARK--
  PASS IEUser@
  ",
  --ENDMARK--
  PASS IEUser@
  PORT 205,217,153,62,80,80
  PORT 205,217,153,62,0,80
  --MARK--,"sáb jun 26 12:12:40 CEST 2010","ssh","83.61.252.186","192.168.0.22",1443,22,
  "SSH-2.0-Nmap-SSH2-Hostkey

  Otro ejemplo de escaneo es el realizado por nessus que incluye más plugs para comprobación de vulnerabilidades que nmap. Un ejemplo de los datos capturados por los scripts de honeyd lo podemos ver en la imagen dónde vemos como otro usuario empleando nessus es capaz de comprobar también nombres de usuarios en el servicio FTP.

  

  Comprobamos con whois la procedencia del tráfico con el comando whois o bien desde un navegador web:

  En cualquier caso la información más exhaustiva, siempre que esté disponible y haya captado la firma del ataque nos la proporciona snort. En la siguiente captura se puede ver un ejemplo del fichero de alertas generado por otro compañero al hacer un “ruidoso” escaneo de puertos:

  [**] [125:4:1] (ftp_telnet) FTP command parameters were malformed [**]
  [Priority: 3]
  06/25-13:00:10.933428 79.x.137.x:35267 -> 192.168.0.22:21
  TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:135
  ***AP*** Seq: 0x825D4C76 Ack: 0xF02C098 Win: 0x7FFF TcpLen: 20
  [**] [1:100000160:2] COMMUNITY SIP TCP/IP message flooding directed to SIP proxy [**]
  [Classification: Attempted Denial of Service] [Priority: 2]
  06/25-13:00:12.764218 79.x.137.x:35271 -> 192.168.0.22:21
  TCP TTL:52 TOS:0x0 ID:11101 IpLen:20 DgmLen:64 DF
  ***AP*** Seq: 0x836BC090 Ack: 0x112039FA Win: 0x16D0 TcpLen: 20

  dónde podemos ver como el primero se corresponde con una búsqueda de vulnerabilidades en el servicio ftp:

  Si quisiéramos comprobar de modo más exhaustivo esos tráficos, tan sólo tendríamos que irnos a las capturas completas dónde podemos ver las vulnerabilidades buscadas y cómo:

  

 4.- Conclusiones

Tras haber leído bastante documentación sobre honeypots – a los que sólo conocía de oídas- y pasarme bastante tiempo viendo logs y averiguando el funcionamiento de los mismos, creo que es un software interesante por varios motivos: en primer lugar porque recoge bastantes de las cuestiones relativas a seguridad (IDS, iptables, programas de detección de vulnerabilidades,...) y en segundo lugar porque creo que constituyen la demostración práctica ideal de que en cuanto conectamos un ordenador a la red quedaremos expuestos a múltiples riesgos.

Me llamó la atención -por mucho que lo hayamos leído a lo largo de este año- que cada vez que enchufamos nuestros equipos y abrimos puertos, comenzamos a recibir intentos de conexión desde múltiples redes en Internet: Francia, Suiza, Corea,.... y otras desde la red de nuestra propia operadora.

Mejor demostración de la existencia de gusanos, auto-rooters, mass-rooters es difícil encontrarla.

También creo que los honeypots constituyen la mejor demostración de la necesidad de instalar mecanismos de seguridad en nuestras redes locales, en ocasiones se puede ver las mismas ips -o rangos sospechosamente cercanos- como a lo largo del tiempo realizan escáneres en busca de puertos abiertos sin que snort lance ninguna advertencia (¿quién podría sospechar de escaneos tan lentos que son lanzados a lo largo de días?).

Por otro lado me gustaría comentar que un problema con el que me pasé horas batallando, consistía en que los banners de los sistemas no salían correctamente ( cuando en los scripts aparecía echo -e “...”, aparecía la “e” cuando se accedía al servicio desde el exterior aunque no en local) por lo que los escáneres de puertos no reconocían ni permitían una correcta interacción con el honeypot. Como el link entre sh y bash estaba creado, lo que hice fue llamar a los scripts directamente desde el fichero de configuración sin emplear sh y cambiar todos los scripts para que los interpretara como #!/bin/bash, incluyendo el “scripts/misc/base.sh” que es llamado desde otros.

Finalmente añado un par de imágenes en las que se puede ver parte del escaneo con zenmap a mi red (uned.dnsalias.com) y la página web que sería visible desde el exterior:

Honeyd (VIII). Tráfico capturado

Para obtener más información y comprobar a modo de sumario de ataques, si esto es así, acudimos a los ficheros de log. Por ejemplo en /var/log/honeypot/honeyd.log

en el mismo podemos ver varias cosas, en primer lugar que es un escaneo automatizado por las inexistentes diferencias de tiempo entre cada test (primer campo de cada lína) además

• el segundo campo nos indica el protocolo, tcp, udp, o icmp
• el tercer campo puede ser una S (indica inicio de nueva conexión), E (end) final de conexión o “-” si el paquete no pertenece a ninguna conexión. En el caso de E, además nos marca la cantidad de datos recibidos y enviados al final de cada línea
• los siguientes cuatro campos indican: ip y puerto de origen e ip y puerto de destino
• Para los paquetes que no forman parte de una conexión honeyd muestra el tamaño del paquete y los Flags TCP
• Finalmente se añaden comentarios al final como idetinficación pasiva del sistema operativo.

Teniendo esto en cuenta, es bastante probable que se trate de escaneos realizados desde un programa tipo nmap o nessus que se esté ejecutando desde Windows

Esto se verá corroborado accediendo también al fichero /var/log/honeyd.txt dónde viendo una parte de las entradas podemos comprobar cómo ha intentado las conexiones con el usuario anónimo para el ftp y contraseñas para distintos servicios, finalmente vemos que ha empleado nmap para realizar los escaneos con los scrpits incluidos en nmap.

USER anonymous
USER anonymous
--ENDMARK--
PASS IEUser@
",
--ENDMARK--
PASS IEUser@
PORT 205,217,153,62,80,80
PORT 205,217,153,62,0,80
--MARK--,"sáb jun 26 12:12:40 CEST 2010","ssh","83.61.252.186","192.168.0.22",1443,22,
"SSH-2.0-Nmap-SSH2-Hostkey

Otro ejemplo de escaneo es el realizado por nessus que incluye más plugs para comprobación de vulnerabilidades que nmap. Un ejemplo de los datos capturados por los scripts de honeyd lo podemos ver en la imagen dónde vemos como otro usuario empleando nessus es capaz de comprobar también nombres de usuarios en el servicio FTP.

Comprobamos con whois la procedencia del tráfico con el comando whois o bien desde un navegador web:

En cualquier caso la información más exhaustiva, siempre que esté disponible y haya captado la firma del ataque nos la proporciona snort. En la siguiente captura se puede ver un ejemplo del fichero de alertas generado por otro compañero al hacer un “ruidoso” escaneo de puertos:

[**] [125:4:1] (ftp_telnet) FTP command parameters were malformed [**]
[Priority: 3]
06/25-13:00:10.933428 79.x.137.x:35267 -> 192.168.0.22:21
TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:135
***AP*** Seq: 0x825D4C76 Ack: 0xF02C098 Win: 0x7FFF TcpLen: 20
[**] [1:100000160:2] COMMUNITY SIP TCP/IP message flooding directed to SIP proxy [**]
[Classification: Attempted Denial of Service] [Priority: 2]
06/25-13:00:12.764218 79.x.137.x:35271 -> 192.168.0.22:21
TCP TTL:52 TOS:0x0 ID:11101 IpLen:20 DgmLen:64 DF
***AP*** Seq: 0x836BC090 Ack: 0x112039FA Win: 0x16D0 TcpLen: 20

dónde podemos ver como el primero se corresponde con una búsqueda de vulnerabilidades en el servicio ftp:

Si quisiéramos comprobar de modo más exhaustivo esos tráficos, tan sólo tendríamos que irnos a las capturas completas dónde podemos ver las vulnerabilidades buscadas y cómo:

4.- Conclusiones

Tras haber leído bastante documentación sobre honeypots – a los que sólo conocía de oídas- y pasarme bastante tiempo viendo logs y averiguando el funcionamiento de los mismos, creo que es un software interesante por varios motivos: en primer lugar porque recoge bastantes de las cuestiones relativas a seguridad (IDS, iptables, programas de detección de vulnerabilidades,...) y en segundo lugar porque creo que constituyen la demostración práctica ideal de que en cuanto conectamos un ordenador a la red quedaremos expuestos a múltiples riesgos.

Me llamó la atención -por mucho que lo hayamos leído a lo largo de este año- que cada vez que enchufamos nuestros equipos y abrimos puertos, comenzamos a recibir intentos de conexión desde múltiples redes en Internet: Francia, Suiza, Corea,.... y otras desde la red de nuestra propia operadora.

Mejor demostración de la existencia de gusanos, auto-rooters, mass-rooters es difícil encontrarla.

También creo que los honeypots constituyen la mejor demostración de la necesidad de instalar mecanismos de seguridad en nuestras redes locales, en ocasiones se puede ver las mismas ips -o rangos sospechosamente cercanos- como a lo largo del tiempo realizan escáneres en busca de puertos abiertos sin que snort lance ninguna advertencia (¿quién podría sospechar de escaneos tan lentos que son lanzados a lo largo de días?).

Por otro lado me gustaría comentar que un problema con el que me pasé horas batallando, consistía en que los banners de los sistemas no salían correctamente ( cuando en los scripts aparecía echo -e “...”, aparecía la “e” cuando se accedía al servicio desde el exterior aunque no en local) por lo que los escáneres de puertos no reconocían ni permitían una correcta interacción con el honeypot. Como el link entre sh y bash estaba creado, lo que hice fue llamar a los scripts directamente desde el fichero de configuración sin emplear sh y cambiar todos los scripts para que los interpretara como #!/bin/bash, incluyendo el “scripts/misc/base.sh” que es llamado desde otros.

Finalmente añado un par de imágenes en las que se puede ver parte del escaneo con zenmap a mi red (uned.dnsalias.com) y la página web que sería visible desde el exterior: