Forum Discussion

S_L_V_Ramana_T's avatar
S_L_V_Ramana_T
Icon for Nimbostratus rankNimbostratus
Jan 21, 2019

ASM policy block mode for one particular source IP address and remaining IPs ASM should be in transparent.

Created two ASM policies for one virtual server and configured below iRule for traffic routing. Kindly check and let me know if any issue in the iRule and also I want to forward the logs to remote rsyslog as well. Kindly help me on this.

when HTTP_REQUEST {
                    if {[IP::addr [IP::client_addr] equals x.x.x.x] } 
                        { 
                            ASM::enable /Common/Policy_A 
                            log local0. "Traffic sent to policy A"
                        } 
                    else 
                        {
                            ASM::enable  /Common/Policy_B
                            log local0. "Traffic sent to policy B"
                        }
                  }

2 Replies

  • for traffic routing it is much better and easier to use the local traffic policy instead of an iRule.

     

    If you need different blocking behaviour for just 1 IP address you are doing it wrong - maintaining 2 identical policies is a massive overhead - use Trusted IP address feature instead: https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-12-0-0/24.htmlunique_418795504

     

    For remote logging simply configure the remote logging profile in your policy, here's the ASM manual chapter describing how to do this:

     

    https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-12-0-0/14.htmltaskid

     

  • As far as I know you can only use trusted IP addresses, when policy builder is in use. If not, there should be no effect on that. From my understanding trusted IP addresses are not meant to no block anything in general, but help policy builder to tighten/loosen the policy.

     

    I'm not sure what you are trying to achieve. Do you need to create a new policy on an existing VS without having false positive issues? If so, I assume that the single address, for which blocking mode should be used, is a test client, correct?

     

    What about 1. use the transparent mode in general and just use event logs or better traffic learning to see if your configuration is working as assumed? You can issue violations from your test client and check the traffic learning for matching entries. 2. working with IP address exceptions. You can set a single IP address or whole networks to "policy default", "never block" or "always block". I'm not sure if longest match is working at this point (network 0.0.0.0/0.0.0.0 -> never block, network 1.1.1.1/255.255.255.255 -> policy default). Just check this out. 3. using different hostnames for testing purposes. The ASM policy allows to use transparent mode for single host names (ASM -> Headers -> Host Names), while all others are using the policy default (which would be blocking mode in your case).

     

    Does that help?

     

    I fully agree with samstep, that iRules are not the correct or best way to to dynamic policy assignments. In fact you will need to have an ASM policy assigned to the virtual, to be able to use ASM:: functions in irules. So you would need to issue ASM::disable to disable ASM on your conditions.

     

    LTM policies are much faster than iRules and most of my customers don't like to write iRules, event they are much more flexible that LTM policies. In fact there is always at least one LTM (auto)policy, when you assign a security policy to a virtual.