Re: [fw-wiz] Log checking?

From: Paul D. Robertson (paul_at_compuwar.net)
Date: 09/30/04

  • Next message: Luke Butcher: "RE: [fw-wiz] Log checking?" 
    To: Mark Tinberg <mtinberg@securepipe.com>
Date: Thu, 30 Sep 2004 17:20:38 -0400 (EDT)

    On Thu, 30 Sep 2004, Mark Tinberg wrote:

    > > I've always felt that worrying about denied traffic was mostly for sport-
    > > if the firewall's policy blocked it, I wasn't all that worried about much
    > > more than overall trends- what got *through* the firewall seemed to be the
    > > more interesting set of things.
    >
    > I'd agree that this is true for traffic denied incoming from the big, bad
    > Internet but not true for traffic denied from within your organization.

    I'd still argue that what gets through the firewall is more interesting-
    Every insider attack I've investigated that involved external connectivity
    went through the firewall's allowed policy- even when the insider wasn't
    an admin. The largest insider abuse incident I've responded to was
    potentially the largest damage amount I've seen, perhaps more than all but
    one other I've seen put together.

    The largest external compromise I've seen came through a firewall's
    allowed policy (it was the worst policy I've seen ever, but it was the
    policy.)

    So, my direct experience leads me to conclude that the biggest problems
    I've seen have all been from the allowed vector- and the organizations
    which were hit were all looking only at the denied traffic. In every
    case, we checked firewall logs, and I don't recall that ever bringing any
    value for places that logged only blocked traffic.

    > You can learn all kinds of things from denied outbound logs, backdoored
    > machines trying to connect to their IRC controllers, machines with various
    > adware/spyware trying to phone home, machines with misconfigured software
    > that isn't going through your internal proxies (AV updates for example),
    > machines with misconfigured DNS or NTP settings, etc.

    Sure you can- but I'll argue that a Trojaned system that can't talk back
    to its wanna be controllers is *still* less interesting than one that can
    and does.

    I'll also argue that the system got its Trojan through an allowed vector
    in the first place.[1]

    It helps in the "show we're adding value" bucket, but not as much in the
    "threats our defenses aren't handling" one.

    I've always found that misconfigured systems generated helpdesk calls and
    got taken care of by desktop support- the occasional call so that folks
    know you're watching is, in my mind anyway- just part of the sport. It
    has some deterrent value, but that traffic isn't going anywhere but into
    the bit bucket anyway.

    If it's trying to phone home and can't, it's automatically less
    interesting to me than if it's trying to phone home and can.

    Now, sure- there's intelligence value from an escalation perspective in
    catching them early, but it's been my experience that the huge losses
    in the worst case sorts of things have never hit a denied log- because it
    was an insider gone bad who was using allowed things.

    In any case, I had a large enough user base that spending time tracking
    down misconfigured systems just wasn't productive. Taking the occasional
    luser down for sport was only slightly more productive, but looking at
    what was likely to get past my policy was the whole point of having a
    human with a clue in the mix. Granted, spyware and botnets weren't really
    issues back then- but I'd still fork that off to someone else today as
    long as the firewall was blocking it.

    Paul
    [1] I recognize that laptops aren't covered in the firewall's
    permitted logs- unless you consider the physical building security part of
    your firewall. The proliferation of those types of problems is probably
    the best argument for looking at denied traffic unless you extend the
    permitted argument to personal firewalls on those devices, and even then
    it'd be a good check and balance item. Mostly though, those systems would
    have to tunnel out for them to be a major risk- though there are scenarios
    where that doesn't happen on the corporate network.
    -----------------------------------------------------------------------------
    Paul D. Robertson "My statements in this message are personal opinions
    paul@compuwar.net which may have no basis whatsoever in fact."
    probertson@trusecure.com Director of Risk Assessment TruSecure Corporation
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

  • Next message: Luke Butcher: "RE: [fw-wiz] Log checking?"

    Relevant Pages

    • Re: [fw-wiz] httport 3snf
      ... > Having worked in the Firewall support role at several companies, ... I had my CIO approve my security policy. ... time educating him about Internet risk. ... There's also a very good "at what point is the firewall now useless" ...
      (Firewall-Wizards)
    • RE: Sandboxing
      ... the 3Com Embedded Firewall would be extremely useful and enabling (in ... your case) when you look at it in a VPN context. ... This security policy will accomplish quite a few things: ... During the Policy Server installation, ...
      (Focus-IDS)
    • Re: How can I edit a Group/Domain Policy to effect only one computer?
      ... First create a global group e.g "Machines with Firewalls Disabled" and then ... disables the Firewall and ensure that it is processed after the current GPO ... should now do is using GPMC change the scope of the policy and remove ... normally effect all machines they will not process the policy unless they ...
      (microsoft.public.windows.group_policy)
    • Re: [fw-wiz] Firewalling at the domain users level instead of network level
      ... > users" level instead of network or ip level. ... If the firewall has to ask ... other machines on the network about information (such as looking up IP ... The second concern is a matter of policy: why do you want your firewall ...
      (Firewall-Wizards)
    • Re: Questions About Windows Firewall and Domain Policy Enforcement
      ... Can you please provide me with more detail with what you mean by connecting ... configure the firewall, namely group policy, net shell scripts, manual ... You can do this through group policy or a login script. ... > as there is no Standard Profile configured. ...
      (microsoft.public.win2000.group_policy)