ModSecurity (mod_security) Packages Now Available

August 24, 2007 by · 34 Comments 

ModSecurity (mod_security) 2.1.2 has been added to my Yum Repository at the request of multiple users. ModSecurity is a Web Application Firewall that can help to minimize the threat from attacks such as SQL injections, protocol violations, and other common attacks. The standard configuration is courtesy of the ModSecurity Core Rules and will do a pretty good job of protecting your site from all of the script-kiddies out there (although that's no excuse for not keeping your system up to date).

This package is available in both 32-bit & 64-bit variants for RHEL and CentOS 4 & 5. Users of my Yum Repository can run 'yum install mod_security', followed by 'service httpd restart', and be off.


34 Responses to “ModSecurity (mod_security) Packages Now Available”
  1. Sam Roberts says:

    Thanks Jason. You are a champ and I am now a happy camper.

    Your modsec version fixed the Apache segfaults I was having with the 2.1.2 I compiled.

    And so far - after admittedly only a little testing - no problems except a weird:
    "ModSecurity: Could not set variable "resource.alerted_960903_compression" as the collection does not exist" error that regularly appears in the Apache error log but which does not cause any Apache crashes. Fingers crossed 🙂

  2. Jason says:


    ModSecurity does not support compressed content. Do you see any instances of "ModSecurity does not support content encodings" in your mod_security logs? If so, something you're serving is causing you to fail a validation rule in "modsecurity_crs_30_http_policy". If not, I don't have any clue, sorry.

  3. Avi A says:

    Hi Sam,

    As Jason said, this is a rule used to alert the webmaster that he uses mod_deflate, since there are uncertainties when the 2 modules interact. It uses the resource collection in order to log only once per location. There are situations where the collection is not initiated (when errors occur), and this is probably why you get this message.

    Questions directed to modsecurity & the core rules, can be sent to the modsecurity mailing list:

    Jason - Keep up the good work 🙂

  4. Jason says:

    @Avi A,

    Thanks for the extra info and for the link to the mailing list.

  5. Ivan Ristic says:

    Hi Jason,

    I've added a link to your Yum repository to the ModSecurity download page.

    Thank you for your work!

  6. Peter says:

    hello, first thanks for your work!

    i run into troubles with mod security.
    on new box (centos5) the httpd dont reatart after installin mod_security

    Starting httpd: httpd: Syntax error on line 209 of /etc/httpd/conf/httpd.conf: Syntax error on line 3 of /etc/httpd/conf.d/mod_security.conf: Cannot load /usr/lib/ into server: /usr/lib/ cannot open shared object file: No such file or directory



  7. Peter says:

    sorry, forgot the solution

    in this case, in /etc/httpd/conf.d/mod_security.conf the path to is /usr/lib64/

    thx again


  8. Jason says:


    That has actually been fixed in the newest package (mod_security-2.1.3-1.jason.2). If you don't have that then you can try running a "yum update".

  9. Mark Hamilton says:


    I run into a special problem on CentOS5. httpd restart says:

    Stopping httpd: [ OK ]
    Starting httpd: Syntax error on line 212 of /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf:
    Invalid parts specification for SecAuditLogParts: ABIFHZ


    Also, although your packages for other stuff looks good, I won't be able to install because it might seemingly conflict with the Virtualmin GPL install script's installed packages.

  10. Jason says:


    My mod_security packages were compiled against httpd 2.2.6, not 2.2.3 as with CentOS 5. While that shouldn't have caused any issue since they have the same MMN value, I can't be sure.

    As to the value 'ABIFHZ', that is a valid entry for SecAuditLogParts so I don't know what the problem might be, sorry.

  11. Mark Hamilton says:

    I got it to work with ABCFHZ

  12. Ivan Ristic says:


    ModSecurity supports compressed content in embedded mode by positioning the response filter to run before mod_deflate does. If you have encountered any issues related to this do let us know and we will fix it. When working in reverse proxy mode you will need to disable compression by removing the appropriate headers from the request before it is forwarded to backend servers. You can always add compression in the proxy itself.

  13. Jason says:


    Good to know, thanks for the info.

  14. Tam says:

    I too had problems starting httpd after installation on a Centos 5 box, owing to the path of

    # /sbin/service httpd start
    Starting httpd: httpd: Syntax error on line 212 of /etc/httpd/conf/httpd.conf: Syntax error on line 3 of /etc/httpd/conf.d/mod_security.conf: Cannot load /usr/lib64/ into server: /usr/lib64/ cannot open shared object file: No such file or directory

    I had to edit mod_security.conf to use the original path. I.e. I changed:




    and it worked.

  15. avtx30 says:

    Thank you Ivan for the mod_security and Jason for the rpm packages! Your works saved me.

    I have a question about mod_security2 and mod_deflate.

    My logs are fulled with mod_security warnings and I know that they are because of mod_deflate.

    Ivan said "ModSecurity supports compressed content in embedded mode by positioning the response filter to run before mod_deflate does.".

    Please tell me in more detail so that I can make them works properly.

    Thank you in advance.

    My environment:
    - CentOS 5.1 (x64_86)
    - Apache: httpd-2.2.6-jason.2.x86_64.rpm
    - Mod_security: mod_security-2.1.4-1.jason.2.x86_64.rpm

  16. Jason says:


    If you disable mod_deflate, do those messages go away? If so, try opening up your httpd.conf and moving the "LoadModule deflate_module modules/" line below the "Include conf.d/*.conf" line. Once you've done that try restarting httpd.

  17. avtx30 says:

    I post a reply yesterday. I confirmed it displayed properly after submitting but now I cannot see 🙁

    Short answer:

    - No change with your suggestion of editting the httpd.conf.
    - After disabling mod_deflate, annoyed warnings disappeared.

    May I turn-off all modsec rules related to "gzip", "mod_deflate"? I cannot give up mod_deflate, it speeds up my sites.


  18. Jason says:


    Are the warnings you're getting 960902 or 960903. If the former, these are from incoming requests; if the latter, from outgoing content. In any case, disabling the warnings isn't going to do you any good.

  19. avtx30 says:

    No they are not. They are: "960015", [No_id], "970903"

    [No_id] looks like this:

    [Sat Jan 19 10:47:34 2008] [error] [client] ModSecurity: Warning. Match of "rx (?:\\\\b(?:(?:i(?:nterplay|hdr|d3)|m(?:ovi|thd)|(?:ex|jf)if|f(?:lv|ws)|varg|cws)\\\\b|r(?:iff\\\\b|ar!B)|gif)|B(?:%pdf|\\\\.ra)\\\\b)" against "RESPONSE_BODY" required. [hostname ""] [uri "/modules/newbb/viewall.php?sortname=p.post_time&sortorder=ASC&since=0&type=all&mode=0&start=1000"] [unique_id "cVr5R3kBlTcAAAOYcR4AAAAL"]

  20. RSnow says:

    Just came across this, and I have 960903 errors with mod_deflate active. I was just curious, should I completely ignore the errors and take no action, or should I look at disabling some of the checks I am doing with mod_sec since it cannot analyze this compressed content?

  21. Jason says:


    The 960903 warnings are there to let you know that some or all of your outgoing content is compressed and that mod_security cannot analyze that data.

    You can handle this two ways. First, you can disable mod_deflate and allow mod_security to scan the outgoing data (recommended). Second, you can disable that rule by adding "SecRuleRemoveById 960903" to your "/etc/httpd/modsecurity.d/modsecurity_localrules.conf" file.

  22. Ivan Ristic says:


    As I mentioned in my previous comment here, we have had conflicting reports regarding the compatibility of ModSecurity with mod_deflate. We aren't able to replicate the problem ourselves but have put the rule there just to be on the safe side.

    I propose that you first determine whether ModSecurity sees the response content (i.e. it acts before compression takes place). You can do this by reconfiguring audit logging to include response bodies by adding part E to your SecAuditLogParts directive. When you look at such audit log entry, if you see the response in the clear then ModSecurity sees responses before mod_deflate (in this case we will work to fix that). If you see a bunch of binary data, it does not (in this case you can safely remove the rule). If you go through this exercise please send me the resulting audit log entry.

  23. Jason says:


    I'll give that a try later today and let you know how it goes.

  24. Jason says:

    @Ivan, et al.,

    The data in the audit log after adding "E" was in the clear. I've emailed you that chunk.

  25. roni says:

    Hi Jason,

    i run into troubles with mod security on my new box with centos5. the httpd dont reatart after installin mod_security.

    Starting httpd: httpd: Syntax error on line 210 of /etc/httpd/conf/httpd.conf: Syntax error on line 5 of /etc/httpd/conf.d/mod_security.conf: Cannot load /etc/httpd/modules/ into server: /etc/httpd/modules/ undefined symbol: ap_get_server_banner

    what should i do?

    thx for your help


  26. Jason says:


    Run "yum update mod_security" and make sure you get the version labeled 'jason.2'. The 'jason.1' version was up there for about 30 minutes and had a config bug for 64-bit systems.

  27. Brian says:


    Looks like you have a ModSecurity 2.5 version (the ap_get_server_banner function is not called prior to 2.5). With Apache >= 2.2.4 there is a new ap_get_server_banner() function that is used and ModSecurity will attempt to use this if it determines it is available (via looking at the Apache version). However, it looks like that function is not in your version of Apache yet ModSecurity is still trying to use it. What version of ModSecurity and Apache are you using and where did you get both of these from?


  28. Jason says:


    It actually looks like I misread your message. Your glitch is not related to the config bug I mentioned. As Brian mentioned, it sounds like you're using the stock version of httpd that comes with EL5. If you are going to use my packages you need to use ALL of them.


    Good catch.

  29. Joerg says:

    Hi Jason,
    if have the same problem roni has. I am running RHEL5 with Apache 2.2.3. This is the latest releas from RedHat.
    With ModSecurity 2.1.4 everything works fine. So, i think i have to wait for the new Apache release from RedHat.

  30. Jason says:


    The packages I offer are not meant to be used separately. If you use my mode_security packages then you should also use httpd, php, etc.

  31. roni says:

    i installed all ur packages.n its worked and running well.

    thanks mate 🙂

    U are my hero

    thanks , mate




Check out what others are saying about this post...
  1. Protect Your Web Server from Security Attacks using ModSecurity | my-whiteboard says:

    [...] [...]

  2. Apache mod_security on CentOS 5 x86_64 | BASE Logic, Inc. says:

    [...] got through some means in one of these tutorials. Then I found an updated module from Jason Litka ( The install went fine, and even came with a new configuration file and rules. But then I kept [...]

This site is no longer updated. If you have a need for RHEL/CentOS LAMP Stack updates outside the normal channels, I recommend ART.