On Nov 4, 2010, at 9:13 AM, Les Mikesell <lesmikes...@gmail.com> wrote:

> On 11/4/10 7:15 AM, Ross Walker wrote:
>> 
>> 
>> If the client PC was set up in a split pipe setup it would be like running 
>> your corporate LAN with either no firewall or a consumer level firewall 
>> product with questionable administration.
> 
> Things really aren't that simple, though. The big risk is not so much that an 
> outside source will be able to route directly through the connection because 
> most remote endpoints would be behind NAT, have an OS level firewall, and not 
> be 
> configured for routing anyway.  The more likely scenario is that the remote 
> is 
> corrupted by some sort of trojan/virus malware which can make its own 
> outbound 
> connectons or collect data to transmit later - and the problem is that this 
> can 
> occur at any time prior to the vpn connection.  It also isn't limited to vpns 
> - 
> the same thing can happen when laptops are connected to the LAN or if you 
> insert 
> any removable media, execute email attachments, browser plugins, etc., etc.  
> And 
> browser plugins can even subvert what you are doing over ssl.  You probably 
> permit outbound https connections and there's not much you can do to monitor 
> them.

Yes the malware threat is another big reason VPNs give me pause.

>> You can filter within the VPN which protocols are passed but then at this 
>> point wouldn't it be better to do this at the firewall anyways?
> 
> How much can you filter once all your connections are using ssl?  And of 
> course 
> you are still assuming that the bad guys are on the other side of your 
> firewall 
> when statistics show otherwise.

Well I'm only thinking perimeter at the moment, internal threats are a whole 
other can of worms and need to be handled differently.

As for the SSL part, you can monitor traffic over it in a couple of ways. For 
internal services being served out you can have the SSL connection terminate at 
the gateway and the gateway establish an internal SSL connection to the 
service. For internal clients connecting to external services I have used SSL 
inspectors, these basically initiate an SSL connection to the destination, take 
the certificate, generate a per-destination itself and pass that to the client, 
basically acting as a man in the middle, as long as the gateway/inspector is a 
trusted intermediate CA and the subject is preserved then the client doesn't 
have a problem with it.

-Ross

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Reply via email to