Servers hacked. How to protect it?

[Yoh Asakura]

Hello,

I have three servers and recently all of them has been hacked somehow. I don't know how because I already let phpmyadmin acces only to my IP Adress and I also changed the phpmyadmin folder.

Is there anyway I can protect my server? I believe it's about the MYSQL, php and phpmyadmin installation.

Anyone could help me on this?

Regards.

 

[remix]

Get a dedicated server is one option to protect your server.

What is the name of your server?

 

[Yoh Asakura]

There's no difference since I've made all the installations...Dedicated or VPS will be the same.

 

[Dastgir]

1) Never use phpmyadmin

2) have strong and unique password for all things, (no common passwords).

Probably if they can visit SQL even if phpmyadmin only allows your IP, they might have got vps info.

 

[Yoh Asakura]

Never use phpmyadmin? I will use what?

The hacker don't have access to my vps, this is impossible.

 

[Mystery]

Majority of hacks nowadays are caused by lack of strong passwords. A simple " dsadfsafeD2005 " password can be cracked by password generator softwares 'dem hackers use. Strong Passwords = symbols, letters, numbers and roughly longer than 10 characters long.

 

[evilpuncker]

use passwords like this:

U^4spfQEKcJ^vJjhC%!gBR3s

or this

*~Uw_D!d.|mx.c4K6SD*JvXG

 

[Nebraskka]

Maybe there is a security hole in your site?

Try to give only needed SQL access rights from site to your game, so if hacker would receive access somehow, he couldn't do anything serious.

Try to connect to your SQL not by phpmyadmin, but with HeidiSQL through SSH tunnel - there is an option for that.

 

[Arei]

Like the others said it's most-likely your passwords that aren't strong enough. Another possibility could be a keylogger installed on your computer (or on someone's who have access to your servers); it's always a good good thing to scan for viruses and malwares once in a while.

Besides using strong passwords here are a couple of tricks to help prevent your (linux) server from being hacked :

1. Never access your server as a root except that one first time when you will create yourself an user with a strong password as well (you can always escalate your privileges with su/sudo if needed afterwards)

1.2 Disable root login from ssh /etc/ssh/ssh_config you will most-likely not need it anymore and it will negate LOTS of ssh bruteforce attempt

2. Install fail2ban and configure it for all the online services you are using on your server. fail2ban allows to temporary ban a remote IP address for a given time after a given number of failed login attempts.

3. Regarding MySQL as the others said, avoid using php-mysql editors such as PHPMyAdmin and don't directly allow remote connections to your MySQL server. If you really need to access your MySQL server it is safer to forward your remote server to your local machine using ssh.

I.e :  ssh -L 3306:localhost:3306 user@host

I have no idea if you can do this on windows though, but MySQL-Workbench allows connections to remote servers via SSH. You should probably look into it.

This kind of situation sucks, but what's done is done and you should turn this into an opportunity to learn and never let it happen again. I hope you will be able to fix your servers without too much trouble.

Cheers!

 

[Yommy]

i use the last 10 digits of PI for my password, never been hacked

 

[Poison]

i use the last 10 digits of PI for my password, never been hacked

but what is the last 10 digit of an infinite sequence of numbers? 

 

[Garr]

Bet that's exactly the reason it wasn't hacked yet

 

[Yoh Asakura]

I believe the hackers did SQL Injection...I've saw many strange columns on my login table and also on my server email adress.

I remember I had removed the remote login acess from MYSQL...and the passwords were very strong...

 

[Arei]

In that case finding the source of the problem might be more difficult.

First of all, you should list every single web application using MySQL you use on your server and update them to the latest version. Chances are there is an unfixed SQL injection exploit are relatively high. Looking at the modified tables might or might not help you locate the faulty application depending on how you handle your MySQL databases and users; it's most-likely going to be useless if you have only 1 user and 1 database, for instance.

As for FluxCP, I doubt it's the cause of the problem since it uses PDO prepared statements to retrieve data from the MySQL database (the query and the values are handled separately which prevent injections unlike query using strings with concatenated variable values). I am no expert on security though and someone might just prove me wrong on that point. ^^'

Anyways after you updated your applications, the last (but not least) thing to check is your custom applications/scripts. Look for SQL query strings with concatenated variables; if the variable is used as is, without any sort of data validation, simply use mysqli::real_escape_string to escape the potential quotes before passing it to your query, or even better, use prepared statements.

Injections are possible when you concatenate a variable value coming from user input (may it be a field in a form or a GET variable in an URL) to a SQL query string without any kind of validation/security process.

Your #1 rule when you develop an application should be "Never, ever trust user inputs.".

EDIT : By the way when I am talking about applications and scripts I'm not only meaning PHP applications, but actually your RO server scripts as well. RO scripts can also use sql queries; unlike PHP, you can't use prepared statements and have to escape values coming from user input.

Basically, search "query_sql" in your custom RO scripts and if you find out that a query uses a variable coming from user input as is, escape the variable with escape_sql() before passing it to query_sql().

I.e : query_sql("select lastlogin from login where userid='"+.@userInput$+"'", .@lastlogin$); => query_sql("select lastlogin from login where userid="+escape_sql(.@userInput$)+"'", .@lastlogin$);

(We all agree using such a query would be retarded anyways, that's for the sake of example ^^)

Cheers and good luck!

 

[Yoh Asakura]

@@Arei

I wasn't using FluxCP when the servers were hacked. My website has a registration script to register new accounts, but I don't know how the hackers got access to all the servers accounts.

I've also checked the IP's that logged on my VPS, and only my IP's appeared, which means that the hackers didin't get the acces of my VPS...

Do you think is better having a Web Hosting for my site and a VPS for the server or better website and server on the VPS?

 

[Arei]

Just edited my post, I wasn't precise enough and by applications/scripts, I also meant actual RO scripts that can be victim of SQL injection attacks as well.

It's hard to say if the hacker has actually been able to retrieve data or if he just messed your database up. In case of an injection coming from a RO script, I'd say it would most-likely be the later, but you can't really be sure. Another way to get hints would be looking MySQL query logs if you have them enabled, that might help you locate the faulty application/script and see what kind of queries have been injected.

Anyways, as long as you use MD5 for passwords, your user passwords shouldn't be compromised even if the hacker retrieved them, but it still best to ask them to change their passwords, just in case they are too simple and are crackable easily with a dictionary. (The hacker might want to try with GM accounts for instance)

Regarding your website and server separation I don't think it's required to separate them as long as you have enough resources to have everything running smoothly and a good separation of permissions.

I.e : having different MySQL users for Hercules and your account management website, even though they would most likely use the same database.

As long as your faulty web-application/RO-script is active and linked to your RO database (even if stored on another host), your data may get compromised; if you want to avoid further injection attacks, you really have to locate and eliminate the security breach allowing these attacks or it will happen again, no matter if your server and websites are separated or not. You should look at my previous post regarding how to locate and fix SQL injections.

Hope this helps.

 

[evilpuncker]

I guess you are br, stop using br CP (if you are) and you will never be hacked again

 

[Yoh Asakura]

@@Arei

Thanks for helping.

I will change company, I'm going to buy a VPS on Godaddy. At least there I can have their managed service, with security, monitoring and backups. And the VPS already comes with MYSQL (I was using BudgetVM without managed service, so I've made all the installations).

And what do you mean that is possible to make a SQL Injection through my RO Scripts? o.o

@@evilpuncker

I was using Ceres CP when they first hacked the servers, but then I've changed to fluxcp and they still hacked, but I think it's not related with the Panels....I believe it's about the MYSQL. I may have not installed and secured it very well, and also can be my website. Maybe the guy who developed it didin't made the scripts so well...who knows.

 

[Arei]

@@Yoh Asakura

Regarding the provider it's up to you really, if you don't feel like handling Apache, MySQL etc a managed plan might be better for you, but it won't magically protect you against some exploits such as SQL injections. This kind of exploit is not related to your server configuration in any way, it is always related to an application/script you are executing on your server and you have to locate and fix the faulty application/script to solve the problem for good.

If you don't use any kind of PHP application/script accessing your RO DB besides your CP (your tests imply the injections don't come from your CP) such as a forum or PHPMyAdmin for instance and still have issues, the problem might as well lie in one of your RO scripts. Yes they can be subject to SQL injections if not protected (see my previous example); as soon as you concatenate a variable which value is set by unfiltered user input in a SQL query, you open a SQL injection exploit; no exception. May it be an Athena script or a PHP script, it is not related to the language you are using, but the code itself.

If you don't allow remote clients to access your MySQL server and don't have any logs showing up another IP logging in your VPS, I really doubt somebody could have accessed your MySQL database just like that.

EDIT : Here's a better example of an SQL injection exploit in a RO script and how to fix it :

Exploit:

input .@mob_name$;// SQL injection exploit, .@mob_name$ is not filtered before it's concatenated into the SQL queryquery_sql("select count(*) from mob_db where iName = '" + .@mob_name$ + "'", .@nb);
Exploit fix :

input .@mob_name$;// SQL injection exploit fixed as escape_sql(.@mob_name$) will add escaping characters before quotes and prevent injection exploitquery_sql("select count(*) from mob_db where iName = '" + escape_sql(.@mob_name$) + "'", .@nb);