File and Malware Policies

Objective

In this lesson you will learn how to configure and validate File Policies and malware (cloud/AMP) lookups on an FTD-managed environment so that malicious files carried over allowed application sessions (for example, FTP) are detected and blocked. This matters in production because application-layer allowances (e.g., permitting FTP control traffic) should not permit file-borne malware to transit the network unchecked — file policies and cloud lookups allow the firewall to inspect file payloads (first 1460 bytes and/or cloud hash analysis) and take disposition actions (Detect, Block, Log). In a real-world scenario, an organization allows FTP backups from branch servers to a DMZ, but needs the firewall to block malicious binaries in those transfers without blocking the entire FTP service.

Topology (quick recap)

This lesson re-uses the topology from Lesson 1. No new devices are added.

ASCII topology (exact IPs from the reference):

192.168.75.39 (Host-Client) | | inside network 192.168.75.0/24 | [FTD]--------------------------------------[Next-Hop/ISP] inside | dmz outside (Gi0/1) | 192.168.76.1 | | (dmz IP from ARP) 192.168.77.40 (upstream) 192.168.75.14, .12, .122 (other inside hosts) 192.168.76.14, .39 (DMZ hosts)

Notes:

• The FTD has logical zones named "inside", "dmz", and "outside".
• The reference ARP output contains these IPs: 192.168.75.14, 192.168.75.12, 192.168.75.39, 192.168.75.122 (inside); 192.168.76.14, 192.168.76.1, 192.168.76.39 (dmz); 192.168.77.23, 192.168.77.40 (outside).
• Interface name explicitly shown in the reference: GigabitEthernet0/1 for the "outside" zone.

Device Table

Device	Role	Interfaces / IPs
FTD (managed by FMC)	Perimeter firewall / file inspection	Zones: inside, dmz (192.168.76.1), outside (GigabitEthernet0/1)
Host-Client	Inside endpoint generating FTP/other traffic	192.168.75.39
DMZ Server	FTP/backup target or server	192.168.76.14, 192.168.76.39
Upstream Router/Next-hop	Internet/peering	192.168.77.40, 192.168.77.23

Key Concepts (theory + practical implications)

• File Policy vs. L7 ACL

  • Theory: A File Policy is invoked to inspect file payloads that traverse an allowed connection. A Layer-7 ACL (L7 ACL) can permit the control channel (e.g., FTP control port 21) while directing the firewall to consult a File Policy for any file-transfer payloads.
  • Practical: In production, you allow the control session but still block files that match malware signatures or cloud verdicts. Think: L7 ACL = "allow the conversation," File Policy = "scan every attachment in that conversation."

• First 1460 bytes signature detection

  • Theory: The File Policy engine can operate on the first 1460 bytes of a file to detect file type and run heuristics/signature checks. If the file is identified as malicious in that window, the firewall can block it immediately.
  • Practical: This means small malicious payloads that fit in the first 1460 bytes will be caught quickly without full-file buffering. For large files, additional techniques (hashing and cloud lookups) may be needed.

• Malware Cloud Lookup (AMP-like behavior)

  • Theory: The firewall can compute a SHA-256 hash for suspicious files and perform a cloud lookup. If the cloud (or local static DB) determines the file is malicious, the firewall logs and/or blocks the transfer.
  • Practical: Useful in production to leverage threat intelligence beyond local signatures. Note: for cached URLs or cached results, lookups can be local; non-cached items will involve cloud lookups.

• Policy ordering and IPS interaction

  • Theory: Intrusion policies (IPS) can intercept and drop/blacklist sessions before Access Control (AC) rules are evaluated for logging/allow decisions. The engine will re-evaluate the AC policy after an IPS-induced block to produce the final logging decision.
  • Practical: If an IPS drop occurs, you may see "Session was deleted because we hit a drop IPS rule and blocklisted the flow. This happened before AC rule was matched."

• Session flow & packet-level behavior

  • Theory: When a file transfer triggers the File Policy, the firewall may hold or re-evaluate the session, block the payload, and generate events (e.g., file type verdict, file event logs). The capture and ARP outputs help correlate the flow and next-hop/egress interface resolution.
  • Practical: Use packet traces and ARP tables to verify egress decision and to troubleshoot why a file-policy action fired for a specific flow.

Tip: Think of File Policy like an X-ray machine at a secure checkpoint — the access rule lets people pass, but the X-ray inspects items in their bags and can stop specific objects (files) without stopping the person.

Step-by-step configuration

Note: In modern managed FTD deployments, File Policies and L7 ACLs are configured on the Firepower Management Center (FMC) or via the FDM GUI. The verification below uses CLI show commands available on the managed FTD (LINA/ASA style show commands) as in the reference. Each step explains the action, why it matters, and how to verify using the show commands from the device.

Step 1: Review existing file events and sample logs

What we are doing: We examine the FTD’s runtime logs and packet capture traces to find file-policy and file-verdict events. This confirms that the engine is producing file event entries and helps us understand how the system records file blocks.

show capture CAPI packet-number 3 trace 3

What just happened:

• The capture command prints a packet trace for capture session "CAPI" (capability/inspection engine trace) number 3. The output includes times, source/destination IPs, and event descriptions such as ICMP echo requests and file-policy phases (route-lookup, adjacency). This helps correlate when the firewall resolved next-hop decisions and whether a file event was triggered.

Real-world note: Packet captures tied to the file engine are crucial when you need to explain to incident response why a file was blocked — you can show the exact flow and engine phase.

Verify:

show capture CAPI packet-number 3 trace 3

Expected output (excerpt):

09:11:54.814395 192.168.75.39 > 192.168.77.40: icmp: echo request .. Phase: 15 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.77.40 using egress ifcoutside
09:11:54.814395 192.168.75.39 > 192.168.77.40: icmp: echo request .. Phase: 16 Type: ADJACENCY-LOOKUP Subtype: next-hop and adjacency Result: ALLOW Config: Additional Information: adjacency Active next-hop mac address c84c.758d.4980 hits 140

Step 2: Inspect ARP and interface state for egress/adjacency confirmation

What we are doing: Verify egress adjacency and MAC resolution for flows so that file-policy hits correlate to correct egress behavior. If the firewall cannot resolve the next hop or adjacency, file-policy actions may not produce expected logs.

show arp inside

What just happened:

• The command displays the ARP table entries learned on the "inside" zone. You can verify MAC addresses and timestamps for hosts that initiated file transfers or other sessions. This helps ensure the firewall knows the path for return traffic and can reassemble and inspect payloads.

Real-world note: In production, stale ARP entries can cause false negatives in file inspection if the firewall forwards traffic incorrectly; confirm ARP entries during troubleshooting.

Verify:

show arp inside

Expected output:

192.168.75.14 000c.2930.2b78 8 inside
192.168.75.12 000c.29d0.ebcf 1286 inside
192.168.75.39 0004.deab.681b 3923 inside
192.168.75.122 000c.29ec.80e1 12451 dmz
192.168.76.14 000c.2998.3fec 55 dmz
192.168.76.1 c84c.758d.4981 3413 dmz
192.168.76.39 0004.deab.681a 3743 inside
192.168.77.23 6c41.6aa1.2bf5 1305 outside
192.168.77.40 c84c.758d.4980 4613 outside

Step 3: Configure File Policy (GUI action) — Detect, Block, and Malware Cloud Lookup

What we are doing: Create/enable a File Policy on FMC/FDM that:

• Sets detection to analyze the first 1460 bytes (Detect Files),
• Blocks files matching malicious criteria (Block Files),
• Enables Malware Cloud Lookup (send SHA-256 for cloud verdict).

Why this matters: Detecting on the first 1460 bytes enables fast classification and allows the firewall to block malicious files inline. Cloud lookup increases detection coverage using external intelligence.

Configuration (FMC/FDM GUI actions — no device CLI for these policies):

• Login to FMC (or FDM) for the managed FTD appliance (use administrative UI).
• Navigate: Policies -> Access Control -> File Policies.
• Create a File Policy with actions:
  • Detect Files (first 1460 bytes)
  • Block Files (for file types/indicators you choose)
  • Enable Malware Cloud Lookup (SHA-256 upload), and optionally Local Analysis if desired.
• Save and apply the File Policy to the Access Control Policy (ACP) or to the rule which will reference it.
• Ensure an L7 ACL or ACP rule forwards file flows to this File Policy (see next step).

Real-world note: File policies are typically applied as a module of an Access Control Policy; remember to deploy the policy to devices after editing.

What just happened:

• The FMC GUI steps create a File Policy that inspects file payload bytes and, when configured, performs cloud lookups of file hashes. Once applied, any flow that triggers the File Policy will be inspected and either allowed, detected/logged, or blocked based on the policy decisions.

Verify: (Use the FTD to confirm file event generation; a file block should produce entries similar to the example event in the reference.)

show capture CAPI packet-number 3 trace 3

Expected relevant output (file event excerpt):

6 AS 1 I 0 File type verdict Reject, fileAction Block, flags 0x00003500, and type action Reject for t0 192.168.76.14 -20 > 192.168.75.14 -36943 6 AS 1 I 0 File type event for file named fu.exe with disposition Type and action Block

Step 4: Associate L7 ACL / Access Control Rule to forward FTP data to File Policy

What we are doing: Ensure the FTP traffic is permitted at the control channel level but forwarded to the File Policy for payload inspection. This keeps the FTP control channel functionality while inspecting the transferred files.

Configuration (FMC/FDM GUI actions):

• Policies -> Access Control -> Rules
• Create or edit a rule that permits FTP control (or application FTP) and under Advanced > File Policy / Inspect > select the File Policy created in Step 3.
• Save and deploy policy to the FTD.

Why this matters: The separation allows protocols to function while files are inspected — this is how "L7 ACL allows FTP control channel, but File Policy blocks malicious file transfer" in the reference is achieved.

What just happened:

• The Access Control Rule now directs file payloads to the File Policy. When the client initiates a file transfer, the control traffic passes, but file payload parsing triggers the File Policy engine which can log or block.

Verify: Trigger a sample FTP transfer (from 192.168.75.39 to 192.168.76.14 in lab) and then run:

show capture CAPI packet-number 3 trace 3

Expected output indicating file policy action (excerpt):

L7 ACL allows the FTP control channel traffic, but File Policy blocks the malicious file transfer
6 AS 1 I 0 File type verdict Reject, fileAction Block ... File type event for file named fu.exe with disposition Type and action Block

Step 5: Observe IPS-before-AC behavior and session deletion (correlation)

What we are doing: Understand and verify the ordering where an IPS rule can delete/block a session before an AC rule match; the engine will then re-evaluate AC policy for final logging.

show capture CAPI packet-number 3 trace 3
show interface outside

What just happened:

• The capture output from the reference shows lines such as: "Deleting session [!Session was deleted because we hit a drop IPS rule and blocklisted the flow. This happened before AC rule was matched (Intrusion policy before AC rule match dropped). Firewall engine will re-evaluate from top of AC policy to find a rule for logging decision]".
• The show interface outside command confirms the physical/line-state of the outside interface and output packet counters which help correlate whether traffic was forwarded or dropped.

Real-world note: IPS dropping a session early is desirable if the payload is known-bad; however, ensure logging is sufficient for forensic needs because early drops may prevent later AC logging unless re-evaluation is performed.

Verify:

show capture CAPI packet-number 3 trace 3

Expected output excerpt:

6 AS 1 I 0 Deleting session [!Session was deleted because we hit a drop IPS rule and blocklisted the flow. This happened before AC rule was matched (Intrusion policy before AC rule match dropped). Firewall engine will re-evaluate from top of AC policy to find a rule for logging decision] 192.168.62.3 -54650 > 10.123.175.22 -22

show interface outside

Expected output excerpt (interface status and counters):

Interface GigabitEthernet0/1 "outside", is up, line protocol is up
273399 packets output, 115316725 bytes, 80 underruns
input queue (blocks free)

Verification Checklist

• Check 1: File policy created and applied to access control policy — verify by generating a file transfer and seeing a "File type verdict" or "File type event" in capture logs (show capture CAPI packet-number 3 trace 3).
• Check 2: L7 ACL allows control channel but the file transfer is inspected — verify by confirming L7 ACL hit and a subsequent file block entry in capture logs.
• Check 3: Malware Cloud Lookup uses SHA-256 and results in disposition — verify logs where the File Policy shows cloud lookup/block for a file (file event indicating block and SHA/hash in the GUI event; see capture excerpts showing "File type event for file named fu.exe with disposition Type and action Block").

Common Mistakes

Symptom	Cause	Fix
File transfers complete but no file-events/logs appear	File Policy not associated with the Access Control or L7 rule	Associate the File Policy to the relevant AC rule and re-deploy to the FTD
File blocked by IPS with no AC rule log	Intrusion policy dropped session before AC rule match	Review IPS policy tuning; ensure logging profile captures pre-AC drops; correlate IPS and AC logs
Cloud lookups slow or intermittent	Non-cached URLs require cloud lookup; intermittent connectivity to cloud	Ensure outbound connectivity to cloud lookup endpoints; enable local caching where available
Files not detected for small/malformed payloads	Detection relies on first 1460 bytes; if file is beyond this window or obfuscated it may evade simple detect	Enable Malware Cloud Lookup (SHA-256) or Local Analysis for full-file inspection where supported

Key Takeaways

• File Policies inspect file payloads (commonly the first 1460 bytes) and can Detect, Block, or forward files for Cloud/Local analysis — essential for preventing malware via allowed protocols like FTP.
• L7 ACLs permit application control channels while delegating payload inspection to File Policies — this lets protocols function while files are scanned.
• Malware Cloud Lookup (SHA-256) extends detection beyond local signatures by consulting external threat intelligence; caching behavior affects performance and lookup frequency.
• IPS actions can occur before Access Control decisions, possibly deleting sessions early; always correlate IPS and AC logs when investigating file blocks.

Important: For GUI-based configuration use the FMC/FDM interface (deploy changes after editing). Use the CLI show commands shown in this lesson to validate the file-policy behavior, adjacency, and interface state on the managed FTD.

Lab resources and examples use domain lab.nhprep.com, password Lab@123, and organization NHPREP for procedural references.