Recently, while browsing these forums regarding the 'strange' errors thrown by PHPIDS on the logs, I noticed that this package — which, as far as I can understand, seems to be mandatory — has been abandoned by its sole maintainer, Ananda Krishna, precisely one month before it was introduced in ISPConfig3. Obviously, at the time, nobody could even imagine that the September 2014 version would be the last version of PHPIDS... ever. PHPIDS was designed to run under PHP 5.6. It seems to be possible to run it under 7.4, however, since that's what ISPConfig3 uses (for now). But the road to the future is unclear. There have been some forks of PHPIDS, maintained for a while, but long since abandoned; the most 'recent' version is from circa 2019, and may not even be fully compatible with the PHPIDS configuration. Also, it makes little sense to replace a deprecated package with a different deprecated package. Having an intrusion detection system for PHP applications makes a lot of sense — perhaps even more so now than back in 2014 — and even if it's just 'advisory' (and very cryptic in its 'warnings'), it's clearly much better than nothing. Old hacking scripts are still being used all the time by wannabe hackers and 'script kiddies', and they can be annoying, especially if they do manage to break into old parts of someone's code. On the flip side of the coin, having an 'unupgradable' component of ISPConfig3 around, means that ISPConfig3 itself cannot be fully upgraded to work under contemporary (and not EOL!) versions of PHP — which is especially important now that the PHP core team is back on track with their major-releases-every-two-years roadmap, after (almost) 20 years of sticking with the PHP 5.X codebase. PHP 9 and 10 are just around the corner, lurking, waiting to jump on those who have been neglected their own code for far too long In my experience, there is a huge amount of work to do to move PHP code to at least satisfy PHP 5.6 (with warnings), to get it ready for 7.0 (where warnings become errors). 7.1, 7.2 etc. will just flag more and more warnings as errors, and some functionality might not work exactly as intended; finally, starting with 8.0, what were errors in 7.X become deprecated functions, which will simply panic and abort the script. Not taking those pesky warnings into account leads to code that becomes impossible to maintain if you skip a few major versions. This is the case of PHPIDS today. I have not the slightest idea if the ISPConfig3 core developer team is keeping PHPIDS up to date with recent PHP versions (and guys, if you are, be nice and release it as pull requests on GitHub, under the LGPL-3.0). But one thing is having PHPIDS running under 7.X or even 8.X; the other is having PHPIDS being useful in its current, outdated form. I'm not really sure about that. There might be still good reasons to keep it around. There might really be no alternatives — as said, some PHPIDS fans have been searching for active forks or even completely different packages doing the same kind of analysis — and failing to find anything worthwhile. Or there might be a few around, which, however, would require a new integration with ISPConfig3. I think that the best solution for now is to either completely drop PHPIDS from ISPConfig3 or make it an option that could be turned off by the administrator. There seems to be such an option on the configuration stored inside the database (they must have been loaded from /usr/local/ispconfig/security/security_settings.ini), but I have no idea if (or how!) it works: in my case, although I have ids_enabled=no, PHPIDS still seems to be operational; then again, ids_anon_enabled=yes and ids_user_enabled=yes, so I guess this somehow overrides the first? The security/README.txt doesn't say... Anyway, I have placed a suggestion/feature request on ISPConfig3's GitLab (#6499).
Could you add some paragraphs/line-breaks to your text, because right now it really is difficult to read the text. Regarding the topic: I've never really/actively used/monitored the PHP-IDS feature. One reason is that I run the listen port on a different port than port 8080, so the risk of potential attacks are already reduced due to this change and in the rare occasions when I've checked its log files, I've only found false-positives. So, I don't know how the future of the IDS in ISPConfig will look like but I wouldn't miss it, if it was removed. On the other hand, something that could be thought about is to replace it with a real WAF, but this likely will imply testing and tweaking of the rules from the core rule set, but depending on the used WAF, it's possible to just use it in a detection/logging mode only.
PHPIDS is basically just a bunch of regex rules with some PHP code wrapped around them to detect invalid requests, XSS attacks and SQL injections. These rules are still valid and are working fine, as URL and SQL syntax is stable for many years. There might be some rules for new attacks missing, though. The parts of PHPIDS that we are using are working fine in PHP 7.x and 8.x, so no updates are needed for that reason, and no reason to remove or turn off PHPIDS as it's still very useful and is not causing any issues on a correctly configured system.
There are no options in the database for the IDS, the configuration file is /usr/local/ispconfig/security/security_settings.ini To turn off IDS for requests from not logged in users, set: ids_anon_enabled=no To turn off IDS for logged in users, set: ids_user_enabled=no The option ids_enabled=no exists only in the readme and is not used, I removed it from there now.