Hack Attack

We woke up Friday morning with over 40,000 email notices from scripts on our server, indicating a hack attack.

Persistent hack attempts like this one are not an everyday occurrence. When it does happen, I like to watch their actions to develop defense for use in the future.

Whoever was doing this tried to be subtle, or so it seemed. The hacker rarely made more than 3 attempts per second. They may have thought many more would slow the server and spawn an overloaded warning. Of course, they didn't know about the email alerts I get.

After reviewing some of the attempts, it was clear they were trying to break into any MySQL table they could break into. My thought is they were looking for usernames and passwords, but they may also have had other reasons.

The attempts all seemed to be probing for known security issues of deprecated MySQL functions that I've been bypassing or defensive coding for many years.

The hacker had the site downloaded. This became obvious when I changed a field name of a form he was going through. The attempts continued with the old field name.

There is only one MySQL table on the domain with usernames and passwords. That one is extra tightly secure, including best-practice recommended password encryption methods. (It also has code that watches for certain strings of characters and warns me of MySQL break‑in attempts. Those warnings were over half of the thousands of emails that were waiting for me Friday morning.)

So I wasn't worried.

But I watched anyway in case there was a vulnerable script anywhere on the server. If there was, this hacker's persistence would reveal it to me and I could fix it.

Files Monitor warned us of any file changes, such as log files, so we could have a look and see if the file changed because of the hack.

The hacker's IP address could have been banned at the server level.

But I didn't want to do that. If the IP address was banned, the hacker would likely just used a new one, or perhaps several.

Letting the hacker work with that one IP address served me well.

Because I wanted to continue to watch the hacker, any defenses I employed while the hack was going on needed to be implemented in a way that didn't alert them to the fact they were detected.

Access to MySQL was blocked for additional protection, without alerting the hacker, and other functionality was bypassed, like emailing of form use acknowledgements. The blocking and bypassing was done with the hacker's IP address. The rest of the script functionalities worked as if nothing untoward was happening.

To implement, I made a blocked-list file on the server with the hacker's IP address. Additional IP addresses could be added.

(Which I did when testing a script after modification. I would add my own IP address to the blocked-list file in order to verify blocking and bypassing happened like it was supposed to. Then removed my IP address after testing.)

It case it faded in memory between now and the next time a hack attempt happened, I put example code into the blocked-list file itself.

The hacking attempt was a time sink, most of two days. But one thing really good came out of it:

A version of the code will be implemented in Spam‑free Form.

In a moment, I'll provide the blocked-list file with example code that I used. Please note that I'm unable to write specific implementation instructions because every script is different. But there will be an overview of what I did with the code.

Here, in case you can use it, is the blocked-list file with IP address and example code (file names changed for security).

One ip address per line - blank lines okay

44.33.22.11

Example code:
<?php
$OKIP = true;
foreach( preg_split( '/[\r\n]+/', trim( file_get_contents("{$_SERVER['DOCUMENT_ROOT']}/BLOCKEDforSCRIPTS.php") ) ) as $ip )
{
    if( $_SERVER['REMOTE_ADDR'] == trim($ip) ) { $OKIP = false; break; }
}
if( ! $OKIP ) { file_put_contents( "{$_SERVER['DOCUMENT_ROOT']}/BLOCKEDlogFILE.json", json_encode(array('stamp'=>date('r'),'$_POST'=>$_POST,'$_SERVER'=>$_SERVER))."\n", FILE_APPEND ); }
?>

<?php if( $OKIP ): ?>
[blocks and bypasses]
<?php endif; ?>

An overview of what I did with the code:

You see the blocked IP address in the file (not the hacker's real IP address). More IP addresses can be added for blocking.

Below that is the example code for the various scripts that were updated as the hack was proceeding.

How the example code was implemented depended on the script. If the entire script was PHP code, the <?php and ?> lines were omitted — the script already had them.

The blue and red lines were always included in the script being updated.

The blue lines check to see if the current user's IP address is in the blocked-list file. If yes, the $OKIP is set to false. Otherwise, $OKIP remains true.

The red line updates a log file if the IP address is indeed listed. The log gets all the information available to the server. If you decide to use this code but don't want the log file, omit the red line.

The green lines are a note to check the $OKIP value when determining that certain code should or should not run for any listed IP address.

By early Sunday morning, the hacker had left.

My plans are to extend the functionality to automatically add a hacker's IP address to the block-list file when MySQL code is encountered that generally is used only for hacking MySQL tables. If you are interested in this, let me know.

(This article first appeared with an issue of the Possibilities newsletter.)

Will Bontrager