Greetings Harlan,
I apologize for not getting back to you sooner. Left early and went
camping in Sedona, had to get away for a bit ;)
When I made the comment in regards to checking for potential
punch-through incidents in the ip filters and firewalls between the host
in question and the world, I'm referring to not just the host itself,
but any network device in the path that may have information on the
incident; some of it direct such as an IDS spotting an atypical
packet(s), some of it indirect such as a UNIX kernel or application
message buried in a *.debug logfile. Someone mentioned netflow, that is
an outstanding suggestion as well that i hadn't even considered as i've
not needed to yet, but have added that to my own docs as well. Anything
in the flow or even each and every broadcast domain along any path such
a frame could have possibly traversed (let your mind free, if it's
connected L1, it's worth checking). Essentially, and I apologize for
being vague; but my suggestion is that to play investigator for such an
incident would be to search not just for network anomalies though that
is a focal point, but to comb EVERYTHING with potential interrelation
from L1-L7, on every single device with an extremely liberal timeframe
within which to check. There would almost always be records suggesting
enumeration of the network from the outside prior to such a compromise.
Personally, I like to configure a dumb host with the TX leads snipped
and statically arped via the other machines and a meticulously
maintained /etc/hosts file, that just sits there with a huge disk and
snarfs the absolute highest granularity of [udp] logging facility
possible from every single net-related device in the DMZ' and the first
1-2 tiers beyond. In my experience, all the fancy high-dollar reporting
in the world can't replace a per-pop single logfile upon which you can
run regex after regex, or even just stare at each and every entry from
the timeframe in question, until you find that one entry that gives you
the clue or lead that you need. On hosts that perform edge routing or
edge services, I turn up the debugging levels as much as possible
without hurting performance, then direct all of that to the dumb syslog
box for later perusal. Even raw netflow can go there, everything you can
think of.........
So yeah, my suggestion is basically check everything with potential
clues, L1-L7, bar none with a generous timeframe until it does or
doesn't flesh out something worth checking. Examples are going to be an
NDA issue but let me have a route through my prior engagements and see
what I can come up with (will send off-list..)
Best Regards,
Jayson
-
On Sat, 2005-08-27 at 02:19 -0700, Harlan Carvey wrote:
Jeff,
Thanks for the response. However, it doesn't address
the comment that Jayson made, re: post-mortem
analysis. I'd still really like to know where to
look, and what to look for...
Thanks.
--- Jeff Bryner <jbryner1@yahoo.com> wrote:
<harlan & jayson on where to look for post-mortem
packet traces>
Lacking full network packet logs, one thing I did
during this one was
look at flow data from our network infrastructure.
<disclaimer>my flowdata knowledge is
limited</disclaimer>
This can be misleading, however because internal
flow data will capture
the outgoing attack packets that may get blocked
later by a firewall.
There also doesn't seem to be a one to one
correspondence between the
flow and what the firewall blocked outgoing. (i.e.,
the firewall
records more blocks than the flow data shows ).
Does someone with more flow-data/flow-tools
experience know why this
may be so?
Jeff.
P.S. Flow-tools example queries:
http://www.splintered.net/sw/flow-tools/docs/flow-tools-examples.html
------------------------------------------
Harlan Carvey, CISSP
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com
------------------------------------------
