RE: VPN concentrators

[Crispin Harris <Harris_C () DeMorgan com au>]

> From: Patrick Darden [mailto:darden () armc org]
>
> > > By the way - a VPN is not a firewall...
> > > The encrypted traffic hitting the VPN must be validated after decryption
> > > is performed... This is the reason why, sometimes, a VPN+Firewall in one
> > > box (e.g. checkpoint) will be a good solution, or a
> > > firewall-VPN-firewall "sandwich" will be also used.
> >
> > > Just my 2c.

Actually, just to clarify this: I don't usually recommend that the VPN
concentrator be sandwiched, rather that "downstream" (i.e. internal)
protection be employed: 
Internet---Router(+limited ACLs)---VPN---firewall---Internal_Network
The main reason (as explained below) is that I really just dont trust the
traffic flowing over an otherwise trusted VPN tunnel.

> I happen to agree that a vpn engine is not a firewall, but you two have
> put your foot in it by stating this.  

<ohh goodie, this should be fun <grin>>

> Nobody really agrees as to what a firewall is, exactly.  


My (short) definition[1] is:
firewall, n: A device or region in which you apply network security policy.

[formatting modified for clarity in my thinking]
> However, I would have to say that a vpn engine certainly does what a 
> firewall typically does.  
> A vpn engine (e.g. ipsec, 3des, sha1) discards ALL traffic except that 
> which is:
>  - authenticated,
>  - authorized, 
>  - encrypted, and 
>  - untampered with.  


> That means that all traffic that could possibly be suspected of anything 
> overt is dropped (e.g. malformed packets are dropped, icmp is dropped, 
> anything that is not on the up and up as an ipsec packet is dropped).  

Oh I get you now... "If it is properly encrypted, then it is OK"?

Please can I clarify a few things about our assumptions with respect to VPN
concentrators & VPN client/End-point devices.

I assume that you assume that: <ugly, ugly, ugly language sometimes - shakes
head> [2]
1) for Client <-> Concentrator VPNs
1.1) The client can enforce security policy
1.2) The enforced security policy will be strict enough to protect the core
network
1.3) The client can deny routing/trojan/hostile traffic.
1.4) The Encryption tunnel is strongly authenticated.
2) for Fixed VPNs
2.1) The end points have similar security postures
2.2) VPN peers are trusted networks
3) for VPN Concentrators
3.1) The VPN concentrator is capable of enforcing network security policy
(Packet filtering).
3.2) The VPN Concentrator can perform layer 3 (Source/Dest Port) inspection.
3.3) The VPN concentrator will implement similar access control rules to
those of the firewall.


Unfortunately, I must say that in my experience, very few sites match more
than 1 of the above points, and certainly no more than 3 or 4. This is
particularly so when dealing with Roaming-Clients or
Organisation<->Organisation "Partner" (Extranet) scenarios.

> However, the reason that I agree with your original
> statement "a VPN is not a firewall" is because I believe it to be a piece
> of a firewall, with a firewall being a system instead of a monlithic black
> box.  

Agreed, in fact "Strongly agree".

    BBI
     |
    [R] <ingres packet filters
     |
  ,--H--+--[s] (Hostile Zone)
  |     |
 [V]   [Fw]---+--[s]
  |     |
--+-----+--[s]

My personal preference is to have a policy enforcement system between the
VPN Terminator and the internal networks. This is mostly because I don't
trust that the traffic INSIDE the VPN is as clean as it cold be. Much of
this is because I am a paranoid SOB, who is aware that the easiest (and
often cheapest) ways to break a network are _NOT_ through the firewall:
 - Steal the CEO/CFO/CTO's laptop.
 - Break-in to the CEO/MIS' house and use the "Fully Authenticated,
Encrypted" VPN.
 - Bribe the secretary.
 - Break in to a partner organisation who has a useless firewall/VPN
security setup.

For these reasons I tend to demand/recommend strong protections on VPN's
(both fixed and roaming). 

The proviso here is that I am unlikely to be working with an organisation
that does not already have (at least a small) an understanding of security,
and the desire/requirement to implement protections. 
 
Kind regards,
        Crispin Harris

Notes:
[1] - For my longer definition, look in a recent posting on GIDS in this
forum. The GIDS thread included at least three Firewall definitions, all of
which would suffice for this discussion.
[2] - After reading the rest of your e-mail three or four times (sorry - not
thinking particularly well at the moment), I have come to the conclusion
that you are arguing a point, rather than stating that "VPN Concentrators do
not need other network access control systems", which is the position of
which I was afraid.

----------------------------------------------------

 This correspondence is for the named person's use only.  It may
 contain confidential or legally privileged information or both.
 No confidentiality or privilege is waived or lost by any
 mistransmission.  If you receive this correspondence in error, please
 immediately delete it from your system and notify the sender.  You
 must not disclose, copy or rely on any part of this correspondence
 if you are not the intended recipient.
 
 Any views expressed in this message are those of the individual sender,
 except where the sender expressly, and with authority, states them to
 be the views of DeMorgan Pty Ltd.
 
 This e-mail has been checked for known Viruses. It is the responsibility
 of the receiver to check their system for infected files and any such
 file is deemed not to be the responsibility of DeMorgan.

---------------------------------------------------------