Valdis.Kletnieks@vt.edu wrote:

Looks like some of your boxes are running with the system clock set to GMT, and some with local time. Either that, or $TZ isn't being set right.

Are these running in a chroot environment that has a busticated or unreadable /etc/localtime?

Thank you for the quick reply. Nothing's chrooted. $TZ is blank for all systems, and /etc/localtime is available. All systems have identical /etc/sysconfig/clock settings. These messages are all from the same host, so I'll get two at the same time with a 5 hour offset in the time. Jeremy -- : Jeremy Kindy : System Administrator - Unix Infrastructure : Wake Forest University : : email - kindyjd@wfu.edu : work - 336-758-3076 : cell - 336-782-8500 --

Szeti, Balazs wrote:

Have you tried the timezone fix which was sent to the list some day ago? (date:2006.11.10. 11:28) Maybe it's not final, but it helped me...

B. Szeti

No, I have not tried that patch - I'm using 1.6 and I thought that patch was for 2.0. I'm willing to try the patch if it is compatible with 1.6. Jeremy -- : Jeremy Kindy : System Administrator - Unix Infrastructure : Wake Forest University : : email - kindyjd@wfu.edu : work - 336-758-3076 : cell - 336-782-8500 --

Balazs Scheidler wrote:

It is not compatible, but 1.6.x was not affected with that problem. Someone posted a possible solution saying that sshd in question was affected and after upgrading the problem went away.

The message was posted by Evan Rempel on tuesday

I suspected that was the case. The version of sshd installed on our machines (it was just updated last night by RHN) is openssh-server-3.9p1-8.RHEL4.17.1 I'll continue monitoring the logs, but a first look today indicates that the problem is not fixed. Thank you, Jeremy -- : Jeremy Kindy : System Administrator - Unix Infrastructure : Wake Forest University : : email - kindyjd@wfu.edu : work - 336-758-3076 : cell - 336-782-8500 --

We saw this too. It is a bug in sshd, after applying the latest updates, the problem went away. Evan. Jeremy Kindy wrote:

Hello all,

I've set up syslog-ng (1.6.11) on a test server (RHEL4), and am getting some strange timestamps on messages. Here is a sample, as it appears in the log:

Nov 10 14:04:54 host1 sshd[29798]: Accepted password for bob from ::ffff:10.40.131.115 port 32799 ssh2 Nov 10 09:04:54 host1 sshd[29797]: Accepted password for bob from ::ffff:10.40.131.115 port 32799 ssh2 Nov 10 09:04:54 host1 sshd(pam_unix)[29802]: session opened for user bob by (uid=0) Nov 10 22:00:54 host1 sshd[28326]: Accepted password for bob from ::ffff:10.40.131.115 port 33569 ssh2 Nov 10 17:00:54 host1 sshd[28325]: Accepted password for bob from ::ffff:10.40.131.115 port 33569 ssh2 Nov 10 17:00:54 host1 sshd(pam_unix)[28330]: session opened for user bob by (uid=0)

Any suggestions?

My guess is that it's a local time vs GMT or something like that (we're in Eastern Time Zone of USA, which is GMT -5). All of our servers are currently in the same time zone, and all of the ones currently logging to syslog-ng are RHEL4, though we do have a few RHEL3 and RHAS2.1 hanging around.

Thank you, Jeremy

-- Evan Rempel erempel@uvic.ca Senior Programmer Analyst 250.721.7691 Computing Services University of Victoria

thanks, looks like I'm keeping hostname re-writing using dns... -h Hari Sekhon Philip Webster wrote:

G'day Hari,

Hari Sekhon wrote on 11/13/2006 10:37 PM:

...

Hi,

I'd like some advice on what I should do on my logserver regarding hostnames.

I've currently got

keep_hostnames(no) use_dns(yes)

in order to get accurate and consistent hostnames but I'd like to consider just skipping the whole dns check rewriting thing and use

keep_hostnames(yes) use_dns(no)

The only issue I can see from this is that the hostname gets logged according to the packet. I'm reasonably confident that most machines will report the right name in their logs to the logserver but I also think that it makes it all too possible to screw up the logserver maliciously since any old junk that is sent to the port is put into the logs so you could hammer the integrity of the logs just by sending loads of bogus logs from a machine with the name set to that of any other machine on the network.

I've seen some Unix systems where things like SCSI errors get logged with the hostname as "SCSI", etc. So unless the remote systems are well-behaved you may end up not being able to identify where the log came from.

As for malicious names in the messages - if you accepting UDP logs then its quite simple to send a UDP syslog packet with a spoofed source IP address, so DNS lookups aren't going to help you there.

Cheers Phil

By the time you have to query dns you may as well just re-write the hostname, though. If storing things by IP, it's not as friendly and doesn't come out very well if using any interface since you then have to become a dns server yourself and query to match host and ip before you can get any useful information out of it. The advantage of your method is that you can inspect it the machines are sending the wrong hostname. -h Hari Sekhon Nathan Campi wrote:

I think I put an example in the faq on how to store logs in files/dirs according to the source IP or DNS hostname but store the log entries with the hostname the client sent.

Something like that is a good balance between the two, don't trust the client but still have record of what was sent. -- Nate Campi _______________________________________________ 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