4 ms·

Look at modsecurity.org. That's what people call (rightly or wrongly) a web application firewall. You can put a bunch of rules in and if it seens certainly ba

Look at modsecurity.org. That's what people call (rightly or wrongly) a web application firewall. You can put a bunch of rules in and if it seens certainly bad incoming requests or certain outgoing requests (all of which are configurable) it'll take whatever action you've got configured. For example, if you try and submit javascript tags to my websites, they'll just drop the connection. SQL injection attempts (at least, very obvious ones) are also logged and dropped. There are commerical hardware devices that'll do the same sort of thing modsecurity does - I guess it's being suggested Sony didn't use any, which IMHO is very stupid. If you look at the definition of firewall, modsecurity seems to fit it: "A firewall is a part of a computer system or network that is designed to block unauthorized access while permitting authorized communications." I don't think the term is being abused, just used in a way that people aren't familiar with. Most people seem to think a firewall is only a network (IP or Ethernet) level device.

Sephr 15y ago
What if I want to actually submit JavaScript tags to your website such as in a plaintext comment in a blog, to help illustrate my comment? This is not how you handle input. You sanitize output, not filter/drop input. And by sanitize, I mean encode safely for the medium, not just completely block anything unsafe before encoding.
- muppetman 15y ago
  Like any firewall, you write the correct rules for it! Allow what you want to allow and block what you don't. 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.
- Jach 15y ago
  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.
  - muppetman 15y ago
    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.
    - chc 15y ago
      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.
    - seanp2k 15y ago
      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).
- jrockway 15y ago
  mod_security is a hack that you put in front of hacks to make them collapse in a more amusing manner. The idea is to stop the dumbest of dumb attacks. 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.
  - muppetman 15y ago
    I'd much rather put up some barriers that'll make it harder for the hackers. I'm not saying modsecurity (or anything else) is a perfect prevention, but combined with other things I can't see how you can argue it's _not_ useful. Are you so confident in your sanitized inputs that you run your webserver as root? 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.
    - jrockway 15y ago
      I agree; I always design my software with as many failsafes as possible. For example, I design my applications to crash safely. But, I also try to make sure they never crash. 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.
      - 15y ago
phillijw 15y ago
Isn't that an IDS? Intrusion detection system

Sephr 15y ago

What if I want to actually submit JavaScript tags to your website such as in a plaintext comment in a blog, to help illustrate my comment? This is not how you handle input. You sanitize output, not filter/drop input. And by sanitize, I mean encode safely for the medium, not just completely block anything unsafe before encoding.

muppetman 15y ago
Like any firewall, you write the correct rules for it! Allow what you want to allow and block what you don't. 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.
Jach 15y ago
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.
- muppetman 15y ago
  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.
  - chc 15y ago
    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.
  - seanp2k 15y ago
    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).
jrockway 15y ago
mod_security is a hack that you put in front of hacks to make them collapse in a more amusing manner. The idea is to stop the dumbest of dumb attacks. 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.
- muppetman 15y ago
  I'd much rather put up some barriers that'll make it harder for the hackers. I'm not saying modsecurity (or anything else) is a perfect prevention, but combined with other things I can't see how you can argue it's _not_ useful. Are you so confident in your sanitized inputs that you run your webserver as root? 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.
  - jrockway 15y ago
    I agree; I always design my software with as many failsafes as possible. For example, I design my applications to crash safely. But, I also try to make sure they never crash. 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.
    - 15y ago

phillijw 15y ago

Isn't that an IDS? Intrusion detection system