Re: Cisco Firepower inconsistent behavior in blocking files with file policy

laurin.beckhusen · ‎02-14-2018

I have a File policy set to block various files and have noticed some interesting behavior when testing.

I am testing between a site to site vpn by transferring a one note document between my workstation and a server. (both have a file policy to block various office files including .one files.) The near FW policy is in monitor mode and the far FW policy is inspecting all traffic and actively blocking. The near FP module is managed through FMC, the far FP module is managed through asdm.

If I open a smb admin share to one of the servers from my workstation and try to drop the file I get a block via the far end Firepower policy ( I would think it would block it via the near end policy first. Maybe it doesn't because it's in monitor only mode....)

If i leave the smb session open for 10 minutes or so I can then copy the file over without issues and don't get a block from either.... I have closed the windows explorer window and open a new one connected to admin share and could copy again. If i clear out the session using net use \\server\c$ /delete I get the block again, but after I leave it open again for 10 minutes wala, I can copy the file over.

If i do it the reverse way (from the server to my workstation ) the far fp module blocks the file correctly every time. I have left the smb share up for 30 minutes plus and it won't let me copy it from the server to my workstation.

Server is 2008R2, workstation is Win 10pro

1 )Trying to figure out why if I leave the smb session open, I can copy over the file eventually from my workstation to the server.

2) does file blocking not work in monitor mode? Why is the near FP module not even blocking the file.

Syslog message when sending from workstation to server:

<42>Feb 14 18:34:27 farfwfp farfwfp: Protocol: TCP, SrcIP: x.x.x.x, OriginalClientIP: ::, DstIP: x.x.x.x, SrcPort: 65218, DstPort: 445, TCPFlags: 0x0, IngressInterface: outside, EgressInterface: inside, IngressZone: outside, EgressZone: inside, DE: Primary Detection Engine (30f92b52-baa0-11e7-984b-a98ffa569947), Policy: farfw_acp, ConnectType: End, AccessControlRuleName: _malware_ips_check, AccessControlRuleAction: Block, AccessControlRuleReason: File Block, Prefilter Policy: Unknown, UserName: No Authentication Required, Client: NetBIOS-ssn (SMB) client, ApplicationProtocol: NetBIOS-ssn (SMB), FileCount: 1, InitiatorPackets: 26, ResponderPackets: 14, InitiatorBytes: 24104, ResponderBytes: 3376, NAPPolicy: Balanced Security and Connectivity, DNSResponseType: No Error, Sinkhole: Unknown, URLCategory: Unknown, URLReputation: Risk unknown

Sys log message when sending from server to workstation:

<42>Feb 14 18:40:30 farfwfp farfwfp: Protocol: TCP, SrcIP: X.X.X.X, OriginalClientIP: ::, DstIP: X.X.X.X, SrcPort: 57961, DstPort: 445, TCPFlags: 0x0, IngressInterface: inside, EgressInterface: outside, IngressZone: inside, EgressZone: outside, DE: Primary Detection Engine (30f92b52-baa0-11e7-984b-a98ffa569947), Policy: farfw_acp, ConnectType: End, AccessControlRuleName: _malware_ips_check, AccessControlRuleAction: Block, AccessControlRuleReason: File Block, Prefilter Policy: Unknown, UserName: No Authentication Required, Client: NetBIOS-ssn (SMB) client, ApplicationProtocol: NetBIOS-ssn (SMB), FileCount: 1, InitiatorPackets: 26, ResponderPackets: 17, InitiatorBytes: 22812, ResponderBytes: 9042, NAPPolicy: Balanced Security and Connectivity, DNSResponseType: No Error, Sinkhole: Unknown, URLCategory: Unknown, URLReputation: Risk unknown

near fw file rulefar fw file rule

ghalleen · ‎02-15-2018

I recommend opening a TAC case. You should not be seeing this behavior.

laurin.beckhusen · ‎02-19-2018

That is what I am leaning towards.

I have noticed the timings are not always the same. I.E. sometimes I don't have to leave the session open for 10 mins before it allows me to transfer the file and sometimes I have to leave it open longer....

John Telford · ‎02-20-2018

Hi,

1 )Trying to figure out why if I leave the smb session open, I can copy over the file eventually from my workstation to the server.

Agreed a TAC case is in order. Perhaps the farfw is running different version code. It may require a Network Access Policy setup in preprocessing but ONLY on the advice of Cisco TAC

2) does file blocking not work in monitor mode? Why is the near FP module not even blocking the file.

We cant see your file policy in the screen shot for the nearfw but I assume it is set to 'Detect' and the answer would be File blocking does NOT work in detect mode. You should see an event of the file transfer in the logs though. Interesting to know if the nearfw consistently sees the file transfer regardless of when the file is sent.

Regards

laurin.beckhusen · ‎02-23-2018

Hi John,

I will look into the pre-processing policy. both fw's are running the same FP version 6.2.2-3. Haven't created a ticket for this, but planning on doing so.

File Policy is set for action block. I created a ticket for for the near firewall not even sending a connection event / syslog alert for the policy. It records an event of "detect" even though the file policy is set to block. TAC wanted me to take it out of monitor-only mode and test. I am planning on doing it this weekend to see if the file policy blocks the traffic and generates the expected connection event / syslog entry of block.

Thanks for the reply!