FirePOWER services on ASA 5506 or similar SMB

[Dieselboy]

I have a friend who owns a food factory. It's a new business and I get the impression things are a bit turbulent. Months ago (almost a year) I warned him of the cryptolocker virus and explained some key things;
1. dont visit dodgy websites or click on things which seem dodgy
2. dont open email attachments from whom you're not expecting emails or attachments from
3. dont open attachments from people you know, if you're not expecting them to contact you or send you anything either (same goes for links in emails)

But, alas the unfortunate has happened. He sent me a photo asking me how he can open his documents as they are all weird.

I was thinking that possibly an ASA5506 with firepower would be a good idea to help stop this from happening again in the future. But I am aware that more and more things these days are using HTTPS. SSL certs are free these days so anyone can set up HTTPS and not get security warnings.

Is it possible to inspect HTTPS traffic from anywhere to protect the end users?

One use-case is that we use Google Apps. and all connectivity is over https. So, if someone was to use GMAIL web app. or even use Outlook, the connection is encypted so the ASA will pass it through. With this, is there something I am missing that would allow the end users to be protected in such use-case?

Has anyone done such a thing? I'm almost sure  that I can get him SSL certs for free, if this helps.

[wintermute000]

I know you're a Cisco fanboy so you might not have noticed   but in the NGFW market, SSL decryption is normal, even in SMB class devices.

In general it goes like this, regardless of what vendor you pick. You don't need a cert, you need a CA....

1.) Have a signing CA you control that is trusted by all devices on the network. 99.9% of the time that's just the CA in your MS domain and push its public keys and chain of trust via GPO. If he hasn't got a 'real' domain setup, you can still do it, but you'd have to also manually import the signing CA and the root CA's public keys onto all PCs, which is where AD/GPO makes it really easy.

2.) You need a CA you control because you need the private key. This is loaded on to your NGFW. Configure SSL decryption.

3.) Now what happens is that the NGFW does MITM with all HTTPS traffic. It terminates it on behalf of the client device, rips out the HTTP, generates a NEW HTTPS header and signs it using the CA private key you imported. Your hosts trust the CA so any cert it generates is valid according to the client browser.

4.) As your NGFW is cracking the HTTPS open it can do all the threat prevention/IPS/AV good stuff as well.

I'd personally go for a Fortigate, say a 60E would be plenty for ~50 users. Take their numbers with a real heavy pinch of salt though.

FIREPOWER is late to the game and I would not go for a VM smashed on top of an ancient aging codebase (ASA) that's just recently had BGP and route-based VPNs shoehorned in. Esp in a SMB class box that can probably do without the overhead. Do you really want to manage 2 things..... also I would bet you that in 24 months ASA is dead and its sourcefire only from there on in. Pure sourcefire I'd consider but at my VAR its all Palo (hi) / Fortinet (low) with a smattering of checkpoint. The only people buying Cisco (security products) are the ones who basically specify in the requirements phase 'it must be cisco' and can't give you any actual reasons why.


Having said all that, most of the 'locker incidents out there spread via email. Now a NGFW can scrub email as well but most people run their email through something separate, whether cloud based or on-prem (yech!)

[Dieselboy]

Thanks mate! You've literally answered all my questions and cleared up my confusion. I thought that the firewall would need to do MITM but then thought that the whole SSL protocol detect it and stop it, hence the confusion. So, we need the private key of the CA, seems a bit iffy to push that to devices, though? How do you protect against that being hacked?

I'm happy to use Palo, the previous company I worked for have been implementing those instead of 2900 routers for a long time for the hosted customers.

We use Google Apps for our business email because we have a free account that you cannot get anymore. Client <-> google apps is either via https or encrypted imap/smtp so would we still be able to inspect it? ie not just SSL.

I honestly don't know what network he has, I've been trying to avoid it (can-o-worms theory) but I think I can offer some assistance. Don't want a friend to suffer if we can avoid it.

Is there any way of doing this without setting up a private CA? I've been using StartSSL for all my certs because I basically use their CA and it's nice and convenient not having to manage a CA. The senior guy at my last place explained how his experience, in previous employment their private CA was a laptop that was powered off and stored in a safe and never turned on unless it was a must, to protect the ROOT CA (the laptop was the root ca). An intermediate CA was used to publish certs. Don't really want to have that consideration, but I would like to inspect encrypted traffic for security reasons. Of course, I'll bite the bullet if there's no other option. But for my friend, if he just has a Windows WORKGROUP type setup which I think he does, it starts getting pretty involved I guess.

[wintermute000]

No way around the need for the key. The fire wall needs to sign trusted certificates on the fly. All decent firewalls will have it encrypted to the wazoo and non exportable
This is why people use is sub ordinate signing CA so they don't have to give the root key out

[SimonV]

hey wintermute, we had also explored the ssl decryption route on Palo Alto but found that a lot of applications and website cannot be decrypted due to certificate pinning. 

https://live.paloaltonetworks.com/t5/Configuration-Articles/List-of-Applications-Excluded-from-SSL-Decryption/ta-p/62201

The list only mentions a few but if you go down in the comments, and look at the sites that have started implementing it, you could conclude that ssl-decrypt is pretty much broken now.  Your thoughts?

[wintermute000]

Well its security AKA whack-a-mole so I'm not surprised. I actually wasn't aware it was such a big issue, I haven't been the primary on a FW implementation for a few years now (phew LOL).

I still reckon its of massive value as you can still decrypt most https websites. If you don't decrypt SSL at all, all you have is very blunt URL filtering options based on the initial URL and a few certificate attributes, let alone being unable to apply any of the IPS special sauce to the contents. We certainly have more than a handful of big implementations doing https decrypt and its always requested as a mandatory requirement when sizing up NGFW projects. But I will go ask our FW guys how they deal with this topic if the customer raises it. Perhaps they just don't say much and the customer doesn't notice as the bypass list is there by default (which I do agree is kinda backward for a security product - though that's Palo for you, gotta be slick!)...

Don't forget too that on a Palo app-id is still awesome even if decrypt isn't turned on, so you can still enforce per-app policy through that, though of course no content inspection if its not cracking it open. I will freely admit I'm still not completely up to speed on how best to craft Palo rules on a per URL or a per-app or per-service basis and the exact order of operations, I guess that's why I'm not in the sec team  


Also according to stuff like this, certificate pinning is likely to stay in the minority as its too much a PITA
https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead

I'm sure with things like certificate pinning and SPDY things will keep getting fun for the firewall jockeys


On an aside, I just read that PAN has a bigger market cap than juniper. That is freakin ridiculous, they just flog firewalls.... Juniper runs SP core infra everywhere AND does firewalls and normal routers and switches....

[deanwebb]

Open all email attachments inside a VM.

If the VM gets ransomware'd, delete the VM, spin up a new one, and don't open that attachment ever again.

NGFW isn't going to scan your emails and those pinned certs can also mess things up for you, NGFW-wise.

See if the Gmail box can be kitted out with some add-on to do email scanning. If not, consider getting off gmail and on to a hosted Exchange solution.

But copy all attachments to a VM, and then open them on that VM. You're welcome.

[wintermute000]

That will never fly in SMB

[Otanx]

Open all email attachments inside a VM.

This is basically what FireEye MX does. It is a sandbox that tries to execute all attachments for email before delivering them. You can have it even follow links, and check the URLs as well.

As for certificate pinning this is typically a non-issue as browsers will ignore the pinning if a certificate is issued by a manually trusted CA. This way a company can still MITM their traffic without causing issues. However, if someone tried to issue a certificate from a "real" Internet CA it would cause an alert.

As for the list from PA that was linked I am guessing those applicaitons are doing something special specifically to break intercept, or just something weird. Note that the link is from 2012. A lot changes in 4 years.

-Otanx

[wintermute000]

Spoke with our firewall guys. Apparently this issue blew up in the last year or two when a ton of big sites started doing it. They reckon SSL decryption is on the way out,.if you need to look inside, back to traditional proxy whether cloud or on premise
Oh yeah forgot about sand boxing. Palo had wildfire, same same. I thought Dean was taking about manually using a vm LOL

[SimonV]

As for certificate pinning this is typically a non-issue as browsers will ignore the pinning if a certificate is issued by a manually trusted CA. This way a company can still MITM their traffic without causing issues. However, if someone tried to issue a certificate from a "real" Internet CA it would cause an alert.

Interesting. I just read the Wiki article on it and apparently it can be manually disabled in Chrome and Firefox, but not in the MS browsers, which are still the standard in most enterprises. 

As for the list from PA that was linked I am guessing those applicaitons are doing something special specifically to break intercept, or just something weird. Note that the link is from 2012. A lot changes in 4 years.

Last updated on on ‎11-30-2016 02:50 PM

[deanwebb]

Spoke with our firewall guys. Apparently this issue blew up in the last year or two when a ton of big sites started doing it. They reckon SSL decryption is on the way out,.if you need to look inside, back to traditional proxy whether cloud or on premise
Oh yeah forgot about sand boxing. Palo had wildfire, same same. I thought Dean was taking about manually using a vm LOL

I actually was talking about using a manual VM.

This is a solution for the HR people at more than one firm that I know of. They're the guys that have the highest infection rates because it's their job to open all attachments, suspicious or not. So, they all have a VM they log into where they open attachments. Payload goes off, VM gets infected, they just delete it at the end of the day and spin it up again. The VM itself is walled off so it's treated like an outside website.

[Otanx]

From the wiki,

The Chromium browser disables pinning for certificate chains with private root certificates to enable various corporate content inspection scanners[4] and web debugging tools (such as mitmproxy or Fiddler). The RFC 7469 standard recommends disabling pinning violation reports for "user-defined" root certificates, where it is "acceptable" for the browser to disable pin validation.[5]

So if a company wants to MITM SSL certificate pinning allows for that without disabling it all the way. Also IE/Edge does not support pinning at all.

I missed the last updated line. My bad. I don't think that the list is because of pinning though. I have a SSL intercept running, and I can get to some of the sites they list as broken. Also I can get to Google using Chrome, and get a green lock. I think most of the list is because there is a local application running that uses hard coded certificate stores, and not the system store. Not really a pinning issue as a no way to update the trusted CA list issue.

I don't think SSLi is dead in any way. More and more companies will start doing it to get visibility on outbound traffic. As more malware is using SSL, and piggy backing on real sites with trusted certs it is going to be more important to inspect inside the encrypted session. As an example there was malware that did all it's command and control through Google Docs. This would be very hard to detect without SSLi especially if the company uses Google Docs.

-Otanx