Scanning Your Server for Malware

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.

PHP database can’t connect to localhost but 127.0.0.1 works

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 skip-name-resolve and 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 my.cnf [mysql] and [mysqld] sections for the socket parameter. This is more likely to occur if you are using MariaDB for example.

$_SESSION global is empty

If you find that your global $_SESSION variable is empty there can be several reasons, here are a few:

  • The session.save_path is invalid (does not exist) or is not writable.
  • The session.cookie_secure is set to true but you not using a secure site (SSL/https).
  • The 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.

PHP Session Save Path

You can find the session.save_path through php info or using the command line:

php -i | grep save_path

E.g. /var/lib/php/session

Once you have that, you clear PHP sessions by going into that path and clearing out the relevation session files.

Find constants in your PHP code base

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 (with PHP)

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

CMD+`

to open your sublime text console and look for any errors. Also check the very comprehensive documentation:

http://sublimelinter.readthedocs.org/en/latest/

Undefined index: HTTP_HOST

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.

Disallowed Key Characters Error

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.

Force PHP errors to display

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:

error_reporting(E_ALL);

ini_set("display_errors", 1);

Very handy when you are really stuck!