[Snort-devel] Syslogd (Was: Re: Call for Bugs)

Rich Adamson radamson at ...442...
Sun Jul 8 17:06:40 EDT 2001


Jason,

As noted in my reply to Marty, I didn't realize the unix versions of snort
didn't include the function to "generate syslog messages on the wire".

> I know various firewall appliances have built-in remote syslog options.
> This is because they're not full Unix systems with their own syslogd
> running.  The same can probably be said of most NT programs.  In Unix,
> syslogd is an expected, integrated part of Unix; daemons therefore use the
> local one.

For those of us that have to support a lot of different assets, practically 
"all" network devices (eg, routers, switches, hubs, firewalls, dsl modems,
local directors, distributed directors, access servers, gateways, most
commercial ids's) include the capability of generating standard syslog 
messages and sending those messages across the wire to some syslog server. 
The issue is not whether these manufacturers have the talent or resources
to write a syslog daemon. (I'd hate to have to log into 500+ remote devices
to check the syslog files; in fact, I'd never do it). So why should we
"assume" that a company with 10 IDS's distributed in their enterprise be
contrained to "logging into 10 boxes" to view syslog contents, etc?

The real issue turns out to be MS Products vs Unix, again. If the customer
chooses to deploy 10 IDS's on Win32 plateform (because that's what their
corporate wennies told them they had to do), we are going to ignore their 
needs to generate syslog messages "because unix has a daemon". That
serves no purpose other than to force the company into buying commercial
ids products.
 
> As a bonus, the local syslog.h constants which snort compiles in should
> (I'm pretty sure) get translated between the local & remote syslogd's
> in the remote syslog protocol.
> 

That sort of depends. Any syslog messages arriving at a unix machine via
the wire "do not" get repeated using the @hostname approach; those messages 
are simply written to disk only (based on syslog.conf). Since all
disk-based messages exclude the Facility and Priority codes, you can't 
do anything with those messages other than analyze the message-string
content.

The bottom line is adding the capability for snort to generate syslog 
messages independent of the underlying OS:
  1. increases the user's flexibility in "how" they manage their environment
  2. increases the number of companies that would use the product (since
     the Win32 environment does not include a syslogd)
  3. would allow users better mechanisms to manage syslog messages by
     giving them more control over Facility and Priority choices
  4. allow regionalized syslog server machines to "store & forward" messages
     not unlike a corporate org chart (eg, corp, div, region, city), giving
     each the ability to view/manage their resources.

For the most part, the coding is already done (within the Win32 version)
and only needs to be cleaned up, if-def'ed, and tested to maximize the 
benefits to everyone. I don't see a down-side to that.

Rich

cc: Marty





More information about the Snort-devel mailing list