Re: Secure Remote Connections

["Jody & Jennifer McCluggage" <j2mccluggage () adelphia net>]

I agree with basically everything that everyone has said.  Here are my
suggestions:

 

1.       On the notebook computers, if using Windows, use Windows 7 Ultimate
or Enterprise to get BitLocker whole volume encryption.  I know there are
many fine 3rd party software that can do whole volume encryption but the
benefit of BitLocker is that you can configure it to be totally transparent
to the end-user (no needing to have the end-user enter a separate password
to decrypt) and has Active Directory support.

2.       Use Active Directory to centrally enable, configure, and enforce
the Windows Firewall.

3.       Use a VPN solution that can leverage your domain active directory.
That way your users can log on with their domain credentials and you can
centrally control their access.   If using Windows 2008, you can try to also
leverage its built in NAP to ensure that the remote users machine meet an
acceptable baseline before granting access.

4.       If possible, use a solution that does not require the end user to
run with local administrator rights.  It takes a bit of work to work out all
the kinks (it is a bit easier to do now with Vista/7) but in my opinion well
worth it.  A knowledgeable end-user with local administrator rights can
undue all your best intentions.   It will also limit damage that malware can
inflict (of course not eliminate them.  Any malware will still have access
to whatever the user has but would protect system files and registry
settings only accessible to admin)

 

Well that is my opinion at least.  Good luck.

 

Jody

 

 

From: pauldotcom-bounces () mail pauldotcom com
[mailto:pauldotcom-bounces () mail pauldotcom com] On Behalf Of Jack Daniel
Sent: Wednesday, August 11, 2010 10:18 PM
To: PaulDotCom Security Weekly Mailing List
Subject: Re: [Pauldotcom] Secure Remote Connections

 

My answer to most things remote-access related is OpenVPN.  Make the users
establish the VPN connection, and tunnel whatever they need through that
(don't allow any direct access to resources over the Internet).  Tie OpenVPN
authentication to your domain, add granular rules by user, and you have an
answer.  You can even let them keep their RDP autologin for now, and fight
the desktop battle later.  OpenVPN does require local admin rights on
Windows (for now, they're working on solving that), but I bet your road
warriors have admin rights on their systems.

Jack




On Wed, Aug 11, 2010 at 2:28 PM, Tyler Robinson <pcimpressions () gmail com>
wrote:

Alright so after failing a recent security audit which I knew we would I
have a little bit of fire to allow me to make some corp changes one of them
being remote devices and policy. Currently there are mobile devices
unencrypted, and with cheesy passwords out on the road using unsecured RDP
to connect back to our terminal server to use apps, My question is what is
going to be an easy to roll out solution to make this situation secure I
worry that one of these devices will get stolen or sniffed and the terminal
server is on the LAN with the rest of everything , it's a flat domain. so
how to I allow remote connections securely without allowing them to save
there stupid RDP Connection credentials(set to autologin) on an unpassworded
desktop. Any ideas or suggestions I have one year to plan, implement and
change this broken system, over about 10 corps all releated and setup the
same..

Thanks as always to everyone,

TR


_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com




-- 
______________________________________
Jack Daniel, Reluctant CISSP
http://twitter.com/jack_daniel
http://www.linkedin.com/in/jackadaniel
http://blog.uncommonsensesecurity.com

_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com