Re: [fw-wiz] Log checking?
From: Paul D. Robertson (paul_at_compuwar.net)
To: Mark Tinberg <firstname.lastname@example.org> 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
I'll also argue that the system got its Trojan through an allowed vector
in the first place.
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.
 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
email@example.com which may have no basis whatsoever in fact."
firstname.lastname@example.org Director of Risk Assessment TruSecure Corporation
firewall-wizards mailing list