So you want to run your own ssh honeypot but don’t know where to start? That’s OK, I didn’t either. What I did know was that in the battle between my honed over many years paranoia, and my at times insatiable curiostity, was that curiosity won! But I still don’t want to let the script-kiddies onto my honeypot. So while I want to know what’s out there, I want to be as safe as possible.
One of the first rules of running a honeypot is “Start Simple”, (as seen in Forensics Analysis of a Compromised Honeypot ). This is so you can start getting data as soon as possible, without opening yourself up to the “Great Unknown” of hackers and script-kiddies. The more you open yourself up to gather data, the greater the chance that you might miss something and leave yourself wide-open to the script-kiddie with the magic “Silver Bullet”. Right now I’m interested in accounts, passwords, and IP addresses where they are coming from. This is a fairly standard starting point in the world of honeypots.
There seems to be four methodologies of running honeypots,
- Ridiculously high interaction, these are wide open servers, where it’s a real server with backdoors left open intentionally and monitored through the network to see what is being done to it. I’ve see this on the web, but I can’t find a link now that I’m looking for one.
- High interaction servers where the server looks and acts like a real system, but are heavily monitored to make sure the hackers don’t get full control, and all their actions are logged. These are more “real” than Kippo, but have external firewalls blocking outbound attacks. Again, I’ve seen this on the web but can’t find a link now.
- Medium interactions servers that look like real servers but aren’t, and while they look like a live system, they don’t really do anything. This is like Kippo Honeypot
- Low interaction servers, like custom built ssh honeypots like at http://securehoney.net/ or through modifying the openssh code like at hacking-sshd-for-a-pass_file
For my purposes, I chose to low interaction server and modified the current OpenSSH code myself (openssh-6.7p1.tar.gz). I wanted the data, but I wasn’t willing to take a lot of risk getting it. What I basically did was to set my REAL sshd to run at an obscenely high port number, so I could still get in, and have my customized sshd running on port 22.
As a side note, while there are lots of instructions out there on doing this, I’m documenting how “I” did it, with my viewpoint on what I did, and how I did it, and I’m including some other details that they’ve left out.
Setting up my “REAL” sshd
To setup my real sshd, I edited /etc/ssh/sshd_config and set the following variables:
# Not the real port, but a really high port number
#These are the defaults anyways, but I wanted to MAKE SURE!
#This is the default anyways, but I wanted to MAKE SURE!
# Set so only I can login from a few IP addresses
AllowUsers myaccount@*.mydomain.com myaccount@localhost
Then I did a
service sshd restart
and checked that I could still ssh into my server, and that it was properly logged into /var/log/secure.
Setting up my “FAKE” sshd
I chose to use the “real” OpenSSH instead of any of the “fake” ssh daemons because …
I downloaded the code from http://mirrors.nycbug.org/pub/OpenBSD/OpenSSH/portable/openssh-6.7p1.tar.gz into /usr/local/source/openssh.
I then edited auth-passwd.c include #include “canohost.h” so I can get the IP address, added a logit line, and added a “return 0” so that it always thinks the password was wrong. Please note that I added the word PassLog in the logit line to make it easier for me to grep out the account/password lines from the log file.
The context diff is below (and the source file is at https://github.com/wedaa/LongTail-Log-Analysis
[wedaa@localhost openssh-6.7p1-22]$ diff -c3 auth-passwd.c-hacked auth-passwd.c.orig
*** auth-passwd.c-hacked 2015-03-27 11:12:05.767799071 -0400
— auth-passwd.c.orig 2014-07-18 00:11:25.000000000 -0400
*** 55,67 ****
– /* Added by ERICW so we can do IP lookups*/
– #include “canohost.h”
extern Buffer loginmsg;
extern ServerOptions options;
extern login_cap_t *lc;
— 55,63 —-
*** 87,100 ****
struct passwd * pw = authctxt->pw;
int result, ok = authctxt->valid;
– /* ERICW ADDED logit */
– logit(“IP: %s PassLog: Username: %s Password: %s”, get_remote_ipaddr(), authctxt->user, password);
– /* ERICW ADDED return 0 so the password ALWAYS fails */
– return 0;
#if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE)
static int expire_checked = 0;
— 83,88 —-
*** 226,229 ****
strcmp(encrypted_password, pw_password) == 0;
— 214,216 —-
Then I did a ./configure, make, and a make install. By default openssh will install into /usr/local/etc, so I wasn’t worried about killing my /sbin/sshd file. I then renamed /usr/local/etc/sshd to /usr/local/etc/sshd-22 and /usr/local/etc/sshd_config to /usr/local/etc/sshd_config_22. I did this so that I could also recompile the code and create another sshd_config file for listening to port 2222 and to make sure that the logging indicated which ssh daemon and port was being targeted.
I checked /usr/local/etc/sshd_config_22 to make sure it was still set to Port 22, and set the logging to the same as my real sshd.
I also made sure to disable publickey logins (for the time being), by editing the RSAAuthentication and PubkeyAuthentication to no.
As a side note, it took me a few tries to actually get the code to compile since I was missing some packages on my honeypot server. I had to add
yum install wget
yum groupinstall ‘Development Tools’
yum install zlib
yum install zlib-devel
yum install openssl-devel libssh-devel
at this point it’s ready to go. I started it manually with
/usr/local/sbin/sshd-22 -f /usr/local/etc/sshd_config_22
and then did an ssh to port 22. The connection worked, but my account and password failed to log me in, as they should (remember I put the “return 0;” line into the code). I then checked my log to make sure it was there. Then I deleted the log so my password wasn’t in the log file anymore.
Since my system still supports the file /etc/rc.local, I added this line to the end of that file as well. That way when my server reboots, it starts up the honeypot sshd as well
/usr/local/sbin/sshd -f /usr/local/etc/sshd_config
Setting up iptables for my honeypot
Then I had to setup my firewall to allow ports 22, 2222 AND into my server.
# Accept inbound ssh
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 2222 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport <BIGPORT> -j ACCEPT
Telling SELinux about the new ssh ports
You also need to run the following selinux commands if you have selinux installed.
semanage port -a -t ssh_port_t -p tcp 2222
semanage port -a -t ssh_port_t -p tcp <BIGPORT>
semanage port -l | grep ssh # Shows ssh ports
Setting up my router for my honeypot
Then I had to setup my router to allow ports 22, 2222, AND into my server.
Doing all this the eash way…
I have a script at https://github.com/wedaa/LongTail-Log-Analysis/blob/master/install_openssh.sh which will do most of this for you.