Help determining downside to this method of blocking access

[schwim]

Hi there folks,

I was wondering if you guys wouldn't mind helping me figure out any potential downfalls to this method of blocking site access(banning).

Currently, I check for the bots that are looking for vulnerable scripts, for instance wp-login.php or fck_about.html. Also access to certain directories that don't exist, like /administrator. On a request, it loops through this short list and placed the IP into the banlist if matched. This is done for a few reasons, the main one being to lessen the load on the server by taking these bots out of the page generation before the heavy lifting is done. The check is done right at the beginning and they get a static html page include. Second reason is to stop them from continuing their attempts until they find something.

One thing that I've been getting a lot of that I've just recently begun blocking is anything with a "%" in the query of the URL. I've been getting tons of injection attempts like so:

/?action=my-filter%27%26%26BeNChMaRK%282999999%2CmD5%28NOW%28%29%29%29%26%26%271&cat_id=37

Which decodes to:

/?action=my-filter'&&BeNChMaRK(2999999,mD5(NOW()))&&'1&cat_id=37

I've written the entirety of the site's code. I have not written anything that would utilize this symbol in the query portion of the URL. There's plenty in the referers, like Facebook, but I'm only checking the request URI.

Is there something I'm missing in implementing this? I am monitoring the system to look for any false positives, but thought I would ask in the event there's more to this that should be considered.

Thanks for your time!

[dalecosp]

For whatever it's worth, I've done things similar to this and haven't noticed any issues/downsides.

[NogDog]

One possible issue is if you have a search function or other reason that a GET request would be (correctly) used which might possibly have characters that have to be url-encoded in order to be used, e.g.:

https://www.example.com/search?term=I+can%27t+search+this

...which would also be just as correct as...

https://www.example.com/search?term=I%22can%27t%22search%22this

[schwim]

Thanks very much dalecosp for putting my mind at ease a little bit 🙂

Here's how I've implemented it.

First, this function is run on the URL. I do this right at the beginning and use the resulting array for various things in the site, one of which is the bad GET data:

function dissectURL($url){
	$scheme = parse_url($url, PHP_URL_SCHEME);
	$host = strtolower(parse_url($url, PHP_URL_HOST));
	if(substr($host, 0, 4) == 'www.'){
		$host = ltrim($host,"www.");
	}
	// $user = parse_url($url, PHP_URL_USER);
	// $pass = parse_url($url, PHP_URL_PASS);
	$path = parse_url($url, PHP_URL_PATH);
	$path = ltrim($path,"/");
	$query = parse_url($url, PHP_URL_QUERY);
	$fragment = parse_url($url, PHP_URL_FRAGMENT);

$returnURL['scheme'] = $scheme;
$returnURL['host'] = $host;
$returnURL['path'] = $path;
$returnURL['query'] = $query;
$returnURL['fragment'] = $fragment;

return $returnURL;

}

Then this is what I run to check for the % character:

if (strpos($testquery, '%') == TRUE OR strpos($testquery, '%') == TRUE) { 
		/* We've got a match on the percentage sign in query.  Add them to the autoban list and direct them to the bad boy page. */
		--DB INSERT HERE--
		include("./includes/autobanned.html");
		exit;
	}

The site doesn't see much traffic yet, so no real world matches or false positives, but I'll keep a close eye on it to make sure I've not screwed something up.

[schwim]

NogDog;11045573 wrote:

One possible issue is if you have a search function or other reason that a GET request would be (correctly) used which might possibly have characters that have to be url-encoded in order to be used, e.g.:

https://www.example.com/search?term=I+can%27t+search+this

...which would also be just as correct as...

https://www.example.com/search?term=I%22can%27t%22search%22this

Thanks for your help, Nog. Currently, all my search data is passed via POST. The link sharing portion of the site passes a shortstring, so they will only consist of a combination of 62 letters or numbers, like http://schw.im/Q7 .

My thought concerning having to change this due to an issue like you stated is maybe match against "%29" instead of simply the "%" since so far, every exploit attempt has included parentheses.

[sneakyimp]

It is to your advantage that you have written all the code. This means that you can tune your exclusion rules to your very specific circumstance.

However, there are apache mods that are built to scan for this kind of thing. I'm not sure if this is the right url, but I recall working on one project that had an apache mod (mod_security?) installed that would scan requests for injection attempts and such. We had some problems with this mod because it prevented legitimate functions of our site so we had to tune it and disable certain rules. Obviously, it's harder to write security filters that work for all sites.

There's also fail2ban, which I strongly recommend. It does a great deal to secure your machine and it supports a variety of log sans (apache, ssh, etc.) that can help secure your machine.

As for excluding percent chars, Nog has a good point. You might get away with filtering all such requests, but you might also hamper your site's functionality in certain ways that are possibly hard to detect.

Lastly, I would suggest that you send an appropriate HTTP response code like 404 not found or 410 gone or something when you detect someone being a jerk.

[schwim]

Hi there Sneaky and thanks a bunch for your thoughts.

I've had to have the host remove and modify a few modsec rules that were stopping legitimate traffic, so I do know that it's enabled on the server my site resides on, but it hasn't stopped any of the type of requests that I've posted an example of here. I'm not sure if it's even supposed to. I will have to do a little learning on the matter.

I have never heard of fail2ban, but I will read up on it. I did find it a bit humorous that an entity that is going to help me protect my site from malicious use had to completely disable user registration on their wiki because they couldn't control the bot registrations.

I will most definitely push a 404 on the pages. I've overlooked that completely.