Servers hacked. How to protect it?

[Yoh Asakura 9]

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 1]

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

 

What is the name of your server?

[Yoh Asakura 9]

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

[Dastgir 1246]

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 9]

Never use phpmyadmin? I will use what?

 

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

[Mystery 594]

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 503]

use passwords like this:

 

U^4spfQEKcJ^vJjhC%!gBR3s

 

or this

 

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

 

[Nebraskka 4]

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 5]

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!

Edited June 14, 2015 by Arei

[Yommy 265]

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

[Poison 10]

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 117]

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

[Yoh Asakura 9]

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...

Edited June 16, 2015 by Yoh Asakura

[Arei 5]

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!

Edited June 16, 2015 by Arei

[Yoh Asakura 9]

@@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?

Edited June 16, 2015 by Yoh Asakura

[Arei 5]

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.

Edited June 16, 2015 by Arei

[evilpuncker 503]

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

[Yoh Asakura 9]

@@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.

Edited June 16, 2015 by Yoh Asakura

[Arei 5]

@@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);

Edited June 16, 2015 by Arei

[Yoh Asakura 9]

@@Arei

But how they could know the tables of my script to make an SQL Injection?

I also paid SiteLock to protect my website against SQL Injection, Malwares, virus...but they still hacked somehow.

[Arei 5]

@@Yoh Asakura

Well, I personally don't believe that a server provider could offer you a service to protect you from SQL injections, I might be wrong, but I really don't see how someone could do that unless they would look into your code and fix SQL injections exploit themselves.

 

As I said I'm not a security expert (I hope actual security experts won't hesitate to correct me if I'm wrong ), but an SQL injection is not really related to the tables you are using in your scripts.

Let's pretend you have the following code in one of your RO scripts :

input .@mob_id$;query_sql("select iName from mob_db where ID=" + .@mob_id$ + "", .@mob_name$);

Now let's pretend the user pronpting this scripts enters "1;drop table inventory;" (without the quotes) the query would become :

select iName from mob_db where ID=1;drop table inventory;

Which is valid SQL code to select from mob_db where ID=1 AND drop table inventory. Someone hacking an Athena-related database can easily assume table names and execute code to his liking accordingly.

Sure this code won't allow the hacker to get your account list with passwords, but it still allows him to drop your inventory table.

 

This code is for example sake and a SQL exploit won't always be *that* big, but it is still a good practice to filter user input when you are about to use it for a SQL query.

 

Good luck with your server.

[Yoh Asakura 9]

@@Arei

I just called SiteLock and they've told me that I might have a Firewall, and they can provide me a good one, that helps to protect against SQL Injections, and they also have the deep scan...malwares, virus, malicious codes. SQL Injection Scan, etc. But it's like between $50~$140/month.

[Dastgir 1246]

@@Arei

I just called SiteLock and they've told me that I might have a Firewall, and they can provide me a good one, that helps to protect against SQL Injections, and they also have the deep scan...malwares, virus, malicious codes. SQL Injection Scan, etc. But it's like between $50~$140/month.

Mostly its due to SQL injection, but that site don't help a lot, you need to check your script, and all things that connect to SQL from web.

Or it might also be some password guessing.

[Arei 5]

@@Arei

I just called SiteLock and they've told me that I might have a Firewall, and they can provide me a good one, that helps to protect against SQL Injections, and they also have the deep scan...malwares, virus, malicious codes. SQL Injection Scan, etc. But it's like between $50~$140/month.

@@Yoh Asakura

In that case yes, they may have automated scripts that would look into your sources and detect potential SQL injection exploits, but the code must still be fixed since there is just no way for the MySQL server or any firewall AFAIK to guess if a given query is legit or containing a malicious injection.

 

Personally I really don't think it's worth the price since you can fix these issues yourself relatively easily (and probably will have to do it yourself even with a script warning you). All you have to do is use a function to escape special characters from user input before passing it to a query. So :

Hercules :

.@escaped_string$ = escape_sql(.@input_string$);

PHP :

$escaped_string = $mysqli_instance->real_escape_string($input_string);

 

I understand digging into your scripts sounds tedious, but if your problem really comes from SQL injections in RO scripts, you probably won't have any other choice.

Edited June 16, 2015 by Arei

[Yoh Asakura 9]

@@Arei

Follow some screenshots of my server email.

 

These things also appeared on my login table from my server database.

 

It was definetly SQL Injection through my website contact page and also through my website donation confirmation page.

 

 

 

Edited June 16, 2015 by Yoh Asakura

[Arei 5]

These of course are SQL injections + XSS (Cross-Site Scripting) exploit attempts. If these appeared on your login DB I would say again that your CP is at fault (or at the very least a PHP script with an unprotected login/account form); I really, really doubt these injections could have been done via your client login screen.

 

Another possibility would be some kind of account "protection" or "security" RO script using unfiltered user input inside a query on your login table, but when looking at your screens it reeks like an unprotected login/account form lying somewhere...

Edited June 16, 2015 by Arei