Arei

You are welcome, I'm glad if I have been of any help And don't forget; never, ever trust user input!

At least it can't hurt to disable these tools until you locate the precise source of the problem if it puts a stop to these attacks. I assumed FluxCP would be relatively safe from injection due to PDO prepared statements, but then again, no software is 100% secure AFAIK Last thing: it might be also worth looking if you are not using FluxCP addons/themes that would allow such an exploit to exist. It would actually be extremely easy to put such an exploit for malicious intents, I guess it also might happen accidentally as well. Good luck

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

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

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

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.

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!

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!

I think it's normal -3:00 doesn't work since php can't magically guess what timezone you are referring to (GMT, UTC, EST, DST...). What about trying UTC-05:00 (assuming from your post you're from New York) ?

I didn't get to know you, but I wouldn't be back in Ragnarok "business" if it wasn't for you. Thanks a thousand times for your amazing work, Hercules is a truly remarkable piece of software. Wish you the best for your future!

From a fresh install : 1. Extract FluxCP somewhere you like and, assuming your user is the owner of the parent directory, type the following commands in the FluxCP directory. (If you are working directly into /var/www escalate your privileges to root to use these commands.) 2. chown -R www-data:www-data data/itemshop 3. chown -R www-data:www-data data/logs 4. chown -R www-data:www-data data/tmp I've always (re)installed it that way and I've never had any issue. Also I would personally avoid doing a recursive 777 chmod into the whole directory, since FluxCP only need to write into these 3 directories as far as I know.

Thank you guys for the welcoming! Yes Hercules seems to be really stable and the only bug I had to report so far was an innocent typo in a teleport script (that was actually bothering one of my crazy friends who grinded to his 3rd job in a couple of days despite the low exp rate ¬¬). It took me a couple of minute to set the server up and to be honest I would have expected more troubles especially since it has been a decade since I last used a RO server emulator. ^^ I really hope I can contribute to Hercules someday, my inner self is actually harassing me to start learning C/C++ at last... Also thanks for retaining yourselves from bashing me because of that guilty pleasure called Java

You don't really need vnc and running a desktop environment on your server will use more resources for no benefits... Download putty and access your server through ssh from windows (or use the ssh command if you are using LInux) The easiest way to handle things is to make yourself an user account with a strong password on your server with the command adduser and use it to access your server. You can always escalate your privileges with the su command if you need it and you can also mitigate bruteforce attacks on your server by disabling ssh root login in /etc/ssh/sshd_config Then install yourself an ftp server like proftpd if you need to transfer files to your server and make sure to edit /etc/proftpd/proftpd.conf to jail users in their homes to limit security issues. When connected through ssh to your server with your user account download and install Hercules with the following tutorial (assuming you are using a debian-based distribution) : http://herc.ws/wiki/Installation_%28Debian%29 To handle server instances and launching I suggest you install screen and use a bash script like this one in your Hercules folder to start your RO server : #!/bin/shscreen -S login -d -m ./login-serverscreen -S char -d -m ./char-serverscreen -S map -d -m ./map-server to access a server instance, simply use the command screen -r [screen name] and use ctrl+a+d to leave the screen without stopping the server. Regarding PhpMyAdmin it should only take a configuration file to edit after you installed apache and php of course. Personally I prefer forwarding port 3306 through a ssh session and access my database with mysql-workbench but I have no idea if you can do this on windows. EDIT : Typos, bad English...

Here is a rather disgusting, but quick fix for those having problems with the support tickets module. Don't forget to backup your files before applying the following fixes. Fix department list items appearing twice : addons/support/modules/support/department.php change : <?php if (count($all_dep_res)): ?> <?php foreach ($all_dep_res as $row): ?> <option value='<?= (int) $row->id ?>'><?= htmlspecialchars($row->name) ?></option> <?php endforeach ?> <?php foreach ($all_dep_res as $row): ?> <option value='<?php echo (int) $row->id ?>'><?php echo htmlspecialchars($row->name) ?></option> <?php endforeach ?><?php endif ?> to : <?php if (count($all_dep_res)): ?> <?php foreach ($all_dep_res as $row): ?> <option value='<?php echo (int) $row->id ?>'><?php echo htmlspecialchars($row->name) ?></option> <?php endforeach ?><?php endif ?> Fix addons/support/themes/defalut/support/list.php and addons/support/themes/defalut/support/view.php (Quick and dirty workaround for Flux::Config("ThemeName") not working with add-ons. lib/Flux.php change : public static function config($key, $value = null, $options = array()){ if (!is_null($value)) { return self::$appConfig->set($key, $value, $options); } else { return self::$appConfig->get($key); }} to : public static function config($key, $value = null, $options = array()){ if (!is_null($value)) { return self::$appConfig->set($key, $value, $options); } // Disgusting hardcoded fix for Flux::Config("ThemeName") in addons else if ($key == "ThemeName") { return Flux::$sessionData->theme; } else { return self::$appConfig->get($key); }} This fix is far from being satsfying because it's hardcoded and the issue will repeat with every application parameter passed as an array like ThemeName. I am not that good with PHP and I have actually no idea how to fix this without diving into the core of FluxCP. I'll edit my post if I come up with a better solution though. 06.08.2015 Edit : I found another error in the support module and a way to fix it in the addon code (even though I suspect the problem comes from FluxCP itself ). The error (Trying to get property of non-object in [...]function.php line 306) happens when you try to log in with a wrong username/password. I didn't realize the problem until I turned debug mode on when I started working on an addon. addons/support/modules/support/functions.php change : $group_col = getGroupCol($server); to : $group_col = getGroupCol($session->loginAthenaGroup); 06.14.2015 Edit : Yet another bug, yet another ugly fix for support addon. This fixes the query errors in the ticket list pages happening depending on the current user AccountLevel. addons/support/modules/list.php change: if ($sth->rowCount()){ $i = 0; foreach ($group_res as $row) { if ($i != 0) $sql .=" AND"; $sqlpartial .= " department != ?"; $bind[] = $row->id; $i++; }} to: if ($sth->rowCount()){ $sqlpartial = "WHERE"; $i = 0; foreach ($group_res as $row) { if ($i != 0) { $sqlpartial .=" AND"; } $sqlpartial .= " department != ?"; $bind[] = $row->id; $i++; }} 06.16.2015 Edit : Another one. Fix the error when clicking on a ticket to see the detail : addons/support/modules/support/view.php change : $mail = new Flux_Mailer(); to: $mail = @new Flux_Mailer(); Same fix applies to any other page affected by the issue. Hope this helps! Also don't hesitate to correct me if you find a more proper (I know there are some) way to fix those issues! ^^