FirewallScript - does it work?

This new firewall script (http://firewallscript.com) seems almost too good to be true - it's a simple PHP script that prevents your site from being hacked.

Anyone else see this? or even better, use it?

 

Security is a very complex task, and unfortunately there's a lot more to worry about. I never used that script and know nothing about it, though. The script is closed source so I can't even figure out what it is doing. In many cases it may even end up that your site will be less secure, since the script itself may be attacked by hackers.

BTW, I like your blog alot

 

Get PHPIDS if you're interested into securing your scripts. It's open source and free. Of course this won't stop all the attacks but at least will help. You can read more about it here too. Remember that the only way to secure your port 80 is by having a security professional review your code or at least review your website. If you're interested PM me

 

It's only an IDS, Intrusion Detection System.
It will do nothing by itself - at most it will alert you so that you can react.

I am really doubtful on the real world efficacity of such solution. Most hackers are operating from all over the world and they might hack your website while you are sleeping for example. When you'll be waking up in the morning it will be too late.

The way to secure a server is typically not to install plenty of additional software. It's to review and secure the already installed software. Try to use only well known apps, preferably open source ones. Install chroot jails, persmission hardening stuff such as grsec or selinux, periodically audit your website/scripts/..., and if you can... hire a pentester for a blackbox and a whitebox penetration test.

 

I totally agree.

If you want a high degree of security you may use SELinux with the strict policy enforced, very strict settings of the httpd related sebooleans, and a full audit system. Furhermore, use only well known software. Then also, in the case you are using PHP-code, disable unsecure PHP-functions with the "disable_functions =" in php.ini, and configure your web server to block threats that are specific to your CMS/blog-system. You may also set up very limited rights for the database user.


However, If you for any reason want some kind of application level filtering to protect your site. I would suggest widely used well known solutions like mod_security.

 

Ok, you're really missing the point here.
An IDS can react however you want, not only manually.
Detection means that, according to score for the attack you can choose to block it, redirect, close the session, ban the ip, bomb the town of the hacker and so on. I own a website that has at least 120 hackers everyday trying to hack it. I audited my scripts since I'm a security professional and I installed phpids as a further layer of security.
You don't need to stay up all night to have a reaction. It can act as a firewall, even if it has nothing to do with web application firewall that can work from Layer 3 to 7 adding the banned ip addresses to a blacklist, resetting the connection at tcp level much before they come to your web server thus avoiding useless cpu cycles spent to deal with attacks.
If you can't afford a real pen tester it's at least a good (free) solution for you.

 

I just had a quick look around their website and forums looking for anything on how this script actually works. (The best I found was here: http://firewallscript.com/forums/work-t34.html) and I will have to agree completely with drno. Security is complex and adding a new script may only make it more complex.

Specifically, there appear to be a number of possibilities this script does not account for:

1. The script runs in PHP and therefore can only protect you from badly written PHP code. It will not protect you from security vulnerabilities in Apache, PHP itself, MySQL or your operating system.
   
2. The script "sanitises" all input. To do this it must be changing your input in an unknown way which could break your site. As an example, if your script uses htmlentities() to sanitise input that becomes HTML output and this script does the same thing then the input may end up being double-encoded which would leave & on your page instead of &.
   
3. The script must be sanitising for all known attack vectors. This means that it would have to sanitise characters that have a sepcial meaning in HTML and characters that have a special meaning in SQL and characters that have a special meaning in Bash and so on for every application the input could conceivably be passed on to. This is infeasible because: a) the script can't possibly know all attack vectors - I may have made my own scripting language in PHP that has unique special characters and b) the characters < and " have no special meaning in SQL whereas ' and % have no special meaning in HTML. Which one are they filtering for ?
   
4. It is unclear how the filtering works. Do they place a backslash in front of an apostrophe or put another apostrophe in front of it ? Do they run htmlentities() over the input ? What will that do if the input is passed to Bash instead of an HTML page ? Do they strip out "bad" characters by removing them or by replacing them with harmless characters ?
   
5. The script appears to have rulesets. In fact, it says that if you install it without any rules then it won't be effective. This means that you will still have to manage your own security and understand the implications of any rule you write or omit. If you miss one rule you may be leaving an opening.

This script looks to me like a framework for adding configurable filtering and sanitising of input to all PHP scripts with pre-configured rulesets for common applications.

When you look at it that way, it is a good addition to your security but it is no silver bullet. It may catch an attack that the developers of your application didn't think of but the chances are that if they didn't think of it then no one will have written a rule for it either.

Lastly, the script is still falling into that age-old trap of enumerating badness. Even if I assume that they have done everything in the best possible way, (I have to make assumptions because they don't give us very much information about what they are actually doing) they are still trying to look for X and Y and Z and block them rather than allowing P through and blocking everything else.

The proper way to implement input sanitising is to define all allowable input (often using a regular expression) for the specific use the input is about to be put to on the very line of code before the input is handed over to the application.

 

Script looks worthless imho. Secure your server and scripts seperately.