Hi Erek,
Sorry to be unclear. By alerts, I meant the one-line messages typically
sent to snort_fast and the longer messages typically sent to snort_full and
analyzed by SnortSnarf.
Thanks for the suggested optimization; that is, logging in only a single
format. But, if I log only to binary, how do I get near-real-time alerts?
In any case, this particular box has CPU power to burn. So, generating logs
and alerts is a convenience that doesn't seem to be costing me anything.
Using strace sounded like fun. But, I ended up with a b'zillion line trace
file. To help find the needle, I decided to compare straces for 1.8.3 and
1.8.4. But I realized that 1.8.4 was compiled for debugging, but 1.8.3 was
not. So, I recompiled 1.8.4 without debugging. Then, I ran strace on each
version.
Before I analyzed the trace, I discovered that 1.8.4 was properly logging
alerts. My guess is that the problem is related to the way I worked about
the compilation problem about which I earlier posted. Most recently, I
tweaked config.h rather than /usr/include/sys/types.h. Another possibility
is that the failure to create alerts only occurs in debug mode.
I'm kinda tired and way behind on the day's other tasks. So, I'm gonna
leave well enough alone, unless someone pipes up with further data or
problems. In that case, I'm willing to use my setup as a test bench.
Thanks and Cheers,
--On Monday, March 25, 2002 1:17 PM -0800 Erek Adams
<erek at ...577...> wrote:
> Well... That's a bit of overkill. If you are going to log in binary,
> there's no need to burn CPU logging any other way.
>> I'd remove everything but log_tcpdump, then strace the binary and see what
> it's trying to open. It might be something as simple as permissions or a
> umask issue from one version to another.
---------------------------------------------------
Bill McCarty, Ph.D.
Associate Professor of Web & Information Technology
School of Business and Management
Azusa Pacific University