Anyone know when syslog-ng will be supporting encryption and digital signatures for file integrity. Plus is there a way to only allow connections to the main syslog-ng server based on for example 10.2.*.* Also the doc's are just "a little" out of date and the syslog-ng.conf.demo is confussing since the syslog-ng.ps document states as of 1.3.4 encrypt() and compress() are nolonger supported. What about mac() and authentication() are they supported? Yazz Atlas -- Yazz D. Atlas <yazz@osdn.com> Systems and Network Engineer O | S | D | N, 50 Nagog Park, Acton, MA 01720 http://www.osdn.com/ Open Source Development Network
On Tue, 28 Nov 2000, Yazz D. Atlas wrote:
Anyone know when syslog-ng will be supporting encryption and digital signatures for file integrity.
Plus is there a way to only allow connections to the main syslog-ng server based on for example 10.2.*.*
For this, it seems most appropriate to use the system's network filtering tools to achieve access control. Do we really want every application to have to build it's own, differently broken version of access control? On linux, I suggest ipchains for 2.2 and iptables for 2.4. I must agree whole-heartedly that the documentation is useless for the latest syslog-ng. The only good reference seems to be the configuration grammat in the source code. -jwb
On Tue, Nov 28, 2000 at 03:52:41PM -0800, Jeffrey W. Baker wrote:
On Tue, 28 Nov 2000, Yazz D. Atlas wrote:
Plus is there a way to only allow connections to the main syslog-ng server based on for example 10.2.*.*
For this, it seems most appropriate to use the system's network filtering tools to achieve access control. Do we really want every application to have to build it's own, differently broken version of access control?
On linux, I suggest ipchains for 2.2 and iptables for 2.4.
Could it perhaps link to TCP Wrappers' libwrap instead? Personally, I'd prefer that to most other options I can think of for basic control like this.
William Yodlowsky on Tue, Nov 28, 2000 at 07:35:42PM -0500: Hi,
Could it perhaps link to TCP Wrappers' libwrap instead?
Personally, I'd prefer that to most other options I can think of for basic control like this.
I agree. I think having to maintain packet filter configurations for every system that serves a critical function is a bit much. Plus, the wrappers are supported on and the configuration is portable to many UNIX systems. Also, some commercial UNIX systems are not shipped with packet filtering capabilities. When I suggested this to Balazs, he correctly said that tcp PARANOID checking could easily DoS your nameserver when it is used to control access to your syslog/udp. Obviously, the same goes for rfc931 (ident), spawn and other nice hosts.* directives. You could also produce nice effects by logging access to the syslog port to a remote machine, which in turn for security reasons sends all network access information to you as a replication means :) I still think it would be really nice to have, especially because it's portable, well tested and I believe lots of people still use it for non-firewall machines. I do :) Greetings, Gregor. -- Gregor Binder <gbinder@sysfive.com> http://www.sysfive.com/~gbinder/ sysfive.com GmbH UNIX. Networking. Security. Applications. Gaertnerstrasse 125b, 20253 Hamburg, Germany TEL +49-40-63647482
On Wed, Nov 29, 2000 at 02:35:44AM +0100, Gregor Binder wrote:
William Yodlowsky on Tue, Nov 28, 2000 at 07:35:42PM -0500:
Could it perhaps link to TCP Wrappers' libwrap instead?
I agree. I think having to maintain packet filter configurations for every system that serves a critical function is a bit much. Plus, the wrappers are supported on and the configuration is portable to many UNIX systems. Also, some commercial UNIX systems are not shipped with packet filtering capabilities.
That's what I had in mind :-)
When I suggested this to Balazs, he correctly said that tcp PARANOID checking could easily DoS your nameserver when it is used to control access to your syslog/udp.
Ah, a good point. IMHO a warning during the configure phase and a blurb in INSTALL would be enough, though. I haven't been on this list very long, but I would hope people replacing their syslogd would at least read INSTALL :)
You could also produce nice effects by logging access to the syslog port to a remote machine, which in turn for security reasons sends all network access information to you as a replication means :)
I dare say I was thinking about that too...
I still think it would be really nice to have, especially because it's portable, well tested and I believe lots of people still use it for non-firewall machines. I do :)
I second the motion!
participants (4)
-
Gregor Binder
-
Jeffrey W. Baker
-
William Yodlowsky
-
Yazz D. Atlas