Hello guys

Thank you for the membership here in the forum.

We have been exposed to our root password being reset.

I have no solution why, but have come closer to the problem.

I can look at the following picture that the password has been reset.
http://imgur.com/a/Yu6Fh

Command:
nano secure-20170806
Log location: /var/log/

Is there any way to see how it happened?

Firewall does not allow access to port 22 (SSH) from the outside and into the server.

I additionally need someone who can help through 2 Cent OS 6 servers and make sure the security is good on them and there are no holes and bad things.

This is of course for a fee. Please write a private message of interest.

Best regards
AF

#1 I would take a look at the node 10.2.2.97 and see who would be arriving over ssh from that node. I suspect that the root password was changed to attempt to make that link work. If you find out who was working on making that work, you can ask if they changed the root password.

#2 someone had to HAVE root access to change that password. How many people have root access: either via sudo or some other tool for escalation.

#3 assuming you are using sudo : check the sudo logs and see if you can tell who used it about that time.

Without more information about your servers, server usage, local threats (internal as well as external), local security needs and standards I would hesitate to advise you in any more than a general way. I will say that the Red Hat online documentation and security advisories are excellent, and they all apply to the corresponding version of CentOS.

1# 10.2.2.97 is our gateway (router), which is translated from other local subnets. We have other subnets, which is connecting to the Cent OS 6 server. That is OK.

#2 What about scripting? We have about 1000 webhotels in the Plesk installation. My bid is that we have been attacked with earlier Wordpress attacks and there has been a script that can reset the root pw.

# Have checked the sudo log/bash log, nothing to see about theres is runned a command passwd... And either no time stamps.

We are willing to pay to review our setup.

1) It could be someone in your organization who is able to reboot the system (via ctrl+alt+delete) and boot into single user mode in order to zero out the root password, and or read the /etc/shadow file.
* Countermeasures: Comet out the line ca::ctrlaltdel:/sbin/shutdown -t3 -r now (note this will also legitimately stop you from using ctrl+alt+delete)

2) Look for duplicate root entries in /etc/passswd, or unauthorized entries in /etc/shadow which can provide covert access..

3) The $home/.rhosts file is a prime target as it can allows one to gain entry to any host, from anywhere with the privileges of the userID who contains it in their home directory. This file is intended to specify which remote users can access the BSD r-commands (i.e. rsh, rcp, and rlogin) without a password.. An attacker can add entries to this file by either manually editing it, or running a script that exploits an unsecured CGI script on a web server application that's running on the system. These files aren't enabled by default, but users (including root) can just create on in their home directory which can represent a huge security hole.
* Countermeasures: chmod 600 $/home/.rhosts and change disable=no to disable=yes in the files rexec, rlogin, and rsh (which are in the /etc/xinetd.d directory; system must be rebooted for changes to take effect, or you can restart xinetd via kill -HUP pid#)

4) The /etc/hosts.equiv can be used by an attacker to see which hosts can access services on the local system, and as with the ~/.rhosts file they can read this file and spoof their own IP/hostnames to gain unauthorized access to the local system, or other systems as specified in those files.
* Countermeasures: chmod 600 /etc/hosts.equiv