[Snort-devel] Call for Bugs

Martin Roesch roesch at ...402...
Sun Jul 8 00:31:12 EDT 2001

Hi Rich,

> 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" 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 only way that I've found to accomplish this is to change source
> in log.c at multiple locations and re-compile. For example...
>     {
>      /* ICMP packets don't get port info... */
>      /*    syslog(LOG_AUTHPRIV | LOG_ALERT, "%s: %s -> %s", msg,  */
>            syslog(LOG_LOCAL3 | LOG_WARNING, "%s: %s -> %s", msg,
>                 sip, dip);
>     }

I just tested it on FreeBSD and Solaris, it seems to be working fine

> Also, the "LOG_AUTHPRIV" value is defined with a non-standard value (10)
> which causes some syslog daemons to choke. ("LOG_FTP" is also non-standard
> as 11, and "LOG_CRON" value should be 15 not 9. All are defined in syslog.h)
> Historically, valid Facility values are 0-8 and 15-23, while valid Priority
> values are 0-7.

Snort draws its values from the local /usr/include/syslog.h file, so any
oddball definitions you might see are probably local to the host that's
generating the alerts.

> I've been using a very nice Windows-based syslog app that has some nice
> context-sensitive, threshold, paging-notification features for immediate
> personalized alerts. Trying to manage syslog messages from multiple devices
> without the ability to specify Facility and Priority values from each
> device is difficult at best.

Are you using Snort-win32?

> It would be very nice if some Rule-specific value mapped to a syslog Priority
> value, so the security admin person could specify different notification
> processes depending upon the seriousness of the intrusion. But, that's
> probably asking too much for now.

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

ruletype suspicious
     type alert
     output alert_syslog: LOG_NOTICE LOG_SECURITY

redalert $EXTERNAL_NET any -> $HOME_NET 143 \
	(flags: A+; content: "|FFFF C0E8|/bin/sh"; \
	msg: "IMAP buffer overflow";)

suspicious !$HOME_NET any -> $HOME_NET 6667 \
	(msg:"Internal IRC Server";)

Check out the section on ruletypes in snort.conf for more info.

> If I were a stronger c programmer, I'd offer up the corrections. However,
> I can barely read/understand the language therefore I don't think you'd
> want me to try that. It appears to me (although I might be wrong) the log.c
> and syslog.c source makes no attempt to use/read the values defined in the
> "output alert_syslog:" statement at all. That also seems to be the same
> opinions expressed by several postings by others over the last few months.

I just tested it and it's working exactly the way it's supposed to.

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.

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.


Martin Roesch
roesch at ...402...
http://www.sourcefire.com - http://www.snort.org

More information about the Snort-devel mailing list