Note: Updated Kippo Write-Ups:
1. Getting Started
Kippo is a medium interaction SSH honeypot designed to log brute force attacks and the entire shell interaction performed by the attacker.
Kippo is very similar to Kojoney (a low interaction SSH honeypot). In my personal opinion, Kippo is a much better SSH honeypot than Kojoney. Kippo has a higher sticky factor and better logging system. Moreover, Kojoney is no longer an active project.
I’m using a fresh installation of a Kubuntu 12.10. It’s a machine that I use activities with the Computing Society at Royal Holloway, University of London, thus the username – “compsoc”.
sudo apt-get install subversion python-twisted python-mysqldb mysql-server
Now, grab the Kippo codes using subversion (I’m at revision 246 in my setup).
svn checkout http://kippo.googlecode.com/svn/trunk/kippo-svn
To utilise the database logging feature of Kippo, we need to configure the MySQL database we just installed.
mysql -h localhost -u root -p
CREATE DATABASE kippo;
GRANT ALL ON kippo.* TO ‘compsoc’@’localhost’ IDENTIFIED BY ‘kippo-pass’
Use the SQL script provided by Kippo to create the tables used for logging.
mysql -u compsoc -p < mysql.sql
If you already have MySQL database installed and could not remember your password, check out StackOverflow: MySQL – Error 1045 – Access denied.
Before we run Kippo, we need to do some basic configuration.
cp kippo.cfg.dist kippo.cfg
Take note of the port number Kippo will be listening on. By default Kippo listens for SSH connections on port 2222. As changing it to 22 requires root privileges, we will be using port forwarding instead.
sudo iptables -A PREROUTING -t nat -i eth0 -p tcp –dport 22 -j REDIRECT –to-port 2222
Configure your database setting.
In the configuration file, you will also find where essential logs and files are located at
- Directory where log files are saved in: log
- Directory where downloaded (malwar) files are saved in: dl
- Directory where virtual file contents are kept in: honeyfs
- File in the Python pickle format containing the virtual file system (this is created by the createfs.py utility): fs.pickle
- Directory for miscellaneous data files, such as the password database: data
- Directory for creating simple commands that only output text: txtcmds
With everything set, let’s start running Kippo!
Now let’s look at how Kippo logs some of my unsuccessful brute force attempt using my Microsoft Windows 7 machine (192.168.161.1).
The two SSH sessions:
And the list of passwords I tried:
By default, the only root password is “123456”. Additional root passwords can be added to data/userdb.txt by using the passwd command within the honeypot. It’s a good idea to only have one easy password set, as multiple successful logins by the same scanner might look suspicious.
2. User & Password Management
Unlike Kojoney where you have a text file that list all the username and password combination it accepts, Kippo is slightly more advance than that. By default, the only root password is “123456”.
If you want to accept more username and password combination than that, you can append it to data/userdb.txt.
In addition, if a attacker uses the passwd command, the new password will also be appended to the file.
In other word, you can look at the trend of password attackers like to change to.
To add a new fake user into your Kippo SSH honeypot, you cannot simply use the useradd command within the honeypot. However, the useradd command provides a more interesting feature:
It will be interesting if you can collect personal information about the attacker.
To add a new user, you just have to append your new username and password combination into the data/userdb.txt file.
Similarly, if a successful login to that user launched a passwd command, the new password will be appended to the file.
Explore your Kippo!
By now, you would have successful logged into your Kippo SSH honeypot. Explore around with it, and you will realise you get some return values from some basic Linux commands (e.g. w, ps, ls, etc.), unlike Kojoney which always tells you that command is not found.
3. A Sticky Honeypot
In the beginning, I briefly mentioned that the sticky factor of Kippo is much better than Kojoney. If you have heed my advice you would have realised Kippo entertains most of the common commands.
You can modify the files in the directories kippo/commands and textcmds to change the return values that differs from the default configuration, or add more files in these directories to have your honeypot entertain more commands.
However in this section, I would like to demonstrate a more interesting type of stickiness/persistence.
As most Linux users or attackers, we like to use commands to control the entire machine. Unfortunately, the “exit” command in Kippo does not close the SSH session completely. It makes the attacker think he/she has, but actually not.
The intruder is still in your Kippo shell, and you are still logging whatever they are about to type. With this capability, you can look into what attackers do after an intrusion.
The attacker will actually have to close the session window to exit the SSH session. If the attacker is using a bash only machine, he/she will have to do a force shutdown the machine to exit the SSH session.
I’m not sure if this is done intentionally, I found that the “exit” command does close off the session window if you are connecting through Putty. Having a “Connection to server closed” message still remaining on your Putty shell is really suspicious.
Since I’m already in the topic of stickiness, I’ll briefly cover a few configurations you should have done to make your Kippo unique; adding the sticky factor by not having the attacker know it’s a honeypot straight away.
In your Kippo configuration file – kippo.cfg – change the hostname of your honeypot. If you observed closely, my SSH honeypot is named “edgis-compsoc” instead of the default “nas3”.
Change the result returned by the ifconfig command. It will be suspicious if the attacker sees an IP address that differs to the one that he/she has connected to.
You should also change most of the command’s return values of your SSH honeypot and its file system.
4. Kippo-Graph (v0.7.4)
In this final section, I will be looking into the analysing logs captured by Kippo. In the beginning I highlighted that Kippo allows you to log data into a database. You can analyse the data captured by looking into the relevant tables. Or you can enable text-based logging (via your Kippo configuration file, kippo.cfg) and analyse it using tools such as Splunk.
However, I would like to dedicate the reminding of this section to Kippo-Graph – a full featured script to visualise statistics from a Kippo SSH honeypot.
sudo apt-get install libapache2-mod-php5 php5-cli php5-common php5-cgi php5-mysql php5.gd apache2
Grab a Copy of Kippo-Graph
Now, grab a copy of Kippo-Graph from BruteForce Lab and place it in your Web server.
/var/www$ sudo tar -xvf kippo-graph-0.7.4.tar –no-same-permissions
Kippo-Graph visualise statistics from your Kippo SSH honeypot by accessing data from your MySQL database. You will need to configure your Kippo-Graph so it can gain access to your database.
/var/www/kippo-graph$ sudo vim config.php
Now, browse through your Kippo-Graph Web page and you will realise that the statistics are not updated in real time. You will have to manually click on the link “GENERATE_THE_KIPPO_GRAPHS();” before any results are visualised.
But before you can run that script, modify the permission so you can run it.
/var/www/kippo-graph$ sudo chmod 777 generated-graphs
With everything set, generate your Kippo-Graphs and let the visualisation magic begins!
I would like to thank Leon van der Eijk for his wonderful workshop (“Show me the Honey! – Conducted at BSides London 2013), his amazing installation guide and demonstration on Kippo.
Kudos to Ioannis “Ion” Koniaris (author of Kippo-Graph) for writing such an amazing piece of work.