Firepower Policy

[GRANT3779]

From the FMC -

I have created an Access Control Policy and within that Policy I have a simple "any to any" rule.

Within my "any to any" rule - I have my own Intrusion Policy set and also my own File Policy.under the inspection tab.

Within the Access Control Policy -  what would be recommended default action in this scenario?

What is the actual order of operations with the above (if send traffic to the sensor using the above policy)

* All my traffic will match the any to any rule and will then be run through my inspection and file policy?

Should I then "trust" all traffic in the default action (as if it passes my intrusion and file policies, one would assume it is good?)

Am i understanding the order of things here? Any offerings of advice?

Thanks

[Marvin Rhoads · Accepted solution]

As far as the Access Control Policy, yes - you have it correct.

You should also be sure to setup your $HOME_NET and $EXTERNAL_NET objects,Discovery policy and FirePOWER IPS rule recommendations to better inform the ACP of the correct actions to take based on your actual network hosts and their vulnerabilities.

[GRANT3779]

Thanks for the input Marvin.

For the following - $HOME_NET and $EXTERNAL_NET

$HOME_NET - I have put in 10/8 and 172.16/12

(Is it best practise to Narrow this down to actual address space used rather than just the whole RFC1918? Upon looking further, should I be creating network objects containing subnets for each remote site I have and then adding these objects inside the $HOME_NET variable?

For $EXTERNAL_NET -

(what is expected here? Any external IP address space owned/used by the company?, e.g RIPE assigned address space or similar?)

[Marvin Rhoads]

You're welcome.

The primary intent is to tell FirePOWER which hosts are inside your network and which are external. That information is used to give context for many Snort rules that have a directional aspect and to guide FirePOWER regarding which hosts to discover so that it can build more accurate profiles (what OS, what applications running etc.) that it can then use to fine tune your IPS rules to more accurately protect against compromises.

If you have a disparate set of internal networks all with private addresses then you can use the RFC 1918 pre-built object (since version 6.0) or define them manually as you have partially done with the 10.0.0.0/8 and 172.16.0.0/12 supernets. If you have any publicly addressed internal networks then be sure to include those in the $HOME_NET object.

Once you have $HOME_NET defined, the recommendation is to simply define $EXTERNAL_NET = !HOME_NET (that is, anything that is NOT the home net object).

[GRANT3779]

Excellent points, thanks.

Last query and I believe I am good :-)

"Once you have $HOME_NET defined, the recommendation is to simply define $EXTERNAL_NET = !$HOME_NET (that is, anything that is NOT the home net object)"

Is this just a case of of going into the EXTERNAL_NET variable and adding HOME_NET to the excluded Networks?

Thanks again.

[Marvin Rhoads]

Yes.

In FirePOWER Management center, go to Objects > Object Management > Variable Set > Edit Variable Set Default-Set > Edit variable $EXTERNAL_NET.

Select $HOME_NET and put it in the Excluded Networks column. Save and it should then show up as I noted - i.e., !HOME_NET.

[GRANT3779]

It does indeed! Brilliant, thanks a lot Marvin. I do appreciate the time you take to answer my queries.

[dvalinho]

Hello Marvin,
Please what do you mean by "Snort rules that have a directional aspect"?

Thanks.

[Marvin Rhoads]

Some Snort rules (aka IPS Policy rules) have a direction specified within the rule. See the following screenshot for example and note that within the Rule tree I selected those with Rule Content > Direction > Directional. The one I have selected applies to traffic from $HOME_NET

:

[dvalinho]

Thank You