2

I'm setting up a secure server for my use only to store encrypted files, but it will need to be accessed from the internet. The server itself is in a secure location with no physical access which is fine, but I'm more worried about the internet side. I'm thinking of using Ubuntu with no other software apart from open ssh.

How do I set up iptables to block all connections apart from ssh? And how do I set up open ssh to lock out any more than 2 failed attempts?

2
  • This is really several questions you've rolled into one. Next time consider asking them separately after researching each piece.
    – Caleb
    Apr 11, 2011 at 17:13
  • 1
    Use a distrib with good SELinux support instead of Ubuntu, and run in strict mode. Hard work, but it's actually secure.
    – niXar
    Apr 12, 2011 at 11:05

6 Answers 6

5
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --name sshattack --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name sshattack --rcheck --seconds 60 --hitcount 4 -j LOG --log-prefix 'SSH REJECT: '
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name sshattack --rcheck --seconds 60 --hitcount 4 -j REJECT --reject-with tcp-reset

See, eg, my writeup on the subject for more details (including where in your firewall rules to put these, which does matter).

The other respondents' recommendations to allow only key-based ssh I thoroughly endorse, because it renders brute-force password guessing useless; but you could go even further and allow only two-factor authentication, see my writeup on the yubikey for more details on that.

4

For Ultra security allow SSHKEY entries only instead of allowing password logins.

2

For SSH, I would recommend switching to key-only authentication. Turn off root access to the daemon and password authentication period. Once key based authentication is the only way in, there is really no need for "lock out" like you suggest. That is really only an effective way to slow the effectiveness of brute force password attacks.

The iptables site has already been answered by @MadHatter.

2

If you want a bit extra security above other fine measure suggested in these answers, you may want to consider port-knocking. Port-knocking gives good protection against attackers that scan ranges of IP numbers for servers to attack, which in my experience is by far the most common attack in real life.

1

Here's a basic guide to securing Linux ssh. This covers setting up (and only using) Public Key Authentication, disabling root login (and seting up sudo), and using non-standard ports.

Here's an iptables guide.

1

I use Shorewall to configure my iptables rules, with a default policy to DROP everything, and a single rule to ACCEPT SSH connections (well, plus rules/policies to permit outgoing traffic, of course); the effect is pretty much identical to what @MadHatter has posted, but I find Shorewall to be a whole heckuva lot easier to configure and use than direct iptables rules. (Shorewall is a configuration layer on top of iptables, using a series of easier-to-understand configuration files to employ complex firewall setups; it is not itself a firewall.)

Next, set up your SSH server to only allow key-based authentication, as suggested by just about everyone so far -- that should tell you how good an idea it is!

And to satisfy your requirement to block brute-force attempts, I strongly recommend Fail2ban, which can be configured to set how many failed attempts to block on, how long to ban the offending IP, and it can even monitor itself to effect a longer ban on persistent attackers not deterred by the first level of response (see the HOWTO on the Fail2ban site "Fail2ban monitoring Fail2ban"). You can even setup e-mail notifications about Fail2ban's responses: I set this piece up last night, and by this morning it had already banned a would-be Chinese hacker (based on the whois of the IP, anyway).

You must log in to answer this question.