Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Nikolai_Borhart
Contributor

Question to Https Inspection Policy


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!

0 Kudos
25 Replies
PhoneBoy
Admin
Admin

What specifically is in the group object?
0 Kudos
Nikolai_Borhart
Contributor

Groupobject contain host or Networks objekts. 

0 Kudos
PhoneBoy
Admin
Admin

Sounds like a bug that the TAC should investigate.
0 Kudos
Daniel_Kavan
Advisor

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.

0 Kudos
_Val_
Admin
Admin

Inbound or outbound inspection?

0 Kudos
Daniel_Kavan
Advisor

inbound

0 Kudos
_Val_
Admin
Admin

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.

0 Kudos
Daniel_Kavan
Advisor

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

0 Kudos
_Val_
Admin
Admin

Then yes, you can

0 Kudos
Daniel_Kavan
Advisor

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.

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
Daniel_Kavan
Advisor

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_
Admin
Admin

Sorry to mislead you. 

0 Kudos
Daniel_Kavan
Advisor

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
Advisor

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?

 

0 Kudos
_Val_
Admin
Admin

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?

0 Kudos
Daniel_Kavan
Advisor

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

 

0 Kudos
_Val_
Admin
Admin

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
Advisor

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.

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
Daniel_Kavan
Advisor

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.  

0 Kudos
_Val_
Admin
Admin

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. 

0 Kudos
Daniel_Kavan
Advisor

Yes.

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

0 Kudos
_Val_
Admin
Admin

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
Advisor

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.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events