2

This is frustrating. I am often able to login with a root password. Then I cannot login again. However, I am still logged in. Hence my password must be correct.

I changed the root password with passwd. It works again. Then sometimes latter this happens again.

It's as if the root password changes all the time automatically. Did someone hack my server?

manatwork
  • 31,277
user4951
  • 10,519
  • 1
    Just a short note: a password change does not close the existing sessions. The fact you're still logged in does not mean that the password at any given time is the same that you have used to log in. – Leonid Jan 04 '13 at 05:21
  • It's not that the password keeps changing. It seems that server reject all root login for a few hours and stuff. – user4951 Sep 27 '13 at 12:03
  • /var/messages are indeed full with so many failed login attempt. – user4951 Sep 27 '13 at 12:03

4 Answers4

4

Assuming someone is playing around with your box or some kind of practical joke, and they did not cover their track.

Check login history

Via Command Line

w
last

Via Log Files

/var/log/auth.log (debian/ubuntu)
/var/log/secure (RedHat/CentOS/Fedora?)

Other Possibilities

  1. Your box is a virtual machine and some how keep getting roll back to previous state(snapshot).
  2. Many VPS actually reset your root password. You have to use the vendor/hosting web interface to change the root password. Otherwise it will just keep changing back to the previous one.
John Siu
  • 4,765
  • how do I know my server's IP? Maybe I am logged in to a different machine – user4951 Jan 04 '13 at 04:12
  • Login in as root, type command ifconfig. If you are using a windows machine, go to website whatismyip.com – John Siu Jan 04 '13 at 04:19
  • @JimThio I have the following command readily available; it will print the external IP address that you are using to make outbound connections, thus taking into account NAT etc. wget -qO- http://ipecho.net/plain That's just one service to obtain one's IP address; there are numerous others. -q means use quiet mode, and -O- means print the content of the response to - (standard output) rather than saving it to a file. – user Jan 04 '13 at 12:32
1

I just want to share what's going on.

I am the one that make the question and this is a very old recurring problems.

The issue can be seen here:

http://hostechs.com/2008/10/user-root-blocked-cphulk-brute-force-protection/

I am using cpanel.

Cpanel has cphulk that protects machines from brute force loging.

The problem is,

Many people have had the same problem. THe solution is to ensure that your IP is white listed by cphulk. Also rebooting the machine may sometimes work for a while. There is no easy solution.

user4951
  • 10,519
1

While reviewing other posts concerning this issue, I ran across information concerning how to check the system for an infection ..

Run either program:

rkhunter  
chkrootkit

verify the integrity of binaries

rpm -Va .

Confirm all root owned files that have the suid bit turned on. Any such file is executed as root, no matter who the user is. Use:

find / -perm 4755

A resulting file will have rwsr-x-r-x permissions. The "s" tells you the suid bit is turned on. Because it has execute by ANY users (the final r-x) it means any user can run it as root. I run the find for each of 4777, 4775, 4755 etc... - basically for any mode in which anyone other than the user (root) would be able to write the file (so no reason to search for 4744 because though it is readable by everyone else only root could write to it.)

http://www.linuxquestions.org/questions/linux-security-4/root-password-keeps-changing-372647/

Also to reset your passwords: From GRUB boot menu, add to linux16 line ...

rw init=/bin/bash

press ctrl-x

reset root password

passwd

reset user password

passwd [user]
touch / .autorelabel
/sbin/reboot -f

http://linuxbsdos.com/2015/03/19/how-to-reset-passwords-on-fedora-21-and-22/

Also, found the Linux.Xor.DDoS trogan on affected systems. Still searching how to remove it. But, an effective way to keep it from getting in is using private keys.

If you also have an SSH server running make sure to set up key authentication with a strong password, then turn off just password authentication. This forces SSH to authentic witht the public/private keys you set up. Makes it next to impossible to brute force since the attacker won't have the appropriate key and the system will just drop the connection. 

ssh-keygen -t rsa

Follow the instruction to enter a pass phrase and store the key into a file. Now copy the key to the computer you want to ssh to:

ssh-copy-id username@remote_host

Finally, with the key transfered, you should be able to log in with:

ssh username@remote_host

https://www.bleepingcomputer.com/forums/t/562586/the-newly-discovered-xorddos-trojan-infects-linux-systems-to-possibly-build-an/

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-ssh-configuration-keypairs.html

To disable SSH password authentication:

cd /etc/ssh
cp sshd_config sshd_config.orig
vi sshd_config

Change the following settings

PermitRootLogin     no
PasswordAuthentication  no
UsePAM          no

Restart SSH

/etc/init.d/ssh restart

https://www.howtoforge.com/set-up-ssh-with-public-key-authentication-debian-etch

Stephen Rauch
  • 4,239
E Net Arch
  • 111
0

My guess is there's another machine on the network with the same IP address and they're fighting. Sometimes you login to your server, sometimes to the rogue.

dartymoor
  • 1
  • 2
    If you use ssh to log in, then you should be able to tell if this is happening from the host key changing. – kasperd Oct 16 '14 at 10:23