Security Automation with F5 BIG-IP and Event Driven Ansible

Updated (September 19th 2023)

INTRODUCTION TO EVENT DRIVEN SECURITY:

Event Driven Security is one of the projects I have been working on for the last year or so. The idea of creating automated security that can react similarly to how I would react in situations is fascinating to me, and then comes the BIG Question.... "Can I code it?"

Originally our solution we had utilized ELK (Elastic Logstash Kibana) where Elasticsearch was my logging and monitoring tool, Kibana was the frontend GUI for helping me visualize and set up my watchers for my webhook triggers, Logstash would be an intermediary to receive my webhooks to help me execute Ansible related code.

While using Logstash, if the Ansible code was simple it had no issues, however when things got more complex (i.e., taking payloads from Elastic and feeding them through Logstash to my playbooks), I would sometimes get intermittent results. Some of this could be my lack of knowledge of the software but for me it needed to be simple!

As I want to become more complex with my Event Driven Security, I needed a product that would follow those needs. And luckily in October 2022 that product was announced "Event Driven Ansible" it made it so I didn’t need Logstash anymore i could call Ansible related code directly, it even took in webhooks (JSON based) to trigger the code, so I was already half way there!

 

CODE FOR EVENT DRIVEN SECURITY: 

So now I have setup the preface let’s get down to the good stuff!  I have setup a GitHub repository for the code i have been testing with https://github.com/f5devcentral/f5-bd-ansible-eda-demo which is free for all to use and please feel free to take/fork/expand!!! 

There are some cool things worth noting in the code specifically the transformation of the watch code into something usable in playbooks. This code will take all the times the watcher finds a match in its filter and then then copies the Source IP from that code and puts it into a CSV list, then it sends the list as a variable within the webhook along with the message to execute the code.

Here is the code I am mentioning above about transforming and sending the payloads in an elastic watcher. See the Full code in the GitHub repo. (Github Repo --> elastic --> watch_blocked_ips.json)

  "actions": {
    "logstash_exec": {
      "transform": {
        "script": {
          "source": """
            def hits = ctx.payload.hits.hits; 
            def transform = ''; 
            for (hit in hits) 
            {
                transform += hit._source.src_ip;
                transform += ', '
            }
            return transform;
            """,
          "lang": "painless"
        }
      },
      "webhook": {
        "scheme": "http",
        "host": "10.1.1.12",
        "port": 5000,
        "method": "post",
        "path": "/endpoint",
        "params": {},
        "headers": {},
        "body": """{
			"message": "Ansible Please Block Some IPs",
			"payload": "{{ctx.payload._value}}"
		}"""
      }
    }
  }
}

 

In the Ansible Rulebook the big thing to note is that from the Pre-GA code (which was all CLI ansible-rulebook based) to the GA version (EDA GUI) rulebooks now are setup to call Ansible Automation Platform (AAP) templates.  In the code below you can see that its looking for an existing template "Block IPs" in the organization "Default" to be able to run correctly.  (Github Repo --> rulebooks --> webhook-block-ips.yaml)

---
- name: Listen for events on a webhook
  hosts: all

  ## Define our source for events

  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000

  ## Define the conditions we are looking for

  rules:
    - name: Block IPs
      condition: event.payload.message == "Ansible Please Block Some IPs"
      action:
        run_job_template:
          name: "Block IPs"
          organization: "Default"

 

This shows my template setup in Ansible Automation Platform 2.4.x, there is one CRITICAL piece of information i wanted to share about using EDA GA and AAP 2.4 code is that within the template you MUST tick the checkbox on the "Prompt on launch" in the "variables section".  This will allow the payload from EDA (given to it from Elastic) to pass on to the playbook.  

 

In the Playbook you can see how we extract the payload from the event using the ansible_eda variable, this allows us to pull in the event we were sent from Elastic to Event Driven Ansible and then sent to the Ansible Automation Platform template to narrow down the specific fields we needed (Message and Payload) from there we create an array from that payload so we can pass it along to our F5 code to start adding Blocked IPs to the WAF Policy. (Github Repo --> playbooks --> block-ips.yaml)

---  
- name: ASM Policy Update with Blocked IPs
  hosts: lb
  connection: local
  gather_facts: false 
  vars:
    Blocked_IPs_Events: "{{ ansible_eda.event.payload }}"
    F5_VIP_Name: VS_WEB
    F5_VIP_Port: "80"
    F5_Admin_Port: "443"
    ASM_Policy_Name: "WAF-POLICY"
    ASM_Policy_Directory: "/tmp/f5/"
    ASM_Policy_File: "WAF-POLICY.xml"

  tasks:

  - name: Setup provider
    ansible.builtin.set_fact:
     provider:
      server: "{{ ansible_host }}"
      user: "{{ ansible_user }}"
      password: "{{ ansible_password }}"
      server_port: "{{ F5_Admin_Port }}"
      validate_certs: "no"

  - name: Blocked IP Events From EDA
    debug:
      msg: "{{ Blocked_IPs_Events.payload }}"

  - name: Create Array from BlockedIPs
    ansible.builtin.set_fact:
        Blocked_IPs: "{{ Blocked_IPs_Events.payload.split(', ') }}"
    when: Blocked_IPs_Events is defined

  - name: Remove Last Object from Array which is empty array object
    ansible.builtin.set_fact:
        Blocked_IPs: "{{ Blocked_IPs[:-1] }}"
    when: Blocked_IPs_Events is defined
...

 

All of this combined, creates a well-oiled setup that looks like the following diagram below, with the code and the flows setup we can now create proactive event based security!

Here is the flow of the code that is in the GitHub repo when executed.

• The F5 BIG-IP is pushing all the monitoring logs to Elastic.
• Elastic is taking all that data and storing it while utilizing a watcher with its filters and criteria,
• The Watcher finds something that matches its criteria and sends the webhook with payload to Event Driven Ansible.
• Event Driven Ansible's Rulebook triggers and calls a template within Ansible Automation Platform and sends along the payload given to it from Elastic.
• Ansible Automation Platforms Template executes a playbook to secure the F5 BIG-IP using the payload given to it from EDA (originally from Elastic).

In the End we go Full Circle, starting from the F5 BIG-IP and ending at the F5 BIG-IP!