Brian Hatch wrote: > I'm curious about how many folks do their log analysis against full > pattern matches. For example, I have the following swatch rules to > eliminate some standard ignorable events in syslogd output: [snip] > I can already see from the emails to this list that folks are often > using partial strings for their pattern matches. This worries me > because there are many cases where user controlled input is part of > the logging information, which an attacker could use to insert > 'ignorable' strings into otherwise dangerous log entries. [snip] > I haven't seen any nasty performance degradation due to explicitly > matching full strings - or at least anchoring at the beginning and > matching from there - but am wondering how many other folks follow > this practice. It really depends. For "ignore"-style filtering, where you get rid of everything you know you don't care about, it's generally "safer" to use more granular patterns, which generally means matching full strings; that way, as you note, you avoid accidentally ignoring things that might be of great importance. Similarly, for "alert"-style filtering, where you match everything you do care about, it's generally "safer" to use less granular patterns, which generally means partial strings, on the theory that it won't hurt as much to alert on a few extra matches. All of those "generally"s, of course, are the key. If you have a really wide variety of similar messages to ignore, writing a slew of extremely granluar patterns to match each one is a PITA. If you are using the "alert" model, and your patterns are _too_ vague, you'll be inundated with false alarms, which defeats the purpose of using a filtering system in the first place. As far as performance goes, a well-written fully-anchored pattern will almost always perform better than a partial pattern. When I was at Counterpane, I sent some folks an email describing this; Tina, do you still have that anywhere, and do you think it would be OK to forward it to the list? -- Sweth. -- Sweth Chandramouli ; <svcat_private> Ideopathic Systems Consulting
This archive was generated by hypermail 2b30 : Fri Aug 17 2001 - 22:09:28 PDT