I've been trying the new zone editing stuff from work, using Mozilla from Linux. Very nifty, and I now have zones that conform to the geography much better than before.
One thing I've noticed is that the one editing seems to trip one of the Snort community rules:
I've been trying to figure it out. I suspect that particular rule isn't quite specific enough to catch only exploit attempts. The rule matches on packets if:
They are part of an established connection and coming to a server on an HTTP port.
They contain the character 0x3A. (One of these ":" )
They match the regular expression "/^.*\x3a[^\n]{1000}/sm"
I think that last expression means that the 0x3A is followed by at least 1000 non-newline characters.
Last edited by lazyleopard on Tue Jan 24, 2006 5:27 pm, edited 1 time in total.
That's a perl-type regular expression, so the trailing "sm" means match whether the rest of the packet is a single line or multiple lines. I guess exactly what happens depends on what snort considers an end-of-line within a packet.
It seems to be the zone shape editing. I think the reason that rule triggers is the length of the referrer information. Here's one line from the apace log that corresponds to one of those alerts:
Reading history file... webalizer.hist
Reading previous run data.. webalizer.current
2923 records (2923 ignored) in 0.20 seconds
Warning: Truncating oversized request field
Warning: Truncating oversized referrer field
Warning: Truncating oversized referrer field
Warning: Truncating oversized referrer field
...
)
)