Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 18 replies
  • Subscribers 29 subscribers
  • Views 5529 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

question on IPS policy best practice and capabilities for websites behind CDN reverse proxy and XG firewall with IPS

wilder

Pardon the basic question but we're coming from an environment that is set up differently and are considering XG with network IPS. Our current config uses a traditional firewall which receives "shun" style blocks from an IDS as opposed to (inline) IPS. Within the environment we have web servers in the DMZ which serve "origin" content through to a content distribution network which acts as a reverse proxy for our public sites. Consequently, for network traffic into the DMZ web servers that has an IDS signature hit, if our policy were set up to simply "shun" the offending "source" IP of the request (which is the proxy node in the CDN) as opposed to the "True Client IP", we'd shoot ourselves in the foot.

If we move to using inline IPS with XG, is it possible to set the policy such that it performs a session drop or other similar action based on the "true client IP", if the traffic involves an inbound web request to the DMZ? Or what is the best practice to avoid issues with traffic that flows through from the CDN reverse proxy? We don't want to inadvertently block "clean" traffic just because we're reverse proxying, and even though we will also utilize WAF, we don't want to leave http/https inbound traffic simply uninspected via IPS. Is the alternative, simpler answer to just have the policy set up to do a reset as the action? Open to better ideas and hopefully the explanation is clear. Thanks so much in advance for your help/guidance.



This thread was automatically locked due to age.
Parents
  • 0

    Hi  

    There are preconfigured rule available in IPS (Intrusion Prevention) which can be applied on the firewall rule from where your CDN server traffic passing from the XG firewall and there are other configurations which can be set as per your requirement, please refer to the article - https://community.sophos.com/kb/en-us/124015

    You can visit https://docs.sophos.com/nsg/sophos-firewall/v16058/Help/en-us/webhelp/onlinehelp/index.html#page/onlinehelp/IpsPolicyManage.html

  • 0 in reply to Keyur

    Hi Keyur,

     

    There is good IPS related content at those links. However, I'm missing where it speaks to the scenario I inquired about, could you offer any clues of where more specifically you were referencing? Pardon in advance if I missed it.

     

    Thank you!

  • 0 in reply to wilder

    Hi  

    IPS policies are generally applicable on firewall rules configured such as WAN to DMZ or DMZ to WAN, so preconfigured policies are available to apply on the firewall rules, you can apply the IPS policy on the firewall rule from where the CDN server traffic is traversing.

    This video will provide more information - https://www.youtube.com/watch?v=uyRLYXQ5h90 

    For the exception of IPS signature - https://community.sophos.com/kb/en-us/132879

  • 0 in reply to Keyur

    Helpful via video to be able to see how the IPS policies are applied so thank you for sharing that, Keyor.

    The question remains though, will the XG firewall have visibility to the "true client IP" (and/or similar web headers) to use in the rule, or would we be limited to a policy that resets the connection from the CDN as the "source" of the traffic, rather than a heuristic which would only reset/drop requests from the true client IP? 

    A couple of reasons by way of explanation -- one is the thought that best practice within the IPS might be to let it have visibility of the pattern of which true clients are bad actors/requestors as opposed to seeing that pattern as constantly being the same CDN node. But if the best we can do is to just have the policy do a reset or other similar action on a request and be blind beyond the proxy/CDN node that may be the best we can do?

    It may be worth noting the CDN is a cloud solution, so while we would expect to lock down web ingress/egress to the CDN network ranges, the traffic via CDN/proxy would be public-facing rather than private, if that makes any difference.

  • 0 in reply to wilder

    Hi  

    Unfortunately, IPS does not have the feature which you required that it can exclude the request from legitimate IP for inbound or outbound connection, it will take action as applicable in the IPS policy applied for all the traffic

  • 0 in reply to Keyur

    Thanks, Keyur. That helps clarify.

    What would the recommended course of action be from an IPS policy perspective when we don't want "dirty" traffic to flow through the CDN? Would it be to reset the connection? In other words, would only the dirty request's connection be reset in that case? Or would that be disruptive to other requests/traffic flowing through the CDN as well?

  • 0 in reply to wilder

    Hi  

    If the IPS policy is applied and it detects and matches the traffic generated from the source against IPS signature, it will start taking action defined against the signature in the applied policy such as Drop, Recommended or allow packet, You can navigate to Log Viewer and select IPS from drop-down menu to check the live logs .

  • 0 in reply to Keyur

    Right, so it appears a "Reset" is session based. My question would be how the sessions are identified/grouped, since the "true client IP" isn't available... To try and make it clearer, let's say one of our websites has 200 concurrent visitors; all of their traffic is flowing through the CDN back to the origin because the CDN cache has been recently purged. If one of those concurrent visitors is a bad actor which has inbound "dirty" traffic in its web request, let's assume that there is a signature in place on the IPS which matches and correctly identifies the bad traffic. Would the different visitors' requests be lumped together into the same "session" as far as the IPS can identify, since they are all flowing through the proxy? If so it would seem a "Reset" wouldn't be the right policy action? Would the better action be a "Drop", even if it's less efficient from a processing standpoint, since it isn't session based and would only impact the individual offending packet and not impact the other concurrent visitors?

  • 0 in reply to wilder

    Hi  

    There are notable changes in the way IPS behaves when HTTP / https scanning is applied. For example, traffic is submitted to the proxy before IPS acts because the default policy for the web filter in User-Based Policy is Allow All. There can be changes in data size, an increase in the number of packets, etc. which directly affect the behavior of IPS signatures.

    stream

    If stream is set to on, the IPS engine builds an internal table during a session and deletes them at the end of each session. It also reassembles all incoming packets and checks the data for any known signatures. The IPS engine can also:

    • Buffer the entire stream of packets inside a TCP session.
    • Reassemble the TCP segments into a correct stream based on the sequence numbers.
    • Check for overlapping packets along with duplicate segments and their checksums.
    • Scan every packet with the IPS engine to identify the malicious or duplicate payload.

    To turn on stream, enter the command:

    set ips packet-streaming on

    If stream is set to off, then protocols such as Telnet, POP3, SMTP, and HTTP are vulnerable as reassembly of packets or segments can no longer occur. Data is sometimes broken up into chunks of packets and must be reassembled to check for signatures, these protocols are now vulnerable to malicious files that are hidden by splitting. There are no specific parameters for IPS calibration and the settings for maxpkts and stream will be different from case to case based on the:

    • Deployment type and size.
    • Number of signatures being used.
    • Network traffic being generated.
    • Bandwidth provided by the ISP.

    To turn off stream, enter the command:

    set ips packet-streaming off

Reply
  • 0 in reply to wilder

    Hi  

    There are notable changes in the way IPS behaves when HTTP / https scanning is applied. For example, traffic is submitted to the proxy before IPS acts because the default policy for the web filter in User-Based Policy is Allow All. There can be changes in data size, an increase in the number of packets, etc. which directly affect the behavior of IPS signatures.

    stream

    If stream is set to on, the IPS engine builds an internal table during a session and deletes them at the end of each session. It also reassembles all incoming packets and checks the data for any known signatures. The IPS engine can also:

    • Buffer the entire stream of packets inside a TCP session.
    • Reassemble the TCP segments into a correct stream based on the sequence numbers.
    • Check for overlapping packets along with duplicate segments and their checksums.
    • Scan every packet with the IPS engine to identify the malicious or duplicate payload.

    To turn on stream, enter the command:

    set ips packet-streaming on

    If stream is set to off, then protocols such as Telnet, POP3, SMTP, and HTTP are vulnerable as reassembly of packets or segments can no longer occur. Data is sometimes broken up into chunks of packets and must be reassembled to check for signatures, these protocols are now vulnerable to malicious files that are hidden by splitting. There are no specific parameters for IPS calibration and the settings for maxpkts and stream will be different from case to case based on the:

    • Deployment type and size.
    • Number of signatures being used.
    • Network traffic being generated.
    • Bandwidth provided by the ISP.

    To turn off stream, enter the command:

    set ips packet-streaming off

Children
  • 0 in reply to Keyur

    Unfortunately, I still don't think I know what the expected behavior would be, or what the right policy would be. I guess I'll stop asking questions because I'm not sure if you or anyone else might know the specifics of what I've been asking about on this thread. :(

  • 0 in reply to wilder

    Hi  

    Let me try to explain.

    If there are 2 sessions from 2 different IP host has been trying to contact CDN server and on that firewall rule IPS signature has been applied.

    Now as per IPS settings, it will start capturing the packets. IPS Packet Streaming is responsible for verifying every TCP stream that passes thru the firewall by checking for any injected packets

    It buffers the entire Stream of packets inside a TCP session.

    Re-Assembles the TCP segments into a correct stream based on the sequence numbers.

    Check for Overlapping packets and Duplicate segments and their Checksums.

    Scan every packet with the IPS engine to identify the malicious or duplicate payload.

    Stateful Inspection is used!

    An initial conversation is carried out which is known as the three-way handshake.

    Once the connection is set-up, data is transferred. When the data has been transferred, the conversation ends. Using the stream module, during these conversations IPS builds internal tables to represent these sessions and tears them down after each session ends.

    The above explanation is applicable to both the IP host contacted to CDN server and it will trigger IPS alerts in the Log Viewer with the action taken by IPS engine and it will drop/allow only specific packet those detected or triggered by IPS signature, not the entire connection.

  • 0 in reply to Keyur

    Thank you, Keyur. I believe this helps clarify a key concept -- the IPS is using the TCP session, not its own sense of what a "session" is, correct?

    And thus, even though those two different streams in your example both go through the CDN on the public internet first, before then being proxied onward to our edge firewall to pass to the origin web server in the DMZ, those would still be treated as separate/distinct "sessions" in the IDS functionality by way of inspection/use "statefully" of the TCP packet details?

    So in other words, if one of the sessions is totally "clean" and one of the two sessions contains dirty traffic and has a signature match within the IDS, that session would be dropped if the policy was configured to act with a drop, whereas the clean session since it would not match the signature would not be adversely interrupted, even though the same CDN/proxy host might be proxying the traffic of both sessions onward to us as the same traffic "source"?

    Still learning so I may be missing some other aspects here and appreciate your patience and help.

  • 0 in reply to Keyur

    Hi Keyur, one more question / point of clarification, can the XG IPS decrypt to inspect https web traffic? Or is the IPS capability only capable of inspecting inbound http?

  • 0 in reply to wilder

    XG has a outbound DPI based Proxy to generally speaking perform TLS Decryption on internal clients. There is another basic https proxy to decrypt traffic. 

    This is only for Internal to external traffic. 

     

  • 0 in reply to LuCar Toni

    So there is no way to decrypt inbound https traffic for IPS? 

    Can it be pieced together by running the WAF and applying IPS policies somehow besides?

  • 0 in reply to wilder

    Hi  

    The IPS policy will work on Inbound and Outbound traffic, If you apply it on outbound firewall rule such as LAN to WAN or DMZ to WAN, it will scan outbound traffic, if the policy is applied on Inbound traffic firewall rule such as WAN to LAN or WAN to DMZ, it will scan inbound traffic passing from the rule and the IPS policy applied, it will scan the traffic as discussed in previous responses.

    Please refer to - https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/concepts/IPSPolicyManage.html

  • 0 in reply to Keyur

    Hi

    The traffic between the CDN and his Web Servers are encrypted, making XG IPS useless for this situation.  is asking if it will be possible in the future for the DPI Engine to Decrypt and analyze SSL/TLS Inbound Traffic.

     

    "Can it be pieced together by running the WAF and applying IPS policies somehow besides?"

    Yes, you can use WAF for this situation, the only problem of this, you will see a big performance decrease on it.

    With WAF you will be able to apply IPS, also AV and a common thread filter for the traffic.

     

    Thanks

  • 0 in reply to Prism

    Prism said:

    Hi

    The traffic between the CDN and his Web Servers are encrypted, making XG IPS useless for this situation.  is asking if it will be possible in the future for the DPI Engine to Decrypt and analyze SSL/TLS Inbound Traffic.

     

    "Can it be pieced together by running the WAF and applying IPS policies somehow besides?"

    Yes, you can use WAF for this situation, the only problem of this, you will see a big performance decrease on it.

    With WAF you will be able to apply IPS, also AV and a common thread filter for the traffic.

     

    Thanks

     

    Exactly, @Prism, and thank you, given the critical importance of performance on the sites we host, using the new DPI Engine for inbound https scanning would be preferable to using WAF, since we already have WAF at the edge via the CDN. Sophos - Is this a possibility or on the road map?