Re: Remote access and data offloads.

[Russell Fulton <r.fulton () AUCKLAND AC NZ>]

Chris Green wrote:
> Hey from up I-59 :),
>
> I've been trying to address this same problem by trying to make sure that
> the desktop groups have centralized logging for for failed and successful
> login.
>
> I originally went down the road of wanting to block RDP and force VPN but
> have since come to the mindset that there's a lot of pros for people to use
> RDP.
>
> Having users university data using their work desktop rather than having
> their own PC via VPN and working from there gives us more control at the
> point we really care about.  Originally, our VPN was a customer service
> issue when @home blocked MS Networking (my things have changed ;-) )  It's
> also much easier for our helpdesk to walk someone through finding mstsc on
> their PC than it is for someone to install the VPN client.

What we are doing for our critical systems is running rdp on the servers
with some restriction on which IPs can connect.  We block RDP for these
servers at the border and get people to use vpn to get on to campus.  We
are about to set up two factor auth for our vpn and this will dump you
into a special dhcp pool which and the addresses in this pool will have
access to the sensitive servers.

And yes we have a project to centralise our windows auth logs to guard
against brute force attempts.
> A weakness is that it allows brute force attempts against more PCs and local
> account which is traditionally
>
> One line of thought that would move be back towards VPN is the ability to
> have policy compliance (patch checking, AV up to date, infection free?)
> performed on the desktop before they connect to the network. All of the
> products that I've seen for that perform that check AFTER the user has given
> their credentials away which is the (or one of the) event that was critical
> to prevent.

hence our requirement for 2 factor auth (and yes, I know it is no
panacea but it helps ;)

Russell