Utilize the HTTPS interface on Cisco ASAs to shuttle CLI commands

The Cisco ASA has an HTTPS interface which can accept CLI commands, it’s loosely similar to a SOAP API, and is XML based. Example information available here:

https://communities.cisco.com/community/technology/security/ngfw-firewalls/blog/2018/06/11/mitm-an-asdm-session

At my current job, we’re utilizing this technique to talk to ~20,000 Cisco ASAs. SSH would not scale as we needed it to, so we shifted to using the HTTPS interface to send CLI commands. Just like the SSH interface, the HTTPS interface is capable of executing show commands as well as making configuration changes.

Benefits of the HTTPS interface.

• There is a considerably lower CPU cost to use HTTPS. We were frequently experiencing 100% CPU spikes when executing show running-config on large firewall configurations via SSH, no longer with HTTPS.
• Exponential speed increase due to HTTP protocol improvements over SSH character-based transmission. For example, when pulling ~4,000 lines of object-group configuration from a firewall in Hong Kong to our management server in Dallas, USA, SSH took 2 minutes and HTTPS took 6 seconds.
• Able to send multiple commands at one time, receive all output in one response. We can issue show version, show failover status, show monitor all in one command, and get all of the results in one response payload for parsing the device status.

If we want to keep Netmiko purely SSH, I can go ahead and write an independent library for ASA to utilize the HTTPS interface. I just figured since it really wasn’t a REST API and is just another control channel for sending CLI commands it was a logical place for this code.

What do y’all think?

[lykinsbd]

After digging through the way we’ve hacked the HTTP interface into Netmiko internally, it really isn’t something that I would recommend further inflicting on others. It pretty much ignores all the internal plumbing of Netmiko and subverts to a home-grown module to send commands via Requests.

I’ll go ahead and close this issue, and follow up with the Napalm ASA folks to see if it would be a good fit there.

[lykinsbd]

@ktbyers I’ll see what I can pull out of our code base to provide as an example this week. It’s probably not pretty, we sort of just shimmed it into the ASA modules directly, and didn’t modify the underpinnings that were calling out to Paramiko methods. It may make more sense to work with the Napalm ASA folks, but I’ll propose code samples in here before moving over there.

@DiogoAndre We’ve been using some variant of this method for about 4 years now to reach our ASAs. It’s highly stable, from an API Contract perspective, because if Cisco changes this functionality they will break everything else. ASDM, the actual ASA REST API, Cisco Defense Orchestrator, Cisco Security Manager, etc, all rely on this underlying logic to interact with the device. It’s purely shuttling CLI commands to the device and getting the raw CLI output back, so there’s not much to change there. It performs no marshaling of the response or anything of that nature, simply uses HTML/XML as transport for the CLI commands, vs the traditional SSH.