Server Compromise Issues

[Wesker]

We have ongoing issues with our server being compromised and need some assistance. While we have our host helping us along with other people in the community, we really need assistance on the security side. This is really crippling on us and we're all going through a tough time here. We aren't sure how they got in and hoping for additional solutions to ensure this doesn't happen again.

Here is what the host said: There are several OS system files that has been modified and we are not sure what files been modified so that the hacker can get easy access. Using this the hacker will still login easily on the server with his own means and delete all the required data accordingly. The only option is to backup all the important data on your local end and reload OS on the server.

So we are currently working on an OS reload.

1). What recommendations do you have for installations adding maximum security
2). Since they are getting into SSH, what do you recommend we do as a setup?
3). Anything else would be most appreciated.

 

[Sheratan]

Using SSH private key is a good start. And also port 22 whitelist to only your IP is the next option. Dont forget disable root login via SSH.

 

[Wesker]

And also port 22 whitelist to only your IP is the next option.

Tried that didn't work.

 

[Sheratan]

Tried that didn't work.

Are you using ISP with dynamic IP? I had static IP in my office and home, never had problem with that. Whitelist my ip only then drop all.

 

[Wesker]

Static. No I mean we tried that and they still got into the server.

 

[Wesker]

Anyone else?

 

[Fred.]

1). What recommendations do you have for installations adding maximum security

- Keep everything up to date at all times, Install security updates asap.

2). Since they are getting into SSH, what do you recommend we do as a setup?

- Use 2FA on your SSH and use SSH keys (I use Yubikey's for 2FA)

3). Anything else would be most appreciated.

- Use 2FA everywhere
- Use strong and unique passwords

 

[Wesker]

Is anyone available to assist us with configuring this server.

 

[Mouth]

Is anyone available to assist us with configuring this server.

https://xenforo.com/community/threa...k-server-configuration-hosting-support.61392/

 

[fly]

Tried that didn't work.

Assuming you tested this, that indicates that the person isn't using the SSH port.

 

[Wesker]

Assuming you tested this, that indicates that the person isn't using the SSH port.

They are yes. There are entry logs made in SSH.

 

[fly]

They are yes. There are entry logs made in SSH.

Unless I'm missing something, the following can't both be true:
* Your IP is the only one whitelisted in the firewall for SSH
* The attackers are using SSH

So are you sure that you tested the whitelisting? Although the point is probably moot, as there is no way to guarantee the integrity of the server at this point without some serious forensics.

 

[Wesker]

So are you sure that you tested the whitelisting?

Server was already compromised and as far as I know yes but it could have very well not be setup correctly.

Although the point is probably moot, as there is no way to guarantee the integrity of the server at this point without some serious forensics.

That will be one of the next steps.

Thank you.

 

[Jim Boy]

If the server is compromised - ditch it and move to a new one, you'll never recover.

On any new server always make sure your exposure is minimised, eg only ports 80 and 443 open to public, use a ssh key with no password authentication and no root login keep you system up-to-date. use a port scanning tool such as nscan to check for open ports. you could also consider an audit tool to verify

 

[Marcus]

Once a server is compromised, grab the data and ditch it. its also possible that your web application has security holes.

1. You can setup a *server for web access* (80 443) and forward requests to your xenforo server. Should cost no more like 10 usd per month. Once you setup that server, either remove 22 access or restrict 22 access to the ip of the *xenforo server*.

2. Your *xenforo server* only allows 80+443 to your web access server, and 22 to your ip.

 

[TPerry]

They are yes. There are entry logs made in SSH.

Restrict SSH to specific users only, and use GOOD passwords.

Burn the image for the OS out again. Use CentOS and install CentMin with it. It's a little harder than cPanel, and unless you know what you are doing you will want to use an outside service for mail.
You want to export your DB and place it in a location you can access later (like your PC) and them also make a list of all add-ons you currently use (as you will need to manually re-install the files - NOT using any automated process). Reinstall XenForo and either import the data or just import the old DB after making sure all your add-on files are present.

If the server is compromised - ditch it and move to a new one, you'll never recover.

Actually, no you don't have to "move to a new one"... all you need to do is burn the OS image back out and then make SURE that it is secured and good password/account practices are used.
You also need to make sure that you keep it updated (this is one thing that I find MANY supposed "system admins" fail to do).

 

[WSWD]

Don't use Port 22, for starts. Change the SSH port to something else.

 

[TDUBS]

All of the above posts are perfect examples of hardening your server. There are many tutorials for basic yet vital Linux hardening methods that will protect you against vulnerabilities.

Here's a good start.. https://www.rootusers.com/23-hardening-tips-to-secure-your-linux-server/

 

[PlayStage]

Hello,

I see all of you talking about SSH, private keys, open-closed ports, 2FactorAuth.
Most of you are missing key aspects you don't find by running Google searches: a server is as secured as its weakest chain.

Should you need a security audit done by a system engineer, feel free to contact me.

Kind regards,
George.

 

[TPerry]

I see all of you talking about SSH, private keys, open-closed ports, 2FactorAuth.
Most of you are missing key aspects you don't find by running Google searches: a server is as secured as its weakest chain.

Considering that he commented

They are yes. There are entry logs made in SSH.

It's a pretty good indicator that the intrusion point involved SSH at some point. The actual vector of attack is not answered (and can easily be a piss-poorly written add-on or script being ran on the server) to the admin not keeping up with system updates (servers's are NOT a install and forget type deal unlike many amateur admins believe).
At this point, a security audit would serve no purpose other than showing where he/she screwed the pooch - the simplest thing for him to do is provision the server again THEN make sure he hardens it and keeps it updated and use basic good security practices for securing the server.