Event Driven Automation with Ansible AWX, Splunk and Palo Alto firewall
Have you ever received a request from the security team to block an IP address on the firewall because they detected some kind of attack,
such as brute forcing, port scanning, or another technique?
You would need to log in to the firewall, create an object, and place it in the appropriate policy so the address can be blocked.
This is where event-driven automation comes into play, helping save time, improve security, and enable faster responses to incidents.
The diagram below illustrates a logical workflow for event-driven automation.
In this scenario, an attacker is attempting to brute-force or scan services running in the DMZ zone. The Palo Alto firewall forwards logs to a SIEM platform, in this case, Splunk Enterprise. Within Splunk, an alert is generated and triggered once the conditions for this type of attack are met.
Splunk has functionality that allows you to trigger a webhook to a specific URL and send data such as the source IP address or domain to an Automation bridge. Splunk also creates an incident in ServiceNow via an API call. The bridge is a component in this diagram that accepts data in JSON format. It extracts the source IP address from the alert and, via an API call, triggers a job template in AWX.
AWX then runs a playbook to update an external dynamic list with the source IP address. This external dynamic list is a text file hosted on a web server, containing IP addresses listed one per line. Finally, the Palo Alto firewall uses this external dynamic list in a security policy to block the malicious IP address.
That was the logic behind this project. Now, let’s move on to the configuration side for Palo Alto, Splunk, and AWX.
Get Necam’s stories in your inbox
Join Medium for free to get updates from this writer.
On the Palo Alto firewall, I created a log forwarding profile called Splunk, which is applied to the policy for the DMZ zone. All logs from that policy are forwarded to Splunk.
I also created a policy called Block_Malicious_IPs, which uses an External Dynamic List (EDL) as the source or destination address. In the Objects section, I configured the EDL with a URL pointing to a .txt file hosted on a web server.
On the Splunk side, I created an alert that is triggered based on the conditions. The alert has three actions:
- Generate a high-severity alert within Splunk
- Send a webhook request to the Automation Bridge
- Create incident on Service Now
The webhook sends a JSON payload via an HTTP POST request. Spunlk integration with Service Now is done with Service Now Add-on to create incidents.
The Automation Bridge is a Flask application listening on port 5000. It accepts only POST requests, extracts the source IP address from the JSON payload, and then sends another POST request with that IP as the payload to trigger a job template in AWX.
AWX is configured with a Project EDA that updates its repository from a private GitHub repo containing playbooks. An inventory is created in AWX, with the host machine being a web server at 192.168.10.10.
The job template is shown in the picture below. The inventory is Web_Server_EDL, and the playbook is updating_edl.yaml. Credentials for the web server are also configured. In the Variables section, there is an important Prompt on Launch checkbox that needs to be enabled. This option allows AWX to receive extra variables from the payload sent by Automation Bridge.
The playbook that runs when the job template is triggered is updating_edl.yaml. It is a simple playbook that validates the ip and appends the IP address to the edl.txt file on the web server.
After the workflow runs, the AWX job is shown as successful. The EDL list is updated, and after 5 minutes, the Palo Alto firewall blocks the IP address.
Thank you for reading this blog. If you have any questions or ideas on how to improve project, ask me below so we can discuss. Contributions and feedback are always welcome. You can also check out my other projects on my profile.
