Re: [fw-wiz] Log checking?

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

  • Next message: Luke Butcher: "RE: [fw-wiz] Log checking?"
    To: Mark Tinberg <>
    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

    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.

    [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 which may have no basis whatsoever in fact." Director of Risk Assessment TruSecure Corporation
    firewall-wizards mailing list

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