[clug] [OT] IP range of a domain?

[Robert Brockway]

On Thu, 21 Jan 2010, miloska at gmail.com wrote:

> Additionally you can change the default portnumber from 22 to
> something else, so automated robots won't find/try your ssh.

I'm not a fan of changing port numbers.  It has two main problems:

* A legitimate client doesn't know the port ahead of time and either needs 
to be told or scan for it to find it.

* Access may be limited as intervening firewalls may block the 
non-standard port.  It is common for corporate firewalls to limit outbound 
connections to a limited set of destination ports.

If I don't want people to connect to the port then I'd rather block it at 
the firewall and be done with it.

> Also you can implement port-knocking (I think iptables itself can be
> set up for that) to reduce the chance of any unnecessary connection to

Yes port-knocking is a great option.  I'm glad you brought it up as I 
forgot to mention it in my original post.

> your SSH services. Speaking of iptables I think fail2ban (or something
> similar, like limit the number of new connection from an IP to your
> SSH port) can be also implemented with iptables.

Exactly.  One problem I've found with fail2ban is that (by default at 
least) it is looking in the logs for failed password attempts and so isn't 
useful if you are only using key auth.

> I know all these solutions seems a bit amateur, but the combination of
> some of them (I do recommend at least the key-only auth from Rob's
> list on the first place) is a good enough protection for an average
> server - and I guess we are not talking about a banking system.

Use of a firewall to block access and use of key auth for ssh will get you 
to a high level of security.   A higher level of security could be 
obtained through the use of a DMZ and IDS/IPS tools.   All that is still 
possible in the home if you want to go to the extra effort.

One other point I wanted to tack on this email.  A lot of people using 
Linux in homes and small businesses focus on securing ssh since it will 
open a shell on their system if the attacker can get through.  This 
appears to make it an obvious threat, but it is quite easily secured using 
some of the methods we've mentioned here.

It's worth noting that the risk behind most exploits is that there is an 
opportunity to run arbitrary code.  Guess what arbitrary code most bad 
guys run - a shell.  OpenSSH is arguably the most highly audited piece of 
code on a typical Linux box (having come from OpenBSD).  Thus sometimes I 
feel that the threat from OpenSSH gets more attention than it should when 
many other apps may represent a far greater threat to the system.

Cheers,

Rob

-- 
Email: robert at timetraveller.org
IRC: Solver
Web: http://www.practicalsysadmin.com
I tried to change the world but they had a no-return policy