Hi Guys,
Thanks for the thoughtful response David. I don't want to branch from the
ossec src tree in any way if it's not necessary and almost never advocate
violating an RFC unless I do it behind closed doors. By default, syslog-ng
generates log messages with a variety of formats when it comes to hostname. If
an event is received from a locally-generated log source driver (klogd or
sysklogd in this case), it ends up getting written to syslog destinations as
[EMAIL PROTECTED] (default is [EMAIL PROTECTED]),
and if a syslog message is received by syslog-ng from a remote source (router,
another server, etc) then it will be written in a number of possible formats,
depending on the syslog-ng config. The hostname entry will either be the
hostname of the system generating the message, or a combination of the
hostnames that have passed the message. I think the config directive that
pertains to the second case is "chain_hostnames (to retain hostnames for all
systems through which a message passes) which would result in a hostname value
of host1/host2/host3 if messages created by host1 are then passed to host2 and
host3.
I haven't yet tested _not_ declaring a source driver name for klogd and
syslogd, but suspect it will fail....I'll let you know what I learn.
Michael, what version of syslog-ng are you using, and what do messages in your
syslog output look like? For internally-generated messages, are you seeing
nothing different than standard syslog? The problem I'm noticing doesn't
prevent ossec from working properly, but it does generate errors; lest I
configure to watch /var/ossec/logs/ossec.log to flush it out! :) They're
non-fatal, which is good, but odd nonetheless.
grateful,
Matthew
Quoting Michael Starks <[EMAIL PROTECTED]>:
>
> We use SyslogNG and haven't had this problem.
>
> Daniel Cid wrote:
> >
> > Hi Matthew,
> >
> > Having an "@" in the hostname is invalid and I have no clue why
> > syslog-ng does
> > that (it is wrong according to the syslog rfc and as a host name/domain
> > name).
> > Anyway, if you want to have your logs working, you would need to change
> the
> > code to handle that. Go to src/os_regex/os_regex_maps.h and on line 27,
> > change
> >
> > '\040',
> >
> > to
> >
> > '\001',
> >
> > *(\040 == '@').
> >
> > After that re-compile ossec and copies the binaries to /var/ossec/bin:
> >
> > # cd src/
> > # make clean; make all
> > # /var/ossec/bin/ossec-control stop
> > # cp -pr analysisd/ossec-analysisd /var/ossec/bin
> > # /var/ossec/bin/ossec-control start
> >
> >
> > Btw, did anyone else have this problem? I am wondering if I should make
> > this
> > the default behavior on ossec.... Any other syslog-ng user here?
> >
> > Thanks,
> >
> > --
> > Daniel B. Cid
> > dcid ( at ) ossec.net
> >
> > On 3/21/07, Matthew Hilty <[EMAIL PROTECTED]> wrote:
> >>
> > Hi OSSEC listers,
> >
> > First of all, a much-deserved "strong work" to all developers and
> > contributors. This is a very, very flexible package that (gasp) makes
> > me want to relearn what I've forgotten about regexes!
> >
> > Now, to the point, I'm getting the following in ossec.log every
> > time a rule fires:
> >
> > 2007/03/21 10:28:00 ossec-analysisd(1275): Invalid hostname in syslog
> > message: 'Mar 21 15:28:00 [EMAIL PROTECTED] sshd[XXXXX]: Accepted
> > password for user from ::ffff:X.X.X.X port XXXXX ssh2'.
> >
> >
> > It looks like ossec-analysisd is choking on the log format whic contains
> > the source driver identifier (in this case s_local) most likely due to
> > the @ character since it's not an allowed character for a host....I
> > think it's a null in ascii, but I might be wrong.
> > In any event, since this is the default behavior of syslog-ng
> > and a
> > useful feature, I'm wondering if anyone else has encountered it and can
> > help mt think my way out of this paper bag.
> >
> >
> > thanks,
> >
> >
> >
> > Matt
> >>
>
--
Matthew Hilty
Network Administrator
The Art Institute of Chicago
Chicago, Illinois
