Cómo crear un honeypot SSH en Linux

En el mundo de la seguridad informática hay una regla primordial: Cualquier cosa que esté expuesta en el exterior, va a sufrir cyber ataques... Esto es así nos guste o no y se acabará haciendo realidad tarde o temprano, cosa que se puede aprender por las buenas o por las malas... Generalmente siempre querremos intentar hacer que los atacantes no entren, pero a veces podemos "satisfacer" la curiosidad de nuestros atacantes mediante el uso de "tarros de miel" que les haga creer que han logrado entrar, aunque en realidad no sea así; tarros de miel que son conocidos mundialmente como honeypots. Un honeypot no es ni más ni menos que un entorno ficticio con información ficticia que hace de señuelo para que los atacantes no vayan a por la información real; dicho entorno ficticio deja que el atacante "juegue" con él a su libre albedrío pero en realidad no hace otra cosa que hacer perder el tiempo al criminal y evitar que consiga el verdadero objetivo de su ataque... Existen diversos honeypots: FTP, HTTP/HTTPs, SIP... Pero hoy nos centraremos en el tarro de miel más "goloso" de todos: El orientado al protocolo SSH.

Para crear nuestro tarro, recurriremos a una herramienta desarrollada en Python llamada Kippo, una herramienta especializada en la creación de honeypots orientados a ssh que nos creará un entorno ficticio para todos los curiosos que quieran entrar al puerto 22 de nuestro servidor. Para ello lo primero que haremos será cambiar el puerto de escucha de nuestro servidor ssh (si es que no lo tenemos cambiado de antes) a un puerto distinto; queremos que el puerto 22 sea el que usen para entrar el honeypot con lo que tendremos que hacer que el ssh real se realice a través de otro puerto... A modo de recomendación personal evitaría usar el puerto 2222 o 22000, pues dichos puertos son conocidos por ser usados como puertos alternativos al 22. Para cambiar el puerto de escucha editaremos el fichero /etc/ssh/sshd_config y cambiaremos el valor de Port a uno menos conocido como podría ser el 10000 (por ejemplo). Si quisiésemos hacerlo directamente desde la línea de comandos al mismo tiempo que aplicamos los cambios, podríamos hacerlo de la siguiente forma:
sed-i's/Port 22/Port 10000/g'/etc/ssh/sshd_config &/etc/init.d/ssh restart
Esta línea estaría compuesta por una sustitución de la línea "Port 22" por "Port 10000" en el fichero sshd_config, seguido del reinicio del servicio ssh para aplicar los cambios.
Con este pequeño requisito cumplido, tocaría comenzar instalando los preparativos; es decir los paquetes necesarios para que Kippo funcione. Kippo no puede ser instalado desde los repositorios oficiales, pero este programa posee dependencias que sí que pueden ser instalados desde éstos, con lo que comencemos instalándolos. En este caso me he centrado en un entorno Debian, pero el proceso en entornos Red Hat no debería diferir mucho más allá del gestor de paquetes:
apt-get install python-dev openssl python-openssl python-pyasn1 python-twisted authbind
La mayoría de los paquetes están basados en python, a excepción del paquete authbind que se encarga de permitir que usuarios que no sean root, puedan trabajar con puertos menores 1024, pues queremos que el honeypot NO sea ejecutado por root. 
Ahora crearemos un usuario especialmente preparado para ejecutar el honeypot, un usuario que, valga la originalidad, llamaremos kippo y que pertenecerá al grupo sudo.
useradd-m kippo -gsudo
Dicho usuario podrá manipular/usar el puerto 22, un privilegio que única y exclusivamente tendrá él, si bien con lo que hemos hecho no basta, sino que también necesitamos preparar authbind para ello. Esto es tan sencillo como crear un fichero llamado 22 dentro del directorio /etc/authbind/byport/ y darle los permisos adecuados para que únicamente kippo pueda tener acceso a éste; lo cual se resumiría tal que así:

1. touch /etc/authbind/byport/22
2. chown kippo /etc/authbind/byport/22
3. chmod 700 /etc/authbind/byport/22

Ahora que hemos preparado tanto el puerto como el usuario, llegaría el turno de movernos a la carpeta /home de kippo y descargarnos el fichero kippo; fichero que, tal y como he comentado antes, no está disponible desde los repositorios, pero sí desde github con lo que tras movernos a la carpeta, descargaríamos y descomprimiríamos la aplicación. A modo de recomendación, sería bueno crear una carpeta dentro del directorio home que guarde todo lo relacionado con la aplicación.

1. su kippo
2. cd /home/kippo
3. mkdir kippo_DIR
4. cd kippo_DIR
5. wget https://github.com/desaster/kippo/archive/v0.9.tar.gz
6. tar -xzf v0.9.tar.gz

Por fin tenemos kippo descargado, si bien eso no significa que esté operativo... Por un lado es importante tener en cuenta que, a diferencia de muchos programas descargados desde github, este programa no requiere ser compilado/instalado para funcionar y además requiere realizar algunos ajustes para ser del todo operativo... Para empezar, el fichero de configuración que existe ahí, está a modo de plantilla y ni siquiera se encuentra correctamente nombrado para evitar que pueda usarse... Esta plantilla tendría se llama kippo.cfg.dist y además está configurada para trabajar por defecto con el puerto 2222, cosa que nosotros no queremos pues queremos usar el puerto 22 para emular un puerto ssh "real". Es por eso que primero renombraremos el fichero de configuración y después cambiaremos el puerto de escucha del 2222 al 22 mediante el comando sed de forma parecida a como hemos hecho antes con el fichero sshd_config.

1. cd /home/kippo/kippo-DIR/kippo-0.9/
2. mv kippo.cfg.dist kippo.cfg
3. sed -i '/ssh_port = 2222/ssh_port = 22/g' kippo.cfg

Ya lo tenemos casi preparado, solo faltan un par de detalles más. Por un lado, tenemos que saber que los usuarios ficticios del honeypot se encuentran dentro del fichero userdb.txt, el cual se encuentra dentro del directorio data que a su vez se encuentra dentro de la carpeta de la aplicación de kippo. Cada usuario existente dentro de dicho fichero tiene la siguiente estructura:
usuario:0:contraseña

He aquí un fichero de ejemplo:

1. root:0:123456
2. root:0:test
3. ivan:0:ivan

Por otro lado, dentro del directorio de la aplicación de kippo, tenemos un fichero llamado start.sh, fichero encargado de arrancar kippo; dicho fichero tiene que ser modificado, pues ahora mismo no está preparado para trabajar con authbind. Éste tendría que ser editado para ofrecer este aspecto:

1. #!/bin/sh
3. echo -n "Starting kippo in background..."
4. #twistd -y kippo.tac -l log/kippo.log --pidfile kippo.pid
5. DIR=/home/kippo/kippo-DIR/kippo-0.9
6. cd ${DIR}
7. authbind --deep twistd -y kippo.tac -l log/kippo.log --pidfile kippo.pid

A base de prueba y error, he visto que esto no basta y que es necesario que creemos dos directorios nuevos, pues en caso contrario, la aplicación no funcionará correctamente... El primero es un directorio llamado log, que se crearía dentro de la carpeta de la aplicación, mientras que el otro se llamaría tty. Obviamente ambas carpetas tendrían que pertenecer al usuario kippo.

1. mkdir /home/kippo/kippo-DIR/kippo-0.9/log
2. mkdir /home/kippo/kippo-DIR/kippo-0.9/log/tty
3. chown kippo /home/kippo/kippo-DIR/kippo-0.9/log
4. chown kippo /home/kippo/kippo-DIR/kippo-0.9/log/tty

Con esto ya tendríamos todo preparado y si ejecutásemos el script start.sh podríamos arrancar kippo, pero en mi opinión dicho script no es demasiado funcional pues no puede ser ejecutado en el arranque y no te ofrece ninguna posibilidad de pararlo de una forma cómoda. Es por ello que he añadido un pequeño script en /etc/init.d / para poder manejar el servicio con más comodidad. Dicho script sería el de a continuación y se denominaría kippo.sh.

1. #!/bin/bash
2. #
3. # preload init.d script
4. ### BEGIN INIT INFO
5. # Provides:          start.sh
6. # Required-Start:    $local_fs $remote_fs $time
7. # Required-Stop:     $local_fs $remote_fs $time
8. # Default-Start:     2 3 4 5
9. # Default-Stop:      0 1 6
10. # Short-Description: Kipoo starter
11. # Description:  Kippo automatic starter. It starts during the boot
12. ### END INIT INFO
14. PIDFILE=/home/kippo/kippo-DIR/kippo-0.9/kippo.pid
15. NOMBRE="Kippo"
16. SRV="twistd"
17. function status()
18. if [ -f ${PIDFILE} ];
19. then
20.         echo "${NOMBRE}  esta en marcha"
21. else
22.         echo "${NOMBRE} esta parado"
23. fi
24. function start(){
25.  echo -n $"Iniciando servicio ${NOMBRE}: "
26.  su - kippo -c "/home/kippo/kippo-DIR/kippo-0.9/start.sh" >/dev/null 2>&1
27.  RETVAL=$?
28.  echo $! > $PIDFILE
29.  if [ ${RETVAL} -eq 0 ];
30.  then
31.         echo "Se ha iniciado ${NOMBRE}"
32.  else
33.         echo "No se ha podido iniciar ${NOMBRE}"
34.  fi
35.  echo
36. }
37. function stop(){
38.  echo -n $"Parando servicio ${NOMBRE}... "
39.  SERV=$(ps -e |grep ${SRV} |awk '{print $1}')
40.  kill -9 ${SERV}
41.  echo "Servicio detenido"
42. }
43. function restart(){
44.  stop
45.  sleep 10
46.  start
47. }
48. case "$1" in
49. start)
50.  start
51.  ;;
52. stop)
53.  stop
54.  ;;
55. restart)
56.  restart
57.  ;;
58. status)
59. status
60. ;;
61. *)
62.  echo $"Usar: $0 {status|start|stop|restart}"
63.  exit 1
64. esac
65. exit 0

Obviamente sobre dicho script tendríamos que ejecutar dos comandos más; uno que haga que sea ejecutable, y otro que haga que se arranque en el inicio con el fin de que en caso de apagar el servidor. no se pierda nuestro querido tarro de miel.

1. chmod 755 /etc/init.d/kippo.sh
2. insserv kippo.sh

Ahora cualquier que acceda al puerto 22 por ssh, en vez de acceder a nuestro entorno real, accederá al honeypot en cuestión, honeypot en el que en caso de acertar sus credenciales (por defecto está diseñado para tener un único usuario que sería root con contraseña 123456) accederíamos. Obviamente dicho honeypot estaría aislado del verdadero sistema y siempre nos estaría dando datos ficticios, desde la ip hasta los ficheros presentes.
Una evidencia de que no estamos accediendo al servidor de siempre, más allá de la información existente dentro de éste, sería el hecho de que el ssh fingerprinting del servidor ha cambiado, pues en realidad estaríamos accediendo a un entorno diferente al real.
Gracias a este sencillo pero útil procedimiento, lograríamos alejar a gran parte de los curiosos de nuestro servidor ssh, haciendo que los atacantes malgasten su tiempo en un entorno ficticio y evitando que centren su atención en el puerto ssh real.
Espero que os haya resultado útil.
Saludos.