HonSSH is essentially an SSH proxy, acting like a Man-in-The-Middle attack. It sits between the attacker and a honeypot and proxies the SSH connections. By doing this it can log all interactions, spoof (rewrite) login passwords and even capture files downloaded by the attacker on to the honeypot for later analysis.
Below is my topology:
Configuring the Honeypot Server
For the honeypot server (the server attackers will login to), I’m using Ubuntu 14.04 but maybe using an unsupported Linux distribution may yield more interesting results. I’m using QEMU as the hypervisor and tried to configure the honeypot to be as “real” as possible, using an emulated Intel Gigabit Ethernet NIC and setting a valid Intel MAC address, using an emulated SATA adapter etc.
I installed the following on the honeypot:
- OpenSSH server (essential!).
- Apache.
- PostgreSQL.
- ProFTPd.
- Build tools (GCC, make etc).
I set a password of 123456 for the system created “ftp” and “postgres” users and ensured their shells were valid. I created two new users called “setup” and “test” with a password of 123456. I gave the “setup” user root privileges via sudo. Finally, I also enabled the root account with a password of 123456.
The honeypot server needs to route via the HonSSH server and not via the firewall. This is because the advanced networking features in HonSSH will be used, allowing the HonSSH server to automatically source NAT (SNAT) the SSH connection to the honeypot server, so if the attacker ran a netstat they’d see their public IP address and not the IP address of the HonSSH server, therefore making it less suspicious.
After everything was configured I took a snapshot of the honeypot server so it could easily be restored to its non-pwned state.
Configuring the HonSSH Server
For the HonSSH server I’m using Debian. This time fully updated, support, patched etc.
Clone HonSSH from git:
# apt-get install git # cd /opt # git clone https://github.com/tnich/honssh.git # cd honssh
Look at the requirements file and install the packages listed.
Copy the default honssh and users cfg files:
# cp users.cfg.default users.cfg # cp honssh.cfg.default honssh.cfg
Edit the users.cfg file. This maps usernames and passwords sent by the attacker to HonSSH to the honeypot server. There are two modes. Fixed, where you supply a list of valid passwords that HonSSH will accept and random, where you specify a random chance that the password will be accepted. You also define the users and the “real password” that HonSSH will send to the honeypot server. My users.cfg looks something like:
[root] real_password = 123456 fake_passwords = jiamima, wubao, toor [setup] real_password = 123456 random_chance = 25 [test] real_password = 123456 random_chance = 25 [postgres] real_password = 123456 random_chance = 25 [ftp] real_password = 123456 random_chance = 25
In this scenario if an attacker tries to login with root, only the passwords jiamima, wubac and toor will be accepted. HonSSH will in turn login to the honeypot server as root but using the real_password defined. For the other users defined (setup, test, postgres, ftp), HonSSH will accept any password but only with a 25% chance of success. When successful HonSSH will login to the honeypot server as the user and using the real_password defined.
Note that random mode can be confusing for the attacker once logged in and raise suspicion. If the attacker tries sudo, the password they logged in with will not be the same as the password actually configured on the honeypot server.
For a list of popular usernames and password combinations used in SSH scanning, Dragon Research Group produces a handy SSH Username and Password Tag Cloud.
Next edit honssh.cfg.
Under the [honeypot] section:
- ssh_addr: Set this to the IP address of the NIC on the HonSSH server connected to the “outside” (192.168.0.1).
- ssh_port: Set this to the port that the HonSSH daemon should listen on for incoming SSH connections (2222).
- client_addr: Set this to the IP address of the NIC on the HonSSH server connected to the “inside” (192.168.1.254).
Under the [honeypot-static] section:
- sensor_name: Set this to something meaningly, for example honssh-honeypot1.
- honey_ip: Set this to the IP address of the honeypot server (192.168.1.193).
Under the [advNet] section:
- enabled: Set this to true which will enabled the SNAT feature talked about previously.
Under the [spoof] section:
- enabled: Set this to true.
Under the [download] section:
- passive: Set this to true so HonSSH locally captures all files uploaded to the honeypot server via SFTP/SCP.
- active: Set this to true so HonSSH locally captures all files downloaded to the honeypot server via wget.
Enabling email notifications under the [output-email] section is also useful to keep tabs on when a login has been successful and what was done.
Since the HonSSH server will also be acting as a router for the honeypot server, enable IP forwarding:
# cat > /etc/sysctl.d/10-ip_forward.conf net.ipv4.ip_forward=1 net.ipv4.conf.all.secure_redirects=0 net.ipv4.conf.all.send_redirects=0 # sysctl -p /etc/sysctl.d/10-ip_forward.conf
Secure the HonSSH server with suitable firewall rules using iptables:
# apt-get install iptables-persistent # iptables -A INPUT -m conntrack --ctstate INVALID -j DROP # iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # iptables -A INPUT -i eth0 -j ACCEPT # iptables -A INPUT -i eth1 -j LOGDROP # iptables -P INPUT DROP # iptables -N LOGDROP # iptables -A LOGDROP -j LOG --log-prefix "fw deny: " # iptables -A LOGDROP -j DROP
It’s a good idea to implement some basic filtering from the honeypot server. When the honeypot server becomes compromised it’s highly likely it’ll be used to scan other systems, take part in DDoS attacks etc. The below rules will implement some basic rate limiting as well as filtering egress access to SMTP and SSH:
# iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP # iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -m limit --limit 100/s -j ACCEPT # iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT # iptables -A FORWARD -d 10.0.0.0/8 -j LOGDROP # iptables -A FORWARD -d 192.168.0.0/16 -j LOGDROP # iptables -A FORWARD -d 172.16.0.0/12 -j LOGDROP # iptables -A FORWARD -p tcp --dport 25 -j DROP # iptables -A FORWARD -p tcp --dport 22 -j DROP # iptables -A FORWARD -m limit --limit 1/s -j ACCEPT # iptables -P FORWARD DROP
Save the iptables rules:
# /etc/init.d/netfilter-persistent save
Start the HonSSH daemon:
# ./honsshctrl.sh start
Finally, test connectivity and ensure that everything works as expected. Remember to forward TCP port 22 from the Internet to the HonSSH server on TCP port 2222.
Other Notes
As mentioned previously, I’m running the honeypot server under QEMU. On the host I have a cronjob that restores the honeypot server to a default state every few hours. The script looks like this:
#!/bin/sh
VM=Honeypot-1
SNAPSHOT=`virsh snapshot-list $VM | head -3 | tail -1 | awk '{print $1};'`
virsh snapshot-revert $VM $SNAPSHOT
virsh start $VM
HonSSH can run scripts on certain events, so it may be possible to somehow get HonSSH to notify the host to do this automatically after an attacker has closed an SSH session (maybe via an email thats picked up directly on the host which triggers a snapshot revert?).
I’m also running a packet capture on the HonSSH server for better analysis of compromises:
screen -S tshark -d -m tshark -i eth1 -f 'not tcp port 22 and not broadcast and not arp' -w /tmp/capture.pcapng -P -b filesize:20480
This runs tshark in screen (detaching the session), capturing traffic to and from the honeypot server (192.168.0.193) but not capturing SSH traffic. HonSSH is capturing the SSH sessions which can be replayed. A new capture file is created when the current capture reaches 20MB.
Finally
Be careful. You’re allowing a machine connected to the Internet to become compromised. When (not if) this happens, it’s likely the attacker will:
- Attempt to root the server.
- Start scanning for other vulnerable devices.
- Add the server to a botnet.
- Start sending out spam.
- All of the above.
Use a honeypot to learn more about attacks and attackers but always try to mitigate against adding to the problem.
Analyse any captured files in a sandboxed, offline, environment.
Don’t run a honeypot on any public IP addresses/space you care about.
Share your experiences, captures, files and sessions! I’m sure the guys over at SANS ISC would be interested.