Why VPNs aren't magic silver bullet solutions

[Mikael Olsson <mikael.olsson () enternet se>]

Hi all,

I thought I'd do a quick write-up in an attempt to clear up some
misunderstandings about VPNs -- to me, it's apparently needed,
judging from some of the solution suggestions I've seen lately.
(FAQ grade material perhaps? :) )


Why VPNs aren't magic silver bullet solutions
---------------------------------------------
Or: Chains are never stronger than their weakest link
Or: Secrecy is NOT the same as security!

Lately, I've seen lots of proposed solutions for getting traffic 
from one network segment to another network segment by means of 
VPNs, simply because it means "fewer ports opened in the firewall".

Consider this example (view with fixed-width font or you'll
just get garble)


              |
              |
            ----
            |FW|-----------------------
            ----                    |
              |                     |
     Internal | Net             DMZ | Net
   |------------------|     |-----------------|
          |                            |
         ---                          ---
         | |                          | |
         ---                          ---
   Exchange Server            Outlook Web Access


In this scenario, we need to give the OWA machine access to
the Exchange server. Obviously, the OWA won't do much good
if it can't get to the e-mails it is supposed to view.


There are a lot of issues involved here, and this is far
from the optimal design, but in order to get this to
work, amongs other things, you'd need to allow DCE RPC
access from the OWA to the Exchange machine. This means:

- You have to allow access from OWA to Exchange port 135.
  This is the actual endpoint mapper which tells the OWA
  where to connect to get the real work done.

- You have to allow access from OWA to Exchange, on a dynamic
  port range. This used to mean 1024-65535, but fortunately, 
  Microsoft implemented a setting that controls which ports
  the Exchange server uses. This means that you get to choose
  the port span yourself. Let's use 40000-40099, since no
  other services are likely to live there. This leaves
  room for 100 simultaneous connections, which is probably
  realistic in most setups.


This means a total of 101 ports open from the OWA machine
to the Exchange machine, which is quite a lot.

The suggestion was to decrease the number of ports allowed
through the firewall by creating a PPTP tunnel between the 
OWA and the Exchange servers. This would mean that we'd "only" 
have to allow one port and one IP protocol, which looks good 
at a first glance; we've reduced 101 ports to 1 port and 1 IP 
protocol.


Why the VPN is no good here
---------------------------

I believe there are a two main misconceptions involved here.

Misconception 1: It is always better to have fewer open ports
  in a firewall, no matter how you reach that goal.

Misconception 2: Everything travelling through a VPN is 
  automagically safe and secure, simply because it is
  really hard to break into the connection.

There is some truth in both.

Truth 1: You're generally better off trying to limit access 
  between network segments with different security ratings.
  This usually involves limiting the number of ports and
  IP addresses that may be accessed. You shouldn't _ever_
  allow DMZ machines to connect to internal machines, but
  this is beside the point here. Let's assume, for the
  sake of argument, that this was the only way to do it

Truth 2: A third party cannot generally break into a VPN. 
  Just don't suggest PPTP here; there's a reason why 
  Microsoft moved away from PPTP and started pushing L2TP 
  via IPsec instead. Read more about this on:
  http://www.counterpane.com/pptp.html
  Let's assume, for the sake of argument, that a better
  VPN protocol is used.

However, here are a couple of statements that the above 
misconceptions completely fail to address.

- A chain is never stronger than its weakest link. This is 
  certainly old wisdom, but wisdom does not cease being
  wise simply because it is old. Read on to see what I'm
  getting at.

- A VPN (a "tunnel") is never stronger than its endpoints.
  For a good real-world parallel, consider a tunnel through
  a mountain. That's thousands tons of rock there; it 
  is highly unlikely that someone is going to break through
  the tunnel roof through the mountain. 
  But why go to that trouble of doing that, when all you
  have to do is drive in through the opening at either side?

  I know, some of you may be thinking "Bah, those real world 
  examples are always flawed anyhow", but, really, this one
  isn't. The opening of the tunnel (the VPN endpoint) is wide 
  open to the IP stack or application that established the tunnel.
  The VPN will happily push anything across the tunnel that
  gets shoved in its opening in either end.


I can see how these properties would seem attractive to the
casual home-brew security administrator. Nothing can get to
the Exchange server, unless it actually comes from the OWA
server.


What the VPN really is - how to view it
---------------------------------------

At this point, some of you may say "AHA! I See the problem!
Someone can route IP packets to the OWA server, which in turn 
pushes them through the VPN in to the Exchange server!"
and instantly see the remedy "But then all I'll do is
disable routing on the server, or better yet, I'll make
the tunnel be only NetBEUI! Then there is NO way that
IP packets can get through the tunnel!"

No, that's not what I'm getting at.

First, I'll tell you something that usually is a great
help in designing VPNs:

Forget about cryptography. Forget about authentication.
This is only about making sure that noone can read or 
tamper with the data once it's left the network card
of the VPN endpoint

Stop thinking about the "V" in "VPN". Just think
"Private Network". VPNs were designed to replace
physical cables between the two endpoints, and that
is really all that they do, seen in this context.

Instead of thinking crypto here, imagine this:

- We add an extra network card to each server.
- We then attach these two extra NICs to eachother
  with a separate cable. 
- We disable routing at both hosts. I told you that
  this was not the problem.

In this context, the separate cable is the security
equivalent of a VPN connection between the two machines.

So, we get the following network layout:

              |
              |
            ----
            |FW|-----------------------
            ----                    |
              |                     |
     Internal | Net             DMZ | Net
   |------------------|     |-----------------|
          |                            |
         ---                          ---
         | |--------------------------| |
         ---                          ---
   Exchange Server            Outlook Web Access


Beginning to see the problem yet?

"No, because routing is disabled, and besides, I've 
 only enabled NetBEUI, so packets really can't get
 from the outside to the Exchange server."

"No, because this is even better - I don't have
 to open a single port in the firewall. This is great!
 Besides, I can run PPTP on the link too, which will
 give me even more security!"

If you agree with any one of the above two quotes,
you haven't seen the problem.


Understanding how attackers work the application layer
------------------------------------------------------

Your attacker will NOT try to bounce packets through
the Private Network (be it Virtual or not). This simply
won't work, unless they can take over the firewall and
alter its routing table (in which case you have other,
MUCH worse problems to worry about.)

Stop thinking IP here. Think "vulnerable applications"
and "remote control" instead.

- WHAT if there is a bug in the Outlook Web Access server;
  either in its scripts and components, or in the underlying 
  Internet Information Server itself?

- WHAT if this bug allows the attacker to execute commands
  on the server AS IF HE WAS SITTING ON THE CONSOLE?

This is true of most intrusion attacks.

An attacker that wants to get to your internal machines
will very likely attack the outer ones and hope that there
is some way of opening new connections to internal machines,
simply because he knows that _many_ networks are designed 
this way.

Stop thinking about the DMZ machines as "a server with
a router in it". Start thinking about them as "reverse
proxies that do whatever the attacker wants them to do".


With a (V)PN connection between the DMZ machine and an
internal machine, the DMZ machine is allowed to connect
to ANY port and protocol of the internal machine. If you
restrict this to NetBEUI, you get a situation where the
attacker is able connect to any "pipe" or "mailslot" that
is available through NetBIOS, which isn't much better.

The internal machine will happily accept these connections.
After all, it came from the DMZ server through the VPN,
which it is configured to trust to some extent.

Again, don't worry about IP. Worry about the application
layer vulnerabilities that you expose yourself to by
implementing a network layout like this.

It doesn't matter if these attacks are delivered through
IP, NetBEUI, IPX, serial line, floppy disk or singing
telegram. If you let your DMZ hosts execute commands
of some sort (such as opening a mailbox?), through a 
transport of some sort, on machines connected to the 
internal network, you're most likely, pardon my french, 
thoroughly screwed. The situation is even worse so if 
you do not limit what services they can get to.



In conclusion, what we've done here is transform
the 101 open TCP ports to:
- 65536 open TCP ports
- another 65536 open UDP ports
- an additional 254 IP protocols.

Certainly, we've limited what ports get to pass through
the firewall. But so what? We're not worried about 16-bit
integer port numbers passing through the firewall. 16-bit 
numbers won't bite you. Neither will 32-bit IP addresses.

We're worried about what means of communication on the 
internal machine that are available to the DMZ host -- the 
ports and protocols that the DMZ host can connect to, no 
matter how the connection is made.

With an unrestricted VPN, _everything_ is available.

Certainly, it is only available to a machine that can
properly encrypt and authenticate the data it sends,
but remember: The VPN endpoint, the DMZ server, will
happily encrypt and authenticate anything that it
is instructed to send. And if an attacker can execute
arbitrary commands on that server, anything can
be sent through the VPN.

----8<---

Whew! Why do I always get so long winded with these
things? Oh well, I'm done for this time. 

If you're still with me, thanks for listening. I hope 
it'll aid atleast some in choosing better designs for 
their networks.

Regards,
Mikael Olsson

_______________________________________________
Firewall-wizards mailing list
Firewall-wizards () nfr net
http://www.nfr.net/mailman/listinfo/firewall-wizards