FAQ
Here you can find answers on frequently asked questions about the PHPIDS, its installation and usage, tricks and tweaks and basic troubleshooting. If you’re missing an important answer just drop us a line in the forum.
You can also use the generated documentation – which you find here.
What kinds of attacks are detected by the PHPIDS
Currently the PHPIDS detects all sorts of XSS, SQL Injection, header injection, directory traversal, RFE/LFI, DoS and LDAP attacks. Through special conversion algorithms the PHPIDS is even able to detect heavily obfuscated attacks – this covers several charsets like UTF-7, entities of all forms – such as JavaScript Unicode, decimal- and hex-entities as well as comment obfuscation, obfuscation through concatenation, shell code and many other variants.
Furthermore the PHPIDS is able to detect yet unknown attack patterns with the PHPIDS Centrifuge component. This component does in depth string analysis and measurement and detects about 85% to 90% of all tested vectors given a minimum length of 25 characters.
What’s required to run the PHPIDS
You need at least PHP 5.1.2 to use all features of the PHPIDS. Depending on which kind of logging and caching you chose you might need a database that is able to work together with PDO. SimpleXML is required if you wish to use the XML based filter rules – if your system doesn’t provide SimpleXML you can use the fallback JSON based rules. A nice to have for the generic attack detection is Unicode support for the PCRE engine. The PHP packages shipped with current distributions should fulfill all requirements out-of-the-box.
How to install the PHPIDS?
Just download the package – unpack it in your application or include folder. For productive usage you only need the phpids-0.x/lib folder – it includes the filter rules and the PHPIDS core. By watching the examples in the phpids-0.x/docs/examples folder you should get good information on how to install the PHPIDS, perform logging and special configuring etc. You can also open this file directly in your browser when having the PHPIDS running inside a webroot. It’s configured to run out of the box.
How to use it in my application?
You can use the following code to include the PHPIDS and have access to the result object:
require_once 'IDS/Init.php';
$request = array(
'REQUEST' => $_REQUEST,
'GET' => $_GET,
'POST' => $_POST,
'COOKIE' => $_COOKIE
);
$init = IDS_Init::init('IDS/Config/Config.ini');
$ids = new IDS_Monitor($request, $init);
$result = $ids->run();
if (!$result->isEmpty()) {
// Take a look at the result object
echo $result;
}
Keep in mind that you might want to change the order of the arrays to merge if you don’t use the default variables_order EGPCS.
How to configure the PHPIDS
You can configure all important values in the Config/Config.ini. The settings should work out of the box most times but then and when you might want to tweak the paths or change the way of how the PHPIDS uses caching.
As mentioned before the example.php gives great advise in hard-configuring the PHPIDS if the Config.ini won’t work for you for whatever reasons. Just check the sources.
Filter/Storage/Abstract.php wasn’t found?
That’s a typical error when the PHPIDS is not located in the root of an include folder. You can just solve that problem with using the set_include_path() function. Point it to the folder the IDS folder is located in and everything should work fine.
How to work with the impact?
The impact indicates the severity of the attack. The PHPIDS brings around 50 filter rules to detect attacks and each one of them has an impact – the more rules match on the incoming data, the more likely it’s an attack and the higher ranks the resulting impact.
The impact can be received by using the $result->getImpact() on the result object.
You can store the impact as session value, if you want to track an attackers activity for some time and wish to react later – when session impact has risen to 50 or 100. A usual very first attack impact is around 5 – 10 – sometimes 15 -20. A typical XSS probing monitored by session based impact usually results in an impact of 50 – 150. So it’s pretty easy to separate the false alerts from the real attacks using session based impact.
What can be done in case the impact is very high?
There are several ways to react on high (around 15) or very high (around 25-50) impact – first and easiest would be a hard redirect – the suspicious user could be redirected to a warning page which tells him that the application considered his input malicious and asks him to stop. Meanwhile all important parameters of the user can be logged and used for forensics. Another effective way would be to destroy the users session.
Basically the PHPIDS leaves the choice on what to do up to you. If you found a smart way of defending your application in case of very high impact feel free to let other users know via our forum.
What about performance issues?
The PHPIDS is being developed under constant profiling with xdebug and performance measurements to make sure that your application will not become noticeably slower. Only request parameters are checked whose values inhabits characters besides a-Z, 0-9, @ and _.
Furthermore modules like the HTML parser are only included and used in case there is input coming in with a key matching the ones given in the Config.ini / via $monitor->setHtml() for content with HTML allowed. So the performance hungry components normally won’t be loaded during about 95% of all requests.
How to get information about new releases?
Just subscribe to our newsfeed. By the way – the API is not going to change in the coming releases – if yes it will pointed out prominently in the news and the forum.
