[c-nsp] Logging your Firewalls

[Dobbins, Roland]

On Apr 9, 2011, at 5:17 PM, Peter Rathlev wrote:

> With 6 years of experience using the FWSM for what we use it for currently I beg to differ.

With many years of experience with the FWSM, starting when it was first under development and not yet released as a product, then deploying it and operating it on a very large production enterprise network, I beg to differ, too.

;>

> To be clear here: Are you saying only debugging level is wrong?

Yes.

> Keep in mind that debug level messages (level 7) won't appear unless you enable debugging.

It never occurred to me that one might enable debug-level logging without actually enabling debugging, so my obviously incorrect assumption was that both were enabled.

;>

> When you do enable debugging, what do you think the FWSM spends most CPU cycles doing: Sending the log message via UDP to a syslog server, or sending the log message through an SSH session to my terminal?

The latter.

>  Most of the logging comes in at informational level, describing builds/teardowns.

Concur, informational level makes sense for firewall operators.  Debugging level with debugging doesn't, that's what I was trying to say, as I have never run across an instance of enabling debugging-level logging without debugging itself enabled, and incorrectly assumed that both were enabled.

> These are critical if you perform any kind of NAT, as most enterprises (cf. OP) do.

I don't know that most enterprises perform NAT, FWIW.

> They're also very relevant when tracing activity even without NAT. You can compare them to Netflow data, except they're more precise and more
> inefficient.

I find them to be much less useful that NetFlow, myself, as they're contextless, without any direct bearing to what the actual packets are doing on the wire.  They're useful for understanding policy decisions on packets, sure, as well as for keeping track of NAT/PAT pairs; that doesn't mean these logs are 'more precise' than NetFlow, but are a different type of information altogether, focused on policy rather than behavior on the wire.  I call this 'policy-plane' information.

> If you're only talking about debugging level, I'd disagree even more.  Saving debugging output is a good thing.

I don't, due to the additional overhead generated by debugging-level log output.

> Most problems aren't resolved in a matter of minutes,

Right - so, enabled debugging when necessary to help troubleshoot a problem, then disable it, afterwards.  This seems to be what you're doing, anyways, and makes perfect sense.

> and having historical data to analyze is priceless.

For the policy and NAT stuff, sure.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde