[Snort-devel] Syslogd (Was: Re: Call for Bugs)
radamson at ...442...
Sun Jul 8 17:06:40 EDT 2001
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
> 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
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.
More information about the Snort-devel