Re: Client End Firewalls

• Previous message: GUs: "Fw: MAC level authentication or filtering"
• In reply to: GuidoZ: "Re: Client End Firewalls"
• Next in thread: GuidoZ: "Re: Client End Firewalls"
• Reply: GuidoZ: "Re: Client End Firewalls"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Fri, 8 Oct 2004 02:08:05 +0200
To: security-basics@securityfocus.com

On 2004-10-01 GuidoZ wrote:
> > Maybe it would, maybe it wouldn't. It will never be able to do this
> > reliably, since Windows provides far too many ways to work around
> > it. Once the box gets compromised it's simply not yours anymore and
> > malware may very well fool or disable the client-side firewall (more
> > or less easy, depending on the firewall's configuration).
>
> A very good point. I guess I was going along the lines of "it's better
> then nothing". Even if a client side firewall was to block just one
> piece of malware from causing a problem, but get duped by the 2nd, it
> was worth it.

Depends on your point of view. People may consider it sufficient if the
program stops at least one attack, but I just can't accept unreliable
software as a security feature.

[...]
> The configuration is a big key. I won't discuss centralized management
> right now, however I have a point to make about individuals holding
> their own. Using a firewall with password protection is a must.

It raises the bar a little bit, but IMHO not enough. Password-protection
may be circumvented e.g. by sniffing the password or its hash from
Windows-messages. A client-side firewall should be a service and no user
should be able to tamper with it in any way. Configuration should be
done through a separate program (available only to administrative users)
and should be written to a file (the registry, whatever) from where the
service reads it.

> > I don't see much sense in client-side firewalling, especially in an
> > enterprise environment. You can't control outbound connections in a
> > reliable manner, and you don't need it to control inbound
> > connections.
>
> You shouldn't need to control inbound connections, no. However, once
> again, in most cases it doesn't hurt to have an extra layer of
> protection. Configuration is the key.

You're adding more code and more complexity to the system. This approach
has already been proved wrong by the Witty worm.

> > Shut down the services you don't need, set up an IDS/IPS, and you're
> > fine.
>
> Definitely something to do, though I would argue that you're fine just
> because you have locked down the box a bit. After all, email viruses/
> malware don't depend on forgotten services.

True. However, shutting down services does not aim at this issue at all.
Browsers and mail clients that can't be tricked into executing code as
easily as IE/OE do. Educating the users does. Spam filters and whitlists
for mail-attachments do. Even AV software does.

> However, even if your AV definitions aren't up to date, a properly
> configured client side firewall will stop the attack dead in it's
> tracks.

Maybe, but I consider it a lot easier to keep AV definitions up to date
than getting the client firewall properly configured. YMMV.

> > Client-side firewalling doesn't qualify as defense-in-depth, since
> > there are more reliable ways to achieve the same goal. IMHO.
>
> No, it certainly isn't defense-in-depth, but it's not pocket change
> either. =) Even Microsoft finally recognized the need for a client
> side firewall and included one in SP2. (Of course how much of a
> firewall it is should be topic for debate; but not now.) Please share
> what other reliable ways to achieve the same goal you know of.

Since blocking outbound traffic can't work reliably, I consider PFWs to
be more like a host-based IDS on this behalf. However, I think a real
NIDS (or IPS) will be much more reliable because the malware cannot
tamper with it.

[...]
> > If you really must have client-side firewalling (for whatever
> > reason), you want at least central configuration of the rules. You
> > definitely do *not* want your users to be able to allow or disallow
> > connections.
>
> This is certainly preferred, though not always possible. Frequently
> applications like this can be rather costly. Individual licenses for
> the different systems is usually cheaper, depending on the size of the
> organization.

The licenses may be cheaper, but are they still cheaper after adding the
additional costs for configuration and configuration-changes?

[...]
> While I was away on other business, a ethernet cable failed (was
> accidentally cut inside the wall by a falling pallet). All they knew
> was that they were offline. The one who knew the most about networking
> (who just barely knows enough to get into trouble) ran a new cable
> directly to their sDSL router from the 16 port switch. This allowed
> them to get back online of course, although it completely bypassed the
> firewall and VPN I have setup. Luckily they all had Sygate
> Professional firewall installed and running. (I also had the log files
> turned on for my own benefit, allowing me to see what applications
> were trying to get out and what was blocked.) I had setup the
> configurations individually (and passworded them) so that they would
> be correct AND be tamper resistant.
>
> During the 3 days that they were wide open to the world (besides the
> protection Sygate provided), I logged a combined 26 intrusion attempts
> to the Windows boxes (not including the script-kiddie port scans,
> usual ICMP requests, etc). The UNIX system with the dumb terminals
> wasn't connected to the same network, so it was safe. Had the
> client-side firewalls not been in place, I would of had a royal mess
> on my hands when I returned.

Why do you think so? Having the unnecessary services shut down should
have worked as well, since the PFW cannot protect services that need to
be available on the local network.

However, they should *never* deal with stuff like this on their own (for
obvious reasons) and there should be a policy in place telling them so.
If the online-connection is that crucial for them, they should have
redundant connections or at least someone who is able to do basic
operations/troubleshooting while you are away.

[...]
> In another case (unrelated to the above example, but makes a good
> point), Sygate has blocked numerous spyware from releasing possible
> sensitive information from one user in particular who has a fetish
> with screensavers. Someone else had disabled their automated AV
> scanning "because it was slowing down copying files" and let Dumaru
> (mass-mailing worm with a trojan dropper) get through. Sygate was able
> to block network access to the trojan, possibly saving sensitive
> information from getting out.

Users definitely should not be able to install software to %SystemRoot%
or disable the virus scanner. Issues like these are prevented by not
granting escalated privileges to normal users. Policies help addressing
social issues with that.

Regards
Ansgar Wiechers

-- 
"Those who would give up liberty for a little temporary safety
deserve neither liberty nor safety, and will lose both."
--Benjamin Franklin

• Previous message: GUs: "Fw: MAC level authentication or filtering"
• In reply to: GuidoZ: "Re: Client End Firewalls"
• Next in thread: GuidoZ: "Re: Client End Firewalls"
• Reply: GuidoZ: "Re: Client End Firewalls"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]