With interface security levels the ASA keeps two principles into mind when a packet comes into the firewall for a new connection:
- Traffic is always allowed from a higher security level to a lower security level, unless an access-list prohibts this
- Traffic is never allowed from a lower security level to a higher security level, unless there is an access-list explicitly permitting the traffic and a static translation is created
So, in this example, the client with internal IP 10.1.1.10 is allowed to go outbound to the webserver on the Internet, but unless you configure a specific access-list, traffic is not allowed from the Internet to the inside mail server.
If you then take into account that IOS/PIX/ASA access-lists always have an implicit deny ip any any statement in the access-list, so even if you configure an access-list (except of course permit ip any any), traffic will be blocked by that implicit match. So it’s relatively easy to tie down the traffic flows, right?
In FTD things are working quite differently.. In FTD there is not really the concept of an access list with an implicitly deny any any. Within FTD, an access policy is used to define the policies that need to be applied to one or more FTD devices. One or more rules, which are run sequentially, combined define the access policy. Each rule in itself contains several elements that can be combined to define the policy rule. Each rule consists following elements:
||Within FTD it is possible to logically combine different interfaces into a single zone. One or more zones can be used as selection criteria
||Also one or more destination zones can be used as selection criteria, for example the “outside” zone
||This is the classic selection criteria for a layer3 firewall, based on one or more source IP networks.
||This is the classic selection criteria for a layer3 firewall, based on one or more destination IP networks.
||It is possible to match traffic based on the vlan tag
||This is part of the next generation firewall that is inside FTD, per user (or group) policy rules can be matched
||Also part of the next generation firewall, in which a lot of applications are already defined. It is also possible to define custom applications using openAppID as well
||Classic criteria for the source ports. Within FTD there is a default group called “high ports” that you can use for client connections
||Classic match criteria for the destination ports. It is possible to use one or more ports to match on, or use a port group.It is possible to mix and match UDP, ICMP, ICMP6, TCP, etc in a single match statement
||This is used if you have a pxGrid ISE integration with FirePower and wish to match on scalabale group tags
||This is also part of the next generation firewall feature set, in which you can use URL categories (like advertisment, Phishing, etc) to match traffic on. It is a recommended from Cisco not to combine these URL categories together with the application matching statement.
||This option (within the rule details) specifies which file detection policy is to be used in AMP for networks.
|IPS Policy (with variable set)
||It is possible to define different Intrusion Policies within FMC. Within a specific rule it is possible to set a custom IPS signature policy.
||The resulting action that FTD will take when the packet is matching this rule.