If you experience any difficulty in accessing content on our website, please contact us at 1-866-333-8917 or email us at support@chicagovps.net and we will make every effort to assist you.
In their book, “Think like a Freak”, authors Steven Levitt and Stephen Dubner discuss about the Nigerian Prince email scam. The chapter discusses why someone would use such an obvious and famous scam in their emails. They conclude that the scammer is actually weeding out folks who are initially interested and then later walk away and be left with a set of folks who are genuinely gullible. Every minute/email spent by the scammer with someone who is just stringing them along is wasted effort (as compared to having an email server pump out 10,000 emails in a matter of minutes)
In this spirit, we shall attempt to keep potential hackers interested in our Honeypot SSH where they can actually do no harm rather than use this time to find other true targets.
SSH Honeypots are classified based on their level of interactivity – from minimal interaction to high interaction. The former offers limited support for commands and it is easier for a hacker to give up on the current session and move on.
Highly interactive honepots allow more commands to be entered, support more activities such as uploading files and have detailed logging capabilities. You could look back at a logged in session and review the commands used and work on closing similar attack opportunities on your real server. HonSSH is one such example, though it would mean that it must be installed on a separate server and act as a SSH Tunnel between the internet and your actual server (the real honeypot)
While the honeypot applications are designed to be completely cut off from actual shell command processing, you should look at installing such traps on separate servers. The advantages are two-fold. Firstly, if at all the barrier around the honeypot is broken and someone gets access to the true Unix shell, an unused server is not going to have any data that can be compromised.
The second advantage is that if you are running a cluster of servers, hackers usually use one compromised server to attack the remaining ones. This is due to the fact that many administrators whitelist known IPs (for e.g., the other servers within the cluster). If your log shows an attack from one of your own IPs, you know that that server has already been compromised and take necessary steps.
We will install Cowrie, a medium-level interactive SSH Honeypot. This is based on Kippo, and thereby integrates with Kippo interfaces such as Kippo-Graph. Cowrie is written in Python and emulates a Linux Shell and logs information about the attacker (IP address) and the commands executed. The following steps relate to a Ubuntu 16.04, but similar setup can be done easily on CentOS/RHEL systems.
To start off, update your server via apt-get and get everything to their latest & greatest versions
Change the default port the real SSH runs to a port of your choice. We will use 2024
# What ports, IPs and protocols we listen for
Port 2024
# Use these options to restrict which interfaces/protocols sshd will bind to
Restart SSH via service ssh restart. You can find that the port change is effective by issuing a netstat -tlpn command
..
tcp 0 0 0.0.0.0:2024 0.0.0.0:* LISTEN 1763/sshd
..
Cowrie should be run as a non-root user, next, we will add the user winnie (you could create the user with a different name, just remember to replace winnie in the below commands with your user name)
adduser winnie
Before we login and install cowrie, lets install some dependencies
apt-get install git python-dev python-openssl openssh-server python-pyasn1 python-twisted authbind
Next, we will need the cowrie application to be able to listen on port 22, the standard TCP port
touch /etc/authbind/byport/22
chown winnie /etc/authbind/byport/22
chmod 777 /etc/authbind/byport/22
We will login as winnie and install cowrie
su winnie
cd $HOME
git clone https://github.com/micheloosterhof/cowrie.git cowrie
Change to the directory cowrie and issue the following command
mv cowrie.cfg.dist cowrie.cfg
This renames the default config file to the file that the program uses. We will edit some details in this via nano cowrie.cfg
Search for hostname and replace it to your choice of hostname
# (default: svr04)
hostname = webfront
and
listen_endpoints = tcp:22:interface=0.0.0.0
Cowrie lets you decide which user ids password combinations are okay and allowed. This is in the data subfolder under cowrie. The file is userdb.txt. If you want to allow a combination of root:passw0rd, add an entry as below to the file
root:x:passw0rd
Setup virtual environment for cowrie to run. Go back to the cowrie directory (/home/winnie/cowrie) and run virtualenv cowrie-env
If you get an error, you may have to install virtualenv via pip (pip install virtualenv)
Let’s activate the virtual environment and install dependencies
source cowrie-env/bin/activate
Now, your prompt should be something like this
(cowrie-env) winnie@collider:~/cowrie$
Run the following commands
pip install --upgrade pip
pip install --upgrade -r requirements.txt
Under bin/cowrie, edit the AUTHBIND_ENABLED entry from no to yes
You are now ready to run cowrie
(cowrie-env) winnie@collider:~/cowrie$ bin/cowrie start
Join the Cowrie community at: http://bit.ly/cowrieslack
Using activated Python virtual environment "/home/winnie/cowrie-env"
Starting cowrie: [twistd --umask 0022 --pidfile var/run/cowrie.pid --logger cowrie.python.logfile.logger cowrie ]...
Let us see if the port 22 is up & running. netstat -tlpn returns something like this
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 11767/python
Let’s test and connect to the honeypot
$ ssh root@204.44.73.15
The authenticity of host 2XX.XXX.XXX.15 (2XX.XXX.XXX.15)' can't be established.
RSA key fingerprint is 4a:b0:0d:f4:b4:d3:0d:21:f0:2f:98:76:95:57:ed:55.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '2XX.XXX.XXX.15' (RSA) to the list of known hosts.
Password:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@webfront:~#
With your honeypot up and running, check back later under /home/winnie/cowrie/logs in the file cowrie.log. You get a complete list of those who fell for your trap.
While the honeypot is a fun way to keep attackers occupied (at least for a while), it is still recommended to keep your SSH safe. Changing your SSH port is just security by obscurity and any hacker with good search skills will be able to port scan and get the real SSH port.
I just reinstalled my VPS and logged in as root after 30 mins, here is the login screen
root@2XX.XXX.XXX.15's password:
Last failed login: Wed Jul 18 20:56:04 MSK 2018 from 95.87.XXX.75 on ssh:notty
There were 18 failed login attempts since the last successful login.
As observed in the referenced CISCO’s article below, the top user ID used in logging in was root which accounted for the largest majority of login attempts. With sudo users and ability to locally elevate oneself as root, there is no reason why one should not add this line to the ssh configuration
PermitRootLogin no
SSH is the main gateway to your server. For someone to gain access is as good as forgetting about the server and hoping that nothing has happened that results in law enforcement knocking on your door.
Obervations of Login Activity in an SSH Honeypot: https://www.cisco.com/c/en/us/about/security-center/ssh-honeypot.html
Cowrie on GitHub: https://github.com/micheloosterhof/cowrie
