Whoops, I missed that it was commented... Personally, I would remove that line completely to make sure it doesn't accidentally get uncommented... At the very least put in multiple #'s

Sure thing. The original was a straight out translation of the guide on the internet; I was going through each line and seeing if I really needed it it. I'm rebuilding the system this week now I understand a bit more of the basics, and I'll remove the MySQL line since I won't need it.

_________________
David Shaw, a.k.a. "Trazoi"

While flooding a host with traffic is one type of DoS attack, there are others, like the ones described in the article to lock you out by tricking your installation of fail2ban or denyhosts. Lish and the AJAX console let you get into your Linode even if the firewall configuration or hosts.deny has been subverted to keep you out.

I don't think there's much an individual host owner can do to deal with a large traffic flood; someone upstream will have to (try to) block the traffic before it enters their network.

To prevent brute force attacks, I'm using a few things at once:

• Edit the sshd_config file so that root login is not allowed, and only allow users from a specific group to get access.
  
  Code:

  PermitRootLogin no
  AllowGroups special_friends
  

  
  You will need to create the 'special_friends' group (name it what you like), and make sure that your regular user is added to that group. Then you can restart the ssh server:
  
  Code:

  groupadd -g 9000 special_friends
  usermod -aG ssh_allow <user_name>

  
  I learned this method right here on this board.
• This set of rules in iptables:
  
  Code:

  iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set \
    --name SSH
  iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update \
    --seconds 60 --hitcount 4 --rttl --name SSH -m limit --limit 2/min -j LOG \
    --log-prefix "SSH_brute_force: "
  iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update \
    --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
  

  
  This method is adapted from here and here. It limits a single ip address to 3 logins within 60 seconds (no distinction for good or bad guys, just 3 in that time limit). The logging is limited to two log notices per minute. I picked up the logging limit trick (which will cut down on 24 hour brute force attacks filling your /var/log/syslog with useless crap) from this nice tutorial.

You can do even more (limit ssh login to people who have public keys on your system, only allow specific ip ranges, change the ssh port, use portknocking), but I find that for the moment, this is a good balance for me of security and manageability. Check your logs (/var/log/auth and /var/log/syslog) regularly, and if you're messing with iptables rules, be patient. You may lock yourself out, but usually a manual reboot will fix you there. (Unless you've already set the machine to load iptables rules automatically whenever the network starts. Don't do that until you're pretty sure of your rule-set.)

No need to do that, you can just use Lish which doesn't use a network interface.

Yup, I still haven't gotten out of my old habits. Thanks for the reminder about Lish.

Word of warning: This has bitten me in the ass more then it has helped. bash-completion on scp and this do *not* mix well.

As for myself, I only allow public key authentication so brute forcing is basically useless but I was annoyed by all the failed authentication messages in my auth.log so I use iptables to restrict access to port 22 from IP addresses in my current /16 range. If my dynamic IP address changes to something outside the specified ranges I just login via Lish and add the new range.

I hear you, but for me - so far - it's working well. I'm not doing the kind of work into the box via scp that you may be. I tend to log in once or twice, work in that terminal while checking, eg, css changes in a web browser. So far, I'm good. But I will keep my eye on it.

@Zengei: I've used public key auth, but that has bitten me. Moving to a new machine to work and not having a key-stick. That's a pain.

No perfect solution for every situation, probably.

I use Telemachus's "recent match" method as well; it's great. And if you have a problem with how you use SCP, just prepend a rule allowing connections from your IP.

I use iptables to restrict port 22 to two of my ISP's netblocks, but I also have sshd running unrestricted on other ports.

Wow, that's a really good idea, thanks. And it'll work on a physical server as well where you don't have the benefit of Lish.