Re: Client End Firewalls

[GuidoZ <uberguidoz () gmail com>]

Awesome points Ansgar. I'll attempt to reply to them as best I can -
it's late and I just got home from a very long day. =)

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

Exactly - it really is about the POV. Depending on the situation, even
stopping one attack can be helpful. Of course it isn't preferred, and
often not the case, but that wasn't the point I was trying to make.
Sometimes spending a little extra time is worth the effort.

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

No, it's not enough by any means. However, like a padlock, it's a
deterrent. Sure, you could just go use bolt cutters to remove a Master
padlock, but most don't just carry them around with them. If you come
prepared (with bolt cutters), then you obviously have the intention of
getting in. You've done your homework and know how, so a small
deterrent isn't going to mean much. Same goes for small deterrents in
computer security. They aren't designed to stop everyone, just the
casual "passer-by" that thought it might be fun to peek inside (or
play with settings).

While I certainly agree with your points about admin rights/access
only, that's more difficult to do on Win98 boxes. =) (They have a
handful of them plus some XP Pro and Home.)

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

Thsi I agree with to a point, however I disagree with the idea you
raised. Yes, it certainly would add more code and complexity to the
system - but since when does adding ANY layer of security not do that?
=) Security and ease of use have never gone hand in hand and I doubt
they ever will.

The Witty worm is a poor example in this case, IMHO. It was a very
advanced worm and designed to attack a specific vulnerability on a
specific product. (Again I point to my "padlock and the prepared
attacker" scenario.) If someone is out to get past minor deterrents,
OR, is after attacking a specific, known vulnerability, then beyond
stopping that exact exploit you're going to be out of luck. It doesn't
apply in this case.

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

Very true and good points. However, user education and prevention can
only go so far. In fact, this is the same organization I'm discussing
in a different topic that is limited to IE because of some proprietary
ActiveX scripting they use for daily function. I'm slowly converting
them to Java so they can do away with IE entirely. They don't use OE
or Outlook - I have them on Thunderbird for now.

Plus, it doesn't matter if the email client can't be tricked when the
users don't listen to advise to NOT open attachments. I've also had
the issue of people disabling their antivirus ( as I stated) which
kinda defeats the purpose of it, obviously. Again, it's difficult to
control such things on a Windows 98 box. Upgrading is something they
are doing slowly, but refuse to do all at once. The cost to them can't
be justified, even though I've attempted to explain the same points
you've brought up. (Admin rights, access control, etc.) I can only do
what I'm paid to do sometimes. =)

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

Aye, me too. Again, it's just another layer that I prefer to add. As
you said ealier, it depends on the POV and situation. Just because AV
defs are up to date, if they disable their AV, what good does it do
you? I like having the added layer.

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

Totally agree. However, try explaining to a small business that has
enough problems purchasing a few Windows XP licenses that they should
go shell out a few grand for a nice firewall. ;)

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

To them, yes. In the long run, most likely not. Unfortunately some
people don't look to see what the traffic is doing ahead so they can
prepare - they just watch the brake lights in front of them and adjust
accordingly.

> *(In regards to Sygate access blocks and such...)*
> 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.

Once again, If I can't completely control the environment (Win98),
then I prefer to have a layer of protection between the environment
and the outside world that I CAN control. Just because I turned off
one service doesn't mean that they didn't install a "nifty program"
that turned it back on, or worse yet, installed it's own.

Plus, by using driver level protection, you can (to a point) control
services needed for the local network. Plus, with IP filtering and
advanced rules, you can COMPLETELY control services and necessary
ports from system to system. I can enable one-way file sharing and
computer browsing, for example, by using the advanced rules in Sygate.

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

Having a polocy in place and having them follow it are two very
different things. =) You'd think you have never worked with people
before. =P I'm only a consultant, not their IT staff. They pay me to
advise and fix, when they decide they NEED to do so. I have no power
over what they do with their own systems, beyond what they ask me to
attempt to do.

Redundant connections would be nice, but with a 3 figure budget, it's
difficult. That includes all hardware AND software. What I find
slightly funny is the fact they've paid me 10 times the budget they
provide; just to fix stuff that they could of avoided if they would
let me do things right. Guess I shouldn't complain though - puts food
on my table.

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

No, they shouldn't. Unfortunately it took Microsoft awhile to figure
that out too. Again, having policies in place and having them followed
are two very different things. They aren't a very advanced group,
although they like to think so. Maybe I should print out your reply
(and mine) and show it to them. =D Think it might knock some sense
into them? Doubtful, but worth a try...

Thanks for your comments.

--
Peace. ~G

On Fri, 8 Oct 2004 02:08:05 +0200, Ansgar -59cobalt- Wiechers
<bugtraq () planetcobalt net> wrote:
> 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