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.
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?)
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).
People after 20 million credit card numbers can probably find two bugs to exploit, rendering the "protection" useless.
People trying to protect 20 million credit card numbers need to learn how to sanitize inputs and be able to render correct pages even if someone submits <script>'drop database. If they don't know how, it's time to hire programmers to write your applications instead of the monkeys you currently have.
I have it deployed on sites where people are using Drupal and Wordpress with addon modules. I have at least 2 documented cases where it's stopped an exploit that would otherwise have gotten through (though I'm fairly sure the setup of the webserver would have stopped anything bad from happening)
Your last sentence seems to be suggesting I was supporting a "just chuck modsecurity in front of it and don't worry about security" attitude, which I wasn't at all. All my original reply was trying to say is that an Application Level Firewall is still a firewall.
Similarly, web application developers need to make sure that their app is 100% safe without hacks like mod_security. But after you do that, sure, turn on mod_security. People and processes can fail, and it's good to have as many failsafes as possible.
I object to things like mod_security because, in general, people write piece of shit apps and then think they are safe because the mod has the word "security" in it. That doesn't make you safe, that makes you ignorant.
I don't see what the first half of this sentence has to do with the second. No, I will not run my webserver as root but that has literally nothing to do with sanitizing input.
I was just giving examples, the rules themselves are quite complex, same as with most firewalls but even more so with the variation of good/bad code out there! It's an impossible game.
That, however, wasn't my point. My point is a firewall doesn't just have to refer to a network device as the OP (seems to) suggsest.
