IBM Security Verify

 View Only
  • 1.  ModSecurity rule actions based on URI

    IBM Champion
    Posted Fri January 27, 2023 03:19 PM
    @Scott ExtonA while back when we talked about ModSecurity with the IBM developers (specifically @Scott Exton), when they were implementing it into webseal, the IBM developers said it was not possible to customize the rule actions based on the URI (junction) path.  On WCP this was possible, although we never used the functionality and rather just had a set of rules we applied in blocking for all paths behind the webseal instances.

    Of course we are getting questions about this now from our application teams that want specific rules enabled for blocking.​​  So I am trying to think in my head if there is some way this can be done.  Is there anyone on here​ that may have some deep ModSecurity knowledge or some other ideas to make this happen?

    Currently in the webseal WAF (ModSecurity) instance configuration, I am setting this for all phases (1-5):
    # SecDefaultAction "phase:1,allow,log,auditlog"# SecDefaultAction "phase:1,deny,status:403,log,auditlog"

    ​Then at the end of the WAF (ModSecurity) rules for the environment (containers or on each virtual appliance) I am setting this in the RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf file (I do this for the various IDs that we want enabled for blocking, in this case we use a redirect instead of a deny):
    SecRuleUpdateActionById 932130 "t:none,redirect:'https://%{request_headers.host}/static/waf_block.html',log,auditlog"

    This works great for all paths (URIs / junctions) on the webseals.  It logs everything by default, and then blocks specific rule IDs.

    What we are being asked is to have certain rules blocked for certain URIs / paths / junctions.  For example:

    /application_secure would block ID 1,5,10,20,50,100
    /application_public would block all IDs
    /application_internal would not block anything

    Can anyone think of any way to do this without having specific SecRule entries for each OWASP rule for each application?  For example, would there be any way to say like:
    SecRuleUpdateActionById 932130 "t:none,redirect:'https://%{request_headers.host}/static/waf_block.html',log,auditlog" but only for /application_secure

    Thanks for your thoughts!


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


  • 2.  RE: ModSecurity rule actions based on URI

    Posted Mon January 30, 2023 09:58 PM
    HI

    SecRuleUpdateActionById. doesn't allow multiple ruleIDs or condition match  . also at present there are limitation that you can't use SecRuleScript .(can't use LUA) so not much an option

    https://www.ibm.com/support/pages/system/files/inline-files/WAF-TechPreview.pdf

    At present, it looks you need to change specific SecRules ,which you already suggested.

    ------------------------------
    Tushar
    Tushar
    ------------------------------



  • 3.  RE: ModSecurity rule actions based on URI

    IBM Champion
    Posted Wed February 01, 2023 08:56 AM
    Thanks for the reply.  This is what I was afraid of.  I am wondering if I put an "idea"/RFE to have functionality added, what the best way to go about it would be.

    At this point there is talk again from the app teams about parking another WAF in front of the webseals which will break TLS between client and webseal which is a huge headache for client cert authentication.  The maintenance headache of this is going to be astronomical, but people don't see that in the moment of making such decisions.

    I'm just wondering how administrators using Apache have done this over the years.  I would presume this need would have arisen on Apache or other servers where ModSecurity is used.  For example, excluding a role for specific paths.  In fact, great example, I had to exclude rule 920350 for ignoring host headers containing IPs because the container health checks use the loopback IP address.  This would have been more secure if I could have excluded it only for calls to the root context / where the healthchecks present themselves.

    I'll have to keep thinking on it over the next couple weeks.  It seems there should be a better solution similar to how WCP operated allowing rules to be specified on the URI path.

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



  • 4.  RE: ModSecurity rule actions based on URI

    Posted Wed February 01, 2023 03:22 PM

    Matt,

     

    It's an interesting problem, and one which I don't know how we could easily solve.  WebSEAL allows you to programmatically determine whether to trigger the WAF or not via the new Lua scripting.  This gives you a lot more power over when WebSEAL triggers the WAF – but doesn't help if you only want to trigger certain rules for certain requests (it's an all or nothing approach).

     

    I'm definitely not a ModSecurity expert, but have you looked at the ModSecurity ruleRemoveById action?  This will allow you to remove certain rules based on elements of the request.  Take a look at the following article: https://support.trustwave.com/kb/KnowledgebaseArticle20056.aspx.  I suspect that this might do what you are after, but would not be really scalable if you had a lot of rules to remove for a particular request.

     

    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">

     

     






  • 5.  RE: ModSecurity rule actions based on URI

    Posted Thu February 02, 2023 04:12 AM
    Not sure if your problem is exactly the same, this is how I solved similar problem for BigIP health probes. It has to be put into REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

    #
    # Disable Rule Engine for BigIP Health Probes
    #
    SecRule REQUEST_URI "@streq /status.html" \
    "id:10000,\
    phase:1,\
    pass,\
    nolog,\
    t:none,\
    ctl:ruleEngine=Off,\
    chain"
    SecRule REMOTE_ADDR "@ipMatch LIST_OF_BIGIP_IP_ADDRESSES" "t:none"

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