[Snort-devel] Re: Call for Bugs - syslogging

Rich Adamson radamson at ...442...
Sun Jul 8 15:55:40 EDT 2001


Marty,

> > The option to specify a syslog "Facility" and "Priority" in the rules does
> > not work with remote syslogging:
> >   "output alert_syslog: LOG_AUTH LOG_ALERT"
> > 
> > If I use "-s 1.2.3.4" on startup, changing the above statement to anything
> > reasonable prior to the startup has no impact. (This has been traced and
> > analyzed with a Sniffer, observing the syslog packets on the wire.)
> 
> Snort doesn't support specifying a remote syslog server on the command
> line, if you want to do that you need to modify your syslog.conf file
> and restart syslogd.

The Win32 version says: "-s <server:port>", which has been working fine
with the exception of those items noted. Two issues with using the syslog.conf
suggestion: 1) Windows does not have such a thing, and, 2) using that approach
on a Unix box to "forward" messages is less than acceptable because it does not
forward all data that was originally received from the initiating device.

I don't want to get into the Windows vs Unix discussion, but running snort on
a Windows laptop allows us substantially greater mobility, and when combined
with many other assessment and analysis tools, has significant value.

<snip>

> Are you using Snort-win32?

Yes.
 
> You can do that using the "ruletype" capability in Snort:
> 
> ruletype redalert
> {
>     type alert
>     output alert_syslog: LOG_AUTH LOG_ALERT
>     output log_tcpdump: suspicious.log
> }

Okay, I guess I didn't realize the Win32 version of snort is the only
version that "included" code to send syslog messages across the wire.
I assumed the code was present in all versions (unix and Win32).

> It sounds to me like you're specifying "output alert_syslog: <Args>" in
> the rules file and then setting the -s switch at the command line, which
> overrides the settings that you give Snort in the snort.conf file.  When
> you set an output facility in the snort.conf file and then set a command
> line switch to specify another output facility of the same type (log or
> alert), the command line overrides the setting in the conf file.

I have NOT specified the above within the rules file.

> This is really a review of ground that's already been covered a few
> times, this topic has come up repeatedly and the same problem is always
> at the heart of things (setting up syslog in the conf file and then
> overriding it at the command line) and the solution has always been the
> same (don't do that).  If you need to log to a remote syslog server, you
> need to adjust your /etc/syslog.conf file to reflect that setup, Snort
> doesn't do it for you.

Value Statement:
I've worked with clients in 40+ states over the past seven years, and within
the last 12-to-24 months we've seen a very significant number of corporate IT
departments choose to standardize on the NT/Win2000 (let's not get into why),
and remove all existing unix systems. (Part of their decision I know involves
staffing limitations and the lack of experienced unix personnel.)

So, take the syslog code that was written into the Win32 version and make it
part of "all" standard distributions. The value this has includes:
  1. ability to send near-realtime human notifications of unwanted events,
     allowing the human to roam the wireless office/world without being stuck 
     in front of a box with telnet, etc.
  2. generating syslog events on the wire does not force the user
     into installing many other products (and associated overhead) to 
     accomplish the near-realtime notification goal
  3. the existing code can still write messages to the local-disk syslog,
     and placing the exact same message on the wire (formated as a syslog
     packet) gives the user much grater flexibility in choosing the tools
     most appropriate for their environment / needs
  4. those IT groups that have standardized on NT/Win2000 systems can also
     make use of snort, etc. (larger audience)

Rich





More information about the Snort-devel mailing list