Arei

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! ^^

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

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

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!