Utilize the HTTPS interface on Cisco ASAs to shuttle CLI commands

[lykinsbd]

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?

[jvanderaa]

One thing on this front is that there are still a fair number of older ASAs that could be in the world. So a fallback to SSH or escalation/definition/call to https would be preferred in my mind.

[lykinsbd]

We explicitly use this method (vs the actual REST API that came in 9.4) in order to reach our legacy devices, including PIXes on 8 code. If ASDM can reach it, this method works as it’s exactly how ASDM functions.

But I’m 100% for keeping SSH as a fallback. Meaning this as an enhancement not a replacement. We have to do that at work today in the event the HTTP config is borked (and used it heavily in our transition from SSH to HTTP).

[ktbyers]

@lykinsbd How did you integrate the code currently? Can you give me a simple example of how you currently execute the code to connect to a device?

My initial thoughts is that this is probably better suited to reside in its own library or you might want to explore napalm-asa. It sounds very cool...but not sure this is the logical place to put it.

But let me see your response to my first question to give me a better sense of what it looks like from a code perspective.

[DiogoAndre]

This is very interesting @lykinsbd! Also interested to hear more about it. How long have you been using this technique?

Also, feel free to open an issue for this conversation on napalm-asa if you feel more appropriate.

[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.

[devcoinfet]

Very good, I am currently working on this as we speak and was actually looking to see if people were interested. I have been able to do this using python to compliment the 22/23 port speaking of netmiko and have had great success in doing this in a large fashion if need be.

The whole crux of it is handling the accounts Your using and threading it out properly and parsing the command. I have made allot more than this but due to high cisco exploits in circulation I have held off on releasing my code for the thing its tied to but wouldn't mind collaborating on this portion to help the community with older asa's

Now I just learned cisco a few weeks ago so bear with me but I think I have enough of an understanding to work it out.

[devcoinfet]

https://github.com/devcoinfet/port80comms/blob/master/port80.py

I'm aware this isn't https but I reversed the way this worked using fiddler and fixed the code it outputted and modded it a slight bit to produce this.

this is a function out of a tool I'm coding that I will release to my repo once I'm sure everyone is patched well.

[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.