Re: Risk regarding remote login services

[Kevin Hayes <krhayes () OAKLAND EDU>]

We are doing the same thing here at Oakland.  Staff & faculty fill out
a VPN Request form so that we have an audit trail, and then they are
allowed access to our Juniper IVE VPN system.  We use DDNS so once
they connect via the VPN, they can simply RDC to their hostname.

Vendors can have VPN access as well as long as they have a contract
with the University; the IVE is nice that we can restrict which IP
addresses they can access once they connect.

Kevin Hayes
Network Security Analyst

233 Dodge Hall
Oakland University
(248) 370-2546




On Apr 23, 2008, at 5:16 PM, King, Ronald A. wrote:
> We use RDP through VPN and block other services.  Recently, we did
> have a
> vendor who uses one of the other services and opened it up for a
> particular
> host.
>
> Ronald King
> Security Engineer
> Norfolk State University
> Marie V. McDemmond Center for Applied Research
> Suite 401
> 700 Park Ave.
> Norfolk, Virginia  23504
> Phone:  757-823-3918
> Email: raking () nsu edu
> http://security.nsu.edu
>
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Calvin Krzywiec
> Sent: Wednesday, April 23, 2008 9:05 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Risk regarding remote login services
>
> We've setup an SSH proxy for use by faculty and staff. Most seem to be
> happy with this. We block LogMeIn, GoToMyPC, etc. via our IPS.
>
> --
> Cal A. Krzywiec
> Network Engineer
> The University of Scranton
> Phone: (570) 941-6748
> Email: krzywiecc2 () scranton edu
>
>
>
> Basgen, Brian wrote:
> > I'm working on ways to adequately assess the risk of solutions like
> > LogMeIn, GoToMyPC, etc. The main concerns that I have so far are: (1)
> > traditional end point security issues; (2) source addresses are
> > essentially masked by the service; (3) these solutions are user
> > managed/not IT controlled (no policy enforcement, for example); (4)
> > confidential/sensitive data being sent through a third party in an
> > unmanaged way; (5) the security of the third party becomes
> > axiomatic to
> > your institution.
> >
> > The last four points, in particular, seem to make these solutions
> > distinct from traditional VPN offerings.  I don't want to get into
> > making spacious arguments about why this solution is problematic,
> > but it
> > seems difficult to latch onto specifics considering such an open
> > field
> > of possible risk.
> >
> > I'm curious to know institutions that allow one of these solutions,
> > and
> > how they employ it. I'm also curious to hear from those that prohibit
> > it, and what justifications they use for doing that.
> >
> > ~~~~~~~~~~~~~~~~~~
> > Brian Basgen
> > Information Security
> > Pima Community College