[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-opsec-logging-caps-03
On Jul 3, 2007, at 12:55 PM, Roland Dobbins wrote:
On Jul 3, 2007, at 11:39 PM, Warren Kumari wrote:
One possible concern with rate-limiting syslog / SNMP / whatever
is that people will then try and generate non-critical events that
cause alerts to be generated in the hope that they can then slip a
more nefarious event in and have it also be caught by the rate-
limiter.
Possible, but hard to accomplish without inside knowledge (which is
certainly a possibility, of course).
Yup -- very true, although I did see it happen once -- It was a
failed attempt to brute force TACACS. There were ACLs configured on a
device with the "logging" keyword that caused the device to log all
ACLs hits and a (not so bright) employee that had read-only access to
the syslog server -- he noticed that if he did "ping -f" (which he
could easily explain as a diagnostic process that had gone awry or
something) to a device behind the ACL the device would be so busy
logging ACL hits that it wouldn't log failed login attempts. What he
*didn't* check first (I did mention that he wasn't so bright) was
whether failed logins usually showed up in this syslog server.....
I had configured syslog-ng to only forward a very small subset of
logs to the server that he was looking at (the logs were for use by a
NOC tool that watched the logs for interface flaps, ACL hits and one
or two other similar issues)...
The TACACS server logged somewhere between 8,000 - 9,000 failed
logins before I reacted to the alerts that it was generating, but
looking through the aggregated syslog I only saw around 2,000
attempts, so I guess that his trick did work to some extent :-)
What would be great would be, if there were a rate-limiter it
would prioritize high severity messages over lower severity ones
(whee! QoS for logs!).
How about multiple rate-limiters for each individual log-type, as
well as for each severity/informational level?
That would be be work, although I am concerned that the overhead
might overtax the device's processor...
My main comment is that, for local logs, the oldest, least important
messages are dropped before old important messages....
W
----------------------------------------------------------------------
-
Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice
Culture eats strategy for breakfast.
-- Ford Motor Company
--
Curse the dark, or light a match. You decide, it's your dark.
-- Valdis Kletnieks