Friday, March 20, 2020
By Cezar Bucevschi, Fuel User Group Member
The rise of the machines — a title like this can make one think about an apocalyptic scenario similar to The Terminator movies, or topics like machine learning and artificial intelligence.
While the “rise of the machines” I’m talking about here is not a rise over the human race, what I do have in mind has the same capacity to keep firewall administrators awake at night. Firewall administrators used to be in control of every aspect of their firewalls, but now, with an increase in capabilities, firewalls have risen up to better assist with cybersecurity.
While this is a good thing, this rise in advancements has diluted the control administrators have over firewall capabilities and behavior. For the purpose of this article, I will talk about how the auto-tagging feature of the Log Forwarding profiles can automate security actions, and the creative ways it can be used.
The auto-tagging feature was introduced in PAN-OS 8.0 and has gone through several updates over time, with the most notable being an aging timer of the registered IPs introduced in PAN-OS 9.0. The need for such a feature might be obvious when dealing with automated/scripted attacks and probings, but it is also equally impressive since it takes firewalls up to 60 seconds to react to the predefined conditions. While 60 seconds is a long time during an attack or exfiltration attempt, compared to the standard alert, analysis, decision and change control turnaround, it almost looks like a real-time response. That’s what makes this feature a great tool in the firewall admins’ toolbox.
While other technologies can be leveraged for this functionality like SOAR solutions, etc., this kind of setting is far simpler and easier to implement in Palo Alto Networks firewalls, as it is already built into the PAN-OS. Let’s go through the details of some implementation use cases:
Blocking of Attacks
My favorite implementation is the blocking of attacks. While the firewall already has great results blocking exploit traffic patterns, the probes will continue to check for the attacks redundantly filling the logs and unnecessarily increasing the number of alerts we need to pay attention to on a day-to-day basis.
In this scenario, let's say that a web server needs to be exposed to the internet and geoblocking cannot be used because the client does business with countries notorious for such attacks. In this case, if an IP starts probing for vulnerabilities, it could be automatically added to a group of attackers, so that all the traffic from the source IP address gets dropped. This way, not only was a possible breach prevented by limiting the exposure even further, the threat logs are also cleaner because no other threat alerts will be triggered by the same source. Usually, in cases like this, we see the attackers changing the source IP of their attack vector, but that takes time. This makes me think that the tables are turning and they are starting to do more manual work than the admins do. That alone could discourage them to continue as the economic toll of their efforts could surpass the potential benefits and they start looking somewhere else for a new target.
Routing Based on Behavior
Another case scenario is routing based on behavior. Let’s say we always want a cloud-based application to prefer one particular internet service provider over another, but because of AppID shifting, this criterion is not ideal for such a decision. For that, we can ask the firewall to keep an eye on the AppIDs that are seen on the link where they should not be present, and add the destination IP to a dynamic group. That dynamic group, in turn, will be used in a policy-based forwarding, and that rule will always push the traffic to the desired link. While this does not achieve 100% successful redirection on the desired link, the session that triggered the action will continue to work unaffected by app shifting on the wrong link, while all the new sessions will be pushed to the correct one afterward. A very elegant and effective compromise!
Temporary Access to Resources
Another creative way to use this feature is for temporary access to resources. Like using a keypad to get access through a door in real life, we can leverage this feature by doing a Telnet or HTTP session to a high port (our personal key). If that condition is met, the firewall will then add our IP to the list of sources that are allowed to reach other particular resources, like GlobalProtect from the internet — a dynamic ACL, basically. To be sure the door does not stay stuck on open afterward, just add aging to the recipe and remove that access after any inactivity longer than the configuration parameter, which is between five minutes and 30 days.
We can easily see here how the versatility of this feature is limited only by our imagination, because the application methods are closer to art than an exact science. If you have other examples that you wish to share with us, please share them in the Fuel Discussion Forums.
Cezar Bucevschi is a Palo Alto Networks security consultant, helping clients of VersagiliT Inc. with customer enablement and transformation services. While his personal hobby is usually perceived as a risk-taking activity, skydiving actually helped him become the rigorous planner and the OCI (obsessive compulsive improver) that he is today.
More to Explore
Check out these Fuel blog posts for further reading: