[syslog-ng]replacing part of prog name with hostname

Fri, 3 Jan 2003 05:03:03 -0500 (EST)

--EXCITEBOUNDARY_000__4b267e950b19dac096a12de1c5c8e750
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 I won't expect Sun to change their native syslogd. Their syslogd is working good in its native environment, and its "harmonic" with other native syslogd is evry good.
For me it doesn't seem like a bug. Just another mechanism.
Solaris' syslogd recognize the hostname by doing reverse-resolution for each packet. And I don't think it's such a bad idea.
The current mechanism of syslog-ng is trying to run some regexp on the data string (If I understood you correctly).
I believe that the Solaris mechanism is more secure because that way you know for sure that the originating IP is who it claims to be. (Yes, you can always hijack (hope i spelled this correct) an IP in the network, but I guess that in that case you have other trouble).
In syslog-ng mechanism, some1 can inject you fake logs. (I don't know what good it can give an attacker... but I'm sure that some criminal mind can find what to do with this).

Noam

 --- On Fri 01/03, Balazs Scheidler  wrote:From: Balazs Scheidler [mailto: bazsi@balabit.hu]To: syslog-ng@lists.balabit.huDate: Fri, 3 Jan 2003 10:48:51 +0100Subject: Re: [syslog-ng]replacing part of prog name with hostnameOn Thu, Jan 02, 2003 at 03:28:49PM -0500, Noam Meltzer wrote:>  I thing you confused it a little...> According to my last message (and a similar thread I created recently)> The problem with the hostname resolving of Solaris is fixed with using:> > keep_hostname(no)> > But, I would really like to understand what's going on in there.> Is my assumption correct?No. syslog-ng parses the incoming message, but the format of messages is_very_ vague. Depending on the sender the message itself can have many form.The problem here was the sender program contains a space, and Solarissyslogd does not add originating hostname to its local messages (unless itrelays the message) Thus it is not possible to decide whether the messagereceived contains 'hostname' & 'program' or a single 'program' but with aspace in it.keep_hostname() is not a solution, just a workaround, so syslog-ng itselfdoes not rewrite the hostname. The filter expression host('^hostname$')would still use the part before the space (e.g. the program name).The solution is to fix the sender program, no better workaround exists insyslog-ng.Nate, the problem does not apply to local messages only, it happens to caseswhen Solaris sends these messages via UDP. It is not a solution to simplyassume that there is no hostname for local messages-- BazsiPGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1_______________________________________________syslog-ng maillist  -  syslog-ng@lists.balabit.huhttps://lists.balabit.hu/mailman/listinfo/syslog-ngFrequently asked questions at http://www.campin.net/syslog-ng/faq.html

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__4b267e950b19dac096a12de1c5c8e750
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 I won't expect Sun to change their native syslogd. Their syslogd is working good in its native environment, and its "harmonic" with other native syslogd is evry good.
For me it doesn't seem like a bug. Just another mechanism.
Solaris' syslogd recognize the hostname by doing reverse-resolution for each packet. And I don't think it's such a bad idea.
The current mechanism of syslog-ng is trying to run some regexp on the data string (If I understood you correctly).
I believe that the Solaris mechanism is more secure because that way you know for sure that the originating IP is who it claims to be. (Yes, you can always hijack (hope i spelled this correct) an IP in the network, but I guess that in that case you have other trouble).
In syslog-ng mechanism, some1 can inject you fake logs. (I don't know what good it can give an attacker... but I'm sure that some criminal mind can find what to do with this).

Noam

--- On Fri 01/03, Balazs Scheidler < bazsi@balabit.hu > wrote: From: Balazs Scheidler [mailto: bazsi@balabit.hu] To: syslog-ng@lists.balabit.hu Date: Fri, 3 Jan 2003 10:48:51 +0100 Subject: Re: [syslog-ng]replacing part of prog name with hostname On Thu, Jan 02, 2003 at 03:28:49PM -0500, Noam Meltzer wrote: > I thing you confused it a little... > According to my last message (and a similar thread I created recently) > The problem with the hostname resolving of Solaris is fixed with using: > > keep_hostname(no) > > But, I would really like to understand what's going on in there. > Is my assumption correct? No. syslog-ng parses the incoming message, but the format of messages is _very_ vague. Depending on the sender the message itself can have many form. The problem here was the sender program contains a space, and Solaris syslogd does not add originating hostname to its local messages (unless it relays the message) Thus it is not possible to decide whether the message received contains 'hostname' & 'program' or a single 'program' but with a space in it. keep_hostname() is not a solution, just a workaround, so syslog-ng itself does not rewrite the hostname. The filter expression host('^hostname$') would still use the part before the space (e.g. the program name). The solution is to fix the sender program, no better workaround exists in syslog-ng. Nate, the problem does not apply to local messages only, it happens to cases when Solaris sends these messages via UDP. It is not a solution to simply assume that there is no hostname for local messages -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 _______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html <hr>Join Excite! - <a href=http://www.excite.com target=_blank>http://www.excite.com</a> The most personalized portal on the Web!

--EXCITEBOUNDARY_000__4b267e950b19dac096a12de1c5c8e750--