Re: Client End Firewalls

From: GuidoZ (uberguidoz_at_gmail.com)
Date: 10/09/04

  • Next message: tito.basa: "centrally monitored "keylogger""
    Date: Fri, 8 Oct 2004 23:23:56 -0700
    To: security-basics@securityfocus.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
    >
    

  • Next message: tito.basa: "centrally monitored "keylogger""

    Relevant Pages

    • Re: Client End Firewalls
      ... depending on the firewall's configuration). ... Even if a client side firewall was to block just one ... Using a firewall with password protection is a must. ... >> connections. ...
      (Security-Basics)
    • Re: Remote Admin Tools source code for Delphi 4,5,6 & 7
      ... this way I guess the traffic is outbound form the client to ... be remoted and opens up a channel on the firewall. ... the actual client you are going to remotely control. ... all using the same configuration and one Port on your machine. ...
      (borland.public.delphi.thirdpartytools.general)
    • Re: Client End Firewalls
      ... since Windows provides far too many ways to work around it. ... Even if a client side firewall was to block just one ... The configuration is a big key. ...
      (Security-Basics)
    • RE: [fw-wiz] Cisco VPN Client "Stateful Firewall (Always On)"
      ... of attack before and after the VPN client is used. ... Need some opinions on a firewall solution for our notebook computers. ... configuration. ... or not the "Stateful Firewall " feature of the Cisco VPN ...
      (Firewall-Wizards)
    • Re: GET ... /wspad.dat
      ... I know how to edit the configuration file from ISA manager ... or how the client setting file is supposed ... Configuration for the Firewall client setting ...
      (microsoft.public.isaserver)