Scott Okay if that's the case We tried to deploy filtering and correlation capabilities on top of our 25+ unix hosts in our DMZ all doing syslog-ng, but our system managers are very in favour in uniform configs. Fine grained filtering never befitted them, because it tends to differ per host. Uniform course grained config of syslogd or syslog-ng which shifts debug-sev messages into local files while all other messages are forwarded (in potential to multiple) destinations was fine by them. Let the central loghost(s) worry about the potential huge trafficvolume. So: we didn't succeed in distributed filtering and tuning those filters. Undelying reasoning : the more hosts you have, the more the system-config need to be standardized (even the tcp-setting of syslog-ng is part of that). Hope this is useful :-) Ernst Mellink -----Original Message----- From: ScottO [mailto:skippylou@private] Sent: donderdag 25 mei 2006 13:55 To: Ernst Mellink Cc: loganalysis@private Subject: Re: [logs] hosts to central logging servers efficiency: syslog orsyslog-ng Hi Ernst, Thanks for the reply. I think you might have confused my question or mabye I didn't word it correctly. I have the ability to run syslog-ng on every device (no firewalls, or other devices, currently to get logs from as part of this current project). So it is more of a: is it better to install ng on all those hosts to have the tcp ability and filtering capabilities on each individual host, or leave syslog and send to edges via udp, then let the edges filter before sending it to the central (with edges & central running syslog-ng). Thanks, Scott Ernst Mellink wrote: > Hi Scott > > Here are my insights into this matter: > > 1) there quite some network and security devices which have a build-in > syslog feature and there is no way of actually moving those them over to > -ng. > The best yopu can do put preasure on the vendor to add -ng support. > So a simple solution would be to build a kind of a syslogd to syslog-ng > bridge node > This d-ng bridge can do whatever you want it to do: > >>serve multiple destinations either on -d or -ng >>filter-out certain severities (eg debug messages) >>rewrite the logformat (however unadvisable) >>add timestamps to it (if wanted / needed) > > etc > > 2) in widely scattered networks such a bridge can act like a > concentrator. There are lots of local connections to the concentrator > using either -d or -ng All possible firewall-problems can be solved > locally (nice) While the way up into the central server can be a > thightly screened and secured > (why not add ssl-tunneling or do syslog-tls) tcp connections which can be > described by the security enigineers and entered into the firewall/ips. > Ans yes this tcp-connection can be beefed up to dimensions like 100Mbps or > whatever is needed without ever losing a single message. > The suggested term could be area-concentrator > > Such a construction solves > A) protocol-translation (udp to tcp) > B) large firewall-rulessets > C) concentrates security > D) forgo replacing syslogd services if at ever possible > > My 2 cents > > Ir. Ernst J. Mellink > IT Security Architect > > _______________________________________________ LogAnalysis mailing list LogAnalysis@private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2.1.3 : Fri May 26 2006 - 13:11:11 PDT