Question - BUG - DPI appears to be on by default

Hi folks,

while working on a thread in the XG forum I checked some of firewall settings and found I think that the DPI is on by default.The screenshots below do not show the DPI as highlighted, on the rules where it is selected and not selected.

Ian

 

The first screenshot uses the DPI and where as the second screenshot is of an internal connection.

Am I interpreting the screenshots wrong or is there a bug?

  • The way it works (confirmed on my box):

     

    If the firewall rule "Use web proxy instead of DPI engine" is checked then PRX is green and the text is "Use proxy".

    If the firewall rule "Use web proxy instead of DPI engine" is not checked then PRX is white and the text is "Use DPI engine".

     

    Can you confirm this is what you see?

  • In reply to Michael Dunn:

    Hi Michael,

    I can confirm what you posted. My issue is that DPI should not be on a LAN to LAN connection unless enabled by adding a web function in the web drop down box. The rule has NONE in that box and has never used proxy in the v17 versions.

    Ian

  • In reply to rfcat_vk:

    DPI does not care whether it is LAN to LAN or not.

    In your screen shot, it shows that Web is enabled with Allow All policy. Which means that the rule as stands will do port-agnostic HTTP traffic detection. Then depending on what SSL/TLS inspection rule matches it may or may not decrypt TLS traffic and then do HTTP traffic detection on that data. It will apply the Allow All web policy to any HTTP traffic.

    Now if you did not have a Web policy, AV scanning, or App control (all three are white in the summary) it will not do port-agnostic HTTP detection, and you could argue the it should not say "Use DPI engine". It does say it. Of course it will still apply SSL/TLS inspection rules and if there is TLS may decrypt the traffic.

    So there might be a case for setting it to "--" in some instances, but for your scenario Use DPI engine is correct.

    But to be clear, there is nothing that cares what the source and destination zone are when it comes to either web or dpi mode.

  • In reply to Michael Dunn:

    Hi Michael,

    the first screenshot is using the DPI with web as you point that is correct. I posted that as a reference to the DPI box colour. The second screenshot is not using the DPI or any web settings it does have application and IPS but that should not be triggering DPI from my understanding.

    I will remove the allow all from the second rule which is a hangover from a previous since fixed bug.

    Ian

    Update - I have removed all web, application and IPS settings and still the rule shows DPI.

  • Hi Michael,

    As far I understood from your explanation regardless of Zone configuration(LAN-LAN, LAN-WAN) DPI engine will be enable by default. I've tested this scenario as you mentioned in which I have configured LAN-WAN rule with NONE Web Policy and applied SSL/TLS policy with (ANY Source and destination )which in result showed me HTTPS scanning getting applied to that HTTPS website.

    Now my question here is, Earlier in v17 if we set NONE policy then it means that webproxy will not be applied but now with v18 lets say if I want to do some troubleshooting without Legacy/DPI based webproxy then how is it possible to check?

    I tried disabling SSL/TLS inspection option in advance settings in SSL/TLS inspection global option which in result showed me website without any proxy ( DPI/legacy ) getting involved but that is not a solution because let's say if I want to test for a specific machine without any policy(Legacy/DPI) like we try to check with v17 i.e. as NONE web policy how can I verify it?

  • In reply to rfcat_vk:

    rfcat_vk

    Update - I have removed all web, application and IPS settings and still the rule shows DPI.

     
    There is a minor bug in the UI, which will be fixed post-GA.  There is no problem in the backend.

     

     

    This is a checkbox.  Logically a checkbox has two states, checked and unchecked.  So what we coded was if the box is checked, display the summary one way "Use proxy" and if it is unchecked display the summary a different way "Use DPI engine".  The problem is that this checkbox is actually tri-state.  The third state is disabled (and unchecked).

    The checkbox is disabled if there is no web policy or malware scanning (you can see this when you edit the rule).  In this case we summarize as "Use DPI engine" because it is actually unchecked, when we should summarize as "--" because it is disabled.

  • In reply to James Panther:

    James Panther

    As far I understood from your explanation regardless of Zone configuration(LAN-LAN, LAN-WAN) DPI engine will be enable by default. I've tested this scenario as you mentioned in which I have configured LAN-WAN rule with NONE Web Policy and applied SSL/TLS policy with (ANY Source and destination )which in result showed me HTTPS scanning getting applied to that HTTPS website.

    Now my question here is, Earlier in v17 if we set NONE policy then it means that webproxy will not be applied but now with v18 lets say if I want to do some troubleshooting without Legacy/DPI based webproxy then how is it possible to check?

    I tried disabling SSL/TLS inspection option in advance settings in SSL/TLS inspection global option which in result showed me website without any proxy ( DPI/legacy ) getting involved but that is not a solution because let's say if I want to test for a specific machine without any policy(Legacy/DPI) like we try to check with v17 i.e. as NONE web policy how can I verify it? 

    Hi James,

    There are two different systems involved. I'll have to use some internal names.

    The first is sslx. This is the new way of decrypting TLS traffic, and it is configured using the SSL/TLS Inspection Rules. For your purposes, you can say it is implemented in snort.

    The second is web-in-snort, which in the UI is called DPI mode. Web in snort works on HTTP traffic, as well HTTP traffic that comes from sslx (ie HTTPS). It is configured in the Firewall Rules. It is also implemented in snort.

    To go further, IPS (intrusion prevention system) is also in snort. And Application policy is also in snort. And traffic shaping is in snort. And Advanced Threat Protection is in snort.

    So, if you are asking "how do I make sure that nothing is looking at the HTTP traffic" then what you want to do is disable web-in-snort or DPI mode. To do that make sure that the traffic is hitting a firewall rule that does not has web policy None and no malware scanning (eg the "use proxy" button is disabled).

    If you are asking "how do I make sure that nothing is interfering with TLS connection" then what you want to do is not decrypt traffic. Make sure the traffic is hitting a SSL/TLS Inspection Rule for Do not Decrypt with Maximum Compatibility.

    The confusion/complication is the HTTPS traffic is both TLS (sslx) and HTTP (web-in-snort). But in v18 just because you are doing TLS decryption does not mean you are doing web-in-snort (DPI mode) and vice versa. I know it may not make sense but you can have decrypted HTTPS traffic and be using the Certificate Authority from the XG and still not be using DPI mode.

    If you don't want HTTPS to be looked at all, you need to make sure that the firewall rule does not have any web policy or malware scanning, and that the TLS rule is do not decrypt.  But be aware that even then, snort will be looking at the traffic in order to enforce all the other things that snort enforces (App control, IPS, ATP, traffic shaping).

     

    The decoupling of TLS inspection (sslx) from HTTP filtering (web-in-snort / DPI mode) allows everything to be port and protocol agnostic. The TLS decryption rules also apply to SSH sessions, smtps, and other TLS encrypted communication.  The HTTP filtering is port agnostic.

    Think, if you you will, about WebAdmin which is HTTPS going to port 4444.  In 17.5 traffic like this this would not be caught by the transparent mode web proxy.  In 18.0 DPI mode it is.

  • In reply to Michael Dunn:

    Hi Michael,

    in summary what you are saying is we should build our own SSL/TLS inspection rule for each device/device group/users and disable the default rules?

    I would like to suggest that the default rules be unlocked so they can be the default at the bottom instead of at the top. You cannot move your own rules above the default XG rues.

    Ian

  • In reply to rfcat_vk:

    Ian, That is not what I am saying at all.

    The two rules that are in there at the top are for global exclusions for SSL inspections. Unless you were specifically trying to have one of those decrypted, there is no reason to not have them at the top. It is just like Web Exceptions.

    Why are you trying to do that would make you want a higher priority rule?

  • In reply to Michael Dunn:

    Hi Michael,

    All traffic appears to pass through the top rule and there does not appear to be away of passing traffic through the second rule. The second rule (application) never shows traffic. I do have a third rule which has specific devices which does show traffic.

    Ian

  • In reply to rfcat_vk:

    It works like a firewall rule - it is a top-down prioritized list and a given traffic only "hits" one rule.

    Lets say you have:
    Rule 1: Exclusion by website (URL groups Local/Managed TLS exclusion list)
    Rule 2: Exclusion by application
    Rule 3: source is your tv, do not decrypt
    Rule 4: source is your computer, decrypt

    So first your computer goes to adobe.com. That is in the managed TLS exclusion list which means Do not decrypt.
    Then your computer goes to mylocalstore.com. That misses Rule 1,2,3 and hits Rule 4. It is decrypted.
    Now your phone goes to mylocalstore.com. That misses Rule 1,2,3, and 4. It missed every rule. It is not decrypted.
    Then your samsung TV goes to samsungtvapps.com, it hits rule 3 which is Do not decrypt.

  • In reply to Michael Dunn:

    Hi Michael,

    thank you. I misunderstood the two default rules that only apply to URLs and applications in their exclusion lists.

    With that better understanding in mind I will have another go at using the SSL/TLS rules.

    Ian

  • In reply to Michael Dunn:

    Michael Dunn

    So, if you are asking "how do I make sure that nothing is looking at the HTTP traffic" then what you want to do is disable web-in-snort or DPI mode. To do that make sure that the traffic is hitting a firewall rule that does not has web policy None and no malware scanning (eg the "use proxy" button is disabled).

    If you are asking "how do I make sure that nothing is interfering with TLS connection" then what you want to do is not decrypt traffic. Make sure the traffic is hitting a SSL/TLS Inspection Rule for Do not Decrypt with Maximum Compatibility.

    , can you explain the point "To do that make sure that the traffic is hitting a firewall rule that does not has web policy None and no malware scanning (eg the "use proxy" button is disabled)."

    regards

  • In reply to lferrara:

    Michael Dunn

    So, if you are asking "how do I make sure that nothing is looking at the HTTP traffic" then what you want to do is disable web-in-snort or DPI mode. To do that make sure that the traffic is hitting a firewall rule that does not has web policy None and no malware scanning (eg the "use proxy" button is disabled).

    Typo. Sorry. See the "does not has" I think I wrote it one way then edited the sentence to phrase it differently and it ended up jumbled. And since I wrote that I have learned more.
    It should say:
    To do that make sure that the traffic is hitting a firewall rule that has web policy None and has no malware scanning (eg the "use proxy" button is disabled).

    In other words - create a new firewall rule. See how the "Web filtering" section is not expanded. If you expand the Web policy is none, the Scan HTTP and decrypted HTTPS is not checked, and Use Web proxy instead of DPI engine is disabled. Traffic matching that firewall rule will have nothing looking at the HTTP traffic. Except... If the firewall rule has "identify and control applications (App control)" then it may still look at the HTTP traffic, and if you have the global setting ATP (Advanced Threat Protection) then it will still look at HTTP traffic.

    There is a known issue with ATP... Turning it on intentionally turns on HTTP scanning for all traffic regardless of rules. It is working as intended but having unintended consequences. I do not know if/when/how we will resolve.

  • In reply to rfcat_vk:

    Thanks for your input on this.

    We're not going to change the way this is displayed in the product for now. I appreciate that the meaning of this can easily be misunderstood, but sometimes it's hard to be completely unambiguous when you're also trying to pack a lot of information into a small space. The text represents the state of the option, rather than a specific statement about what will happen to matching traffic. It simply means that if there is any web scanning or policy to be enforced on port 80/443, it will be done by the DPI engine rather than the proxy.

    We'll certainly look again at a broad cross-section of UI/UX feedback once v18 is released and consider any changes that may be necessary in future versions.

    Regards

    Rich