Balazs Scheidler wrote: > > #1 can be used tranparently by the OS > > This is true. But we are addressing the issues of the plain syslog protocol. > I don't think it would be a great step forward if we just said: "So you > need a secure syslog? Use IPSec, and you are done." :) Yes, but it is a working solution right now, on UDP. I am more concerned on UDP's packet loss. This can be done by an intruder on-the-fly. see this as example: http://www.monkey.org/~dugsong/dsniff/ this proggies mess with arp, and can be easily modified to filter whatever UDP packet without notice on present protocol. An there are collisions or other normal packet loss around too, as we all know. A lot of syslog configurations across firewalls are implemented in such a way that packets flow in just one way. Using a TCP transport will imply packet flows in two ways and might be resisted by some. Adding message protection and sequence, packet loss and tampering can be noticed. Plus we can keep using UDP and one-way connection. This is equivalent to localhost hash protection already implemented on secure-syslog long ago) and msyslog (and stated in syslog-ng as work in progress). > > #2 SSL needs carefull coding > > What do you mean on this? Implementing a security > related protocol needs > careful coding anyhow, and it applies more to #3 > than to #2 IMHO. By relaying on the underlying transport protocol for several key security concepts in the syslog protocol, those concepts (integrity, authenticity, anti-replay, realiable delivery) start to transfer trust to the security of the underlying transport. Is that what we want for ALL the concepts of a secure syslog. I tried to mean that there are poor SSL implementations. > > #3 reinventing the wheel once again > > That's true. I'm convinced to use SSL. The question > is: what's going inside the SSL tunnel. IMHO it'd be nice to START on a protected UDP protocol, since it'd be hard for every network appliance to use SSL or IPSec. But a simple UDP based with hash protection looks way easier. And it doesn't break the current one-way setup. Implementing it on msyslog right now as test... field size ------------ ------ Version 1 Action 1 start/mesage/keepalive/end Hash_method 2 algorithm and how Flags 2 ascii/unicode crlf/lf etc Stream 2 multiple flows Size 4 Sequence 4 Hash 20 ---------------------- 36 bytes > What do you mean on "streams" ? [snip] > sources -> log center -> destinations > In the log center, you can define virtual paths > which connect sources to "stream" == "vitual path" == "flow" s/stream/virtual path/g On TCP you can do multiple connections but on UDP you cant. Also a host forwarding messages mixes different kind of logs from different nature of originating hosts. It'd be nice to hear some feedback! Cheers, -- Alejo Sanchez - Developer [EMAIL PROTECTED] Core SDI S.A. http://www.core-sdi.com --- For a personal reply use [EMAIL PROTECTED]
