Hi, Community. Just relating information at this time. Selected category as system security.
We have just over 25 ClearOS 7 boxes at various locations. Most are to for individual sites. We have had two boxes compromised in as many weeks. Not been able to ascertain the attack vector. We find a user named support with the same ID as root and indicates the same login times as our with root. It removes the bash history for root, removes many of the logs from /var/log and adds config.txt, cpu.txt, minerd, and monero to /etc/sbin. Cron for root is edited to start monero from /etc/sbin every 5 minutes. We have managed to recreate the logs and rename the additional files to prevent the miner from starting again and getting the boxes operational again (both run Zarafa Community). I removed the user via "vipw" and "vipw -s". Not going to leave the boxes in production.
Port 81 is open and accessible from outside, passwords are fairly complex, root access is allow from WAN but the port was closed (we only open when we to use for support). It is possible the threat came from LAN side but not been able to find anything from remaining information.
Posted queries about restoring mail archives due to compromised box but didn't hear anything from anyone. Was wondering if anyone had seen anything like this or if ClearOS would be interested in some telemetry. Going to replace the box compromised last week with fresh install tomorrow and try to replace the other by end of week.
We have just over 25 ClearOS 7 boxes at various locations. Most are to for individual sites. We have had two boxes compromised in as many weeks. Not been able to ascertain the attack vector. We find a user named support with the same ID as root and indicates the same login times as our with root. It removes the bash history for root, removes many of the logs from /var/log and adds config.txt, cpu.txt, minerd, and monero to /etc/sbin. Cron for root is edited to start monero from /etc/sbin every 5 minutes. We have managed to recreate the logs and rename the additional files to prevent the miner from starting again and getting the boxes operational again (both run Zarafa Community). I removed the user via "vipw" and "vipw -s". Not going to leave the boxes in production.
Port 81 is open and accessible from outside, passwords are fairly complex, root access is allow from WAN but the port was closed (we only open when we to use for support). It is possible the threat came from LAN side but not been able to find anything from remaining information.
Posted queries about restoring mail archives due to compromised box but didn't hear anything from anyone. Was wondering if anyone had seen anything like this or if ClearOS would be interested in some telemetry. Going to replace the box compromised last week with fresh install tomorrow and try to replace the other by end of week.
Share this post:
Responses (3)
-
Accepted Answer
I did reply to your mail archive thread.
In terms of compromise, if the secure log got deleted it would be impossible to check for SSH breaches, otherwise that is a possibility, But, unless you've given shell access to others, it could only be the root user. Do you run websites on these boxes, especially Wordpress ones? I seem to get so many attempted WP logins on my box (even though I don't run WP) that there must be a lot of vulnerabilities appearing continually and it seems to go in bursts, so presumably when another vulnerability is found. Would there be anything in in the httpd logs?
Have you been able to research the the app to work out what attack vectors it used. A quick google gives a load of horrible stuff. -
Accepted Answer
Thanks, Nick. I just didn't see your follow up. Replaced the first box yesterday with new hardware.
We serve out the built in sites like Webconfig, Zarafa Webapp, and Z-Push. No other websites hosted. Root password was 14 characters. Found the external port was also shared as IMPI port on Supermicro box. Looking at that angle as well. SSH was blocked by firewall when not in use. Shell access component was installed for OpenLDAP and several users had it enabled after the fact but I'm unable to confirm it they did before on one of the boxes. The other box didn't have the component installed. It is not our practice to give shell access until needed and then custom rules to allow specific IP addresses to connect. No users needed it a either location.
I'm comparing the files that were left behind. Unfortunately, it covered its tracks pretty well. Most of the log files were removed along with bash history. Will be happy to share what I find. -
Accepted Answer
This is a situation where using the remote logging facility in rsyslog might be a helpful, assuming you have another machine to record the logging information. The intruder would then need to also compromise the logging system to cover his tracks. Even if he disabled the remote logging - you might still have enough in the logs previous to his changes to provide some information.
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »