Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm setting up a small VPS (last Centos) and I'm facing a problem with my SSHD logs. I want to install fail2ban and everything seems to run fine, but I noticed a lot of attempts of bruteforce in the secure log, and nothing seems to be jailed. By investigating further I noticed that a lot of these attempts happens to be logged in the future. I guess that could be the problem for fail2ban.

Is anybody have an idea why my SSHD would log events in the future ? Thanks.

Here is an example of what I said :

[root@myhost log]# date
Mon Nov  1 11:44:57 EDT 2010

--- content of /var/log/secure

Nov  1 09:01:21 myhost sshd[5381]: pam_unix(sshd:auth): check pass; user unknown
Nov  1 09:01:21 myhost sshd[5381]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.XX.XX.XX
Nov  1 09:01:23 myhost sshd[5381]: Failed password for invalid user smecher from 221.XX.XX.XX port 22502 ssh2
Nov  1 13:01:23 myhost sshd[5384]: Received disconnect from 221.XX.XX.XX: 11: Bye Bye
Nov  1 13:01:33 myhost sshd[5409]: Connection closed by 221.XX.XX.XX
Nov  1 09:03:01 myhost crond[7335]: pam_loginuid(crond:session): set_loginuid failed opening loginuid
Nov  1 09:18:01 myhost crond[30300]: pam_loginuid(crond:session): set_loginuid failed opening loginuid

As you can see, the attempts coming from 221.XX.XX.XX are in the future. I really wonder why.

share|improve this question
add comment

2 Answers

up vote 0 down vote accepted

Perhaps the sshd process is inheriting a TZ environment variable from somewhere that is causing it to misreport the time.

It is also possible that there is something wrong in your provider's VPS setup. The technology your provider may be using to provide you a virtual server might not be correctly emulating or virtualizing the RTC. I ran in to this problem using QEMU; sometimes the virtualized RTC and the hosts' real RTC would get out of sync.

share|improve this answer
    
I guess you were right. I change to the default timezone for my system (UTC), and now things are working... but in UTC, that is not very convenient to read logs knowing I'm in EST. Thanks anyway, it seems that's the way to go to fix it. –  Remiz Nov 4 '10 at 17:17
add comment

It looks like you are seeing this bug. What version of CentOS exactly are you running, and do you have all of the latest patches?

share|improve this answer
    
Thanks, I'm running CentOS release 5.5 (Final). I also plugged yum to Epel and IUS Community. When I check the version of sysklogd, it says 1.4.1-46.el5. So I assume it's not covered by the bugfix. I'll try to update it by another way than yum. –  Remiz Nov 1 '10 at 17:54
    
Strange thing is I have the same version of sysklogd on a RedHat server, with everything working fine (fail2ban included).I guess I should check my config files... –  Remiz Nov 1 '10 at 18:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.