Re: Client End Firewalls

[GuidoZ <uberguidoz () gmail com>]

Interesting perspectives. =)

> With Windows 98 you're doomed since you have to rely on the users not
> making mistakes :(

Yeah, I've kinda had the same problem. There are ways to apply
policies and such (poledit), which is helpful though. I've used this
successfully to thwart some curious users. (A useful write-up can be
found here: http://www.zisman.ca/poledit/) Although, in the long run
it's still Windows 98. As my father always said, "You can't polish a
turd."

> Even XP Home is better than Windows 98 although it has drawbacks of its
> own, e.g. the missing security settings in the files' and folders'
> properties. Removing that tab was really a brilliant idea of Microsoft.
> Not. Which home user is going to use (x)cacls or subinacl? However,
> there are means to work around them to a point [1,2]. What's really
> annoying with XP Home is that you don't have policies and can't
> integrate it into a domain. I'm not aware of ways to work around that
> besides replacing it with XP Pro.

I'm not a big fan of XP Home for the very reasons you mentioned.
Although, it IS meant to be used on a stand-alone PC, at home, no it
shouldn't make a huge difference. The problem arises that quite a few
homes now have home networks, hooked up by the kid next door and left
completely open. I guess in this case, having XP Pro might not help
because your average end-user wouldn't have enough know-how to use the
tools available. The immortal catch-22.

> > 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?
>
> Removing the services you don't need does.

Point taken. Although, technically thats removing a layer of security.
=D (It's reaching, but hey... worth a shot.)

> Of course. But that was not my point. I was referring to the technical
> complexity of the system, not complexity regarding ease of use. The less
> code runs on the system, the less configuration needs to be done, the
> less configuration issues and (exploitable) bugs are to be expected.

I misunderstood. The complexity of the system certainly is a different
thing, which you explained quite well might I add.

> (skipping ahead a bit - all that was snipped needs no discussion)
>
> Services that don't run can't be exploited and thus don't need to be
> protected by a PFW. Services that need to be available can't be
> protected by a PFW.

While this is true, that only applies to the services that I expressly
defined as necessary, or shut down. Again I'll remind you that I still
have to depend on users in certain circumstances. I've been in there
removing Spyware on a weekly basis. Having the Firewall set to allow
access to ONLY what I have defined and password protected adds a layer
that, again, I prefer to keep in place.

I'll also comment on your second statement - you certainly CAN control
necessary services with a PFW. You can setup advanced rules and
filters to, for example (but not limited to), only allow access to a
machine from or to a certain IP#. That way Tom (who found the password
on a post-it note) can't be jumping into Jane's network share even
though it's open to Bill (who had the post-it note). I've used this
very scenario to secure network share access to only those that need
it, attemping to lesson the amount of access. (The names have been
changed to protect the innocent, however.)

> > > 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.
>
> They should not be able to disable the AV, otherwise you have to rely on
> their well-behaving which is simply not acceptable from a security point
> of view. Plus AV software and PFWs address different issues.

No, they shouldn't be able to, but unfortunately they can. Due to the
old DOS apps they run, they need access to a command prompt and DOS.
It's not uncommon for them to kill AV through a batch file, again,
"because it slows down file copying". (I continue to use that line
because that pissed me off quite a bit - it's also how Klez got in way
back when.) I'll agree that AV software and PFWs address different
issues - which is why I prefer to have both. ;)

> Well, you don't always have to have a Checkpoint or Cisco. A small
> packet-filtering router (or a Linux|*BSD box) may very well suffice and
> are a lot cheaper.

This is true. I've run Smoothwall a few times as a test and it's
worked quite well. There are still some minor kinks that I've yet to
solve through forums, lists, and Google. Maybe I'll run them by you
off-list. =)

> [1] http://www.luckie-online.de/programme/UserManager/index.shtml
> [2] http://www.fajo.de/portal/index.php?option=content&task=view&id=6

I've seen #2 before, though I haven't really given it a test run.
Thanks for the reminder. As for #1, is there an English version?

> Regards
> Ansgar Wiechers

My pleasure, as always.

--
Peace. ~G


On Sun, 17 Oct 2004 20:12:37 +0200, Ansgar -59cobalt- Wiechers
<bugtraq () planetcobalt net> wrote:
> On 2004-10-08 GuidoZ wrote:
> > 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.)
>
> With Windows 98 you're doomed since you have to rely on the users not
> making mistakes :(
>
> Even XP Home is better than Windows 98 although it has drawbacks of its
> own, e.g. the missing security settings in the files' and folders'
> properties. Removing that tab was really a brilliant idea of Microsoft.
> Not. Which home user is going to use (x)cacls or subinacl? However,
> there are means to work around them to a point [1,2]. What's really
> annoying with XP Home is that you don't have policies and can't
> integrate it into a domain. I'm not aware of ways to work around that
> besides replacing it with XP Pro.
>
> > > 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?
>
> Removing the services you don't need does.
>
> > =) Security and ease of use have never gone hand in hand and I doubt
> > they ever will.
>
> Of course. But that was not my point. I was referring to the technical
> complexity of the system, not complexity regarding ease of use. The less
> code runs on the system, the less configuration needs to be done, the
> less configuration issues and (exploitable) bugs are to be expected.
>
> > 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.
>
> It attacked a vulnerability that wouldn't even have existed, if the
> systems hadn't been "protected" by additional software. That's the very
> point of this.
>
> > (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.
>
> Services that don't run can't be exploited and thus don't need to be
> protected by a PFW. Services that need to be available can't be
> protected by a PFW.
>
> [...]
> > > 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.
>
> They should not be able to disable the AV, otherwise you have to rely on
> their well-behaving which is simply not acceptable from a security point
> of view. Plus AV software and PFWs address different issues.
>
> > > 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. ;)
>
> Well, you don't always have to have a Checkpoint or Cisco. A small
> packet-filtering router (or a Linux|*BSD box) may very well suffice and
> are a lot cheaper.
>
> > > 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.
>
> *sigh*
>
> True. Which is why they eventually crash.
>
> [1] http://www.luckie-online.de/programme/UserManager/index.shtml
> [2] http://www.fajo.de/portal/index.php?option=content&task=view&id=6
>
> 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