Enterprise Level Software (Client-side) Firewall?

[RebateMonger]

Originally posted by: dclive....I don't think ISA Server 2004 is what most people would really consider a client-side firewall product in the same class as, say, Symantec Corporate FW.

(I'm MS Certified in ISA 2004). ISA 2004 is a Server-based firewall. It's a very good one and a very powerful one, but it isn't a client firewall. It won't keep a worm from spreading directly from one PC to another PC on the same subnet. It protects subnet from subnet, it protects from outside invasion, and it controls VPN and Wireless Clients. The ISA Firewall Client interacts with ISA to aid the client in its communication with ISA and allows ISA to control what the Client can and can't send and receive THROUGH ISA. Most companies don't even use the ISA Firewall Client, preferring the much-simpler NAT client or Proxy client that ISA also supports.

I have little familiarity with non-Microsoft client firewalls, other than removing them every chance I get. They cause me nothing but headaches when maintaining Small Business Server Networks. The PC owner clicks on the wrong answer and starts blocking critical communications with the Server.

My personal preference is to stick with Microsoft's XP SP2 firewall. It blocks INCOMING stuff just fine. In theory, as long as all the PCs are controlling incoming packets, you won't get anything that spreads across your entire network. And it's simple to turn on the "Don't allow exceptions" switch when traveling with a laptop.

Unlike many other client firewalls, SP2 doesn't, by default, block anything necessary for a functional Windows Server network. It's easy to create Group Policies to open additional holes if you have 3rd-party software that needs them. I can't imagine TURNING OFF the client firewalls when the PCs are inside the network. That's just asking for a worm to run rampant inside the network.

 

[dclive]

Originally posted by: RebateMonger
My personal preference is to stick with Microsoft's XP SP2 firewall. It blocks INCOMING stuff

I can't imagine TURNING OFF the client firewalls when the PCs are inside the network. That's just asking for a worm to run rampant inside the network.

I appreciate your response.

A few responses:
XPSP2 has been ruled out. The problems:
1. We need SMS functionality / We need remote control functionality. We constantly develop new products, and those must work when on the corporate network; we don't want to need to punch new holes in the FW every time a new product comes out needing another port.
2. XPSP2's location awareness, based on DNS Suffix recieved from the AD, is easy to spoof and also doesn't work with VPN networks, a critical requirement. In other words, it detects when you're on the domain network great (the physical network) and detects when you're off of it (say at a hotel), but doesn't know when you're on it via VPN and so the firewall comes up, which is unacceptable.

XPSP2's FW is a great start, and in a small (SBS!) environment, I'm sure it's wonderful. It's not an enterprise product, for our requirements.

The clients are not user-managed, so they'd have no rights to turn on or off exceptions; allowing that to take place in an enterprise environment, IMHO, is just asking for trouble.

RE: Worm: Don't allow users to install software, and keep patching up to date, and get a firewall with worm (intrusion protection/awareness) detection.

 

[RebateMonger]

Originally posted by: dcliveRE: Worm: Don't allow users to install software, and keep patching up to date, and get a firewall with worm (intrusion protection/awareness) detection.

While those actions should be adequate, it was made pretty obvious by the SQL Slammer worm that Corporate America hasn't been following those rules. A lot of BIG companies without PC firewalls enabled got hit pretty badly. Many of the infections came from INSIDE the networks.

Anyway, good luck with your quest. Let us know if you find something good, please.

 

[Czar]

Using group policies to poke holes in the xp firewall would work for you.

And if I remember correctly you can just add on your corporate firewall to trust your vpn ip addresses and use group policies to set the client so it trusts the internal network completely.

 

[dclive]

Originally posted by: Czar
Using group policies to poke holes in the xp firewall would work for you.

And if I remember correctly you can just add on your corporate firewall to trust your vpn ip addresses and use group policies to set the client so it trusts the internal network completely.

Please see all previous comments about what network we're on and why we can't do that. See also how XPSP2's location awareness doesn't work.

 

[Woodie]

Why would you set 10.* to be a trusted network? Is your internal network really that big?
We have ~500 subnets defined in our internal network, and I don't think *any* of them are class B. (~40,000 network devices, probably >50,000 ip addresses)
These subnets are all defined to the PFW that's deployed on *all* laptops. (I hope it's all laptops!)

 

[PlatinumGold]

i am a big proponent of Sonicwall Firewalls and Global VPN Client.

it works for me. i don't know if you can get it to do what you want tho.

 

[dclive]

Originally posted by: Woodie
Why would you set 10.* to be a trusted network? Is your internal network really that big?
We have ~500 subnets defined in our internal network, and I don't think *any* of them are class B. (~40,000 network devices, probably >50,000 ip addresses)
These subnets are all defined to the PFW that's deployed on *all* laptops. (I hope it's all laptops!)

The issue is that any hotel or home residence (or airport, or...) network could potentially be a 10.* network, and so if we had a policy to trust our internal 10.* network, we'd end up trusting the (local, granted) network at the hotel/airport/etc.

That's a problem.

As far as limiting things to specific subnets within 10.*, yes, that may limit the risk a bit, but we'd still be exposed unnecessarily. I believe the best solution is some sort of location awareness.

As discussed, XPSP2's location awareness doesn't quite pull it off... it also lacks other things too - comprehensive logfile reporting and forwarding (yes, it's got a basic logfile; I'd like a bit more than that), and other little issues that are disappointing (but fine for home users or small business users, I'm sure!)

 

[RebateMonger]

Originally posted by: dclive
The issue is that any hotel or home residence (or airport, or...) network could potentially be a 10.* network, and so if we had a policy to trust our internal 10.* network, we'd end up trusting the (local, granted) network at the hotel/airport/etc.

If you are using L2TP for your VPN, why would you have to trust another network? Only the remote PC is joining the VPN. Only the company-authorized remote PC is going ot have a certificate that allows it to authenticate. And the encryption and authentication protocols are supposed to prevent spoofing and changes to the packets.

 

[Woodie]

Originally posted by: dclive

Originally posted by: Woodie
Why would you set 10.* to be a trusted network? Is your internal network really that big?
We have ~500 subnets defined in our internal network, and I don't think *any* of them are class B. <snip>

The issue is that any hotel or home residence (or airport, or...) network could potentially be a 10.* network, <snip>

Hmmm...the way we've been working (>3 years w/o significant infection events) is:
Combination FW and IPS:
Configure FW for two different network groups: Internet and Intranet
Internet FW rule say: Deny all inbound, Allow all outbound
Intranet FW rule say: Allow these (Windows networking, etc...) inbound, Allow all outbound
IPS: Turned on for all subnets

Internet = *.*.*.*
Intranet = 10.x.y.*, 10.x.z.*, etc..... (No 192.168....!)

For example:
SQL Slammer attack from Internet subnet => Blocked by FW
SQL Slammer attack from Intranet subnet => Blocked by IPS
Windows networking request from Internet => Blocked by FW
Windows networking request from Intranet => Permitted by FW, no attack signature noted, so permitted by IPS.

Note that there is no "trusted" network, just subnets w/ different FW rules.

 

[dclive]

Originally posted by: RebateMonger

Originally posted by: dclive
The issue is that any hotel or home residence (or airport, or...) network could potentially be a 10.* network, and so if we had a policy to trust our internal 10.* network, we'd end up trusting the (local, granted) network at the hotel/airport/etc.

If you are using L2TP for your VPN, why would you have to trust another network? Only the remote PC is joining the VPN. Only the company-authorized remote PC is going ot have a certificate that allows it to authenticate. And the encryption and authentication protocols are supposed to prevent spoofing and changes to the packets.

I don't need to trust 'another' network. The office network and the VPN network are 10.*. If I was to do trusted zones (and not any kind of location detection) then I would trust all of 10.*. If I was at the office, that would be great. If I then went to a hotel with a 10.* network, I'd be vulnerable.

That's the issue with trusted networks.

 

[dclive]

Originally posted by: Woodie

Originally posted by: dclive

Originally posted by: Woodie
Why would you set 10.* to be a trusted network? Is your internal network really that big?
We have ~500 subnets defined in our internal network, and I don't think *any* of them are class B. <snip>

The issue is that any hotel or home residence (or airport, or...) network could potentially be a 10.* network, <snip>

Hmmm...the way we've been working (>3 years w/o significant infection events) is:
Combination FW and IPS:
Configure FW for two different network groups: Internet and Intranet
Internet FW rule say: Deny all inbound, Allow all outbound
Intranet FW rule say: Allow these (Windows networking, etc...) inbound, Allow all outbound
IPS: Turned on for all subnets

Internet = *.*.*.*
Intranet = 10.x.y.*, 10.x.z.*, etc..... (No 192.168....!)

For example:
SQL Slammer attack from Internet subnet => Blocked by FW
SQL Slammer attack from Intranet subnet => Blocked by IPS
Windows networking request from Internet => Blocked by FW
Windows networking request from Intranet => Permitted by FW, no attack signature noted, so permitted by IPS.

Note that there is no "trusted" network, just subnets w/ different FW rules.

For the intranet (which is, essentially, you're 'almost-trusted' network) you'd have to keep it up to date; we have multiple groups of development teams releasing new applications into the environment; we don't want to have a full time firewall person needed, who'd constantly have to update what ports were open or what programs were allowed on the intranet.

Also, that model doesn't account for laptops. If you have a laptop on that network, and then take it to a hotel and plug it into a 10.* network, you're vulnerable, because you trust everything on your allow list. Assuming you've got a few remote control tools and normal filesharing permitted (hard to do away with that....) it's concievable that you'd be fairly vulnerable.

Bear in mind we're talking degrees of vulnerability. I'm not suggesting the rule is inherently horrible or that there's anything wrong with it - there's just a decision to be made about the amount of acceptable risk.

 

[dclive]

BTW, the IPS in all that is the saving grace. Symantec's products have it, and it's quite a good feature.

 

[Woodie]

Agreed, IPS is the saving grace.

FWIW, we've seen very few "public" networks using the 10.* We do see 10.* a lot in other companies (mid-size & above), usually found during the M&A process. Most people running small LANs/WLANs tend to stick w/ the 192.168 stuff.

Our "Intranet" rules get around the FW maintenance issue by pretty much allowing *any* port. =

(Security or Convenience...you can't have both!)

 

[Goosemaster]

Originally posted by: Woodie

Originally posted by: dclive

Originally posted by: Woodie
Why would you set 10.* to be a trusted network? Is your internal network really that big?
We have ~500 subnets defined in our internal network, and I don't think *any* of them are class B. <snip>

The issue is that any hotel or home residence (or airport, or...) network could potentially be a 10.* network, <snip>

Hmmm...the way we've been working (>3 years w/o significant infection events) is:
Combination FW and IPS:
Configure FW for two different network groups: Internet and Intranet
Internet FW rule say: Deny all inbound, Allow all outbound
Intranet FW rule say: Allow these (Windows networking, etc...) inbound, Allow all outbound
IPS: Turned on for all subnets

Internet = *.*.*.*
Intranet = 10.x.y.*, 10.x.z.*, etc..... (No 192.168....!)

For example:
SQL Slammer attack from Internet subnet => Blocked by FW
SQL Slammer attack from Intranet subnet => Blocked by IPS
Windows networking request from Internet => Blocked by FW
Windows networking request from Intranet => Permitted by FW, no attack signature noted, so permitted by IPS.

Note that there is no "trusted" network, just subnets w/ different FW rules.

very nice....

 

[melthemoose]

didn't I read somewhere that Cisco's VPN client has, when active, an embedded software firewall?

 

[servin247365]

Zone alarm has a free firewall and it seems to work very well.

www.zonelabs.com

JML

 

[dclive]

Zone Alarm isn't an enterprise product. It's designed for the local user who runs as administrator.

I've gone with XPSP2's firewall. With a bit of scripting, the firewall on the VPN interface(s) can be completely turned off, and then the on-domain and off-domain sensing works flawlessly. The issue was just the behavior of the firewall when VPN'd in. Now that that issue is resolved, it's a fairly good solution for our fairly basic needs.

I'd like to thank everyone for their feedback and opinions!

 

[RebateMonger]

Originally posted by: dclive
I've gone with XPSP2's firewall. With a bit of scripting, the firewall on the VPN interface(s) can be completely turned off, and then the on-domain and off-domain sensing works flawlessly. The issue was just the behavior of the firewall when VPN'd in. Now that that issue is resolved, it's a fairly good solution for our fairly basic needs.

Thanks for following up. Good luck with it.

 

[Smilin]

Originally posted by: dclive
Zone Alarm isn't an enterprise product. It's designed for the local user who runs as administrator.

I've gone with XPSP2's firewall. With a bit of scripting, the firewall on the VPN interface(s) can be completely turned off, and then the on-domain and off-domain sensing works flawlessly. The issue was just the behavior of the firewall when VPN'd in. Now that that issue is resolved, it's a fairly good solution for our fairly basic needs.

I'd like to thank everyone for their feedback and opinions!

Hey just so you know dclive, there have been some gripes about the sensing mechanism and requests to correct it. Not at liberty to discuss where that process is at though.

 

[dclive]

Can you provide more detail on the potential problems, the frequency of the problems, and the conditions under which they're experienced? In all of my tests we've had 100% success, and it's been -faster- at detection then Checkpoint's Integrity product (no delay, vs. a 1-2 minute delay from the Checkpoint product). Quite impressive.

Any KBs written yet?

 

[nightowl]

Cisco Security Agent. That is what is running on my laptop and has protected it so far from all of the attacks/worm.

 

[Smilin]

Originally posted by: dclive
Can you provide more detail on the potential problems, the frequency of the problems, and the conditions under which they're experienced? In all of my tests we've had 100% success, and it's been -faster- at detection then Checkpoint's Integrity product (no delay, vs. a 1-2 minute delay from the Checkpoint product). Quite impressive.

Any KBs written yet?

No KBs that I'm aware of. This may help..
http://www.microsoft.com/technet/community/columns/cableguy/cg0504.mspx

profile determination is also covered here:
http://www.microsoft.com/technet/prodte...b6af5-d960-4a8d-b12b-70692dc47bf4.mspx

There is no actual bug. It's just the detection algorithm is a bit simplistic. Basically it looks at the connection suffix and compares it to the connection suffix used the last time group policy was pulled down. If same, you're on domain, if not, you're not and it applies the appropriate policy. Dial up and VPN connections are ignored for this comparison. That's pretty much it. Works great in most cases but there are some specific circumstances where the wrong policy can be applied or the OS can be fooled into applying the wrong policy.

As a best practice, keep your domain firewall policy locked down enough so that should you inadvertently connect to a rogue wireless AP for instance that you're still safe.

 

[piasabird]

Some non-microsoft products can kill other windows boxes if they start taking over as master browser.

You could solve this if you take an old PC at home and just make it into a firewally using a Linux Firewall Box.

Smoothwall is one example of this. I think just using two nics and a windows box you can put one firewall on it and just put in two nic cards and configure it as a firewall/router for your network.

If you were not so cheap you could just buy a firewall for home use.

 

[dclive]

Originally posted by: piasabird
Some non-microsoft products can kill other windows boxes if they start taking over as master browser.

You could solve this if you take an old PC at home and just make it into a firewally using a Linux Firewall Box.

Smoothwall is one example of this. I think just using two nics and a windows box you can put one firewall on it and just put in two nic cards and configure it as a firewall/router for your network.

If you were not so cheap you could just buy a firewall for home use.

Entire topic concerns firewall for client machines, not the network as a whole.