Security Basics mailing list archives
Re: Client End Firewalls
From: Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>
Date: Fri, 8 Oct 2004 02:08:05 +0200
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
Current thread:
- RE: Client End Firewalls David Gillett (Sep 30)
- <Possible follow-ups>
- Re: Client End Firewalls Ansgar -59cobalt- Wiechers (Oct 01)
- Re: Client End Firewalls GuidoZ (Oct 04)
- Re: Client End Firewalls Ansgar -59cobalt- Wiechers (Oct 08)
- Re: Client End Firewalls GuidoZ (Oct 12)
- Re: Client End Firewalls Ansgar -59cobalt- Wiechers (Oct 18)
- Re: Client End Firewalls GuidoZ (Oct 19)
- Re: Client End Firewalls Ansgar -59cobalt- Wiechers (Oct 20)
- Re: Client End Firewalls GuidoZ (Oct 28)
- RE: Client End Firewalls Jef Feltman (Oct 30)
- Re: Client End Firewalls GuidoZ (Oct 04)
- Re: Client End Firewalls GuidoZ (Oct 05)
- Re: Client End Firewalls xyberpix (Oct 07)
- Re: Client End Firewalls Ken S (Oct 07)