MonitorWare Knowledge Base

Is it possible to have more than seven facilities?

Or, perhaps a different way to attack this goal:

We have lots of snort sensors scattered around a geographically diverse area.
We need all output sent encrypted via syslog from each sensor to a group of central snort servers that then subsequently send syslog data to an intrusion detection aggregator.

We are currently identifying which device the data reports to via the facility. (Each box uses a specific facility)

It would be nice to have more than seven facilties, like say, a hundred would be great!


Bruce D. Meyer

Hi Bruce,

the facilities are unfortunately limited by the syslog RFCs. We tried to bump that number with the upcoming new syslog RFC, but unfortunately that was not accepted. So we are stuck with the 8 (local*0* to 7) custom facilities.

If you run rsyslog on each box, you could simply identify the boxes by their HOSTNAME - provided that it is set to a unique value on each host. Does that help? Or am I overlooking something?

Rainer

After I posted, we discussed things over here.
I read a reply of yours to someone else about the limitations being from the protocol.
I would **** to read the reasons for the rejection in the RFC. We figured out that we can just split off the logs via your filtering and templating.
I had considered syslog-ng and rsyslog. as a replacement for syslogd.
Please correct me if I overlooked something, but it seems tha rsyslog is a bit ahead of syslog-ng's abilities right now, so I am converting several boxes over to it, to see how things go. (v2.0)

--Bruce D. Meyer

bdmeyer wrote:After I posted, we discussed things over here.
I read a reply of yours to someone else about the limitations being from the protocol.
I would **** to read the reasons for the rejection in the RFC.

That's a very long story, but it boils down to backwards compatibility... I still think it was a nonsense argument (btw: the draft supported up to 2gig facilities). If you really want to dig into it, here is a good starting point:

http://www.mail-archive.com/syslog@list ... 00128.html

But to see the spirits, it proabably is useful to read posts starting November, 8th 2005 from Sam Hartmann ("Returning your documents"). Read this and roughly the next two month ... or a bit of it

http://www.mail-archive.com/syslog@list ... mail7.html

bdmeyer wrote:We figured out that we can just split off the logs via your filtering and templating.

excellent!

bdmeyer wrote:I had considered syslog-ng and rsyslog. as a replacement for syslogd.
Please correct me if I overlooked something, but it seems tha rsyslog is a bit ahead of syslog-ng's abilities right now, so I am converting several boxes over to it, to see how things go. (v2.0)

Well... quite honestly I am not sure. With v2, there are some things that rsyslog can do better (or syslog-ng can not do at all) and there are some things where it is vice versa. I tend to say that the later is still in the majority.

But, believe it or not, I never looked deeply at syslog-ng, I even don't know more than a few config statements. That may sound silly, but I wanted to start rsyslog without a bias and primarily used my own experience and user feedback as the driving force.

With rsyslog becoming more popular, I started to look at some syslog-ng features (not easy to find a feature sheet). The most exciting of them are not available in the open source edition.

Having said that, I personally think the future is more important. Rsyslog has just begun to materialize. I have much more on my agenda that is available today. I am working on v3 right now and *that* will be a very exciting release. I think a first release will be available some time next week. I've already implemented input plugins, different queueing modes and massive multithreading (user-configurable). But again, that is primarily stage work. We will see, hopefully in late January, a very powerful store-and-forward capability. Then, expressions are on the agenda (if nothing more important slips in between, as in the last time). And a lot of other things to come. With v3, I think, rsyslog will really take off and offer a myriad of features not seen in syslog-ng (not even in the paid edition). Maybe today's cryptic notes on my blog provide some idea:

http://rgerhards.blogspot.com/2008/01/r ... ading.html

You may also want to read a bit on the periodically posted work logs, they tell quite a lot of what we are heading two and how fast progress is made.

Of course, the direction depends on user feedback, but I'd say we are on an extremely good road

Rainer