Si estás metido en el mundo de la seguridad informática o en el mundo Linux fijo que alguna vez has escuchado ya este término. Un
honeypot no es más que un pequeño tarro de miel que, como éste, atrae a todos los posibles atacantes. La idea es dejar "un equipo" accesible y de fácil acceso para que los posibles atacantes "queden en él" y así no se centren en equipos más importantes de la red.
Existen numerosas aplicaciones de éste tipo, especialmente para servicios tales como
ssh o
telnet y hoy nos vamos a centrar en un
honeypot ssh, en este caso
kippo. La verdad es que existen muchos y la decisión de comentar éste no es por nada en particular, sólo que ofrece una gran facilidad de instalación (especialmente en equipos debian) y una gran versatilidad, ofreciendo la posibilidad de enviar de forma automática los reportes a base de datos (
mysql), con lo que el análisis estadístico será mucho más fácil de hacer.
Para realizar la instalación seguiremos los pasos que está perfectamente descritos en la
wiki del proyecto, con algún añadido que espero os sea de utilidad. Comenzamos.
- Instalación del software necesario
Por defecto para poder arrancar kippo necesitamos tener instalado python-twisted y si nos interesa la conexión con la base de datos (mysql), también hay que instalar python-mysqldb.
shell> apt-get install python-twisted python-mysqldb
- Obtener kippo
Descargamos desde la
web oficial la última versión del
honeypot. En este caso la 0.5 y lo descomprimimos.
shell> wget http://kippo.googlecode.com/files/kippo-0.5.tar.gz
shell> tar zxvf kippo-0.5.tar.gz
- Configurar kippo (kippo.cfg)
Sólo falta configurarlo antes de arrancar. La configuración que trae por defecto es perfectamente válida, pero yo prefiero cambiarle el nombre, para saber a qué 'máquina' de la red me estoy conectado (en real, este nombre mejor no establecerlo) y también configurar la conexión contra la base de datos.
Antes de arrancar el servicio tenemos que crear la base de datos de kippo y desplegar el
schema, ya que no lo hace automáticamente. Pincha
aquí para ver cómo se hace.
...
hostname = kippo # nombre del equipo 'fake'
...
fake_addr = 192.168.1.254 # ip del equipo 'fake'
...
[database_mysql]
host = localhost
database = kippo
username = kipoo
password = kippo
- Establecer las contraseñas fake
Aunque por defecto la contraseña empleada es '123456', es mejor crear ya una seria de contraseñas que quieras que sean válidas para tu sistema. Para hacerlo ya trae una utilidad (passdb.py) que sirve para tal fin. Permite en tiempo real generar (add), borrar (remove) y listar (list) contraseñas.
shell> utils/passdb.py ../data/pass.db add root
shell> utils/passdb.py ../data/pass.db add 1234
shell> utils/passdb.py ../data/pass.db list
1234
root
- Arrancar el honeypot
Y finalmente sólo queda arrancar la trampa. Aunque no se citó hasta ahora, por defecto y para proteger el sistema no se permite la ejecución como root del honeypot. En caso de que tenga algún fallo y el atacante consiga acceso al sistema, al no ser root no tendrá un acceso completo.
shell> ./start.sh
Starting kippo in background...Loading dblog engine: mysql
Una vez kippo arrancado, éste queda en segundo plano ejecutándose sin hacer nada a la espera de conexiones. Toda la actividad que sea detectada se queda almacenada en el fichero log/kippo.log, que podrá ser consultado en tiempo real y a mayores, también está metiendo datos de accesos en la base de datos. Aquí vemos un intento de acceso al sistema con el usuario root y la contraseña empleada aunque infructuoso.
shell> tail -f log/kippo.log
2012-08-08 16:24:39+0200 [kippo.core.honeypot.HoneyPotSSHFactory] New connection: 192.168.1.33:40222 (192.168.1.35:2222) [session: 0]
2012-08-08 16:24:40+0200 [HoneyPotTransport,0,192.168.1.33] Remote SSH version: SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2
2012-08-08 16:24:40+0200 [HoneyPotTransport,0,192.168.1.33] kex alg, key alg: diffie-hellman-group1-sha1 ssh-rsa
2012-08-08 16:24:40+0200 [HoneyPotTransport,0,192.168.1.33] outgoing: aes128-ctr hmac-md5 none
2012-08-08 16:24:40+0200 [HoneyPotTransport,0,192.168.1.33] incoming: aes128-ctr hmac-md5 none
2012-08-08 16:24:40+0200 [HoneyPotTransport,0,192.168.1.33] NEW KEYS
2012-08-08 16:24:40+0200 [HoneyPotTransport,0,192.168.1.33] starting service ssh-userauth
2012-08-08 16:24:40+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.33] root trying auth none
2012-08-08 16:24:40+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.33] root trying auth keyboard-interactive
2012-08-08 16:24:41+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.33] login attempt [root/asd] failed
2012-08-08 16:24:41+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.33] root failed auth keyboard-interactive
2012-08-08 16:24:41+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.33] unauthorized login:
2012-08-08 16:24:41+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.33] root trying auth keyboard-interactive
2012-08-08 16:24:44+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.33] login attempt [root/qwer] failed
2012-08-08 16:24:44+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.33] root failed auth keyboard-interactive
2012-08-08 16:24:44+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.33] unauthorized login:
2012-08-08 16:24:44+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.33] root trying auth keyboard-interactive
2012-08-08 16:24:46+0200 [HoneyPotTransport,0,192.168.1.33] connection lost
Lo mismo lo podemos ver en la base de datos, que también está almacenando dicha información de forma más estructurada. Para este mismo caso se han detectado,
mysql> select * from auth;
+----+-----------+---------+----------+----------+---------------------+
| id | session | success | username | password | timestamp |
+----+-----------+---------+----------+----------+---------------------+
| 1 | c9fc90fce | 0 | root | asd | 2012-08-11 14:24:41 |
| 2 | 63ef9f098 | 0 | root | qwer | 2012-08-11 14:24:44 |
+----+-----------+---------+----------+----------+---------------------+
2 rows in set (0.00 sec)
En caso de que un intento de acceso sea correcto el atacante quedará en una sesión que simula perfectamente un equipo accesible por ssh, pero sin datos reales y almacenando todo lo que ejecuta en la base de datos.
mysql> select * from auth;
+----+-----------+---------+----------+----------+---------------------+
| id | session | success | username | password | timestamp |
+----+-----------+---------+----------+----------+---------------------+
| 1 | c9fc90fce | 0 | root | asd | 2012-08-11 14:24:41 |
| 2 | 63ef9f098 | 0 | root | qwer | 2012-08-11 14:24:44 |
| 3 | a2582fc84 | 1 | root | 1234 | 2012-08-08 14:30:44 |
+----+-----------+---------+----------+----------+---------------------+
2 rows in set (0.00 sec)
mysql> select * from input;
+----+-----------+---------------------+---------+-----------------+
| id | session | timestamp | success | input |
+----+-----------+-------------------- +---------+-----------------+
| 1 | a2582fc0e | 2012-08-11 14:31:00 | 1 | ls |
| 2 | a2582fc1e | 2012-08-11 14:32:05 | 1 | cd /etc |
| 3 | a2582fc2e | 2012-08-11 14:32:10 | 1 | cat fstab |
| 4 | a2582fc3e | 2012-08-11 14:32:13 | 1 | cat passwd |
| 5 | a2582fc4e | 2012-08-11 14:32:17 | 1 | ls |
| 6 | a2582fc5e | 2012-08-11 14:32:46 | 1 | ifconfig |
| 7 | a2582fc6e | 2012-08-11 14:32:58 | 1 | ping 10.98.55.1 |
| 8 | a2582fc7e | 2012-08-11 14:33:03 | 0 | route -n |
| 9 | a2582fc8e | 2012-08-11 14:33:06 | 0 | route |
| 10 | a2582fc9e | 2012-08-11 14:33:09 | 0 | ip a l |
+----+-----------+---------------------+---------+-----------------+
10 rows in set (0.00 sec)
Como podéis observar la información recolectada es de mucha importancia y da una idea clara de lo que pueden hacer los atacantes a un sistema real, así como saber qué tipo de contraseñas y máquinas emplean.
Todo este entorno es de desarrollo en casa y por lo tanto no tiene mucho sentido. Intentaré probarlo en real y ya os mostraré los datos que aparecen después de un par de días de funcionamiento. Fijo que son sorprendentes.
