Take the 2-minute tour ×

I have a little SVN server, old dell optiplex running debian. I don't have that high demands on my server, because its just a little SVN servern... but do want it to be secure.

I just renewed my server to a newer and better optiplex, and started looking a bit into the old server. I took it down after experiencing problems. When I check the logs, its full of brute-force attempts and somehow someone has succeeded to enter my machine. This person created some extra volume called "knarkgosse" with two dirs "root" and "swap1" or something. Don't really know why and what they do, but sure do want to prevent this from happening again. I find this a bit strange though because I change my password ever few months or so, and the passwords are always random letters and numbers put together... not easy to brute-force.

I know I can prevent root from logging in, and use sudoers... and change the SSH port, but what more can I do?

So I have a few questions:
1) How can I prevent logging in for 5 minutes after X amount of incorrect tries. Or slow tries down after each incorrect try?
2) Is there some kind of central blacklist which a server can connect to? A blacklist that keeps track of IP addresses that are "unsafe" and should never be granted access?
3) What more can I do to apply safety to my server?

Like I said earlier, I am running Debian 5 with Apache (www-data user problem?), svn, mysql, php, phpmyadmin, hudson. It is on a home network with port forwarding on 80, 443, 8080, 8180, 23 and 22.

Paul Peelen

share|improve this question
add comment

12 Answers

up vote 14 down vote accepted

Fail2ban and Port Knocking should address most of your needs.

Changing your SSH port and only allowing Key-based authentication are also recommended.

It can be argued that you may reach a point of diminishing returns in adding additional security measures, but then again, it's up to you to decide when you're "secure enough".

It's also a good idea to disallow root login.

share|improve this answer
I use denyhosts, but it's pretty much the same as fail2ban afaik. –  pfyon Aug 26 '10 at 20:59
Fail2Ban sound familiar... I'll have a look into that. –  Paul Peelen Aug 26 '10 at 21:08
+1 Fail2Ban, 5 failed attempts = 5 minute IP block. Unless you have a ridiculously easy password, it'll never be bruteforced at 1 password per minute. –  Chris S Oct 12 '10 at 12:24
@Chris S Yea, that's one of my favorites. Script Kiddies usually don't know how to deal with timeouts... –  gWaldo Oct 12 '10 at 12:52
@gWaldo, confirmation bias goes a long way in rewriting things you read to say what you already think to be true. –  Chris S Aug 12 '11 at 2:40
add comment

There is no substitute for secure passwords AND key-authentication. That being said, Fail2Ban is a great tool for banning IPs of users who attempt to authenticate too many times. It's also available as a pre-built package for most distros. Be warned, you can accidentally get yourself banned, so make sure you have a recovery white-listed IP too or easy console access...

Fail2Ban has several good examples of how-to configure everything you asked... it does not however, have a universal repository of bad addresses. I don't think there is such a repository anyplace due to the ease of getting another IP (dhcp renew/bot-net attacks/etc...). I would also disable logging in via ssh using common 'administrator' type usernames (root/admin/administrator/sysop/etc..) as these are the most commonly banged on.

share|improve this answer
Great answer. I totally agree with you bold text... therefore the letter combinded with numbers passwords. Key-authentication is a bit too much for this server... but a good idea. I have now installed Fail2ban, doesn't seem like that I need to reconfigure it and because this little svn server is at home I have easy access to it (considering that it is in the back off my walk-in closet =S) Thnx for your advice! –  Paul Peelen Aug 26 '10 at 21:21
Spamhaus publishes a list of known spammer networks. It doesn't cover botnets, it's just known "professional" spammers: spamhaus.org/drop –  Chris S Oct 12 '10 at 12:27
add comment

I've stopped brute force attacks with:

  • fail2ban
  • sshd.config:
    • PasswordAuthentication No
    • PermitRootLogin No
  • Limiting SSH Connect rates with iptables (http://www.debian-administration.org/articles/187)
share|improve this answer
add comment

There are a number of good suggestions offered here. I respectfully suggest that three things should make this relatively secure:

  1. Run the sshd on a random high port. The bots typically only go after port 22 and variations on port 22 like 2222.
  2. Disable password based authentication in the sshd config:

UsePAM no

  1. Only authenticate with this site via pre-shared SSH key pairs. Man on ssh-keygen to get started with PKI based authentication.

Hope this helps.

share|improve this answer
For a very low stress solution, I definitely second running ssh on a nonstandard port. From what I have seen, this will drop attempts at brute force connections to your ssh server by an order of magnitude. Over a weeklong period, one of my servers (running ssh on a standard port) got 134 invalid connection attempts. That same time period, a virtual instance on that same server (running ssh on a nonstandard port) had 0. –  D.F. Aug 28 '10 at 22:04
add comment

I've always been a big fan of CSF/LFD which can block IP addresses of people trying to bruteforce, portscan, and some other options. It's basically a huge perl-wrapper for IP tables, but the configuration file isn't hard to read and the documentation isn't bad.

share|improve this answer
Do you know if there is some way one can be alerted (ex. by email) whenever a port-scan is preformed on the server? –  Paul Peelen Aug 26 '10 at 21:37
add comment

You could also look into sshguard. I haven't used it but I've heard good things.





share|improve this answer
This sounds neat... I'll have a look into it. thnx –  Paul Peelen Aug 26 '10 at 21:07
add comment

An option (to be used in addition to other security measures) is have sshd listen on a port other than 22. I haven't tried it myself, but have heard it reduces the number of pure brute force attacks by bots.

I must emphasize that this isn't real security, just reduces the number of automated brute force attacks. Too much work to check every port I guess.

share|improve this answer
I did that as well, swiched to port 23. Mainly because I had another server on port 22 (which I now took down). –  Paul Peelen Aug 26 '10 at 21:22
23 is a reserved port for telnet though. It's often a better idea to use ports that are not reserved, such as > 60k. iana.org/assignments/port-numbers gives you a list of reserved port numbers. –  ℝaphink Aug 26 '10 at 21:44
Thanks for the tip. I don't use tenet on this machine (yet) but will change the port. I have a port range between 52000 - 59000 i use on my professional servers, thinking of using the same for this one. –  Paul Peelen Aug 26 '10 at 21:53
@Paul: I don't use te[l]net on this machine - keep it that way. While you want a telnet client around for various reasons, there's no reason to run a telnet server when you have ssh available. Plaintext passwords over the wire are bad. –  mlp Aug 12 '11 at 6:42
add comment

I have an SSH server connected to the internet on the default port and have never experienced issues..

  • tcp_wrappers (ie. hosts.allow hosts.deny) for SSH.. I dont think there is an SSH out there that doesn't have support compiled in it
  • iptables this in conjunction with tcp_wrappers eliminated about 99% of my random port scans/bruteforce attempts.. the only problem is you need to know where you'll be connecting from in order to allow those IP/IP ranges... I simply did a lookup on popular providers around my area to see their IP ranges and allow those.. most scans seem to come from far away lands :)
  • PermitRootLogin without-password (ie. only RSA/DSA key pairs that are encrypted with a pass-phrase) works wonderfully for automated tasks.. when I login to interact I obviously use my account (regular) which is configured with sudo access
  • sudoers
  • constant updates.. I update this box frequently with all security/critical updates
  • password/passphrase changes
  • run chkrootkit every now and again to see if I've got any issues.. (there are several out there that perform this function)

hope it helps!

share|improve this answer
add comment

Something which isn't mentioned here and really should is limiting access via firewall. This doesn't suit every situation, but if you're connecting to the host from a consistent location with a static IP, you could just block off SSH entirely except to that IP. This will ensure that intruders cannot get in. As I mentioned though, this doesn't always suit every situation, especially if your IP is dynamic and changes often.

share|improve this answer
In general I agree to your solution. I believe this is the standard at the company I work for... but I don't think this is something for me. The problem is that I mainly use my macbook pro either from home (local network), from work (static IP) or on the go (using 3G modem/iPhone). For the last its a problem if I don't have a VPN which is too much overkill i guess. Thanks for your answer thou. –  Paul Peelen Aug 27 '10 at 6:54
add comment

DenyHosts, http://denyhosts.sourceforge.net/, is a good project I have had luck with. If you set denyhosts up to synchronize it will download new IPs to add to a ban list that have had to bruteforce other systems using denyhosts. It also expires IPs that have not tried to brute force for a while.

Using public key authentication and disabling password logging is probably the best thing you could do though. Defeats any brute force attacks.

share|improve this answer
add comment

There is a better way to do this, using fail2ban means you have to add an application, and it operates at the application layer.

If you use iptables it is more efficient as it operates at the network layer and you do not have to install an extra application.

Use the iptables recent module http://www.snowman.net/projects/ipt_recent/

iptables -N SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -j ACCEPT
share|improve this answer
add comment

What has been effective for me:

  1. As others have said, no root login, PasswordAuthentication set to no (only login w/keys) in sshd_config

  2. Only one or two users allowed to log in via ssh and they've got quasi-obscure names that aren't on common brute-force tool user name lists (i.e., not "admin" or "apache" or "web" or "johnny")

  3. Restrictive firewall rules (basically, everything's blocked but my service port and ssh). I even restrict ping, to ward off the more crude scans (much to my partner's chagrin).

  4. On my web host, I do restrict access to a specific few IP addresses - but this looks like it's not an option for you. Certainly can't do it myself on all of our hosts. You may also want to look into "port-knocking."

  5. And my favorite: OSSEC's active response module to block a number of brute force conditions and alerts on other errors, too. It detects x invalid logins in y amount of time, and then blocks (via an iptables firewall-drop command) for a certain period of time. I'm blocking for about 12 hours now for fun. :)

One thing I do here to make sure I don't block too much of the wrong thing, is that in /etc/ossec.conf, I set active response to a high level (that doesn't exist in default configuration) and then go through the sshd_rules.xml and set the rules I want to block to that level and modify thresholds for block vs. alert as needed.

If you're running Apache, you can block stuff that violates apache-rules, too. I don't block on these just because of the NAT issue, I want to think about blocking an entire university or something. :) In addition, you can write custom rules to block on certain conditions in log files, which can be really helpful.

share|improve this answer
add comment

Your Answer


