Firepower malware inspection on HTTPS traffic

Dieselboy · August 23, 2018, 09:10:33 AM

I've set up a test of SSL decryption on the ASA Firepower module. Internet web SSL traffic is decrypted and I have the green padlock icon. The root certs had been pushed out via GPO a little while back. The docs state that, after decryption, the Access Control Policy is evaluated with the decrypted traffic (ie after decryption).

Quote:
SSL Rule 5: Decrypt - Resign is the final rule. If traffic matches this rule, the system re-signs the server certificate with an uploaded CA certificate, then acts as a man-in-the-middle to decrypt traffic. The decrypted traffic is then evaluated against access control rules. Access control rules treat decrypted and unencrypted traffic identically. The system can block traffic as a result of this additional inspection. All remaining traffic is reencrypted before being allowed to the destination. Traffic that does not match the SSL rule continues to the next rule.

Ref: https://www.cisco.com/c/en/us/td/docs/security/firepower/620/configuration/guide/fpmc-config-guide-v62/getting_started_with_ssl_rules.html

However, I have a rule to match HTTPS traffic and check it for malware, but the malware checking does not appear to be happening. I can try to download malware over http onto the test machine and the traffic is blocked. I can try the same url using https:// and the download completes successfully.

Has anyone had any experience with doing this (decrypting and checking https traffic for malware)? We ran a rules debug on the module and downloaded a test file. The rule thats matched is the correct one (with the malware inspection policy applied) but the result is "allow". I've tried matching using tcp/443 and matching HTTP and HTTPS applications - same result. The file policy was configured to match "HTTP" for the non-encrypted rule, there's no HTTPS application in the file policy rule like there is in the ACP rule, though I tried matching "any" there and still the same. I couldn't find any doc specifically for this either..

deanwebb · August 23, 2018, 01:29:49 PM

Can it not decrypt inbound HTTPS traffic?

Dieselboy · August 23, 2018, 06:06:06 PM

Yes it can. Right now I have outbound https decrypted. Will look into this later.

wintermute000 · August 24, 2018, 06:51:01 PM

Keep us posted.

Dieselboy · August 24, 2018, 10:45:14 PM

Yea :/ shame really because it's just a supported and enhanced version of the open source free snort which has good reviews. There are performance issues if you turn everything on basically. But that's not anything surprising really. I do wonder if the bad reviews stem from people not having much experience with Unix and/or snort; or having wild (may be magical) expectations beyond physical capabilities.

Do you have any recommendations for an alternative?

Let's see what tac say about my issue. Then only reason I want to decrypt SSL is to check for issues in this way so it's a must for me, most of my network traffic is SSL, dammit 😁

Dieselboy · August 28, 2018, 02:45:52 AM

Cisco labbed this up and no issue for them. Which is nice.

They're going to check my logs and in the meantime I've asked them if my rules are any different to theirs, suggesting I may have weird config on my side. Good news is that SSL traffic can be inspected for nasties, which is what I want.

Until next time...

Dieselboy · September 02, 2018, 09:58:09 PM

Confirmed bug.

CSCvm32267

wintermute000 · September 06, 2018, 05:35:04 AM

BOOM another bug under your belt

That big fat 0 next to known fixed releases makes me a sad panda

Dieselboy · September 07, 2018, 12:20:29 AM

This job I have been at for the past 4 / 5 years is jinxed; if there's a bug then we'll find it. Cisco once come back to me to ask me if I were working on bug scrubs. I wasn't, I was just trying to get a 2921 stable!

The TAC engineer said the bug ID was internal only, so I didnt bother looking it up. I have just looked it up now and it's not entirely correct. It's not only EICAR files but ALL HTTPS malware is allowed through. Initially, firepower was giving a rule action of "ALLOW" but after trying out some different ways of achieving the same design (eg, setting the application match from HTTP to ANY and deleting and re-creating the policies) now we are getting the action = BLOCK but firepower is not terminating the connection. This means the malware is being downloaded successfully without any blocking action.

At least it's a sev 2 so hope it gets picked up. Today I asked them for an update and for an interim workaround in lieu of a fix. No response so far.

Id be grateful if someone else could set this up then log a tac case to give weight to this bug being fixed

Otanx · September 07, 2018, 09:10:56 AM

That is a nasty bug. I would really hope there is a work around. That is a core feature. I really wanted to like FTD, but too many limitations and/or bugs.

-Otanx

Dieselboy · September 10, 2018, 03:50:58 AM

Quote from: Otanx on September 07, 2018, 09:10:56 AM
That is a nasty bug. I would really hope there is a work around. That is a core feature. I really wanted to like FTD, but too many limitations and/or bugs.

-Otanx

This is not FTD, I have not yet moved over to FTD. I'm not sure what features are missing (I need to do research). So I am not sure if this bug affects FTD. I've just asked TAC the question. As usual TAC don't really want to help and are giving the "I've logged the bug, it's with them now" response.
I've communicated to TAC that;
- I need a fix
- In lieu of a fix, I need a workaround this week
- I've asked if this is affecting FTD

If the issue is not present in FTD (I'm taking it that this issue is not present in FTD) then it might be the kick up the jacksy I need to move to FTD. Basically, a workaround might be to migrate to FTD but TAC have advised me on is that there is no workaround so far; I'm not sure if they have considered FTD.