Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Client End Firewalls |
|---|---|
| Date: | Fri, 1 Oct 2004 01:12:11 +0200 |
On 2004-09-29 GuidoZ wrote:
Personally, I believe a client side solution is a MUST. That includes a personal firewall and an antivirus suite of some kind. There are ways past perimeter security, without a doubt. I was just discussing this very thing with someone concerning the GDI/JPEG exploit. There are ways around content filtering and such. You should have an all-encompassing solution.
I agree on the AV part, but have to disagree on the client-side firewall part.
After all, say something gets through your perimeter AV solution and firewall (maybe through an SSL session, for example). If a trojan executes or is downloaded to the client system, wouldn't you want an AV solution (centrally managed for ease of use and updates) to be there to double check it? Giving the same scenario, wouldn't you want a personal firewall to be there to stop any connect back attempts? The GDI/JPEG exploit is a perfect example. It's possible you COULD of been exploited before your AV knew a thing about it. A client side firewall would stop the outgoing connection request.
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). 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. Shut down the services you don't need, set up an IDS/IPS, and you're fine. Client-side firewalling doesn't qualify as defense-in-depth, since there are more reliable ways to achieve the same goal. IMHO.
All this completely depends, of course, on client side education. =) If they just allow all to pass through the firewall because they don't know any better, then you shouldn't waste your time in allowing 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. 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
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Windows 98 box is 'owned', Paul Kurczaba |
|---|---|
| Next by Date: | Re: learning ethical hacking [my eBook collection], GuidoZ |
| Previous by Thread: | Re: Moderator Policy on crossposts to Security-Basics, GuidoZ |
| Next by Thread: | Re: Client End Firewalls, GuidoZ |
| Indexes: | [Date] [Thread] [Top] [All Lists] |