Do you think FTD image will eventually allow us to make changes from CLI?

[sherazy941]

Hi,

I just learnt the new FTD image that is the future of the Cisco firewalls does not allow you to make changes from the CLI all changes must be made from the web based GUI I don't like the idea of this at all, I'm really hoping at some point Cisco will include the ability to do everything from the CLI without using the GUI do you see them doing this in the future? Or keeping it as it is now and making everyone work from the GUI. I personally love the CLI and would hate to use a GUI.

[Marvin Rhoads]

You can do a few things from cli but most are and will continue to be from the GUI only. Policies are not easily expressed as human-readable cli configurations.

You will have an increasing number of things you can do from the REST API. One could argue that's a way of accessing the device with some scripted cli.

[sherazy941]

Hi Marvin,

Will the foundation of FTD not be ACLS like with the ASA? I hope they don't do the same with the switches ; (

Feel as if all those ASA commands I comitted to memory were a waste of time.

[Oliver Kaiser · Accepted solution]

It will probably take very, very long for any cli configuration to emerge (except for some minor tricks to break HA locally from the cli). The reason is quite simple... software architecture.

Cisco argues that it is because it would be complicated to configure using cli but tbh its just a technical limitation. Sourcefire configuration has always been through Defense Center (aka FMC) and to add the ASA part in FTD to the mix they just re-used their existing Cisco Security Manager (CSM) code for configuration push and created the frontend for configuration using FMC.

IMO they should have waited one more year, develop the asa rest interface for feature parity and use that to interface with the asa code, but they took the easy road and just generate clear text configuration that is dumped into the asa part of FTD... Since we only use FMC to configure FTD we shouldn't see what is behind the UI but it tends to break from time to time :)

If they had the option of an API first approach a unified CLI and UI using the same api calls wouldnt have been much of a problem (see UCS Manager, Junipers Junos or Palo Altos Firewall), but integrating legacy ASA and CSM code into another solution (sourcefire) can get tricky especially if you are under time pressure... I think they will probably re-write much of the existing codebase at some point to get this fixed, but who knows. :)

[Marvin Rhoads]

Nicely put Oliver.

You should consider blogging this type of analysis / viewpoint. 

[Claudiu Cismaru]

FTD is more than LINA + snort side, like Elektra SFR module is for ASA software. It's some sort of symbiosis. Actually, there's tons of references from the generated ACL, which is the ACP from the UI, to snort's objects and back. As there are portions which has to run into snort then come back to lina and back to snort again, maybe.

For simple up to layer 4 ACP rules, which are pushed into lina, is not a big deal. But thing about that layer 7 rules should be handled by lina with help of identification from snort components, like URL, appid rules.

I don't really see how would you configure these manually in CLI... Take a look at some medium complex ACP that includes: users, urls, url categories, application ids, some of them sending the traffic to IPS policies or file policies afterward... see what you get. Do you think you could handle this manually?

[Oliver Kaiser]

To be honest I see no issue with configuring an ACP via CLI. Personally I wouldnt do it, because I am lazy and dont want to remember additional syntax, but apart from my personal preference I still stand with my initial argument which is that the engineering approach taken to unify the two products is not well thought out.

I like firepower. Good ideas are baked into the product, from both ASA and Sourcefire, but Cisco should have given more thought into the integration. 

If an API first approach would have been taken, implementing a usable CLI would be a piece of cake. Both UI + CLI would use the same api calls and users would be free to choose how to manage the solution. Another benefit would be that stuff would fail consistently across the user exposed api, cli and ui if its a backend issue. Fix it once and be done on every front.

[Boris Uskov]

With the version 6.2 of FMC you can make some CLI templates with FCM. It is called FlexConfig. Please, see the release notes:

http://www.cisco.com/c/en/us/td/docs/security/firepower/620/relnotes/Firepower_System_Release_Notes_Version_620/new_features_and_functionality.html

It seems, that Cisco tends to GUI rather then to CLI (at least within Firewalls).