IBM Security Verify

 View Only
Expand all | Collapse all

ModSecurity Details

  • 1.  ModSecurity Details

    IBM Champion
    Posted Tue November 29, 2022 02:52 PM
    @Scott Exton A few questions for you (or anyone else using the new ModSecurity technical preview):

    1. What version of ModSecurity is in ISVA v10.0.4.0?  I just want to make sure I am referring to the correct documentation for either v2 or v3.

    2. I see ISVA includes the v3.3.2 OWASP ModSecurity Core Rule Set.  Do you foresee any issues of using the v4 beta ruleset?  The v3.3.2 doesn't have log4j rules and hence I suspect a lot of other things may be missing that we would want.  Granted we could just add log4j in a rule, but I'd rather use the OWASP rules if possible.

    3. Do you have any tips/suggestions outside of what configuration comes shipped with ISVA v10.0.4.0 IF1?

    Thanks!

    Matt

    ------------------------------
    Matt Jenkins
    ------------------------------


  • 2.  RE: ModSecurity Details

    IBM Champion
    Posted Tue November 29, 2022 05:02 PM
    One more thing, how are the rules loaded?  Is it alphabetical based on what we see in the WAF section of the LMI?  For example, if I create ACME-RULES.conf would that load before all the other rules, and ZEBRA-RULES.conf would load at the end of all them, after the main webseal WAF conf file detail is loaded?

    ------------------------------
    Matt Jenkins
    ------------------------------



  • 3.  RE: ModSecurity Details

    Posted Tue November 29, 2022 06:47 PM

    Matt,

     

    Unfortunately the load order of the rules is not guaranteed.  It is most likely going to be in alphabetical order, but we can't guarantee that.  If order is important for you I would suggest that you raise an 'idea' against the product and we can investigate.

     

    Thanks.

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     






  • 4.  RE: ModSecurity Details

    IBM Champion
    Posted Wed November 30, 2022 08:32 AM
    @Scott Exton Thanks for the reply.  From my understanding, the rules need to be loaded in order.  For example in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf and RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf the comments talk about those files being named so that they are loaded before and after other rules.  That is why I was curious if this was occurring in ISVA, and if we wanted to add custom rules, I was trying to plan out what the best naming convention would be for us to avoid interfering with the OWASP core ruleset rules.

    From my understanding when ModSecurity is used with Apache, an include * is used to load all the conf files.  Apache loads these alphabetically from what I am reading, and thus why the OWASP rule files are named as they are.  Hence, if we are not guaranteed this in ISVA, it may be good for me to put in an RFE/idea.

    Thanks!

    Matt ​

    ------------------------------
    Matt Jenkins
    ------------------------------



  • 5.  RE: ModSecurity Details

    Posted Wed November 30, 2022 04:36 PM

    Matt,

     

    Are you able to raise a product 'idea' and I'll discuss this with the stakeholders at our next meeting.

     

    Thanks.

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     






  • 6.  RE: ModSecurity Details

    IBM Champion
    Posted Thu December 01, 2022 03:23 PM
    @Scott Exton I will raise an idea either tomorrow or Monday on the rule loading.

    I was able to get the ​OWASP CRS v4.0.0-rc1 working but I had to comment out the REQUEST-922-MULTIPART-ATTACK.conf SecRules because they require ModSecurity v3.0.8 which it seems you indicated will release with ISVA v10.0.5.0.

    I had to open a case with support TS011413611.  I enabled ModSecurity on my lab on v10.0.4.0 IF1 in blocking but I am getting no logs to the container logs nor am I seeing it block a simple JNDI test.  I am uploading the container console output and the support file from the config container.

    Thanks,

    Matt​

    ------------------------------
    Matt Jenkins
    ------------------------------



  • 7.  RE: ModSecurity Details

    IBM Champion
    Posted Thu January 05, 2023 01:31 PM
    Scott, I created idea ISAM-I-1158 to request the ordering based on the file names.  Thanks!

    ------------------------------
    Matt Jenkins
    ------------------------------



  • 8.  RE: ModSecurity Details

    Posted Tue November 29, 2022 06:46 PM

    Matt,

     

    In answer to your questions:

    1. 10.0.4 is using ModSecurity v3.
    2. I don't foresee any issues with using the v4 Beta ruleset, but this is not something which we have tested yet.
    3. I don't have any additional tips.  There was a memory leak in the 10.0.4 implementation, but this has been fixed for the upcoming 10.0.5 release.

     

    I hope that this helps.

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     






  • 9.  RE: ModSecurity Details

    Posted Wed November 30, 2022 02:11 AM
    @Scott Exton, will ModSecurity get bumped to V3.0.8 in the upcoming ISVA V10.0.5?

    There are two issues in current V3.0.6 which have been bothering me seems got fixed upstream already.

    Unique_id is not unique enough:
    https://github.com/SpiderLabs/ModSecurity/blob/07514f97798a0bf57a1854d0bd8e2078644241d0/CHANGES#L31

    Corrupted message logged for multiMatch Rules:
    https://github.com/SpiderLabs/ModSecurity/blob/07514f97798a0bf57a1854d0bd8e2078644241d0/CHANGES#L61​​

    Thanks

    ------------------------------
    Frank Wang
    ------------------------------



  • 10.  RE: ModSecurity Details

    Posted Wed November 30, 2022 03:09 AM

    Frank,

     

    Yes, the ISVA 10.0.5 release will contain ModSecurity v3.0.8.

     

    Thanks.

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">



     

     






  • 11.  RE: ModSecurity Details

    Posted Wed December 07, 2022 08:13 AM
    Thanks @Scott Exton for the confirmation.

    I am building a analyzing pipeline for dashboarding and alerting based on the waf_audit.log generated. Comparing with waf_events.log, the audit log contains more information like the request/response headers/body, which don't exist in the events log. Another benefit is it can be written natively in JSON format. 

    I met two problems I can't workaround easily:

    1. Rotation

    waf_events.log is written by WebSEAL, settings can be configured using the 'log-cfg' configuration entry, which supports different agents including syslog. unlike waf_events.log, waf_audit.log is written by ModSecurity itself, and its settings are not modifiable. For ModSecurity running on normal Unix server, I can log to a Pipe or config logrotate to send a signal to to ask ModSecurity to reopen it. I am wondering how could I do rotation in virtual appliance if it is even supported. Would you please advise?

    # Use a single file for logging. This is much easier to look at, but
    # assumes that you will use the audit log only ocassionally.
    #
    SecAuditLogType -- fixed attribute which cannot be modified --
    SecAuditLog -- fixed attribute which cannot be modified --
    SecAuditLogFormat JSON

    2. Forwarding

    Since waf_audit.log can't be send out natively using syslog like other 'log-cfg' configured logs, Remote Syslog Forwarding need to be employed. I was hit hard by the 6k default max message limit, raised a PMR(TS011441949) and learned the rsyslog_forwarder.max_message_size ATP. But it doesn't solve the problem completely as it has a hard limit of 128k. For waf_audit.log, it could go easily beyond 128k if logging the request body is a requirement. Is there any particular reason of having a hard limit and set it to 128k? Could I expect a raise to at least few MB in the upcoming release?

    Thanks in advance and looking forward to your answers.

    ​Frank

    ------------------------------
    Frank Wang
    ------------------------------



  • 12.  RE: ModSecurity Details

    Posted Wed December 07, 2022 03:39 PM

    Frank,

     

    In answer to your two questions:

     

    1. Unfortunately there is no way to do this at the moment.  I would suggest that you raise an RFE against the product to add in log rotation.
    2. If you want to be able to set a larger max-message-size value I would suggest that you raise an RFE against the product.  Having said this, are you really sure that you want to be able to log MB's of data for potentially every single request.

     

    Thanks.

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     






  • 13.  RE: ModSecurity Details

    Posted Fri December 09, 2022 04:04 AM
    Hi Scott,

    That is really unfortunate. The audit log is enabled by default when ModSec is turned on, then it will keep growing till the FS is full or the admin truncate it manually. I guess that is something everyone have to be aware of before considering move it in production.

    Logging MB's of data potentially per request definitely sounds awful for performance, but comparing with missing detection of malicious activities just because the bad actor simply forged requests which generate audit record larger than 128k, I think it is a price worth to pay.

    It is just so easy for it go beyond 128k. First logging of the response body(E) is enabled in default configuration:

    # Log everything we know about a transaction.
    SecAuditLogParts ABIJDEFHZ

    Even if I can remove it from here, I can't prevent individual rules from turning it back on selectively using `ctl:auditLogParts=+E`

    $ grep -R -i auditLogParts .
    ./REQUEST-920-PROTOCOL-ENFORCEMENT.conf: ctl:auditLogParts=+E,\
    ./REQUEST-921-PROTOCOL-ATTACK.conf: ctl:auditLogParts=+E,\
    ...
    ./REQUEST-931-APPLICATION-ATTACK-RFI.conf: ctl:auditLogParts=+E,\
    ...
    ./REQUEST-932-APPLICATION-ATTACK-RCE.conf: ctl:auditLogParts=+E,\
    ...


    Second, even though logging of request body is not enabled by default, it still get logged under `transaction.messages[].details.data` by every rule matching on the REQUEST_BODY variable.

          {
            "message": "Invalid character in request (outside of printable chars below ascii 127)",
            "details": {
              "match": "Matched \"Operator `ValidateByteRange' with parameter `32-36,38-126' against variable `REQUEST_BODY' (Value: `<env:Envelope xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:env=\"http://schemas.xmlsoap.org/soa (251 characters omitted)' )",
              "reference": "o167,1o178,1o221,1o275,1o301,1o313,1o329,1v193,330t:urlDecodeUni",
              "ruleId": "920272",
              "file": "/var/pdweb/shared/waf/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
              "lineNumber": "1401",
              "data": "REQUEST_BODY=<env:Envelope xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:env=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n<env:Body>\n<RetrieveServiceContent xmlns=\"urn:vim25\">\n<_this type=\"ServiceInstance\">ServiceInstance</_this>\n</RetrieveServiceContent>\n</env:Body>\n</env:Envelope>\n",
              "severity": "2",
              "ver": "OWASP_CRS/3.3.4",
              "rev": "",
              "tags": [
                "application-multi",
                "language-multi",
                "platform-multi",
                "attack-protocol",
                "OWASP_CRS",
                "capec/1000/210/272",
                "paranoia-level/3"
              ],
              "maturity": "0",
              "accuracy": "0"
            }
          }
    



    ------------------------------
    Frank Wang
    ------------------------------



  • 14.  RE: ModSecurity Details

    IBM Champion
    Posted Tue March 28, 2023 09:28 AM

    I opened idea ISAM-I-1183 to address the audit log rotation.  L2 told me L3 told them there is no way to do this at the time and it is not an easy fix for them.  I am not sure if others can vote on ideas, but if so you may want to vote on this one if you are running into the same capacity issues we are seeing with it.



    ------------------------------
    Matt Jenkins
    ------------------------------



  • 15.  RE: ModSecurity Details

    Posted Wed December 07, 2022 09:56 AM
    Hello Scott,

    It's came up a question how we can handle old PAM rules in new WAF configuration.  As far as I see more then 1000 rules are in PAM. 

    Actually I don't see the way to import them over to WAF. Is this means everything has to be added manually?

    Regards,

    ------------------------------
    Janos Laszlo Horvath
    ------------------------------



  • 16.  RE: ModSecurity Details

    Posted Wed December 07, 2022 03:29 PM

    Janos,

     

    The two technologies are totally different and there is no automated migration mechanism.

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     






  • 17.  RE: ModSecurity Details

    Posted Thu December 08, 2022 06:47 AM
    Hello Scott,

    So we just tried to test WAF settings with simple "BLOCK" based on Modsecurity documentation. It seems to be working as we expected but ReverseProxy send out HTTP403 like basic error page (from template files).

    Is it possible to use a  custom template pages for WAF?  In the log (waf_events.log) I see  "ModSecurity: Access denied with code 403 (phase 1).

    Our goal to show customer something like "WAF is blocked your access bla bla...".

    Regards,

    ------------------------------
    Janos Laszlo Horvath
    ------------------------------



  • 18.  RE: ModSecurity Details

    Posted Thu December 08, 2022 08:57 PM

    Janos,

     

    It is not possible at the moment to send back different error pages as a result of the WAF processing.  The WAF processing sets a response status (e.g. 403), and then WebSEAL will respond with the configured response for that status code.

     

    Thanks.

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     






  • 19.  RE: ModSecurity Details

    IBM Champion
    Posted Mon December 12, 2022 03:57 PM
    @Scott Exton Will WebSEAL honor ModSecurity redirects?  Using the redirect action like this (or as a default action or on a specific rule)?

    SecRuleUpdateActionById 932130 "t:none,redirect:'https://%{request_headers.host}/messages/blocked.html',log,auditlog"​

    I haven't tried yet, I am having issues getting ModSecurity to work on the containers.  Enabling it seems to do nothing.  I have a support case open but it hasn't gotten any traction since i opened it.  TS011413611 is the case if you are interested.

    Matt

    ------------------------------
    Matt Jenkins
    ------------------------------



  • 20.  RE: ModSecurity Details

    Posted Mon December 12, 2022 09:20 PM

    Matt,

     

    Yes, the integration will honor the ModSecurity redirects.  If a redirect-url is returned from the engine WebSEAL will generate a redirect to the URL which is specified.

     

    I've also taken a quick look at the support ticket which you referenced.  The support engine has investigated the issue and believes that it has been fixed already in the 10.0.5 release – more significant testing was undertaken for 10.0.5, including testing in a container.  The good news is that 10.0.5 has been released and so you should be able to test this out today.

     

    I hope that this helps.

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     






  • 21.  RE: ModSecurity Details

    IBM Champion
    Posted Tue December 13, 2022 11:21 AM
    Scott, this is awesome news!  I am waiting our OpenShift team to make the v10.0.5.0 image available to me so I can begin testing.  When I was online Sunday I noticed it had released so I immediately sent them a message.  This is great news if it does indeed resolve the issues.

    Also great to hear these redirects are going to work.  I think this will be better for us from a user perspective.

    One thing I was curious about is a content-aware redirect, so for example different content if the call was from a JSON app versus a HTML browser call.  I suppose if I got desperate I could do it in a webseal transformation rule.  Ohhh, I wonder if perhaps I could do something with the ModSecurity macros, something almost like https://%{request_headers.host}/messages/blocked_%{content_type}.html.  I'll have to think on this.  For now the HTML will really be helpful I think.

    Matt

    ------------------------------
    Matt Jenkins
    ------------------------------



  • 22.  RE: ModSecurity Details

    Posted Tue December 13, 2022 03:25 PM

    Matt,

     

    The ModSecurity integration is using the native WebSEAL response generation mechanism to generate the 302 response.  In other words, it takes the URL which is provided by ModSecurity and then constructs the standard WebSEAL redirect response with the specified URL.  

     

    WebSEAL already supports content-aware responses, and so you should be able to configure WebSEAL to respond based on the accept header.

     

    I hope that this helps.

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     






  • 23.  RE: ModSecurity Details

    IBM Champion
    Posted Mon December 19, 2022 10:11 AM
    Edited by Matt Jenkins Mon December 19, 2022 10:12 AM
    @Scott Exton Hey in v10.0.4.0 IF1 virtual appliances we are seeing severe​​ memory usage, in fact likely going to have to disable ModSecurity until we can upgrade to v10.0.5.0.

    I presume from what you said we should be better in v10.0.5.0 regarding memory leaks being resolved?

    Also, is there anything in v10.0.4.0 that can be done to resolve the issue without upgrading to get us by for now?

    Whatever it is seems to be load based.  The proxies that get more load start consuming memory more aggressively.  Restarting the webseal instance frees up the memory, but then it starts consuming again.

    ------------------------------
    Matt Jenkins
    ------------------------------



  • 24.  RE: ModSecurity Details

    Posted Mon December 19, 2022 03:44 PM
    Matt,

    This issue has been resolved in 10.0.5. Unfortunately there is no way to avoid the memory leak in 10.0.4.

    Thanks.

    Sent from my iPhone





  • 25.  RE: ModSecurity Details

    IBM Champion
    Posted Fri March 24, 2023 10:39 PM

    @Scott Exton A while back you recall I asked about ordering of the rule files loading.  Is there any way we can verify this by enabling some debugging?  I attempted to turn up debugging in ModSecurity by setting SecDebugLogLevel to 9 but the containers don't write waf_debug.log and the debug output did not go to the console.  I'll have to open a PMR to address the WAF debug logging.  However, is there something like pdweb.waf or a routing trace or something I can enable to check how those rule files are loaded?

    I am running into random issues on some of our proxy instances where they are firing on SecRules that depend on variables set in another file (part of OWASP CRS 4.0/dev).  The rules are hitting because the variables are empty.  I can only speculate this is because the variables were not set because they loaded after the file(s) with the SecRules.

    I opened a case TS012534448 on this problem I believe may be related to rule ordering.  It's starting to get a lot of attention here because we were getting ready to switch from using WCP in blocking to using ModSec in blocking.  However, after a trough review of the logs, we found random inconsistencies on our instances.  I cannot seem to get it to reproduce in my lab.  Simple rules are firing are firing every single request, even with the curl container health checks, such as SecRule id 920430 (HTTP PROTOCOL) or SecRule id 911100 (HTTP METHOD), because the variables that drive them are empty.  An FYI, the variables are set in the initialization rule file for OWASP, and left as default so they are not overridden in crs-setup.conf (I believe the variables would likely be defined if they were defined in crs-setup.conf, however the rule ordering still may not be correct).

    If it is indeed a file load ordering issue, the only thing I can think without changing the ordering is for me to have our automated builds concatenate all the rules files in alphabetical order into one giant file and just have one giant rule file on the environment.  I need to get it resolved so we can continue moving forward with enabling ModSec for blocking.

    Thanks for any thoughts!



    ------------------------------
    Matt Jenkins
    ------------------------------



  • 26.  RE: ModSecurity Details

    Posted Sun March 26, 2023 05:32 PM

    Matt,

     

    Unfortunately there is no guarantee over the order in which the rules are loaded (I know that there is an outstanding RFE on this).  However, once the rules are loaded they should always be executed in the same order.  Unfortunately there is no WebSEAL trace available which you could use to see the order that the rules were loaded.

     

    Your idea of merging the rules into a single file is a good one, at least to verify whether there is an issue with the order of the rules.

     

    I'm sorry that I don't have better news.

     

    Thanks.

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     






  • 27.  RE: ModSecurity Details

    IBM Champion
    Posted Sun March 26, 2023 09:22 PM

    Scott, thanks for the update.  I'll have to write some SecRules at the top of each rule file to append the log file name to a variable and log it each time.  I can't log it at the end as I cannot guarantee the log statement would get executed at the end.  I would use debug statements but I can't seem to get the ModSec debug output on containers (I do see a waf_debug.log on the virtual appliances).  I'll try to remember to update this thread with my findings.



    ------------------------------
    Matt Jenkins
    ------------------------------



  • 28.  RE: ModSecurity Details

    IBM Champion
    Posted Tue March 28, 2023 12:14 PM

    Seems like the rules are loading in order.  I added a SecRule to the top of each rule file with a unique ID and had it fire on every event.  In the console logs, I saw the events fire in the correct order with the filenames, and double verified with the rule IDs I had added.

    So the ordering I witnessed in this test was correct:

    /var/pdweb/shared/waf/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
    /var/pdweb/shared/waf/rules/REQUEST-901-INITIALIZATION.conf
    /var/pdweb/shared/waf/rules/REQUEST-905-COMMON-EXCEPTIONS.conf
    /var/pdweb/shared/waf/rules/REQUEST-911-METHOD-ENFORCEMENT.conf
    /var/pdweb/shared/waf/rules/REQUEST-913-SCANNER-DETECTION.conf
    /var/pdweb/shared/waf/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
    /var/pdweb/shared/waf/rules/REQUEST-921-PROTOCOL-ATTACK.conf
    /var/pdweb/shared/waf/rules/REQUEST-922-MULTIPART-ATTACK.conf
    /var/pdweb/shared/waf/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf
    /var/pdweb/shared/waf/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf
    /var/pdweb/shared/waf/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf
    /var/pdweb/shared/waf/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf
    /var/pdweb/shared/waf/rules/REQUEST-934-APPLICATION-ATTACK-GENERIC.conf
    /var/pdweb/shared/waf/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
    /var/pdweb/shared/waf/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
    /var/pdweb/shared/waf/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf
    /var/pdweb/shared/waf/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf
    /var/pdweb/shared/waf/rules/REQUEST-949-BLOCKING-EVALUATION.conf
    /var/pdweb/shared/waf/rules/RESPONSE-950-DATA-LEAKAGES.conf
    /var/pdweb/shared/waf/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf
    /var/pdweb/shared/waf/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
    /var/pdweb/shared/waf/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
    /var/pdweb/shared/waf/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
    /var/pdweb/shared/waf/rules/RESPONSE-955-WEB-SHELLS.conf
    /var/pdweb/shared/waf/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
    /var/pdweb/shared/waf/rules/RESPONSE-980-CORRELATION.conf
    /var/pdweb/shared/waf/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

    Now the question is why in our other environments some of the rules are running without anything in the variables.  Those should have gotten loaded in REQUEST-901-INITIALIZATION.conf.  So I might need to add a debug rule in that initialization rule file and let it slide into those environments and see if we log that rule before the other rules are firing incorrectly.  Because I never saw this issue in my lab in the first place, so it is possible the other environments perhaps are loading the files in a different order.  IDK.



    ------------------------------
    Matt Jenkins
    ------------------------------



  • 29.  RE: ModSecurity Details

    Posted Tue March 28, 2023 05:04 PM

    Matt,

     

    It is definitely possible that the order is different on different machines.  The operating system doesn't guarantee the order of the returned files – and so the order is likely to be different on different machines.  Here is a stackoverflow conversation which discusses the ordering of returned files: https://stackoverflow.com/questions/8977441/does-readdir-guarantee-an-order

     

    Thanks.

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     






  • 30.  RE: ModSecurity Details

    IBM Champion
    Posted Tue March 28, 2023 07:59 PM
    Edited by Matt Jenkins Tue March 28, 2023 10:59 PM

    Well, drat.  Strangely 3 environments I updated last week stopped having the issue after I pushed some changes and restarted the containers.  However, one today did not.  In fact, it had a new container that suddenly started having the issue.

    This environment I am working with today is a big QA environment, so I pushed my debug lines into the conf files and restarted again to trace.  I then watched our logging system for indications of pods which were incorrectly firing the SecRules where the variables were empty.

    ... and of course you are correct.  I have no idea why, but out of tons of Linux systems, as you pointed out, some just don't return the files in order apparently.  I can see this clearly with the SecRules I placed at the top of each rule file to log and ordering # that increments.  Strangely, most systems are returning the rules in order, or at least I think.  They could just be loading the variable file before the rules that need them.

    Now onto an Ansible play to concatenate and push them as one rule until you all can resolve.  Thanks Scott.

    PS:  This was the ordering I saw in that big QA environment:  901 init loads way after 920 protocol enforcement, which is a glaring issue.

    /var\/pdweb\/shared\/waf\/rules\/REQUEST-911-METHOD-ENFORCEMENT.conf
    /var\/pdweb\/shared\/waf\/rules\/RESPONSE-955-WEB-SHELLS.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-913-SCANNER-DETECTION.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-921-PROTOCOL-ATTACK.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-930-APPLICATION-ATTACK-LFI.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-931-APPLICATION-ATTACK-RFI.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-932-APPLICATION-ATTACK-RCE.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-933-APPLICATION-ATTACK-PHP.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-941-APPLICATION-ATTACK-XSS.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-944-APPLICATION-ATTACK-JAVA.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-949-BLOCKING-EVALUATION.conf
    /var\/pdweb\/shared\/waf\/rules\/RESPONSE-950-DATA-LEAKAGES.conf
    /var\/pdweb\/shared\/waf\/rules\/RESPONSE-951-DATA-LEAKAGES-SQL.conf
    /var\/pdweb\/shared\/waf\/rules\/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
    /var\/pdweb\/shared\/waf\/rules\/RESPONSE-953-DATA-LEAKAGES-PHP.conf
    /var\/pdweb\/shared\/waf\/rules\/RESPONSE-954-DATA-LEAKAGES-IIS.conf
    /var\/pdweb\/shared\/waf\/rules\/RESPONSE-959-BLOCKING-EVALUATION.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-901-INITIALIZATION.conf
    /var\/pdweb\/shared\/waf\/rules\/RESPONSE-980-CORRELATION.conf
    /var\/pdweb\/shared\/waf\/rules\/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-934-APPLICATION-ATTACK-GENERIC.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-905-COMMON-EXCEPTIONS.conf
    /var\/pdweb\/shared\/waf\/rules\/REQUEST-922-MULTIPART-ATTACK.conf

    Edit:  I can confirm that concatenating all the rule files together into a large file works and resolves our issues.  Unfortunately the ModSecurity events obviously do not have the correct rule file name in them, which is going to be frowned upon by our security team.  However, this gets us going until this can be addressed.



    ------------------------------
    Matt Jenkins
    ------------------------------