SSH honeypot using .bashrc

Question

Today I talked to a sysadmin from my company about securing a (SSH) Server and he brought up an interesting idea:

• He has several test users on that server (john, admin, steve, etc...) with easy passwords (asdf, a, b, qwer,....)
• Each user has limited privileges
• Each user's .bashrc contains a call to a function to immediately block the ip from where this user is connecting
• the second line in the .bashrc is 'exit'

My feeling is that this opens pandora's box, but I can't tell why. What might go wrong with this?

Answer 1

The reason it feels dangerous is because it's dangerous. You're going to give somebody you know is trying to compromise your system a foothold into that system just so you can block their extremely replaceable IP address?

When they figure out how to bypass your little script, maybe by using SFTP (which doesn't execute .bashrc) to replace .bashrc so they can log in interactively, they've now got local access to the box, which means that unless you're extremely vigilant about regular patching, they've probably got a quick path to root via local exploit - and even if you are vigilant, they only have to wait until a new local vuln is disclosed that hasn't been patched yet.

Worst of all, you're taking that huge risk just so you can block their IP address; why not just automatically block all bruteforcing addresses and save yourself the honeypot risk? Besides that, IP addresses are easy to come by, and maintaining a list of supposedly 'bad' ones will become an exercise either in futility or in mapping the IPv4 address space.

I hope this helps!

Answer 2

It is opening a pandora's box because the ssh server can easily be used to spawn sftp or scp. Instead of a honeypot, I use fail2ban to blacklist bad addresses attacking my VPS server.

http://www.fail2ban.org/

I have it set for 5 failed attempts in 5 minutes results in a ban for 20 minutes. If I felt it was getting attacked more, I would increase the ban time.

I always login to my VPS with RSA authentication keys, so personally I would only get a single fail when I haven't loaded the key into the agent prior to attempting to login.

Answer 3

.bashrc only gets run on interactive shells.

So attackers would still be able to run arbitrary commands by specifying them on the ssh command line, or by using utilities such as scp.

It's a interesting idea, though. You should make the trap users' shells a custom program that does the above. Or safest, set the shells to /bin/false and use an external program that watches for logins/login attempts on these accounts.

I'd trap on login attempts, whether or not they're successful. Don't let them in the door, just kick them out if they knock.

Really, as other people have answered the safest thing to do is not to do this. Use a program designed to be a true honeypot.

Answer 4

the second line in the .bashrc is 'exit'

Doesn't matter for non-interactive runs like ssh user@remotehost ls /

Answer 5

For test password use John the Ripper.

Don't use real ssh server as honeypot. It is not safe. Use kojoney or other honeypot SSH server.

If you use OpenSSH set /sbin/nologin for honeypot user.

Answer 6

You can setup a simple SSH honeypot using Kippo and log data in a MySQL database. There is also a tool to visualize the results.

There is also another script called Artillery which "is a combination of a honeypot, file monitoring and integrity, alerting, and brute force prevention tool. It’s extremely light weight, has multiple different methods for detecting specific attacks and eventually will also notify you of insecure nix configurations." http://www.secmaniac.com/blog/2011/10/14/new-tool-release-artillery-for-linux-protection/