If you’ve been unfortunate enough to be targetted by hackers who have added malware to your web server, here are a few Linux CLI tools you can use to troubleshoot.
The first is maldet which can be paired with Clam Antivirus to scan for malware. Here’s a good guide on how to do that.
Note you can install maldet via tools like yum or apt usually too. The key is to make sure it is running together with ClamAV which you should keep up to date. You can also get it to alert you and automatically quarantine suspicious files.
Another tool, which is much better at finding hacked PHP code (which is usually encoded) is PHP malware finder. You’ll notice that hacked PHP files aren’t plain PHP code, but have instead be encoded (e.g. base64) to make them unreadable without decoding.
This can be cloned to the server and run from the CLI with PHP. Just a note it will pick up a lot of positives depending on your app (e.g. WordPress) and you’ll need to work through these yourself.
Don’t forget to also have something like [All in One WP Security and Firewall] (https://wordpress.org/plugins/all-in-one-wp-security-and-firewall/) installed to lock down your WordPress site and also to scan for and alert you of any changes.
As a final measure, it helps if your application code is kept under version control on the server using a tool like git. This helps to see any untracked or modified files which you can then investigate and quarantine.
There are many reasons for this, so first check that MySQL/MariaDB is running properly, that you are using the correct credentials and that the the appropriate
user@localhost has access.
Also check you aren’t using
bind-address in your
my.cnf file if accessing from outside of the
localhost. These are things you will find with a google search.
Apart from this one other reason why
127.0.0.1 will work and
localhost will not work is if you are using something other than the default
socket=/var/lib/mysql/mysql.sock location in your my.cnf.
If that is the case, you’ll need to update the relevant
default_socket= parameter in
php.ini (for each driver) to match that socket – see the entries under
[mysqld] sections for the socket parameter. This is more likely to occur if you are using MariaDB for example.
If you find that your global $_SESSION variable is empty there can be several reasons, here are a few:
session.save_path is invalid (does not exist) or is not writable.
session.cookie_secure is set to true but you not using a secure site (SSL/https).
session.cookie_domain is set to a domain that does not match your site – very common if setting up a dev or test environment from a production site with a public domain.
You can find the session.save_path through php info or using the command line:
php -i | grep save_path
Once you have that, you clear PHP sessions by going into that path and clearing out the relevation session files.
The following grep command will search for any constants such as
define('CONSTANT', 1) within your PHP code base so you can see their values. Useful as many applications store the constant’s value in the database and not the constant’s friendly name.
This requires regular expressions, hence the use of egrep.
egrep --include *.php "(define)(.*)" -r *
SublimeLinter is a great syntax/error checking plugin for SublimeText.
Here are the steps to get it working (for example with PHP):
Note if you get stuck, use
to open your sublime text console and look for any errors. Also check the very comprehensive documentation:
Helped out a colleague with this issue. It can occur if you are trying to browse to a local site on your machine via https instead of http (among many other reasons). In this particular case it was due to https-everywhere extension in Firefox. So just make sure you are really going
to a http version of the site.
Another related error you might see is:
SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)
Which immediately tells you your browser is trying to perform a https request.
I loaded a CodeIgniter site today and received a blank page with just the message “Disallowed Key Characters”.
There are myriad of scenarios that can cause this to occur. In my particular example, it occurred due to the fact that my application/config.php file had the following set:
$config['cookie_prefix'] = "<CHANGEME>_";
I had put that in as a placeholder, but the “<” and “>” symbols are not allowed in this particular config value and throw this error. There are other symbols that will also cause this, so something to watch out for.
After you change this, remember to clear your browser cookies too.
Found this pretty cool link to how to syntax check multiple PHP files by passing the results of a find to
I’ve extended this and grepped out any files that pass syntax checking so you are just left with the errors. Here’s the full command in all its glory:
$ find . -name "*.php" -print0 | xargs -0 -n1 -P8 php -l | grep -v "No syntax errors detected"
If you are really stuck and not getting any useful information regarding PHP errors in your log files, then you can the following to the relevant PHP file and it will display those errors on screen:
Very handy when you are really stuck!