Hacker: cowrie: Setting up a cowrie Honeypot.

Recently I ran a cowrie honeypot.  It simulates a compromised SSH Port 22 and allows scanning bots to 'think' they have access to a Linux server.  It is  a virtual access and it was shocking to see how hundreds of scanners immediately attempted to login and access it.  For some unknown reason all the scanners use '345gs5662d34' with password '345gs5662d34' frequently.

• Cowrie is slightly problematic and quite a few libraries and some setup was required - but it worked (best instructions from here)
• Installing on Centos became so problematic I wiped it and built it from the Ubuntu side.

It was interesting to see how many IP addresses were coming from DigitalOcean Servers aka (direct access) the people scanning and penetrating the honeypot were not even attempting to hide their identity (AFAIK).

Problems with ufw:

Ubuntu has a 'Ultimate Firewall' that sits on top of the older iptables. It is great for basic users where they want to 'ufw allow 22' but past that it was no more friendly to use than just using straight IP tables.

• Getting UFW to 'route' packets was poorly documented and none of the examples worked.
• Cowrie runs on port 2222 but needs a piping to that port from 22 so it looks 'real' and is placed in the path of their scanners.
• You can run with authbind but more simply you can iptables reroute as in:

iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222

Moving your legitmate ssh out of the way:

sudo nano /etc/ssh/sshd_config

Change your port to something less common

And then restart it with

systemctl restart ssh

In some instances where you have SELinux you will also need it to allow through the port as per /etc/ssh/sshd_config (but I don't really 'bump' into SELinux hardly)

semanage port -a -t ssh_port_t -p tcp #PORTNUMBER

Troubleshooting:

• Check cowrie direct port at 2222
• Check your iptables 'nat' as root.
• Note you cannot 'ssh root@localhost' you will need the full ip.

iptables -t nat -L

Stale HoneyPot(s)

After a couple days the honeypot slowed down dramatically as the invaders realized they were only accessing fake porridge.

Because the honeypot was becoming  'stale' the fun factor was quickly wearing off. Unbelievably the honeypot had ended up on the hackers own ip blacklist (you can't make this stuff up)...

This offered a great security solution:

• Set your router to route all non-active tcp/ip:22 to your single honeypot.
• After a few days the hackers will blacklist your entire subnet as it is too problematic to filter the real ports from the ones that eat their scripts.
• This would work very well for subnets that are quite large /16 etc.