Checkpoint How to use R80.10 API for Automation and Streamlined Security webcast main points
Just took part in the webcast by Checkpoint How to use R80.10 API for Automation and Streamlined Security and here are some thoughts about it.
-
API is all about working with Management server (but read on)
-
We can set some things on a firewall Gateway as well via API and Management Server, but very few.
-
Web API works as Rest API (JSON/XML), so any automation tool that can emit HTTP requests will work.
-
Web API requests are sent to
r80-mgmt-ip/web_api/after client has authenticated to the Management Server. -
Almost everything in R80 Management Server is stored in the database not proprietary local files as before.
-
The Workflow is such:
-
Login to
mgmt-ip/web_api/login -
Send some API action via HTTPS
mgmt/web_api/add-host(changes are not implemented/saved yet) -
Publish them htps://mgmt/web_api/publish (changes are saved)
-
Finally Install Policy
mgmt/web_api/install_policy(Optionally but recommended) On each sent (usually using POST) request for changes verify that you got 200 OK reponse
-
Actually there are few programming interfaces so to speak:
-
Web API as described above, most suited for automation.
-
mgmt_cli: standalone tool (both for Gaia OS and Windows Management ) that communicates with Management locally, thus can be scripted on the server (Windows batch/Powershell/etc, Linux shell scripting/Python/etc)
-
SmartConsole cli: built-in shell inside the SmartConsole. You just click its link/icon in the SmartConsole and get the shell (emulation). While it is not very suitable for automation, you can still prepare bunch of cli commands to copy and paste to this shell.
-
Gaia cli: the classic Gaia shell (clish) programmable locally via Bash scripting.
The main advantage of the API is in automating daily tasks. Some tasks I can think of: deploying gateways to the cloud (AWS/Azure), creating/deleting/editing objects and rules in the Rule Base, creating your own custom web interfaces to the management server and many more. In the webcast, the presenter Ryan Darst showed in real time how using Ansible playbook he could deploy 2 firewall Gateways from scratch into the Amazon AWS cloud, then create their rule bases with network objects, setting on the way all the needed properties of the gateway – IP addresses, routing, anti-spoofing and such. It took some 10-12 minutes from starting Ansible deployment to having fully functional 2 gateways in the cloud that could pass and secure traffic for the networks behind them.
Doing non trivial things is not, on the other hand, the target of the API. That is, changing the underlying Gaia operating system, doing backups and other things that we are used of doing via bash scripts on the gateway remain as such. This is logical after all, the API in general are designed to automate “boring” daily tasks of large volume and also give management access/capabilities to the less qualified folks. You can for example build web interface and make available very specific tasks and commands to your SOC team, without giving them the powers to destroy something.
In the Enterprise environment, where it is a small team/one person manages the firewall such API usage is less useful, but still, occasionally we can automate time consuming tasks of bulk creation/deletion/import/export of the network objects or rules.
Related
Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ not to miss what I publish on Linkedin, Github, blog, and more.