Linode Forum
https://forum.linode.com/

Firewall method (fail2ban, DenyHosts, iptables-only, other?)
https://forum.linode.com/viewtopic.php?f=19&t=4157		 Page 2 of 2
Author:  fukawi2 [ Wed May 06, 2009 1:56 am ]
Post subject: 
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 ;)
Author:  trazoi [ Wed May 06, 2009 2:10 am ]
Post subject: 
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.
Author:  Vance [ Wed May 06, 2009 2:19 am ]
Post subject:  Re: Attacking Log analysis tools.
trazoi wrote:
Vance wrote:
jbglenn wrote:
http://www.ossec.net/en/attacking-loganalysis.html

DoS attacks are hard to defend against. One more reason to appreciate Linode's out-of-band console access. :-)

So Lish works even under a complete DoS hammering? That's good to know. Given I'm positive I can't predict all the possible ways something could go wrong it's nice to know I've got a way in to correct things in any condition.

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.
Author:  Telemachus [ Sat Jun 13, 2009 6:54 am ]
Post subject: 
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.)
Author:  dbb [ Sat Jun 13, 2009 9:18 am ]
Post subject: 
Telemachus wrote:
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.
Author:  Telemachus [ Sat Jun 13, 2009 9:52 am ]
Post subject: 
zengei wrote:
Telemachus wrote:
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.
Author:  mwalling [ Sat Jun 13, 2009 10:11 am ]
Post subject: 
Telemachus wrote:
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).


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.
Author:  dbb [ Sat Jun 13, 2009 11:04 am ]
Post subject: 
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.
Author:  Telemachus [ Sat Jun 13, 2009 11:41 am ]
Post subject: 
mwalling wrote:
Telemachus wrote:
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).


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.

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.
Author:  Xan [ Sat Jun 13, 2009 2:11 pm ]
Post subject: 
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.
Author:  mnordhoff [ Sat Jun 13, 2009 11:11 pm ]
Post subject: 
zengei wrote:
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 use iptables to restrict port 22 to two of my ISP's netblocks, but I also have sshd running unrestricted on other ports.
Author:  dbb [ Sun Jun 14, 2009 9:39 pm ]
Post subject: 
mnordhoff wrote:
zengei wrote:
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 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.
Page 2 of 2 All times are UTC-04:00
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/