I actually had that problem with my blog, only with "SQL Injection" being picked up. If I wrote a post (or someone else a comment) that had the word "from" in a paragraph, it would commonly reject it entirely with an unhelpful "error 500". One post had 1 = 1^3 as part of a demonstrated proof, and the regex must have picked up "1 = 1" and rejected it. I concluded mod_security is stupid. And since I'm on shared hosting, I couldn't reconfigure it, so I solved the issue by base64 encoding all input with JavaScript before sending it.
That's really stupid, I agree.
But if your webhost was also dumb enough to block port 25 outbound on their firewall, would you say that Netscreen Firewalls are stupid?
A firewall is only as good as the rules the admins have deployed on it. Deploying tight rules like that on shared hosting is very stupid, but the rules used and modsecurity itself are two separate things.
The thing is, there are ports you might legitimately want to block. For sites where users submit data, there is seldom any easily definable text you really need to stop them from submitting unless your underlying app is made out of toothpicks and chewing gum.
But if your webhost was also dumb enough to block port 25 outbound on their firewall, would you say that Netscreen Firewalls are stupid?
Blocking outbound port 25 has legit uses, it keeps from being able to submit mail with the only information about the source of the mail being the IP address. Port 25 is meant for MTA to MTA mail transfers. Outbound 587, named "submission" is the port you can connect to at your email service provider to drop off outbound mail. This port is required to support authentication before accepting mail. This provides an additional layer of auditing and access control, and thus a way to easily turn off problem senders, on a per-account basis, should the need arise.
A smart webhost would block outbound port 25 and require you to send mail authenticated through an MTA provided for the purpose. But of course, chances are most people here are not using purely "web hosting services", but rather dedicated machines or VMs that run their own MTAs. However, any decent MTA can be configured to use a relay host and authentication, which is fine unless you're sending massive volumes of email (in which case, why are you sending it from a rinkydink webhost or single VM?)
Port 80, port 443, port whatever-you-need-to-not-be-blocked.
You can't blame the Netscreen Firewall for doing what it was told - that's my point. mod_security isn't dumb, stupid, annoying. The rulset deployed can be.
I was responding to the side point about someone being "dumb" for blocking port 25. My response offers no opinion on the quality of firewall software, Netscreen branded or not.
Webhosting sysadmin here, we start off with a strict ruleset for mod_security and then add exceptions as needed....they really stick out in the per-vhost error log, so it takes all of about 5 minutes to fix. We err on the side of caution, and the set we use allows the majority of sites to operate without issue. We'd rather spend 10 minutes on a ticket explaining to the customer that it's just us being overly cautious than any real issue. We have to weigh risk mitigation vs usability.
Also, probably >95% of the "website hacks" I see are automated, so mod_security really does greatly cut down on the number of exploits. Sure, if you have a dedicated hacker who knows his or her way around things like modsec, then it won't matter at all, but the number of hacks we've seen has decreased greatly due to mod_security. You only get into trouble with it if you pretend that it's anything more than it is: regex filtering for requests.
To the guy talking about validating input...perhaps you should spend a bit more time on the internet and notice all the sites running copies of WordPress with defaults. This is how the vast majority of websites are...default everything. Input validation is great if you have a custom app and a development team, but most people don't. While it's arguable that they should even be running their own site, it doesn't change the fact that they do. They don't have time, and we don't have time to go through all of their PHP that accepts _GET and _POST and make sure that they're handling input validation / sanitation properly. Yes, the people who develop wordpress / whatever CMS they're using should set some good defaults for input validation and use proper sanitation techniques, but the truth is that tons of sites run on shaky code bases and old versions...so mod_security is the "quick fix" that covers the vast majority of cases and protects tons of our users.
suPHP is great too (privilege separation). Combined with jailkit, our systems are pretty well locked down for shared hosting.
That all said, Sony SERIOUSLY screwed this up. Their system should have better secured the Cardholder Data Environment (the PCI-DSS name for any system that touches CC info). My guess would be poor architecture planning / implementation as to why this obviously wasn't done. Also, mod_security has some filters for data leakage which can be tweaked to prevent obvious HIPAA stuff and obvious PCI-DSS stuff, such as plaintext transfer of zillions of CC numbers. If a skilled hacker broke into this, he/she again could pretty easily find a way around this.
Network firewalls probably wouldn't have helped much in this case, unless they did something really stupid like leaving SSH open to the world. If it was just a site exploit, shame on them for having such a poor system (shame on them anyway for setting up a system that allows this to happen).
Just a caveat, I do not believe these were PCI cards. The European cards were probably bank cards or prop cards not subject to PCI. (all this is a guess) I would guess, again, that it was probably related to a legacy system from some integration of a purchased company.
