ASA - REST API compatibility with certain platforms
jvanderaa opened this issue · comments
I believe that the NAPALM-ASA driver was setup to leverage the REST API. Recent versions of SourceFire software (>6.0) on ASA 5506-X platforms no longer supports the REST API.
Should it look to be moved to Netmiko for connectivity? And possibility of using the ASDM HTTP interface as referenced ktbyers/netmiko#841. This could also open up for use on older ASA platforms that never supported REST API as well.
hey @jvanderaa, the discussion on the netmiko repository is very interesting, thanks for pointing it out. I will take a closer look and join the dicussions there!
On the topic here, yes, we are leveraging the ASA API for this driver. It seemed the logical way forward when it was started. I saw that support for the API was dropped on the 5506-X, nothing much we can do about it with the driver in its current state. Let's see how the ideas on the netmiko evolve, maybe the driver pivot.
The 5506-X doesn't support running the REST-API only when you are runninng the FirePower software module right?
I think it's going to be a bit hard to maintain as the ASDM HTTP interface is not documented at all, so everything will need to be reverse engineered and could potentially change with new software version or ASDM version.
And I don't think you'll have to hope for any kind of support from Cisco
That being said, I do think we could start working on a ASA driver using SSH to support older ASA models. There seems to be a version floating around already from which we could start
https://github.com/colsil/napalm-asa/tree/asa_driver_development
The 5506-X doesn't support running the REST-API only when you are running the FirePower software module right?
Yep. I actually never used a 5506-X, but had Terrible, Horrible, No Good, Very Bad experiences with its predecessor, the 5505.
I think it's going to be a bit hard to maintain as the ASDM HTTP interface is not documented at all, so everything will need to be reverse engineered and could potentially change with new software version or ASDM version.
I have the same feeling. However, still interested to learn more about it, especially for how long they've been using it, which could indicate some stability. It would also be interesting to learn why Cisco didn't leverage that for the API.
That being said, I do think we could start working on a ASA driver using SSH to support older ASA models. There seems to be a version floating around already from which we could start
https://github.com/colsil/napalm-asa/tree/asa_driver_development
Very interesting work as well. Totally 👍 for an SSH version of the driver.
I think it's going to be a bit hard to maintain as the ASDM HTTP interface is not documented at all, so everything will need to be reverse engineered and could potentially change with new software version or ASDM version.
Looks like CSM is using the same HTTP interface. And I have a feeling that FMC is going to use the same method to configure Lina on FTD (but that's going to be harder to reverse engineer).
Hello, I'm the one who raised ktbyers/netmiko#841 over on Netmiko.
We heavily utilize the ASDM HTTP interface to manage over 20,000 ASAs, and I can provide much of the documentation we've gathered for the operation/interactions with it. We've been using it now for over 4 years with much success.
We even use it on devices which nominally have ASA REST API capability, because the inbuilt ASDM interface is dramatically faster (orders of magnitude) and more stable as it doesn't require running a separate .jar file on the box.
I'd be happy to fork this library and attempt to create a version that provides an option to utilize that interface, if folks would be interested.
Hi @lykinsbd, Thanks for bringing the subject here!
We should definitely work on this. Given your success history with this approach, I would say that the benefits outweigh the extra work needed with the screen scraping approach.
Can you provide some documentation so we can try it out?
Let me know how I can help. Really interested in seeing this forward. Thanks!
Hey! Here are the two Cisco Community posts one of my colleagues Aaron Hackney put together based on his Cisco Live presentation on the subject (BRKSEC-2031):
https://community.cisco.com/t5/security-blogs/script-an-asdm-session-part-i/ba-p/3663024
https://community.cisco.com/t5/security-blogs/script-an-asdm-session-part-ii/ba-p/3658069
The first post is about more general ways/means of interacting with the ASDM interface.
The second post is a more specific look at an example use case (along with the source code here https://github.com/aaronhackney/test_ptracer).
Thanks!
Hi All! I was finally able to start working on this. You can check some (very) initial work on the new asdm-interface branch. The get_interfaces_ip method is the only method implemented so far, and still missing IPv6.
It really looks promising, and very fast as you mentioned. I will try to benchmark the REST API against the ASDM interface later on.
@lykinsbd , there was something your colleague mentioned in the part II post that intrigued me:
Here, we can see that instead of obtaining an asdm session token, we are simply base64 encoding our username and password and passing these credentials to the asdm interface as a simple header.
Is Aaron implying that there is a way to get a session token from the ASDM interface? If so, would you have more info on this?
thanks!
Hey, just wanted to comment that I've been trying different ways to have both connection types (REST API and ASDM) to coexist under the same driver. There are ways, but they are too hacky/inconsistent for my taste(especially on the tests side). So this will probably end up either a) being a different diver (eg. nxos and nxos_ssh) or b) replacing the REST API entirely in the current driver.
I will continue working on the asdm-interface branch that can be used in both cases.
There is a second item that we may want to draw away from the REST interface is working with ASAs in multi-context mode. Not sure if the ASDM interface would be a good route to go yet, or if just making things more of an SSH driver instead then.
https://community.cisco.com/t5/firewalls/asa-rest-api-and-multicontext/td-p/2652722
Moving away from the REST API is definitely a good idea, whether it's using the ASDM interface or Netmiko. Cisco is no longer developing the API, and is not supporting it on newer platforms (Firepower 1000/1100, 21xx, 41x5). My suggestion would be Netmiko, since while it's definitely uglier, may be a more stable interface.