From: "Tony Kapela"

Maybe the underlying theme is that, for whatever reasons (market preassures, business idiocy?), we find ourselves on a network that's largely a collection of monoculture hosts -- win32 on x86.

It's been awhile, but both sendmail and cisco routers themselves have had their worms that pointed out this very same issue. Apache had it's worm, although craftily only targeted red had/variants despite others being vulnerable. win32 wasn't even around during the original worms that treatened entire networks. I'm not a win32 fan (ignore the fact that I'm sending this from my win32 gaming system), but it has never been a matter of a specific OS, hardware platform, or software package. It is a matter of awareness. Many people were caught off guard by this attack as their networks weren't designed to guard against and still be managable from inside threats. They won't be caught unprepared twice. Vendors are slowly learning what to test for and protect against. Consumers are starting to realize (a little bit) that they have an impact on the 'net. But seriously, what's the virus policy of many Providers? Are infected accounts cancelled until fixed? Does I provider think about their contribution to the network as a whole or just the big buck? Jack Bates BrightNet Oklahoma

...

Note that in the case of a worm, a VPN could work against you. If you have all the right filters in place at your "perimeter" and yet let your employees in through a VPN solution of some sort, you could still be screwed if one of their home systems gets infected somehow.

So what you're saying is that a really good worm could infiltrate any secure network by targetting those who vpn from exterior sources, collect data, and then run? Hmmm. Wait a sec. Would that constitute a worm if it had purpose?

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. Alex

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>. Yes, I have seen attacks mounted via VPNs. Work like charm. Alex

On Mon Jan 27, 2003 at 03:03:09PM -0500, alex@yuriev.com wrote:

...

...

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

On Mon, 27 Jan 2003, Scott Granados wrote:

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.

On Mon, 27 Jan 2003 alex@yuriev.com wrote:

...

...

...

Note that in the case of a worm, a VPN could work against you. If you have all the right filters in place at your "perimeter" and yet let your employees in through a VPN solution of some sort, you could still be screwed if one of their home systems gets infected somehow.

So what you're saying is that a really good worm could infiltrate any secure network by targetting those who vpn from exterior sources, collect data, and then run? Hmmm. Wait a sec. Would that constitute a worm if it had purpose?

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.

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

...

...

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...

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

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

...

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

...

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

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

at Tuesday, January 28, 2003 4:52 PM, alex@yuriev.com <alex@yuriev.com> was seen to say: 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.