ssh Access from the internet

[Robert Brockway]

On Tue, 13 May 2008, CLIFFORD ILKAY wrote:

> This sounds very much like a repeat of a discussion we had here some months

Hi Clifford.  It is indeed.

> ago. I respectfully disagree that changing ports is a bad thing and reject 
> the notion that the Internet would break as a result. Yes, it's security

Ok, I'll tell you how I arrived at this conclusion and you tell me if 
there is a logical flaw.

Currently we rely on knowledge of the remote destination port to be able 
to make a connection over the Internet.  The software I am using expects 
HTTP to be on tcp/80 and HTTPS to be on tcp/443, etc.  If the sysadmin of 
a remote web server changes their HTTP port to tcp/81 my browser will not 
find it.  I might nmap them to find open ports but that is a bit rude and 
if everyone did it they would be DDoSed :)

Thus if everyone varied ports as a means of "security" no one would find 
the services they needed.  This fulfills my defition of a broken Internet.

DNS SRV records do provide a mechanism for advertising a service on a 
particular address/port.  If SRV records were widely used then sysadmins 
could vary port numbers and still have their services available to those 
who needed them, but in this case the services would not be hidden in any 
way as they would be advertised in the SRV record.  In this case varying 
the port would be neither secure or obscure.

> through obscurity and no, I don't care. The idea isn't just to thwart 
> potential attacks but to make it more difficult for what are obviously 
> scripted attacks on port 22. Changing to some other port all but eliminates 
> joe job attacks. It is very easy to work around port blocking restrictions by 
> using ssh port forwarding.

Even if _only_ ssh gets the special treatment of having its port varied 
(which is highly suspect as it is probably less likely than most services 
to allow arbitrary execution of code) how will I find the port that ssh is 
running on, on remote boxes that I need to access?

This approach is only viable with home systems.  I restate my 
_philosophical_ disagreement with an approach that will only work for a 
home user.  It teaches bad techniques and we already have enough of those 
on the 'net.

> By the way, key-based authentication isn't always possible. FreeNX, for 
> example, or at least the older version I have running, doesn't work unless 
> password auth is also enabled.

Yes I've been this with VMWare console too.  The problem lies with VMWare 
and FreeNX.  I'm not going to drop the security level on the network 
to accomodate this.  When I have encountered this problem I've found 
alternative secure approaches such as a VPN.

Now I'm going to preempt an argument that I hear a lot.  Someone may point 
out that there is a business case to run the app in an insecure way. 
This is absolutely not good enough.  If a company network (or even a home 
network) is exploited because of this then no business case in the world 
will bring that data back after it has escaped or speed up the restore 
from known-good backups that must occur.

If people try to get me to "bend the rules" of security to just "get 
things working" I insist on a personal committment from them that they 
will keep me company in the office while I'm restoring the systems from 
backup if they are broken into as a result of their quick fix - a process 
that can potentially take days if the breakin is serious.  If I am going 
to miss out spending time with my family I'll need someone to keep me 
company ;)  It's amazing how people have a different take on this when it 
is _their_ personal time which is at risk :)

Yes I take a hardline about security.  Yes it has kept my systems safe 
when others have fallen around me.

Cheers,

Rob

-- 
"With sufficient thrust, pigs fly just fine..."
 	-- RFC 1925 "The Twelve Networking Truths"
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists