Re: Remote Access to Staff Desktops

["Miller, Don C." <donm () UIDAHO EDU>]

We use DenyHosts on our public facing ssh hosts.  It is *very* simple to
setup and sends e-mail notices and denies access to the remote host when
an attack is detected.  It is old but good.

http://denyhosts.sourceforge.net/

Don Miller
University of Idaho

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Dexter Caldwell
Sent: Friday, February 20, 2009 5:29 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Remote Access to Staff Desktops

I severely limit ssh access form off-campus, however, we have some
legacy
systems where access is historical or where we've granted it.  We
constantly get ssh brute force attacks on these servers.  The best thing
I've done to shut this down is use an ssh brute force signature on the
ips
to terminate these attemps.  It's been quite successful and users
haven't
noticed the change.

D/C
The EDUCAUSE Security Constituent Group Listserv
<SECURITY () LISTSERV EDUCAUSE EDU> writes:
> On Wed, 18 Feb 2009 09:14:52 CST, Mark Monroe said:
> > We allow it only through VPN. For Users who say they need ssh open 
> > without vpn, they can have it open only if they implement technology
on 
> > their box that will blacklist  any ip  address after  3 failed
attempts 
> > and any ip address that  tries to use root. I have not opened any yet

> > outside systems run by core IT staff. I guess they didn't really need
> it.
>
> Or they really *did* need it, but they ran into troubles deploying your
> requirements, gave up, and are now fulfilling their business need with
> some cobbled-up scheme involving storing their data on some offsite
server
> you have absolutely no administrative control over... ;)
>
> (I've seen more than one "block any address that tries to use root" go
> badly
> astray when the sysadmin accidentally tried to ssh to the other box
from
> an
> 'su' window on their local box, and then was of course unable to
connect
> to the
> remote box to fix the problem.  Of course, at that point, they were
*also*
> unable to fix the *other* problem which was the reason they were
ssh'ing
> to the
> box in the first place. Anybody want to guess what happened to that
code
> as soon as that sysadmin *was* able to login? ;)