Question to Https Inspection Policy

[Nikolai_Borhart]

Hello Community,

I need help designing the Https Inspection Policy rules.

I learned this week that it's important where and what type of https inspection bypass rule you have to place.

I have the R80.30 version with the Take 155 in use.

I use the following objects in the Https Inspection Policy:
- Any as source or destination
- Ip addresses as source or destination
- Groups objects as source or destination
- Access Role's (LDAP groups from domain controller, AD Query)
- Category as Services

Currently, I have set up the Https Inspection Policy as follows:

1. Bypass IP base (IP address, host object, network object or group objects)
2. Bypass Service with Category (Src: Host,Network, Group Object, Any Dst: Internet Srv: Category)
3. Bypass Src:Access Role Dst: Internet Srv: Category
4. Inspect Src: Access Role Dst: Internet Srv:Any
5. Bypass Cleanup Rule Src:any Dst:any Srv:any

Now I've tried the following rules construct:
1. Bypass Src: Group Object Dst: Internet Srv:Custom_Category
2. Bypass Src: Access Role Dst: Internet Srv: Custom_Category(same as above)
3. Inspect Src:Access Role Dst: Internet Srv:Any

Here, the rules with the group object do not match first, the rules with the access role match. But i dont know why.

From the past I learned that you should define IP-Base Bypass rules first and then the Category/Application Bypass Rules.

But what about bypass Policy with Access Role objects, where should the AccessRole objects be placed?
Is there a specific order in which I should build the HTTPS Inspection Policy?

And had anyone already make experience with the R80.40 when updatable objects are in the https inspction Policy add?

Thank!

[PhoneBoy]

What specifically is in the group object?

[Nikolai_Borhart]

Groupobject contain host or Networks objekts. 

[PhoneBoy]

Sounds like a bug that the TAC should investigate.

[Daniel_Kavan]

Can I have a group of web servers (different IP addresses) grp.websites as the destination in https inspection policy or does each website need to be listed in destination separately.   I'm pretty sure you can't have groups in an inspection policy or at least you weren't able to at one time.  I'm using R81 exclusively today, manager and gw.

[_Val_]

Inbound or outbound inspection?

[Daniel_Kavan]

inbound

[_Val_]

For inbound, you use web site own certificate, with private keys. Does not make sense to group those, unless all your web servers are using exactly the same certificate, which is extremely unlikely.

[Daniel_Kavan]

Yes, I have 7 sites(objects with different IPs)  all using the same wildcard certificate.

[_Val_]

Then yes, you can

[Daniel_Kavan]

No, having them all in a group didn't work for us.  We had to list each one out.   A group object like grp.websites isn't recognized of traversed.

[_Val_]

Now you lost me. You do know an answer to your question, but you ask it anyways? 🙂

[Daniel_Kavan]

No, I went live with a group  after your post in production just after 10 am and it didn't work.  Then, after an 45 minutes I switched to the individual sites.

[_Val_]

Sorry to mislead you. 

[Daniel_Kavan]

NO worries Val,  & no down time!  Thanks for your efforts!   It doesn't do anything with a group object, so the inspection was still by-passed.

[Daniel_Kavan]

I actually have a new question RE: https inspection.

An admin I work with said this after I started inspecting taffic.

"The app servers don't actually use http protocol they use the port because it's commonly open. This will only cause problems but not actually add any protection to inspect the app server traffic"

Would I be correct to reply that the IPS protections involve much more than looking at the http protocol?

[_Val_]

In other words, they are oding TCP port 80', but not HTTP. Depending on how exactly they build the connection, and what flows in that tcp session, there might be an issue with some of http enforcement, if the traffic is matched on a rule with HTTP service, which uses a handler, or on a rule with ANY service. 

What are you trying to achieve, exactly?

[Daniel_Kavan]

I'm trying to achieve the best security I can with TCP port 443 traffic, not using the HTTP protocol.  

[_Val_]

I am a bit confused. You do not need to HTTPS Inspection to have IPS for TCP port 80. The whole reason to run HTTPSi is to look inside encrypted traffic.

IPS and other software blade are inspecting all clear text traffic, on expected protocols. In your case, if someone is violating TCP state, it will be discovered and protected regardless on application level protocol using that session, on TCP level. In your case, I would be more concerned about false positive detections, since parsers will be expecting HTTP and failing to parse it. 

Need to see the nature of applications, their risk level and desired security level for your specific user case, to give you any further guidance.  

[Daniel_Kavan]

443 not 80, my bad.  The traffic comes in on 443.  I decrypt it, inspect it, re-encrypt it.  However it's not HTTP traffic.

[_Val_]

If it is not HTTPS protocol, you cannot decrypt and inspect it in the first place. 

[Daniel_Kavan]

The https is coming in being decrypted, inspected and then re-encrypted.  I agree it's confusing.  The  developer is stating what is inside.  The app servers don't actually use http protocol they use the port because it's commonly open.  

[_Val_]

Uh, now I get it. You encrypt non-HTTP with TLS, correct?

Same statement as I said above: as long as you can decrypt, the traffic is being inspected by advanced blades, according to your Threat Prevention policy. 

[Daniel_Kavan]

Yes.

So, in this case, is it good/safe to continue to inspect this traffic or it can cause problems?

[_Val_]

You may want to keep an eye on HTTP related false-positive. I would add an exception for web related IPS protections, but it is hard to make any general recommendation without more details.

[Daniel_Kavan]

So, in general it's going to be management decision.  We'll discuss as a team if the non-HTTP IPS protections outweigh the risk of a false positive.    Thank you for the explanation.