On 6/21/05, • • <googl3meister at gmail dot com> wrote:
> What I am saying is that we make allowances based on conditions,
> requirements and budget. I have installed snort into the m0n0 image
> myself and set it up syslogging to a central server. I have no fears
> of examing false positives because I have no services exposed and so
> the firewall drops the packet anyway. What I wanted was visibility
> for R&D and that is all. It works perfectly (thank you Manuel!). I
> have mitigating factors in place to guard against failures within
> snort - it's defence in depth. It takes time to tune it for it's
> intended purpose, for certain, but the gain in information far exceeds
> the blindlessness of not knowing what it is that ticks away at the
> firewall all day.
Then since you don't allow anything inbound, you're just doing it for
the sake of seeing what's out there because you're curious. That's
much different than relying on it for detecting intrusions. You're
just using it as a Internet Crud Detector. (how about a new acronym,
ICD!) :) You aren't going to detect any intrusions because you
aren't allowing any of that traffic in. A simple ICD is fine for the
sake of the curious, but if you actually want to detect intrusions,
it's of little value.
The sad thing is, for the regs that require or suggest the use of IDS,
having some next to worthless IDS system like this probably suffices
for a "check the box", yes we have IDS. But for that matter, I know
of places that have bought an IDS, slapped it in the rack and plugged
it in but never look at it, so they can "check the box".
My point is, an IDS like this isn't much of any good for detecting
intrusions, though it isn't completely worthless. If you're curious
and don't allow inbound traffic, it's great. If you just want
something logging things so if something happens you have a better
chance of going back and finding out why, then this is also a good
solution. If you want to truly detect intrusions, forget about it.
> With regards to traffic spoofing, those same packets hit your
> firewall, so your firewall logs are equally useless following that
> argument. I've yet to see a recommendation to turn off firewall
> logging, however.
Might as well! (getting me on a soap box again!) ;) Except on pass
rules. By definition, the dropped traffic can't hurt you, yet that's
all most people log. Logging your default LAN -> any rule is probably
overkill in most environments because of the performance hit and the
huge log volume it'd create, but I log all incoming permit rules.
Granted I log denied incoming traffic as well, because it can be
useful under some circumstances, and I don't advocate turning it off.
But it's much more important to log things that most people don't -
what gets through.
Besides, firewall logging is much different from IDS. Firewall logs
are always 100% accurate and complete (assuming your software works).
They don't claim to be something they're not. They don't tell you
much, but for their given purpose they don't leave anything critical
out of the overall picture. They're just a small piece of an overall