Skip to main content

Issues with modsecurity OWASP and false positives.

Comments

41 comments

  • Spork Schivago
    I mean I think the proper fix would be to figure out what scripts are causing this and just add a proper user agent and header field. I think I posted about this a long time ago but never really got that far with it. Any help is greatly appreciated. It is extremely hard finding real attacks when the log file is filled with these posts!!!! They come very often and are very frequent. I don't want to disable the rule completely because that makes my system more vulnerable. I just want to whitelist the stuff from 127.0.0.1, optimally, when we know for certain it's from a cPanel script. Thanks!
    0
  • cPanelMichael
    Hello, It's important to understand the risks involved with using the OWASP ruleset. We document the risks at: OWASP ModSecurity CRS - cPanel Knowledge Base - cPanel Documentation Also, one thread I recommend checking out is: OWASP - mod security and wordpress Though it's regarding WordPress, it includes several posts related to excluding rules that you may find helpful. Let us know if you have additional questions. Thank you.
    0
  • keat63
    I found that I had to disable a small number of rules, 960015 being one of them. I have no idea what any of them do, and I've no idea whether they are false positives or real ones. I'm literally working on the basis that any rules left intact are helping to protect us, which is better than having none at all.
    0
  • Spork Schivago
    I found that I had to disable a small number of rules, 960015 being one of them. I have no idea what any of them do, and I've no idea whether they are false positives or real ones. I'm literally working on the basis that any rules left intact are helping to protect us, which is better than having none at all.

    This is something I considered and didn't want to do. From looking at the contents of the REQUEST-01-COMMON-EXCEPTIONS.conf file, it seems modsecurity is extremely configurable and I should be able to write a custom rule that says something like, If the client is 127.0.0.1 AND it's missing the user agent or the header, AND it's trying to access /whm-server-status, let it through. Or if I could whitelist based on the MAC address and the IP, plus the other stuff, that'd be great. The problem is I'm not very familiar with modsecurity and I have googled a good bit and read a good bit of information but I don't think a lot of users who run it really know a lot about it. It comes with cPanel and cPanel includes the OWASP rule set by default. I think most people probably just enable it and might not even ever look at log files or know where they're located or any of that. I've seen many posts saying I fixed this by disabling this rule. And although that would work, don't get me wrong, it'd also disable that rule for real threats, you know what I'm saying? There's got to be a way to just write a custom rule in that file and get it to ignore the cPanel stuff. If I could figure out what script was causing the issues, I would just try and modify it myself. It might not be a script though, it might be a compiled executable. You know, binary. And without the source, there's not much I could do there. That'd be something cPanel would have to do. I'm going to read the links that cPanelMichael posted. Perhaps there's something in them besides disabling the actual rule. Thanks.
    0
  • Spork Schivago
    Just in case anyone runs into this issue, I've added a new rule to the /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf file. I think perhaps this is better than completely disabling the rules that are causing the false positives. This is what I added:
    # # Exception for cPanel whm-server-status check. # SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,id:'981022',ctl:ruleEngine=off
    This not only stopped the error messages about the whm-server-status stuff but all the other false positives (I think maybe three or four in total) from appearing. It allows all traffic from 127.0.0.1. I think someone with a little more knowledge could perhaps fine tune this a bit more and specifically write it just so it whitelists stuff from 127.0.0.1 if it's trying to pull in whm-server-status or if we know for certain it's a cPanel script. Can anyone think of any negative effects this rule might have? I was thinking a hacker could try spoofing their IP address to 127.0.0.1, but I don't see what could that'd do. I don't see how they'd be able to connect to my server at all. And what would my server do? Respond to itself...I honestly can't see this having any negative side effects, but what do you guys think? Also, shouldn't something like this be in the REQUEST-01-COMMON-EXCEPTIONS.conf file? My understanding is everyone with a server running cPanel with mod_security enabled have this issue and most people are just disabling the rule.
    0
  • quizknows
    Generally you should be OK whitelisting the localhost IP (127.0.0.1). The only way an attacker could legitimately send requests from localhost is if they were already operating in a hacked site on your server, in which case, you have bigger problems. Spoofing an IP is really only relevant (typically) for syn floods, UDP attacks / DNS reflections... DDoS attacks basically. If you wanted to allow it only for whm-server-status you can add additional conditions for a match with the "chain" feature, like this:
    SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,chain,id:'981022',ctl:ruleEngine=off SecRule REQUEST_URI "whm-server-status"
    This would make it so the request has to come from localhost AND be going to that URI to qualify for your "allow" action for the rule.
    0
  • Spork Schivago
    Generally you should be OK whitelisting the localhost IP (127.0.0.1). The only way an attacker could legitimately send requests from localhost is if they were already operating in a hacked site on your server, in which case, you have bigger problems. Spoofing an IP is really only relevant (typically) for syn floods, UDP attacks / DNS reflections... DDoS attacks basically. If you wanted to allow it only for whm-server-status you can add additional conditions for a match with the "chain" feature, like this:
    SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,chain,id:'981022',ctl:ruleEngine=off SecRule REQUEST_URI "whm-server-status"
    This would make it so the request has to come from localhost AND be going to that URI to qualify for your "allow" action for the rule.

    That's awesome! Thank you for sharing!!! There's more than one rule getting triggered but they're all from cPanel. I think cPanel should update the rules with something like we have here (there's already two rules in that file for cPanel stuff I believe but don't quote me) or change the script / program so it doesn't cause the false positives. I mean, honestly, the way it is by default just isn't right. It doesn't really cause physical problems but it makes it a lot harder going through logs because of how often this happens. The whm-server-status seems to happen once per minute. That adds up to a lot of log entries! It's very easy to miss real stuff. What's a DNS reflection? I couldn't think of anyway whitelisting the local loopback could hurt, I tried thinking of cases too....all I could come up with DDoS attacks, but generally, I don't think there's really a lot you can do to prevent those types of attacks via software anyway. There was another way I thought spoofing an IP could help an attack. What happens if I found away to spoof my IP to some random address and then I tried a bunch of exploits....and every one I tried, I assumed they went through and setup a remote shell so I could connect or something. Would something like that work? Would the server just ignore the packet or would it process it, even though I personally wouldn't get anything back on my end...I would this is one of the points of handshakes or something, right? To make sure the communications are two-way, with TCP I mean. Thanks for helping!
    0
  • quizknows
    Like I said, whitelisting 127.0.0.1 is not a huge risk. You are right, OWASP could certainly be better "off the bat." It's a shame that it isn't, and seems to not have improved much in recent months/years. DNS reflections are attacks carried out by sending a packet with a spoofed source address to many DNS servers, so that the replies all go to whoever's IP is being spoofed as the source. This is made easier because DNS uses UDP, and UDP is not as robust as TCP in regards to handshakes etc. It pretty much just spews data and hopes that it gets there. Since protocols like HTTP use TCP, You're not going to be able to simply spoof your address for webapp attacks... the initial TCP SYN would get there and that's about it. Like you said that's where the handshake comes into play.
    0
  • Spork Schivago
    Like I said, whitelisting 127.0.0.1 is not a huge risk. You are right, OWASP could certainly be better "off the bat." It's a shame that it isn't, and seems to not have improved much in recent months/years. DNS reflections are attacks carried out by sending a packet with a spoofed source address to many DNS servers, so that the replies all go to whoever's IP is being spoofed as the source. This is made easier because DNS uses UDP, and UDP is not as robust as TCP in regards to handshakes etc. It pretty much just spews data and hopes that it gets there. Since protocols like HTTP use TCP, You're not going to be able to simply spoof your address for webapp attacks... the initial TCP SYN would get there and that's about it. Like you said that's where the handshake comes into play.

    I gotcha. Thanks for the information. Are only authoritative DNS servers prone to DNS reflections? If not, is there a good document on how I could work on "hardening" bind? Thanks.
    0
  • quizknows
    Generally as long as you are not an open resolver (allowing recursion) you are fine. You can check by performing a lookup for a domain you do not manage and ensuring your nameserver does not return a response, i.e. #dig not-your-site.com @your.server.ip.address if you get a proper response back (be sure to try a domain that actually exists, like google.com or something) then you need to disable or restrict recursion in your named (bind) config.
    0
  • Spork Schivago
    Generally as long as you are not an open resolver (allowing recursion) you are fine. You can check by performing a lookup for a domain you do not manage and ensuring your nameserver does not return a response, i.e. #dig not-your-site.com @your.server.ip.address if you get a proper response back (be sure to try a domain that actually exists, like google.com or something) then you need to disable or restrict recursion in your named (bind) config.

    Good to go! I ran dig on google.com and received QUERY: 1, ANSWER: 0 WARNING: recursion requested but not available. Thanks for sharing!
    0
  • keat63
    any chance of a dummies guide on what you did please. ?
    0
  • quizknows
    Keat63, basically just make sure recursion is disabled in the options section of named.conf like this:
    options { allow-recursion { none; }; allow-transfer { none; }; };
    You may have other options in there but as long as allow-recursion is set to none (or a trusted ACL but that's more advanced) you should not be used in DNS reflection attacks.
    0
  • keat63
    Yesterday, I looked at the recursion thing and added those entries to the options section, but got errors relating to recursion being unknown when i restarted DNS. So Instead I searched named.conf and found 2 entries relating to recursion='yes', I changed these to 'no', then monitored the server. DIG revealed no recursion, and i saw no detrimental effects, that i'm aware of. Domains seem intact and running, no apparent disruption to emails. So provided this is still the case and that i've not done anything stupid, could someone talk me through making the changes to OWASP.
    0
  • Spork Schivago
    ...So provided this is still the case and that i've not done anything stupid, could someone talk me through making the changes to OWASP.

    Yup. Since you were able to edit the named.conf file manually, I'm going to assume you have shell access and know how to edit files via your shell access. Edit the file:
    /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf
    I use nano, so for me, I type:
    nano -w /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf
    At the very bottom of that file, copy and paste (or type this):
    # # Exception for cPanel whm-server-status check. # SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,id:'981022',ctl:ruleEngine=off
    If you type it, be extremely careful and make sure you type it exactly like that. Save the file (in nano, hit CTRL-X and enter). You might need to restart Apache, I'm not certain. For my CentOS system, to restart Apache, I type:
    service httpd restart
    Because I'm on v58, there's a bug that I discovered and that command might not work. So, if that command gives you some stuff about PID not being found or httpd is already running or something like that, use the cPanel script.
    /scripts/restartsrv_apache
    After that, you should be good.
    0
  • Spork Schivago
    Yesterday, I looked at the recursion thing and added those entries to the options section, but got errors relating to recursion being unknown when i restarted DNS. So Instead I searched named.conf and found 2 entries relating to recursion='yes', I changed these to 'no', then monitored the server. DIG revealed no recursion, and i saw no detrimental effects, that i'm aware of. Domains seem intact and running, no apparent disruption to emails...

    I believe you should do more than just set recursion=no. In /etc/named.conf, where you found the recursion=no, in that section, if you scroll down to the bottom of that section (not the file), you should see something like:
    pid-file "/var/run/named/named.pid"; dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; /* memstatistics-file "data/named_mem_stats.txt";
    This is where I made my changes. I also hid my version of named to make it a bit harder for hackers to get in. This is what my section looks like:
    pid-file "/var/run/named/named.pid"; dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; /* memstatistics-file "data/named_mem_stats.txt"; allow-transfer { "none"; }; allow-recursion { "none"; }; /* Hide the version number so it's harder to attack us. */ version none;
    Afterwards, you can check the config file to make sure you typed everything correctly:
    named-checkconf /etc/named.conf
    If it doesn't give you any errors, restart named. On CentOS, I'd do this by running:
    service named restart
    I hope this helps.
    0
  • keat63
    I'm pretty much tied up for a short while, so I'll look at this when I can dedicate some monitoring time and can quickly react to any issues. Thanks
    0
  • Spork Schivago
    Okay Keat63. Please keep me updated with your progress and let me know if you have any trouble.
    0
  • rclemings
    I'm having some trouble dealing with two false positives. This is cPanel's implementation of OWASP ver.3.0.0, as nearly as I can tell (from /etc/apache2/conf.d/modsec_vendor_configs/OWASP/modsecurity_crs_10_setup.conf). I've masked some possibly sensitive data.
    523939:[Thu Dec 01 10:25:39.244073 2016] [:error] [pid 24880] [client xx.xx.xxx.xxx] ModSecurity: Access denied with redirection to Example Domain using status 302 (phase 2). Pattern match "\\\\%((?!$|\\\\W)|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:returnUrl. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"> [line "219"> [id "950109"> [rev "2"> [msg "Multiple URL Encoding Detected"> [severity "WARNING"> [ver "OWASP_CRS/3.0.0"> [maturity "6"> [accuracy "8"> [tag "Host: www.example.com"> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-protocol"> [tag "OWASP_CRS/PROTOCOL_VIOLATION/EVASION"> [hostname "www.example.com"> [uri "/xxx.php"> [unique_id "WEBA83cQjKbwhNpTYWkudQAAAAQ"> 526747:[Thu Dec 01 10:41:28.958952 2016] [:error] [pid 26285] [client xx.xx.xxx.xxx] ModSecurity: Access denied with redirection to Example Domain using status 302 (phase 2). Match of "beginsWith %{request_headers.host}" against "TX:1" required. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP/rules/REQUEST-31-APPLICATION-ATTACK-RFI.conf"> [line "30"> [id "950120"> [rev "3"> [msg "Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link"> [data "Matched Data: https://another.example.com/a/account/validatethirdpartycorporateauthresult?redirectUrl=http://another.example.com/a found within TX:1: another.example.com/a/account/validatethirdpartycorporateauthresult?redirectUrl=http:%2F%2Fanother.example.com%2Fa"> [severity "CRITICAL"> [ver "OWASP_CRS/3.0.0"> [maturity "9"> [accuracy "9"> [tag "Host: www.example.com"> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-remote file inclusion"> [tag "OWASP_CRS/WEB_ATTACK/RFI"> [hostname "www.example.com"> [uri "/xxx.php"> [unique_id "WEBEqF9us8Ws-b6n3kgKmAAAAAI">
    I've confirmed that those rules are the problem by temporarily disabling them, but I would like to create an exception instead. I am trying to use the "add rule" function in cPanel's WHM/Security Center/ModSecurity/Tools/Rules List. Here is what I'm trying to add (singly and both at once): SecRuleUpdateTargetById 950109 !ARGS:'another.example.com' SecRuleUpdateTargetByID 950120 !ARGS_NAMES:'another.example.com' When I try to save and deploy, here is what I get in the cPanel error log:
    [2016-12-01 16:09:21 -0500] warn [xml-api] The system failed to deploy the changes for "modsec/modsec2.user.conf": The system could not validate the new Apache configuration because httpd exited with a nonzero value. Apache produced the following error: AH00526: Syntax error on line 1 of /etc/apache2/conf.d/modsec/modsec2.user.conf: Updating target by ID with no ruleset in this context
    I've tried various combinations of single quotes, double quotes, no quotes, but to no avail. The server vendor thinks it's a syntax error. Suggestions?
    0
  • rclemings
    My server vendor has now consulted with cPanel and cPanel had this to say: ----- I did confirm I am seeing the same issue when attempting to add the rules, which appear to be an issue noted here as well : SecRuleUpdateTargetById not working inside VirtualHost scope " Issue #89 " SpiderLabs/ModSecurity " GitHub This would entail that this requires the configurations be added manually in a separate configuration as you had suggested, which I added in the file the specific rule ID to be updated is present in at /etc/apache2/conf.d/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf and confirmed that it did allow the directive to be added without issue. ----- So I added my two SecRuleUpdateTargetById directives to a new file (/etc/apache2/conf.d/modsec_vendor_configs/OWASP/modsecurity_crs_20_customrules.conf) and restarted Apache. Everything works fine now. Since this bug (or whatever it is) is more than three years old, I think cPanel should note it on the "add rule" page or at least in the documentation (ModSecurity Tools - Documentation - cPanel Documentation). If that had been done already, I would have saved several hours of work.
    0
  • cPanelMichael
    Hello @rclemings, I've merged your posts with this thread. We provide documentation on the OWASP risks and it's configuration files at: OWASP ModSecurity CRS - cPanel Knowledge Base - cPanel Documentation Thank you.
    0
  • danielpmc
    Hello, There is currently a feature request asking cPanel to update the ModSecurity rules to help avoid a lot of false positives. Apparently the updated version of ModSecurity is able to prevent many false positives. Take a look at the link provided and see if this will help. cPanel Feature Request: Update ModSecurity Vendor OWASP to OWASP ModSecurity Core Rule Set (CRS) 3 danielpmc
    0
  • Spork Schivago
    Danielpmc, I still receive a lot of false positives using the current set of rules that ship with cPanel. I've whitelisted my server, which stopped one of the big ones that was showing up every minute. I wouldn't mind testing the new CRS3 ruleset, at least until it cPanel implements it. Do you know if there's any cPanel instructions on how someone like myself might be able to implement on the CRS3 ruleset on my server? I think if I could do it, it'd have to be done in such away where when cPanel gets updated, it doesn't get replaced. I'd also have to keep an eye on the cPanel changelog, so when cPanel does update the CRS to the latest version 3, I can undo my changes and just use the one that ships with cPanel. A long time ago, I found away to install a more up-to-date version of RoundCube than what was shipping with cPanel. Roundcube was fairly outdated. I downloaded, installed and configured RoundCube, Horde, and Squirrelmail with the latest versions. I think one of them I had some issues with. Anyway, I setup cPanel so whenever it installed the mail programs, it'd install my newer version, not the older versions that were shipping with cPanel. I ended up forgetting about it and one day I noticed the version that cPanel was shipping was actually newer than the version I had installed! So I would definitely have to keep an eye on the change logs for cPanel to see when the CRS3 rulesets are finally implemented. The developers seem to really be encouraging everyone to update to the CRS3 now that it's stable. I had hoped cPanel would have implemented it by now. One guy, he has a forum and someone tried typing the post, "I want to curl up by the fire". The current rulesets blocked that though, because of the word curl. It thought maybe it was some sort of attack. Just updating to CRS3 seemed to fix the issue for him. The current logs are filled with sooooo many false positives, it's almost impossible to find real threats by looking at them, so essentially, with me at least (and I suspect other admins), we simply don't look at the logs unless something has gone wrong. If the new rulesets do away with 99% of the all the false positives, than we could monitor the logs for real threats and go from there. What's sad is with all these false positives, legitimate users could be blocked from our sites and we might never even know.
    0
  • danielpmc
    Hello Spork, As far as updating OWASP ModSec to CRS3 by yourself, possibly at their site they have a method for you to try. Code/sql injections happens a lot by a registered member of a site/forum. This is where they will write code and try to submit it to the site/forum by posting or uploading. Of course, do not forget about the talented hacker throwing command lines at your server and/or site(s). As you mentioned ModSec has blocked the word Curl although it was used in a post about curling up by a fire. So how do you filter good Curl versus bad Curl word usage? Now think about a developer or techies site. They may have actual raw code samples or examples displayed on their sites. So how can ModSec even begin to filter code symbols properly? ModSec will never be a works for all security application. There are way to many gray areas for it to be all encompassing. There are thousands of Website builders, CMS, Forums etc... for it to be compatible with. But when a person throws in a half dozen or more plugins, add-ons, apps or widgets to their site that just becomes a nightmare to write security for. I think ModSec is one of those types of software that needs daily development and testing by the people that code it. That is maybe why cPanel crew does not want to get too deep into the approving and maintaining of ModSec updates. Even by using the current OWASP ModSec rules it is so time consuming for their staff to write security rules, that the internet updates faster than ModSec can. A never ending battle against the hackers. When my site goes public i will be there reading through the mass of false positives simply because its smarter to use ModSecurity than not to. danielpmc
    0
  • Spork Schivago
    Hello Spork, As far as updating OWASP ModSec to CRS3 by yourself, possibly at their site they have a method for you to try. Code/sql injections happens a lot by a registered member of a site/forum. This is where they will write code and try to submit it to the site/forum by posting or uploading. Of course, do not forget about the talented hacker throwing command lines at your server and/or site(s). As you mentioned ModSec has blocked the word Curl although it was used in a post about curling up by a fire. So how do you filter good Curl versus bad Curl word usage? Now think about a developer or techies site. They may have actual raw code samples or examples displayed on their sites. So how can ModSec even begin to filter code symbols properly? ModSec will never be a works for all security application. There are way to many gray areas for it to be all encompassing. There are thousands of Website builders, CMS, Forums etc... for it to be compatible with. But when a person throws in a half dozen or more plugins, add-ons, apps or widgets to their site that just becomes a nightmare to write security for. I think ModSec is one of those types of software that needs daily development and testing by the people that code it. That is maybe why cPanel crew does not want to get too deep into the approving and maintaining of ModSec updates. Even by using the current OWASP ModSec rules it is so time consuming for their staff to write security rules, that the internet updates faster than ModSec can. A never ending battle against the hackers. When my site goes public i will be there reading through the mass of false positives simply because its smarter to use ModSecurity than not to. danielpmc

    It's definitely not easy trying to filter out the false positives, from a programming sense, and some, you probably never could filter out completely. With curl, for example, perhaps someone could test for command line options that might be passed to curl. Running just the curl program by itself doesn't really do much, except for telling you to type --help. When you don't find a valid option being passed to curl, you could scan for what curl would return with invalid options and see if any data's coming back. But that's a whole nother headache, because now the developers have to keep an eye on curl and look for whenever new options are added or removed. It's definitely not easy. I don't think cPanel really updates the rules that often. The reason I say this, I have had that false positive (the one that gets triggered every minute) going on for I'd say over a year now, or close to it. In situations where the developer has code on their site, they could always do what I did, and whitelist the server. I couldn't see this being a problem really, but it very well might not have been the best approach. I couldn't figure out how to write a rule just for the whm-get-status stuff or whatever it was, so I decided instead of disabling the entire rule, I'd just disable it for traffic that's coming from 127.0.0.1. If I were cPanel, I'd probably look at it this way. How many tickets and forum posts do we have about issues with the current rule set? Would most of those tickets / forum posts disappear with the new rule set? What are the benefits to updating? What are the disadvantages? I think because the actual developers of ModSec and the CRS3 recommend everyone switch, including companies like cPanel, I think that isn't something they'd say lightly. I think their reasons are valid for wanting people to switch. Granted, ModSec with a ton of false positives is better than no ModSec, but when your site goes public, why not try the CRS3? Do you just like to keep a more unmodified installation of cPanel? Or do you think there are some bugs with the CRS3 that aren't fixed yet? I believe cPanel might actually be currently using a beta version of the CRS3. Perhaps now that it's stable, maybe that's the best reason out of all to update?
    0
  • danielpmc
    Hello Spork, I am only guessing, but i think cPanel crew is waiting a guarantee that the new ModSecurity rules are indeed working as best as can be, before offering the CSR3 version. ModSecurity, and also cPanel, have to take into account these scenarios when creating and updating security software. 1. A person who has decided to go beyond all the free sites and learn how to serve the internet by using cPanel. This is a beginner and generally does not know much about hacker methods and if they do, how to prevent them. ModSecurity is a wonderful security tool for a person running a site that asks/requires input from a guest/member. Such as a search box, contact form or an upload of a photo or document. I am appalled at how secure some sites are, yet have little or no filtering on the search box and contact forms. These are two areas if i was a hacker would use to create mayhem on a persons site. There are well known methods of code injections specifically used in search boxes and contact forms. This is where ModSecurity shines. It will block most injections in these areas. 2. A person who is currently serving the internet with a cPanel and thinks the only security needed is a strong password. Well this person is like an Ostrich with its head sticking in the sand. They do not think they will get hacked. But they do not understand that most hacks, in the millenial years at least, are done by automated bots. So now ModSecurity has to protect this person from all types of attacks, because they choose not to be pro-active in their site security. 3. A person who feels necessary to add multiple addons, plugins, apps and/or widgets to their site and expect them to be secure. This person thinks that unless they have a bunch of addons on their site, nobody will visit/interact/buy from their site. So they will go on the internet and find the first code they can find to make their site look like a golden palace. But they do not understand that every code added to their site is a potential door or access point for a hacker to create mayhem. So now ModSecurity has to protect them against themselves. 4. A person who is using cPanel and understands that there are multiple methods required to secure a site online. This person is like you and i and millions of others online. We understand that security is a combination of Firewalls, Server Tuning, Anti-Virus Software and lots of tweaks. But mainly we know not to add unverified or untested codes, apps etc.. to our sites. So ModSecurity is there only as an additional tool, not the only tool to rely on. As you can see ModSecurity has a lot of varied roles to fullfill, and is very difficult to keep updated in todays world of internet changes. The way i gauge if a product or tool is proper to use is by the amount of UNPAID reviews online. One or two reviews is not enough to qualify a code or tools effectiveness. When i go public with my site i will evaluate wether or not OWASP ModSecurity CRS3 is able to live up to its claim of vastly reducing its false positives. They do great work and definitely have earned my respect for their hard work and time. As a suggestion: Open a thread and ask why cPanel crew can not or will not update Modsecurity. OR Open a thread and ask how a person can update ModSec by themselves and if there are any pitfalls by doing this. danielpmc
    0
  • cPanelMichael
    Hello, I do want to note that the "Report this hit" option is available on the ModSecurity Tools page when "More" is pulled down. You also have the option to disable the rule as you submit the report. This is currently the best way to address false positives, as those reports go to the ModSecurity vendor (E.g. SpiderLabs). You can find additional discussion of this topic at: OWASP - mod security and wordpress Regarding an overall change to the frequency of rule updates and cPanel's involvement with the rule adjustments, our feature request website is the best outlet to seek those changes. Thank you.
    0
  • Spork Schivago
    Hello Spork,... As a suggestion: Open a thread and ask why cPanel crew can not or will not update Modsecurity. OR Open a thread and ask how a person can update ModSec by themselves and if there are any pitfalls by doing this. ...

    We actually have a feature request asking for this, so I think it's just a matter of time. I think maybe two of the biggest reasons cPanel hasn't implemented them yet is 1) They're busy. They're always making cPanel better, adding new features, stuff like that. I bet they have some sort of priority list and maybe the CRS3 isn't the top priority right now? But 2) Like you said, it's gotta be secure. You make a very valid point. Even though it's listed as stable, it's just finally being widely implemented on servers across the world, or, we could probably at least say a lot more people are using CRS3 now that it's out of beta testing stage. In Deposit, when I worked as a computer programmer, I'd always thoroughly test my code before putting it in production, but until it really gets out there, it's usually almost impossible to think of all the situations that can break the code. As a programmer, I always try to think of the unexpected. If my program needs the user to enter a number, make sure they enter a number and not just spell the number. Even though CRS3 is listed as stable, I bet they already have some new bugs coming in. Maybe you're right and cPanel is just waiting until the stable version becomes more stable? I know cPanel always has this policy of thoroughly testing the software before including it in their production builds. I've always kinda liked that, you know?
    0
  • Spork Schivago
    Hello, I do want to note that the "Report this hit" option is available on the ModSecurity Tools page when "More" is pulled down. You also have the option to disable the rule as you submit the report. This is currently the best way to address false positives, as those reports go to the ModSecurity vendor (E.g. SpiderLabs). You can find additional discussion of this topic at: OWASP - mod security and wordpress Regarding an overall change to the frequency of rule updates and cPanel's involvement with the rule adjustments, our feature request website is the best outlet to seek those changes. Thank you.

    I was using the feature request. I found the ModSec CRS3 rules a while back on there and voted them up and added to the discussion a bit. I don't like disabling the rules because of false positives, unless there's no other option. I feel whenever we disable a rule because of a false positive, we're essentially allowing real positives through. I've always liked the idea of trying to write a custom rule that looks for that false positive and catches it. You know what I'm saying? I'll give an example. That cPanel whm-server-status or whatever, that comes every single minute and fills the logs very quick like. There's a lot of minutes in the day. But the rule that's getting tripped, it's protecting our servers for a certain type of attack. So instead of just disabling the rule all together, try to rewrite it to exclude the whm-server-status. If we report this to SpiderLabs using the Report this hit button, if they fix the rule, how long does it take for cPanel to implement that fix? I know on the mailing lists for ModSec, when people start talking about problems with false positives, the general response is always something along the lines of, "We suggest you upgrade to CRS3. This problem is fixed in CRS3". It seems someone reported the whm-server-status to SpiderLabs already and it's been fixed. I just don't think cPanel updated the rules yet. cPanel and its GET /whm-server-status " Issue #620 " SpiderLabs/owasp-modsecurity-crs " GitHub
    0
  • cPanelMichael
    It seems someone reported the whm-server-status to SpiderLabs already and it's been fixed. I just don't think cPanel updated the rules yet.

    That's correct. We do have an internal case open to update the curation for ModSec CRS version 3. I see it's an active project that looks to be nearing completion, but I don't yet have a time frame to report on it's implementation. We'll update the feature request page with more information once it's available: Update ModSecurity Vendor OWASP to OWASP ModSecurity Core Rule Set (CRS) 3 Thanks!
    0

Please sign in to leave a comment.