Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
3  
This is opinion, rather than fact, so I'm leaving it as a comment. It gives you an icky feeling because it's not a good idea. He should be using a purpose-written honeypot program rather than attempting to make a more general purpose SSH daemon as a honeypot. The purpose-written honeypot is going to be written with much more care about limiting general-purpose operations and assumes that, even after "authentication", the remote party isn't just untrusted, but is out-right malicious. –  Evan Anderson Feb 4 '11 at 17:38
add comment

6 Answers

up vote 11 down vote accepted

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!

share|improve this answer
add comment

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.

share|improve this answer
add comment

.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.

share|improve this answer
1  
I want to +1 you, but I'm on the fence when you say "It's a good idea, though". Running a honeypot with a real SSHd, regardless of "trapping" is probably not a good idea. –  Evan Anderson Feb 4 '11 at 17:37
    
I should probably have said 'It's an interesting idea', yeah :) –  MikeyB Feb 4 '11 at 19:04
add comment

the second line in the .bashrc is 'exit'

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

share|improve this answer
    
What the heck is the purpose of the l337-speak? –  Dennis Williamson Feb 4 '11 at 17:56
    
Contextual m0stly. –  poige Feb 4 '11 at 18:01
add comment

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.

share|improve this answer
1  
+1 Why wait for them to actually guess the right password before blocking them? Instead use fail2ban to block them for even trying. (Plus all the stuff about SCP, SFTP, etc). –  Coops Feb 4 '11 at 20:11
add comment

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/

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.