Hi all,
I am new in linux and I have a little server running debian lenny. I have a auth.log file as seen below. I am curious about if I am hacked or not. I also wonder what those pam_unix(cron_sessions) are for. I checked the cronjobs by typing cronabs -l and could not find anything. Any advice would be great, I do not want to loose my datas which are valuable for me. Thanks..

Dec 30 05:14:00 hdd sshd[14154]: Failed password for invalid user brandon from 189.141.192.12 port 56367 ssh2
Dec 30 05:14:02 hdd sshd[14156]: reverse mapping checking getaddrinfo for dsl-189-141-192-12.prod-infinitum.com.mx [189.141.192.12] failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 30 05:14:02 hdd sshd[14156]: Invalid user john from 189.141.192.12
Dec 30 05:14:02 hdd sshd[14156]: pam_unix(sshd:auth): check pass; user unknown
Dec 30 05:14:02 hdd sshd[14156]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=189.141.192.12
Dec 30 05:14:04 hdd sshd[14156]: Failed password for invalid user john from 189.141.192.12 port 57010 ssh2
Dec 30 05:17:01 hdd CRON[14158]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 30 05:17:01 hdd CRON[14158]: pam_unix(cron:session): session closed for user root
Dec 30 05:39:01 hdd CRON[14163]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 30 05:39:01 hdd CRON[14163]: pam_unix(cron:session): session closed for user root
Dec 30 06:09:01 hdd CRON[14175]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 30 06:09:02 hdd CRON[14175]: pam_unix(cron:session): session closed for user root
Dec 30 06:17:01 hdd CRON[14186]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 30 06:17:01 hdd CRON[14186]: pam_unix(cron:session): session closed for user root
Dec 30 06:25:01 hdd CRON[14191]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 30 06:25:16 hdd su[14219]: Successful su for www-data by root
Dec 30 06:25:16 hdd su[14219]: + ??? root:www-data
Dec 30 06:25:16 hdd su[14219]: pam_unix(su:session): session opened for user www-data by (uid=0)
Dec 30 06:25:20 hdd su[14219]: pam_unix(su:session): session closed for user www-data
Dec 30 06:25:20 hdd su[14224]: Successful su for www-data by root
Dec 30 06:25:20 hdd su[14224]: + ??? root:www-data
Dec 30 06:25:20 hdd su[14224]: pam_unix(su:session): session opened for user www-data by (uid=0)
Dec 30 06:25:20 hdd su[14224]: pam_unix(su:session): session closed for user www-data
Dec 30 06:26:23 hdd CRON[14191]: pam_unix(cron:session): session closed for user root
Dec 30 06:39:01 hdd CRON[14288]: pam_unix(cron:session): session opened for user root by (uid=0)

cron jobs also live in /etc/cron.*

189.141.192.12 tried to get in but failed.

http://www.linuxquestions.org/questi...tempts-340366/ explains brute force attempts, which is what you are experiencing. Some of the pam stuff appears to be YOU gaining root access (?). Some are generated from cron jobs that appear to need root access (?).

The auth log logs all authentication attempts, successful or not. The login failures aren't usually anything to worry about IF you've mitigated the risk of running services that expose the machine.

Hi

I run a Mythtv server with external access via ssh, ftp and www. I get this all the time, sometimes the ftp logs are 3-4 megs in size with dictionary attacks. Nobody has yet gained access so I have learned to chill out a little.

What I have found useful is to write a Perl script that summarizes my log files and then emails me the output every morning.

Regards

Stefan

Thank you for the fast reply. I thought it was successful according to this.

Dec 30 06:25:16 hdd su[14219]: Successful su for www-data by root
Dec 30 06:25:16 hdd su[14219]: + ??? root:www-data

I already read http://www.linuxquestions.org/questi...tempts-340366/

It is weird that I did not ever add a cron job and do not know how to do that. I was worried about this then I closed port 22 to access. I hope I am safe now. But I should figure out how to get rid of that cron job.
What would you advise for that.
Thank you


PS: none of those logs are according to my usage. I get up at 8 30 am and see this log...

If you have iptables available you can do something like this...

Basically that means if someone attempts to connect more than 3 times in six minutes to ssh, drop their ip until there is 6 minutes of quiet time.

It'll get rid of most of your attempts on ssh. A strong password if your ssh is using passwords is more important... not using passwords, port knocking, etc is even better yet.

On the cron front, you will find that various administrative tasks are added automatically for you.

Have a look at the scripts in
to see what's running

There are default system cron items setup, as another user suggested check /etc/cron*

You should also ensure that root access via ssh is disabled (it probably is by default) - see /etc/ssh/sshd_config, set "PermitRootLogin no". This is the default.

It's also often recommended that you have sshd listen on port other than 22. On my system for example, sshd listens on port 22 on the LAN, and allows a number of users to log in then su to root, whereas on the WAN, it listens on a different port and only allows one particular (non root, otherwise unused) user to connect.

Thanks for your advices. I did the maybe the most secure one and closed port 22 to access from out of network form the router. But I am curious if something happened because of the previous attempts. I feel like the network sign blinks every few seconds now. I do not think it was like that before. Maybe I am being a little doubtful but I would be sending anonymous mails to the world now. I checked the cron directories and in the daily I have apache2 appt aptitude exim4-base lighttpd logrotate man-db mlocate samba standard and bsdmainutils.

Thanks in advance

Your router should be able to show you traffic to/from that box.

For ssh access, consider using public key authentication and disabling password authentication. The comments in the paragraph above the "UsePam" line in /etc/ssh/sshd_config give instructions on which settings to change. You also need to add your public key to the servers authorized_keys file.

Be sure to use a long passphrase to protect your private key. The nice thing about passphrases is that even though they are longer, they are easier to remember than a shorter random looking password. If someone where to get access to the client user account somehow, and copy the keys, this could allow them to break into the server. However, if the private key on the clients machine is passphrase protected, they can't unlock the private key. Be sure you don't allow a browser or keychain to contain private key. It should only be held in memory ( The computers and yours ) and not on disk.