Cisco Firepower Threat Defense (FTD) Packet Flow
It’s important to understand the packet flow for a FTD device. By understanding the flow you can both troubleshoot and create true policy, and knowing your detection process will impact 2 things:
• How you analyze the data
• How you tune your security appliance
Optimizing detection also becomes easier when you understand the complete path a packet (and the flow) takes through the FTD device. Here are two key optimization points to remember:
- Layer 2-4 traffic that can be matched and either blocked or allowed with FastPath will be handled entirely in hardware.
- Layer 3 Security Intelligence is the first detection that occurs in the Snort process (Now called Firepower layer). All of this traffic will be blocked and no other additional inspection will occur. This optimized your treat monitoring by stopping active threat companies without the need for additional threat analysis.
Understand that there are 2 main engines in the FTD unified software image: Lina and Snort. Lina is the ASA code that FTD runs on, and the snort process is the network analysis of the packets that goes from security intelligence (SI) through the ACP inspection of the traffic by the Snort IPS rules.
Here is an overview of the packet flow:
- When a packet enters the ingress interface and it is handled by the LINA engine
- The packet is inspected by the Snort engine, if configured to do so; this can include SI, IPS, AMP, URL filtering among other inspections.
- The Snort engine returns a verdict for the packet
- It’s important to note that the Snort engine does not drop anything, but instead marks the packet drop or forward, based on the snort verdict.
Lina does the process of layer 2, routing, NAT, VPN, PreFilter, and layer 3-4 access control policy rules before the snort process takes over the analysis. The Lina code takes over again after the default action of the ACP and again does layer 2, routing, NAT, VPN, etc.
After a packet makes it through the Lina without being killed by the PreFiler or layer 3/4 ACP, then it starts traversing the Snort process by going through the Layer 3 Security Intelligence (SI) White and Blacklist. If the packet does make it through the Blacklist, by either not being in the Blacklist or by being in the Whitelist (the Whitelist only exists to override the Blacklist), then application detection can take place.
If there is an SSL policy, the packets can be decrypted and possibly dropped here, if not, it will then go through the L7 SI URL and DNS list and feeds. Authentication can now take place, either actively or passively via an Identity Policy.
Now finally, the packets will be compared to the rules in the main Access Control policy (L7 ACL). Packets can be dropped, passed or even trusted and sent to Egress. It’s important to understand that the packets can be passed before the Snort process by using the PreFilter FastPath rules, or ACP layer 3/4 trust rules. However, remember that the PreFilter is only layer 3/4 whereas the ACP is through L7.
Interface QoS policing can be applied here (but is actually enforced in LINA), and Network Discovery can be configured to either passively or actively gather host/user/application information to help in network analysis.
If configured, URL filtering and the Malware/file policy will be enforced as well as the IPS rules against the traffic. AMP takes the packets and assembles them into files if they match the protocol in the file policy rule. Files that match the malware and file policy can be inspected against data in the cloud, have local malware checks performed or the files themselves may be transfered to a sandbox for inspection. If traffic makes it through the file inspection process it will finally be evaluated against the enabled Snort IPS rules.
Finally, assuming the packets are still alive, the packets will be handed to the Lina process for layer 2, routing, NAT, VPN, etc.
job well done. Great dedication and a good result.
Thank you!
Hi sir,
I have a query in our environment, we have implemented Firepower , after the implementation we got an issue that bulk FTP is not working.
After passing the traffic through pre-filter policy as fast-path bulk FTP started.
As per the article, if we do fast-path packet wil avoid snort engine, so do you suspect that there is some issue with our snort engine ?
Bug or some other thing .
No, I don’t think that you have something wrong with the snort engine, you have something wrong in your Access Control Policy that’s blocking it. Email me a pic of your ACP rules and I’ll take a look [email protected]
This is an issue with FTD handling FTP ( Active Vs Passive )
True, but you can fast path FTP to solve the issue
I want to know where does the “Network Analysis” policy come in the Packet flow?
Two places, at the beginning and end of the LINA process, and at every policy listed in the diagram for the SNORT process.
If SNORT is crashed, can we bypass SNORT process.
Go to Devices>Device> and enable the Automatic Application Bypass option, which bypasses snort when it crashes
this should be enabled by default, but it is not.
If FMC is down for any reason, will any of these features be affected? If so, which ones? Will IPS work?
The FMC pushes policy and provides network analysis, so you only lose AD integration and AMP if the FMC goes down
What is the purpose of Routing and Nat checks before and after the Snort check ?
That is the Lina process where NAT and VPN encryption/decryption happens, so that is the Ingress and Egress ASA code
1. Let’s consider NAT which has two options
a. Source Nat
b. Destination NAT
2. Let’s consider Route which has two options
c. Policy Route
d. Static Route
3.Now there are two places where NAT and Routes are being checked
1. Before Snort
2. After Snort
May I know which is the order via which the packet flows ?
Is it,
1 (b,c,d)
then,
2 (a,c,d)
SNORT has nothing to do with any of that, and only sends a snort verdict to the egress interface. What your asking is done 100% the same as it was with ASA code, as it is ASA code, no differences in this.
I mean, why do we have two different places where the lina engine is checking for NAT and Route ?
Also, appreciate if you can explain which would be checked first? Route or Nat ?
Why “show traffic” shows different traffic rates on Inside/Outside interfaces than what appears on physical interfaces assigned on FXOS?
On FTD
Outside:
received (in 136261.290 secs):
8453958335 packets 5358770956222 bytes
62010 pkts/sec 39327012 bytes/sec
transmitted (in 136261.290 secs):
4930655161 packets 761573415361 bytes
36027 pkts/sec 5589003 bytes/sec
1 minute input rate 70372 pkts/sec, 48774860 bytes/sec
1 minute output rate 39665 pkts/sec, 6833925 bytes/sec
1 minute drop rate, 1384 pkts/sec
5 minute input rate 72095 pkts/sec, 49291003 bytes/sec
5 minute output rate 40480 pkts/sec, 7182970 bytes/sec
5 minute drop rate, 1287 pkts/sec
Inside:
received (in 136261.290 secs):
5042376611 packets 772812853681 bytes
37005 pkts/sec 5671015 bytes/sec
transmitted (in 136261.290 secs):
8975993109 packets 5439996074059 bytes
65022 pkts/sec 39923016 bytes/sec
1 minute input rate 40489 pkts/sec, 6936204 bytes/sec
1 minute output rate 77346 pkts/sec, 49986945 bytes/sec
1 minute drop rate, 1254 pkts/sec
5 minute input rate 41448 pkts/sec, 7306418 bytes/sec
5 minute output rate 78980 pkts/sec, 50535980 bytes/sec
5 minute drop rate, 1328 pkts/sec
FXOS Side:
Eth1/2: 5 min input rate 2009.7 Mb/s, output rate 260.8 Mb/s (Mapped to Outside)
Eth1/3: 5 min input rate 248.5 Mb/s (5.8%), output rate 2047.2 Mb/s (Mapped to Inside)
Since the traffic rates shown by ftp is far lower than what are being observed on physical interfaces, I am not sure hot rate limits (FTD Qos) could be applied?
Do you have any comments/suggestions? CISCO TAC is silent.
Hello, I am not sure of the answer either. I am sure TAC won’t know this as well. If you do QoS, that is only interface policing and it is applied or enforced in the egress interface
Please read ftp as ftd in my previous post
Thanks for your quick reply, you guessed it rightly that TAC did not know the answer.
i have one issue with our telephonic service we are using ribbon voice gateway and for calling we are using MS teams, while making external call we are unable to hear anything but call is getting connect after i tried couple of time call may work we are able to hear each other.
as per voice gateway vendor there is issue with my FTD 2110 firewall
please advise on this
Of course your vendor said it was Cisco Firepower
FastPath the traffic and that will tell you
Good luck!
1. i want to know about Data Aquisition ( copy packet to memory ) ,what is this actually about .
as per diagram i understand Lina engine will give packet to Data aquisition then DAQ will give it to Snort , Snort will inspect and again give it back to DAQ then back to Lina .
Correct me if iam wrong and please explain what is Data aquisition .
2. You said snort engine will never drop any packet and then at a same time you side ( Finally, assuming the packets are still alive, the packets will be handed to the Lina process for layer 2, routing, NAT, VPN, etc. )
Confused , as per my understanding snort will mark which traffic to drop and which to allow .
looking for your valuable answer .
hello, good question.
the packet is placed in memory and that location is sent to each snort process. The snort process hands a verdict to the LINA only, and then the packet is sent to the Egress or deleted from memory.
Something that is not talked about much that someone from TAC told me the other day is that when you fastpath traffic it does not care about the three way handshake vs having that traffic trusted in the acp where it still bypasses snort but does care about the three way handshake. He went on to further elaborate that what he means is that if you had traffic initiate a connection from untrusted to trusted fastpath would allow it. Have you heard about this?
I am not sure I was classify this as something that isn’t discussed.
The reason FP exists is to bypass the snort process completely, so it comes in the Ingress and is sent to the Egress without inspection, that is the idea of the Policy. There are multiple reasons you would use this policy. You can use this to test applications to find out if Snort is causing the issue for example, or to send traffic between trusted zones that don’t need inspection. Maybe even voice traffic to stop any latency issues. I don’t configure untrusted to trusted zones with FP.
So if you had traffic initiate a connection from untrusted to trusted would fastpath allow that traffic to pass even thought the connection was not initiated from trusted? My question is really if fastpath cares about the three-way handshake for that type of situation.
yes, of course it would allow it, that’s what the policy does, so as an advanced network administrator, you would not allow anyone to configure such a rule if not needed. Again, with FP, the traffic is in no way inspected, not the 3-way handshake, nothing. That’s the beauty of it, you can use it for your business requirement needs, now that you understand what it does.
Thanks for confirming that. I totally agree with you and that’s what made me highly concerned about fastpathing too much traffic without fully understanding so thanks again. Really appreciate your time. By the way, different topic but have you been successful with creating a node for FTDv and FMC in CML 2.0?
Vdk, no I have not and its very disappointing. Cisco shoudl have made that native to the application. I still have all my servers running for my labs/classes and it’s expensive! No other way around it :(
Hello. Just to confirm one thing again on this topic. The example was if I specified in the pre-filter rule inside for source and outside for destination. If there was a connection initiated from outside to inside would it still allow it? Traditional ASA would not because it did not see a SYN-ACK but why would the pre-filter policy allow it if there was not a rule set up for outside to inside? Now if the pre-filter rule is any to any for source and destination I can see how it would allow it. Thank you.
So the FTD is not like the ASA, that’s a fact. All interfaces are open and there is no default security or security levels as were on the ASA. However, if you were to just have basic NAT from in>out, then that in itself would create a “poor man firewall” per se and not allow any session in, but without something, the FTD by default allows all sessions until you create rules, zones, profilers, etc that is specific to what comes in and out.
But when it comes to the three-way handshake TAC stated that when you use the trust tule in ACP it does care about it. Is that correct?
It will care about the 3-way handshake because it will build the file and get it ready for the inspection engine before it hits the ACP. Plus, you can have many rules before a trust rule in an ACP, so there is no black and white answer here, but if you really care about inspection, etc then don’t use trust rules.
Just touching base to let you know that someone from the Cisco Learning Network replied with information to get FTDv working in CML. Here is what he provided-For adding custom images and node definitions, please review the following: https://developer.cisco.com/docs/modeling-labs/#!custom-vm-images.
Also, there is a GitHub repository: https://github.com/CiscoDevNet/cml-community. “You’ll have to have the qcow2 image, upload that as a new custom image. Then download the yaml file provide on the github repo, and import that as a node definition.” I did not end up downloading the yaml file but instead went with the first option of just creating it within CML. I downloaded Cisco_Firepower_Threat_Defense_Virtual-6.7.0-65.qcow2 from Cisco’s site and Cisco_Firepower_Threat_Defense_Virtual-6.7.0-65.qcow2 as well. The FTDv booted up and it worked but now I have to get FMC to work to manage it in the lab. Hope this helps because I know you’ll be able to produce a great youtube video out of it which I’m selfishly looking forward to.
Hello! Thank you for posting. I really appreciate your participation in our conversations on lammle.com
You could do FMC/FTD for a while with CML and the previous edition, but it’s hard and cumbersome to setup, as your finding out. That said, creating labs with CLM for the Firepower courses doesnt’ help anyone because they’d have to find the files that you were able to get. Most people can’t get those, and you dont’ want to share yours and get on the bad side of cisco :)
Thank you again for posting!
Todd Lammle
Hello, is it true that Estreamer only captures data from the snort process and not from the line process?
At this point, Bob, that is correct. It’s always been hard to get data from the Lina process into the FMC, however, in the new 7.0 code (starting beta this week), I’ve heard that the Lina process will, or can, connect to the management channel, we’ll see.
Right now you can get that data by creating advanced syslog configurations in the Platform settings of your FTDs
Hi Lammle!
Am facing a problem with snot and I don’t know how to solve kindly assist.
when I packet trace to test mm nat policy, the packets a dropped by the snort as shown below. What could be the issue? Thank you
packet-tracer input tkl_net tcp 4.2.2.2 8080 196.202.216.146 8080
Phase: 11
Type: SNORT
Subtype:
Result: DROP
Config:
Additional Information:
Snort Trace:
00:00:00:00:00:00 -> AC:7A:56:47:A2:6D 8100
4.2.2.2:8080 -> 10.10.10.5:8080 proto 6 AS=1 ID=4
Packet 43179: TCP ******S*, 06/04-12:59:24.872177, seq 1418094664, dsize 0
Session: deleting snort session, reason: stale and not cleaned
Session: new snort session
AppID: service: (0), client: (0), payload: (0), misc: (0)
Firewall: starting rule matching, zone 3 -> 1, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999997, icmpType 0, icmpCode 0
Firewall: block rule, id 1, force_block
Stream: pending block, drop
Policies: Network 0, Inspection 0, Detection 2
Verdict: blacklist
Snort Verdict: (black-list) black list this flow
Result:
input-interface: tkl_net(vrfid:0)
input-status: up
input-line-status: up
output-interface: soc_datacenter(vrfid:0)
output-status: up
output-line-status: up
Action: drop
Drop-reason: (firewall) Blocked or blacklisted by the firewall preprocessor, Drop-location: frame 0x0000558b1cbe893b flow (NA)/NA
Your snort policy is given the packet a Drop verdict. You need to look into your snort policy analysis in order to determine which rule dropped it.
Dear Sir ,
Can you confirm us, SFR module can be delay the traffic from ASA firewall to our Envt
as we have ASA firewall and included SFR module …
Sure it can, depends on how it is configured, but sure.
Back on the FastPath Policy – Is it posible to FasthPath RAVPN traffic ? What would be the downside of that ?
We are having a very heavily utilized FTD 4100s that have all the RAVPN user traffic tunneled to the inside proxies? That creates a huge CPU utilization as total throughput reaches the 8Gbps limit on the firewall.
Yes, you’d want to bypass the Snort process for that traffic. You need the sysopt permit-vpn command
once your VPNs are configured, however, you need to add this command via flexconfig.
I wrote a blog on this:
https://www.lammle.com/post/cisco-added-the-remote-access-sysopt-permit-vpn-gui-command-in-firepower-ftd-6-3-code/
Hello Todd,
I read above that the “Network Analysis” policy is performed at the beginning and end of the LINA process. Is that comment referring to where the NAP policy is involved in analyzing traffic as part of the Intrusion Policy (Advanced Settings)?
I am trying to determine if the NAP policy is a “pre-snort” analysis. For example, when I look at an Intrusion Event as part of an IDS policy with a custom NAP for a packet that “would have dropped,” it shows the rule is “rule-type preproc”.
Am I confusing the NAP policy with Preprocessor IPS rules, which occur at different points in the packet flow?
Thank you sir.
The NAP is part of the Snort process, just after the SSL policy, and before the ACP. It is in no way part of the LINA process
Todd
Thank you for that valuable insight Todd.
Hello,
I had a strange issue with my FTD, i done a restore of configuration and after that all traffic is blocked. once i ran a packet tracer, i found that the traffic is blocked because of Snort. and in my rules on ACP i don’t have snort enabled.
I add two rules on top with any any between the Inside and Outside and resolve the issue. can you please assist in order to understand this behaviour of SNORT.
something is causing snort to trigger a drop resolute. Impossible for me to know what without looking at it. if you look in your connection events, and then table view, it will tell you what rule in your ACP is dropping it
Hello Todd,
If I have an ACP where the first line uses a L7 Snort lookup, does that now mean that every connection is now allowed to complete a 3-way handshake even if I have a L3 deny rule on say line 5? Just wondering if this is expected behavior or not. Seems like I am able to open a socket connection to things I should be able to based on my L3 ACP line, but my first line is denying specific countries.
The FTD won’t do L7 DPI unless the full rule matches the packet. I am not sure I’d have that as my first rule for efficiency sake, but it should still work fine as you are seeing. There are ways to make your ACP rules efficient, but if you dont’ have 100’s of rules, it will still work, as I said.
Hello Mr Lammle,
Could you please provide some more details as to why you would not have a “block countries” as your first rule?
Thank you in advance for you time,
You can do anything you want, but understand that doing an AD lookup as well as a GEO lookup (among others) take time, and the packet will have some latency, depending on the box, so I want the things on top that are fast if possible, but again, you can put the GEO on top. For me, I have other rules that I want to process first, but that is my personal decision
For which porpuse or in which escenario we need to configure fast path?
Thanks
Whenever you want to bypass the snort process, however, fast path is only layer 3/4, so keep that in mind
What do you mean by ALG checks ?
What is ALG checks ?
What is your experience with the amount of “Packets bypassed due to Snort down, Packets bypassed due to Snort busy”? This is seen in the Snort section under the Device Monitoring.
Since upgrading FTD 2110 from Snort 2 to Snort 3, we see a huge jump in this graph. Now seeing Avg. 25.00 – 36.00 K/sec – Packets bypassed due to Snort down.
Not seeing Snort down though. No Snort restarts or crash logs.
Snort 2 is single-threaded and Snort 3 is multi-threaded. If you have Max-detect as a base policy, it will skip some inspection, other then that, i can’t know why it is skipping files for inspection from here
i did have another thought on this. if you are running Snort 2, turn on the Automatic Application Bypass (AAB) in the Devices>Device pages fro each FTD
that will solve this
Still confused on why the Lina engine performs NAT and ACL checks post Snort engine process when it’s already done before leaving the packet to Snort engine.
So there is INGRESS LINA processing and EGRESS LINA processing. In the INGRESS it is decrypting and the EGRESS it is encrypting
Hello @Todd
I have a simple static route (internal) and default route (going to the internet) and the routing or policy does not allow the traffic go through the Firepower unless I configure the NAT policy. As far as I know the NAT is not required to allow the traffic to pass through the firewall.
Any idea about that?
A couple reasons this can happen. DNS resolves a global addresss for a site, and the FTD has no way to get to a global address without translation, unless the outside local address was a global address, which is rarely the case these days. Also, you can get to the remote server/site but that device has no way to understand how to get back to your internet network, so NAT is required to make that work…could be some other issues, but that is generically typically the reasons
Hey @Todd
I have a Firepower firewall configured with basic static route (Inside) and default static route (Outside). The traffic does not go through the firewall if I disable/remove the NAT policy, but everything is working fine when the NAT policy is applied.
As far as I know the NAT is not required. Why the traffic does not pass if the NAT is not applied.
If you’re trying to go to global addresses, then it is required. See comment I left you yesterday below
Hi Todd,
do you know that will the traffic will traverse snort even if we didn’t enable any network analysis policy like IPS, SI or AMP, it’s a pure L4 firewall.
I ask this becase after upgrading the FMC it’s required to restart the snort process because the VDB got updated, we are assessing the impact of snort restart.
thanks.
No, the snort process will not be used. All packets will go to the snort process, but then go to Egress Lina because you have no rules enabled. Deploying and restarting snort will have no impact on your network
Is fast-path stateful? If I fast path inside to outside, is the return traffic also fast-pathed?
Yes, Tom, that is correct. Any response would be accepted in the fastpath.
Hi Todd,
VPN traffic goes via FTD, so FTD decrypt the VPN traffic for inspection or not. if it is not decrypt the traffic then how can it inspect the malicious traffic.
Scenario: Node A————————–FTD—————————-Node B
===============================
VPN Tunnel
The VPN tunnel will be dycrypted, yes, but if you did an end to end encryption, you’d have to have an TLS Decryption policy
Hi Todd,
I am little bit confused with the packet processing order provided in your picture and packet tracer command result on FTD firewall.
On FTD, packet tracer command shows 15 phases of packet being processed, in which 1st phase is Route lookup (to define next hop and interface), 2nd is ACL check.
According to your diagram, ACL works first, then Policy routing and Routing. Which one is correct? If first case if correct, what is the reason for firewall to process route lookup first?
Traffic configured on the Pre-filter policy is still secure in cisco FTD? because this traffic completing bypassing the IPS inspection
If it is set to FastPath, then no it is no secure, it is in the prefilter and not set to be fastpathed, then it woudl be inspected by the snort process…