On Mon, 10 Sep 2001, Jason Lewis wrote:
> While we are on the subject..... Care to go into detail about why VLAN's
> shouldn't be assumed to be secure either? I can't tell you how many
> "discussions" I have had why the firewall shouldn't be in just another VLAN
> off the 6509.
>
> I am sure the list would benefit.
Well, eventually I'll try to get this all written up with pictures and
formal arguments with more exact language (if for nothing else than the
sure joy of watching the folks at Information Security Magazine cringe at
deciding if they wanna run it...)
The basic problem with VLANs is that they're trust extenstion products,
not security products, and anytime you extend trust, you open yourself up
to misuse of that trust relationship. VPNs rely on one thing to function
properly- that's the integrity of the encryption boundry at each endpoint.
For LAN to LAN encryption, it's a pretty easy initial risk assment to make
(and indeed some companys require a high degree of assurance before
extending that boundry to another company or even another office- we sell
a good ammount of corporate certifications because people require the
other end of the link to maintain a continuous security posture that's in
line with the essential elements that make them resistant to attack.[1])
If it's enough of a problem for serious folks to worry that much about,
what chance does the average admin who has few resources and less budget
have to deploy a reasonably safe solution?
The trouble with VLANs are that besides not generally being able to do a
good job of that risk assessment (hey, they're deploying to save money-
why would you tie funding for security into it when you're trying to save
money?) is that people tend to decide quite quickly that remote node type
solutions are a good thing[tm.] Either for that programmer who's going to
quit otherwise, the admin who's too lazy to drive in, the CFO just read
the dial-up bills, your vendor wants more per-seat revenue, the CIO just
read something in a magazine or whatever.
So, now we're sitting on say a home Ethernet hooked up to a DSL network.
If we're *extremely lucky* the only thing on our end of that link is a
company-owned PC with integrity checking software, and a VPN client that
restricts connections (or better yet connections and client software)
while the tunnel is active. Generally though, that's not the case. That
means that we're stuck with our encryption boundary being completely
broken (or we pay lip service to the requirement by making the client push
HTTP/HTTS traffic through the corporate firewall.) Now that we've broken
the encryption boundary, how well the keys are managed, the fact that they
tend to be on untrusted and unprotected clients, etc. doesn't even enter
into the fray (for a prime example look at Microsoft's source code loss
last year due to a trojan.)
Now, you might be thinking- well, if it's going through the firewall to do
HTTP/HTTPS, it's no worse off than any computer on the corporate LAN would
be- and that might be true for some instances, but (a) most PCs in homes
aren't as well managed for things like AV as corporate machines, and (b)
we start to create a rather interesting issue for the company about who
has physical access to machines "on" the corporate network. That doesn't
even get into sharing access with minors who happen to dwell in the same
place (I've got great "how would you handle" scenerios for that!), how you
deal with ECPA/Privacy issues for data if it's not a company machine, what
defines appropriate use, and if there are other machines in the household
sharing the same network. Let's ponder someone with a wireless-enabled
hub in an apartment complex only briefly before we start to sigh because
we *know* that tech support will be the neighbor kid's idea of
computer management inside of three weeks.
Adding in the entire key management problem, the fact that it's very
difficult to do good authentication, the fact that you generally have to
leave that tunnel's corporate endpoint open to the world to probe at, and
*then* start thinking about how you deal with dismissing one half of a
two-roomate dwelling, and the fun gets even better.
It's bad enough when you can bound the external users to a set of
extranetish servers, but most times you end up giving them peer-to-peer
access to the entire internal network.
Just like SSL, VLANs tend to attack the secondary part of the problem
(transit) instead of the primary problem (endpoint security.) Very few
credit card numbers are lost to sniffers, and statiscally its' got to be
close to zero compared to the number lost in server breakins. While
people keep spending an enourmous ammount of time worrying about using
128-bit encryption there are zero real cases in the entire world where
people using 40-bit encryption lost their credit card data.
Yet, without addressing endpoint security in more than the most general
and limited sense, most folks that deploy VPNs think they've bought
themselves security rather than extended their trust boundary immensely.
Done well, VPNs add complexity and cost to the equation to the point where
leased-line and dial-up access start to look pretty good. Most places
however don't do them well.
I could rant on about the problems that have been seen in IVs in IPSec
products, the FWZ1/Secure Remote thing is at least another whole page of
ranting in and of itself.
Anyway, that's the gist of it, the entire thing, with pictures, things to
worry the lawyers with, potential proteciton mechanisms and stuff like
that is on the list of things to write, it's just hiding under some other
stuff that needs to be finished first.
Paul
[1.] My employer's name, along with program details are available via
direct e-mail to just me, please don't clutter the list with questions
about it- name purposefully omitted becasue I'm trying to make a point,
not make sales and I'd hate to have to flame myself!
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
