FTD Snort Fail Open

[Isaiah]

According to the configuration guide, if a Threat Defense device is configured with interfaces in either redundant or transparent mode and the Snort process restarts as part of a configuration deployment, packets will be dropped. 

However, if the interfaces are configured in inline mode, it is possible to set a "Snort Fail Open" setting to enabled, causing packets to instead simply be passed without inspection.

Is it not possible to have this same fail-open behavior when the interfaces are routed, or is there some other trick that can be used to prevent any Snort restart from killing my traffic?

[Marvin Rhoads · Accepted solution]

I don't think you can do that as of the current FTD 6.2. We'll have to watch for it in a future release.

If it's important to your use case, please raise it via your Cisco account manager as an enhancement request.

Routed mode presents a particular challenge since the device may be a gateway or next hop for all traffic so it cannot just be shunted directly to the egress interface.

[Mehdi Derdouri]

You can enable this feature from the FMC. Specifically, you need to edit the relevant inline interface from the device management page, and set it from the advanced tab.

[Isaiah]

You can only fail open if the interfaces are in an inline set.  It is not possible with routed mode.

[Marvin Rhoads]

That's correct Isaih - thank you for pointing that out.

One of Cisco's design goals going forward is to gretly reduce the number of times (and duration of) Snort restarts during configuration changes / deployments. They realize the current situation is a shortcoming and are endeavoring to remedy it.

[prashant dwivedi]

Hello Marvin,

Do you know what kind of configuration can lead to the SNORT restart ?

We should know this before pushing the policy.

Please confirm on below :

1- whenever we push a new signature database to the FTDs will it surely restart the SNORT and hence there would be an outage for a brief amount ?

2- We have seen SNORT restart is also resetting the whole connection table hence these changes should be made on an approved outage window.

This is really something serious which we should be worrying about.

We should have a checklist stating configuration that can lead to a SNORT restart.

Thanks,

Prashant

[Marvin Rhoads]

Prashant,

This behavior has been one area where Cisco has focused lately. The following is valid as of Release 6.2.2:

In general, routine policy changes do not cause Snort restart by default.

However some operations require memory reconfiguration and engine reload. Those include:
- HA, MTU, and other infrequent platform changes
- Application preprocessor settings in Network Analysis Policy (NAP)
- URL category/reputation, application detector changes
- Creating/removing TLS, Network Analysis, File/AMP, and NAP policies

Note that VDB updates replace Snort binary and always require a restart

If you have an HA pair or a cluster, engines restart on both HA peers and all cluster members together.

You should also see that unavoidable restarts and binary changes will now generate warnings prior to committing to deploy.

[prashant dwivedi]

Thanks Marvin for your reply.

I want to know if there is any way where we can find out the difference in policies between two deployments ?

Let say, I login to the FMC and can see that FTDs are having some unsaved/underemployment policies , I would like to know what all the changes that has been configured but not  been deployed. This exercise can help us to understand if SNORT requires restart or not.

I faced some strange issue, last week I pushed the policy and noticed that users lost the access for they needed to reconnect the sessions. later on I found that Signature DB has been updated which has restarted the SNORT or connection table of the firewalls.

In our deployment, most of the policies are configured for "allow" action which certainly send traffic to the SNORT engine even though you don't an IPS/IDS or file policy associated with it. 

You thought please.

[Marvin Rhoads]

For all policies EXCEPT the ACP (not sure why that one isn't included), you can select "Compare Policy"and get a report of the delta between the running and chosen policy.

Procedure

---

Step 1	Access the management page for the policy you want to compare: DNS—Policies > Access Control > DNS File—Policies > Access Control > Malware & File Health—System > Health > Policy Identity—Policies > Access Control > Identity Intrusion—Policies > Access Control > Intrusion Network Analysis—Policies > Access Control, then click Network Analysis Policy or Policies > Access Control > Intrusion, then click Network Analysis Policy Note    If your custom user role limits access to the first path listed here, use the second path to access the policy. SSL—Policies > Access Control > SSL
Step 2	Click Compare Policies.
Step 3	From the Compare Against drop-down list, choose the type of comparison you want to make: To compare two different policies, choose Other Policy. To compare two revisions of the same policy, choose Other Revision. To compare another policy to the currently active policy, choose Running Configuration.
Step 4	Depending on the comparison type you choose, you have the following choices: If you are comparing two different policies, choose the policies you want to compare from the Policy A and Policy B drop-down lists. If you are comparing the running configuration to another policy, choose the second policy from the Policy B drop-down list.
Step 5	Click OK.
Step 6	Review the comparison results: Comparison Viewer—To use the comparison viewer to navigate individually through policy differences, click Previous or Next above the title bar. Comparison Report—To generate a PDF report that lists the differences between the two policies, click Comparison Report.

[prashant dwivedi]

Compare is not availble for ACP, may be Cisco will include this in 6.3 code.