Forum Discussion

DanSkow's avatar
Icon for Altocumulus rankAltocumulus
Feb 21, 2024

ASM/WAF Management Automation - TMOS

This post is to go over some of my thoughts on ASM/WAF management, and some custom solutions I've made to make it easier and more accurate. This will be highly technical and will apply to most use-cases. Written based on TMOS v15 software, but will be mostly applicable to all recent TMOS versions.


Automatic Learning:

  • Informational
    • Automatic Learning will automatically accept most Learning Suggestions that hit 100% confidence
    • Fully Automatic Learning will automatically accept all Learning Suggestions that hit 100% confidence
    • If your application open to the public, it will likely get scanned a lot. Some of the Learning Suggestions will be to loosen your policies based on scanner traffic it sees, like this one that would've accepted a SQL injection attack suggestion from traffic that's clearly from a Veracode scanner
  • Tips
    • Reduce scanner traffic that hits ASM policy:
      • Apply an iRule to your VIPs that have ASM policies that drops external IP-based requests. A lot of scanner traffic hits your VIPs by IP address instead of by hostname, and iRules process before ASM policies. So dropping IP-based traffic via iRule will drastically reduce the amount of bad ASM Learning Suggestions you get
      • I use the attached iRule "irule_all_asm_VIPs" on all ASM VIPs. It has a line to increment the "triggered" field in a Statistics profile named "asm_irule_triggered," so you'll have to create the Statistics profile with the "triggered" field and attach it to the VIP before it will let you attach the iRule to the VIP. This makes sure you don't lose track of how many bad requests are hitting the device
      • If ASM VIP has an existing iRule, irule_all_asm_VIPs must be attached first in order. See below for an automated way to attach this iRule to all ASM VIPs.
  • Ongoing Maintenance Tasks:
    • Enforce Ready Signatures
      • ASM policies have a configured staging period (AKA Enforcement Readiness Period) for all new and modified Attack Signatures. Once this staging period is complete, they must be enforced manually
      • Under Security > Application Security > Policy Building > Traffic Learning, there's an Enforcement Readiness Summary section where you can see ASM signatures that are Ready To Be Enforced. You can also Enforce Ready Entities on this page
      • See here for a script I made that can be pushed from the Big-IQ to Enforce Ready Entities on all ASM Policies:
    • If using Automatic Learning (not Fully Automatic Learning), periodically review Learning Suggestions at 100% confidence


Manual Learning:

  • Informational
    • Manual Learning doesn’t accept any Learning Suggestions automatically
    • Without the automation explained in this post or a full WAF team, it can be hard to manage many policies manually
  • Tips
    • Reduce scanner traffic that hits ASM policy. <see above>
  • Ongoing Maintenance
    • Enforce Ready Signatures <see above>
    • Periodically Review Learning Suggestions at 100% confidence <see below for automation>


Big-IQ Script Automation:

  • Enforce Ready Entities <see above>
  • Review Learning Suggestions
    • Periodic reviews of Learning Suggestions can be tedious because there isn't a main overview page that tells you how many Learning Suggestions each policy has at 100% confidence. So without automation, you have to click through each policy one-by-one to see which policies need to be reviewed.
    • I made the attached "Email Ready Learning Suggestions" script, that builds an HTML table line-by-line showing how many Learning Suggestions each policy has at 100% confidence, then uses the sendmail command to email it.
    • There are 2 initial one-time setup commands at the top of the script you'll have to check first to make sure your F5 can send emails, and you'll have to replace with your own email address in at the bottom. If it doesn't work after that, it's likely that your F5 SMTP traffic isn't allowed through a firewall
  • Attach iRule and Statistics Profile to all ASM VIPs
    • I made the attached "Attach iRule and Statistics Profile to all ASM VIPs" script that can be pushed from the Big-IQ to make a list of all VIPs with ASM policies, then attach the iRule if the VIP doesn't already have it. It doesn't remove existing iRules, and it puts this one first in the list if there are existing iRules
    • Obviously for this to work, your F5 needs to already have the "irule_all_asm_VIPs" iRule and "asm_irule_triggered" Statistics profile created. The Statistics profile needs a field called "triggered"


Cron Job Automation:

  • Reset Log Statistics Profile Count, and Reset
    • I use these 3 commands in a daily cron job that runs at midnight to send a syslog entry with the number of times an IP-Based request got dropped by the iRule, then reset the counter

EXECUTIONS=$(tmsh show ltm profile statistics asm_irule_triggered | grep triggered | tail -n1 | sed s/"triggered"//)

logger -p local0.notice "Daily number of IP-based requests that hit ASM iRule: $EXECUTIONS"

tmsh reset-stats ltm profile statistics asm_irule_triggered



2 Replies

  • Nice post DanSkow - I plan to move this to our Community Articles section but it seems there is a bug in that feature right now.
    Until then - thanks for this excellent contribution.

  • Here's the short version of my recommendations on what to do with all of this information:

    • Drop IP-Based Requests via iRule to make Learning Suggestions more accurate
    • Use Manual Learning if your team has the manpower and expertise to review Learning Suggestions manually. Big-IQ script "Email Ready Learning Suggestions" can help you prioritize which policies to focus on by telling you how many 100% confidence suggestions each policy has. I personally go through all suggestions weekly 
    • Enforce Ready Signatures on a weekly basis on all policies. This Big-IQ script can loop through all policies to enforce ready signatures on all of them: Automate ASM "Ready to Be Enforced" Attack Signatures | DevCentral 
      • This can also be fully automated by using Ansible Tower Scheduled Jobs. I can explain how to do that if anyone is interested
      • I also use Splunk alerts for internal hits against staged signatures so that I can disable them before I run the enforcement automation to reduce the chance of false positive blocks. I can provide more info on that too if anyone is interested