Alex, although technically correct, its not practical. How many end users
vpn in from home from say a public ip on their dsl modem leaving
themselves open to attack but now also having this connection back to the
"Secure" inside network. Has anyone heard of any confirmed cases of this
yet?
I hate to blow a vendor's horn, BUT... checkpoint has atleast thought this
through with SecureClient. There is the ability to push down on the vpn
client a local security policy that SHOULD allow you to enforce corporate
network security policy on the remote system.
> Alex, although technically correct, its not practical. How many end users
> vpn in from home from say a public ip on their dsl modem leaving
> themselves open to attack but now also having this connection back to the
> "Secure" inside network. Has anyone heard of any confirmed cases of this
> yet?
So then they are using a wrong tool. Using a wrong security tool tends to
bite one in the <censored>.
So what's the right tool? Yes, dial or dsl directly into corporate network
is my preferred option, but doesn't fit the corporate plan for the future.
Yes, I have seen attacks mounted via VPNs. Work like charm.
As I suspected, but I keep being told that these problems were in old style
VPN clients, and stuff is much better these days. I remain unconvinced.
Simon
Given that the head of one of our three-letter-agencies managed to get
this sort of thing wrong, what makes you think that Joe Middle-Manager
who's more concerned about fixing a spreadsheet will get it correct?
> > Alex, although technically correct, its not practical. How many end users
> > vpn in from home from say a public ip on their dsl modem leaving
> > themselves open to attack but now also having this connection back to the
> > "Secure" inside network. Has anyone heard of any confirmed cases of this
> > yet?
> So then they are using a wrong tool. Using a wrong security tool tends to
> bite one in the <censored>.
So what's the right tool? Yes, dial or dsl directly into corporate network
is my preferred option, but doesn't fit the corporate plan for the future.
Use a client that will push down corporate policy to the client.
> Yes, I have seen attacks mounted via VPNs. Work like charm.
As I suspected, but I keep being told that these problems were in old style
VPN clients, and stuff is much better these days. I remain unconvinced.
VPN client creates a fake IP interface. If that interface deos not get the
policy of a corporate network, you have an open enterance. Some of the
clients (such as the ones CheckPoint has) do that. Others dont.
Alex
> This is not correct. VPN simply extends security policy to a different
> location. A VPN user must make sure that local security policy prevents
> other traffic from entering VPN connection.
Given that the head of one of our three-letter-agencies managed to get
this sort of thing wrong, what makes you think that Joe Middle-Manager
who's more concerned about fixing a spreadsheet will get it correct?
Because it is not that difficult. A security policy of a little office is
very different from a security policy of a three letter agency. In fact,
fixing a spreadsheet could be mode difficult than implementing a security
policy for an office with 5 computers that are connected to the Internet.
Alex
Ahh... but in the case of SQLSlapper, you have a packet coming in to the
PC.. That traffic doesn't get restricted by your hypothetical security
policy, since it's not entering the VPN, and the outbound traffic isn't
either, because it's locally generated.
This also means that your security policy needs to be fixed so Outlook is not
permitted to connect to any other mail servers - because otherwise the user can
check their AOL account, pick up a Nimda, and whomp it into the VPN.
In fact, if you're talking to the VPN and allow any non-VPN connections
*at any time* (even when the VPN isn't active), you have a vulnerability - think
about downloading a file that has a virus that doesn't have a signature from
the vendors yet (like the first 75,000 copies of Nimda that his our mail
server). Wanna bet that when that VPN connects, there's some shares available
for the virus to attack? 
It's not as easy as it looks.
A good VPN client (I'm familiar with Nortel) will enforce no *simultaneous*
access to or from on-VPN and off-VPN destinations. But I'm not aware of
anything that will enforce that a home or portable machine has never been
connected to anything but the corporate network. That would take TCPA
or the equivalent, which would not bother me if it's on the company's
machine and under control of the company - maybe the only scenario where
TCPA/Palladium-ng would be acceptable.
> > Given that the head of one of our three-letter-agencies managed to get
> > this sort of thing wrong, what makes you think that Joe Middle-Manager
> > who's more concerned about fixing a spreadsheet will get it correct?
>
> Because it is not that difficult. A security policy of a little office is
> very different from a security policy of a three letter agency. In fact,
> fixing a spreadsheet could be mode difficult than implementing a security
> policy for an office with 5 computers that are connected to the Internet.
Ahh... but in the case of SQLSlapper, you have a packet coming in to the
PC.. That traffic doesn't get restricted by your hypothetical security
policy, since it's not entering the VPN, and the outbound traffic isn't
either, because it's locally generated.
Umm... Why is outside world talking to your database server without
supervision?
This also means that your security policy needs to be fixed so Outlook is
not permitted to connect to any other mail servers - because otherwise the
user can check their AOL account, pick up a Nimda, and whomp it into the
VPN.
Umm.. Why is your security policy allowing outlook to connect to somewhere
other than your company mail server?
In fact, if you're talking to the VPN and allow any non-VPN connections
*at any time* (even when the VPN isn't active), you have a vulnerability - think
about downloading a file that has a virus that doesn't have a signature from
the vendors yet (like the first 75,000 copies of Nimda that his our mail
server). Wanna bet that when that VPN connects, there's some shares available
for the virus to attack? 
Nope, in fact, the idea "allow everything from inside to out" is the reason
the vast majority of the problems in the policy.
It's not as easy as it looks.
It is very easy.
Deny everything.
Allow outbound port 80
Allow mail server to 25
Allow ident
If you need netmeeting, allow netmeeting server to other servers.
If you need AIM, allow AIM from workstations to oscar.aol.com and whatever
the name of the other mahine.
I am failing to see a problem.
That's fine for a non-MS view of the world (admittedly, a view I prefer),
but then you've got to allow TCP 138/139 to all the MS servers in your
organisation (why couldn't they seperate auth from file sharing from...).
And then whatever protocols Outlook uses to talk to your
Exchange servers (and if I understand it correctly, that might be more than
one to get to Public Folders, etc). And then SAP. And then Business App A.
And the Business App B. And... And...
Me? I'd give them ports 443, 80, 53, 25 and 22, and be done with it.
If you can't do it with those ports, it's probably not implemented right
Simon
That's fine for a non-MS view of the world (admittedly, a view I prefer),
but then you've got to allow TCP 138/139 to all the MS servers in your
organisation (why couldn't they seperate auth from file sharing from...).
And then whatever protocols Outlook uses to talk to your
Exchange servers (and if I understand it correctly, that might be more than
one to get to Public Folders, etc). And then SAP. And then Business App A.
And the Business App B. And... And...
Again, but why does it talk to the outside world unsupervised? Your
organization clearly has a border that separates its internal systems from
external ones. Why not apply those restrictions on *those* borders?
Alex
on random port numbers. And other protocols which use random port numbers
(not just peer-to-peer, but also things like FTP, etc).
But, we were talking about end-user connected into the inside network using
a VPN. That user needs to have pretty much unfettered access to the
business parts of your internal network. (Okay, mission critical stuff
should be seperately firewalled, but MS makes that hard enough, due to
things like Active Directory, where everything needs to talk to everything).
Simon
But, we were talking about end-user connected into the inside network using
a VPN. That user needs to have pretty much unfettered access to the
business parts of your internal network. (Okay, mission critical stuff
should be seperately firewalled, but MS makes that hard enough, due to
things like Active Directory, where everything needs to talk to everything).
So what prevents the client from denying all traffic other than (a) traffic
on VPN interface (b) IP traffic on non-VPN interface with destination other
than the address that VPN client uses to build VPN?
Alex
It is very easy.
Deny everything.
Allow outbound port 80
Bzzt! You just let in an ActiveX exploit. Or Javascript. Or....
Allow mail server to 25
Bzzt! You just let in a new Outlook exploit.
If you need AIM, allow AIM from workstations to oscar.aol.com and whatever
the name of the other mahine.
Bzzt! You just let in an AIM exploit. That's assuming that you even *know*
what the current name of the other machine is this time around - this
laptop has had 6 IP addresses in as many hours. Remember there's a reason
why 'talk george@his-box.whatever.dom' isn't as common anymore....
I am failing to see a problem.
Well.. other than you let a box that wants to talk on the VPN get outside
access to 3 things that are *KNOWN* vectors of malware which could then
attack the VPN side of things, no, there's no problem here.
> Deny everything.
> Allow outbound port 80
Bzzt! You just let in an ActiveX exploit. Or Javascript. Or....
And I have successfully blocked everything other than AcriveX or JavaScript
or whatever else.
> Allow mail server to 25
Bzzt! You just let in a new Outlook exploit.
It is talking only to your own server. Presumably you already made sure that
your Outlook by itself does not do anything funny?
> If you need AIM, allow AIM from workstations to oscar.aol.com and whatever
> the name of the other mahine.
Bzzt! You just let in an AIM exploit. That's assuming that you even *know*
what the current name of the other machine is this time around - this
laptop has had 6 IP addresses in as many hours. Remember there's a reason
why 'talk george@his-box.whatever.dom' isn't as common anymore....
Oscar.aol.com and whatever the name of another .aol.com machine it is
are the names associated with services that AIM connects to.
> I am failing to see a problem.
Well.. other than you let a box that wants to talk on the VPN get outside
access to 3 things that are *KNOWN* vectors of malware which could then
attack the VPN side of things, no, there's no problem here.
That's why the policy on that box that wants to talk to the secure network
over VPN is to drop all but the traffic to/from gateway VPN client connects
to on the floor.
It is being done. CheckPoint, for example, manages to manage policy on the
client not to contradict the policy of the site. Why dont others do it is
beyond me.
Alex
was seen to say:
This is not correct. VPN simply extends security policy to a different
location. A VPN user must make sure that local security policy
prevents other traffic from entering VPN connection.
This is nice in theory, but in practice is simply not true. even
assuming that the most restrictive settings are used (user may not
install software by admin setting, has no local administration on his
machine, IP traffic other than via the VPN is exclusive to the vpn
client) it is *still* possible that the machine could be compromised by
(say) an email virus who then bypasses security by any one of a dozen
routes.
> This is not correct. VPN simply extends security policy to a different
> location. A VPN user must make sure that local security policy
> prevents other traffic from entering VPN connection.
This is nice in theory, but in practice is simply not true. even
assuming that the most restrictive settings are used (user may not
install software by admin setting, has no local administration on his
machine, IP traffic other than via the VPN is exclusive to the vpn
client) it is *still* possible that the machine could be compromised by
(say) an email virus who then bypasses security by any one of a dozen
routes.
Welcome to the world of formal security models. If in theory a VPN is
nothing more than a tool of extending the security policy of a site to a
remote location, then it does not matter what kind of things you try to
achieve with it, it *wont* work for anything other than extending a security
model of a site to a remote location. Can one try to use it for something
else? Sure, one can. It may even work for a little bit, as long as it does
not contradict that security model.
Your VPN connection dropped you back into your site. If it is site's
security model that all mail comes in and goes out via some mail server that
filters out email viruses, and via VPN you are virtually in a footprint of
that site, then why are you not using the site mail server or why is the VPN
client lets you not use it? If it does not enforce the site's security
policy, then it is a BAD VPN client.
Alex
Welcome to the world of formal security models. If in theory a VPN is
nothing more than a tool of extending the security policy of a site to a
remote location, then it does not matter what kind of things you try to
achieve with it, it *wont* work for anything other than extending a security
model of a site to a remote location. Can one try to use it for something
else? Sure, one can. It may even work for a little bit, as long as it does
not contradict that security model.
Right. In the *formal* sense, this is correct.
But that's not how things work out in the Real World. As I pointed out
before, you have *USERS* involved, and they'll do stupid things like try
to connect their laptop to the internet. And as I also pointed out,
if the head of a TLA screws up and Gets This Wrong, why should we expect
untrained, non-security-aware users to Get It Right?
The problem is exacerbated by the fact that these mobile laptops are usually
*NOT* configured like a kiosk, where the user is unable to make any changes.
that site, then why are you not using the site mail server or why is the VPN
client lets you not use it? If it does not enforce the site's security
policy, then it is a BAD VPN client.
And when the VPN client isn't even running, what stops the user from changing
the mail software config to fetch his mail from some other server like AOL or
MSN or whatever?
Remember - users do NOT care about security. Users care about finishing
whatever task THEY are busy with, which is almost never security.
was seen to say:
Your VPN connection dropped you back into your site. If it is site's
security model that all mail comes in and goes out via some mail
server that filters out email viruses, and via VPN you are virtually
in a footprint of that site, then why are you not using the site mail
server or why is the VPN client lets you not use it? If it does not
enforce the site's security policy, then it is a BAD VPN client.
Email is different, unfortunately.
Almost unavoidably, if you use Exchange and Outlook (and managment will
often refuse to drop their expensive and security-vunerable addiction to
that tool), you are going to get infections at some point. AV libraries
are (unfortunately) largely reactive, and often are up to a day behind
an outbreak (if the attackers plan the release well to maximise the time
it takes to get people working on a library update)
Once a VPN client is infected though, it has more opportunities to gain
access to a "raw" internet connection than a lan host would. The same
goes for an infected CDR or floppy - if it *knows* it is on a vpn
machine, it can find ways to get raw access that would be impossible for
a lan machine to even attempt. Consider a VPN machine a LAN machine
with a modem hanging off it already configured for an ISP - nobody in
their right mind would allow that to be *issued* as a standard setup,
but if you have to have that setup, you are going to have to work bloody
hard to keep it secure - made worse if the laptop is in a salesperson's
home where they can convince themselves it is "only fair" or "everyone
does it" when they (or their offspring) bypass security settings to get
into kazaa... or worse yet, where they download the client onto their
broadband-connected machine to connect with because "that dialup is too
slow"
1. Should it happen?
no
2. do we slap them down for it when we find out?
yes
3. Should we assume that it won't happen because they know about (1) and
(2)?
this is the real world.