Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 14 replies
  • Subscribers 29 subscribers
  • Views 72487 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

Sophos XG HTTPS Hostname Blocking

OliverKnights

Hello,

 

I seem to be having issues connecting to the HTTPS webpages for ESXI and Vcenter. My PC's are in the zone LAN and my https websites are in the zone LAB. I can connect to the sites fine using IP. When i try to connect to the sites using the hostnames i get a 501 bad gateway error. Interestingly if i place a PC in the LAB zone and try to connect to it from there it works using both IP & hostname.

 

I have a firewall policy setup to all traffic to flow from LAN to LAB and also from LAB to LAN. The policy includes no scanning of any kind and no NAT. 

 

Interestingly i have noticed that when i get the 502 bad gateway error the SSL certificate that is shown has been issued by the sophos firewall.

 

 

I believe that the sophos is intercepting the traffic and blocking it, but i can't work out why because the firewall policy doesn't include any scanning.

 

 

Any help will be greatly appreciated

 

Regards

Oliver 



This thread was automatically locked due to age.
  • 0 in reply to Billybob

    It is not forced pharming protection.  Its just on by default.
    It is applied even if you don't have any web proxying configured.  We're looking into changing that in the future.


    2.
    So my understanding of the feature is limited, but I think roughly this is what is actually does.

    With no pharming protection:
    Laptop gets infected with malware.  The malware creates an entry in the hosts files that mybank.com is 1.2.3.4
    Laptop browser goes to mybank.com
    Laptop makes a TCP connection to 1.2.3.4
    XG intercepts the connection and answers it.
    On the connection is made the laptop sends an HTTP request like GET /   Host:mybank.com
    XG makes a TCP connection to 1.2.3.4 (since that is where the original one was meant to go)
    XG sends the HTTP request on that connection
    Laptop browser shows that it went to mybank.com but in reality it is going to a pharming site that looks the same and steal the login credentials.


    With pharming protection:
    Laptop gets infected with malware.  The malware creates an entry in the hosts files that mybank.com is 1.2.3.4
    Laptop browser goes to mybank.com
    Laptop makes a TCP connection to 1.2.3.4
    XG intercepts the connection and answers it.
    On the connection the laptop sends an HTTP request like GET /   Host:mybank.com
    -->>  XG makes a DNS lookup for mybank.com
    XG makes a TCP connection to 5.6.7.8 (which is where mybank.com really lives)
    XG sends the HTTP request on that connection
    Laptop browser shows the correct website


    1.
    As far as I know, pharming protection is not logged anywhere.  My limited understanding is that there is no check to see if the original IP the connection was made to was owned by that domain.  Instead it just throws away the original IP and just uses the one it resolves itself.  Trying to do a compare is more costly and may result in false positives for domains with multiple IPs or different IPs based on geolocation.

    Therefore it is not a "detected threat" that can be logged.  AFAIK.


    3.
    I know nothing about port 53 stuff.
    To my limited knowledge, turning on/off pharming protection does not affect DNS done on port 53.

  • 0 in reply to Michael Dunn

    Thanks again Michael, your description pretty much clarifies the limited knowledge of pharming protection that I have. ie. A compromised client with hijacked DNS or fake host entries can make connections to fake sites look like a legitimate connection.

    However, from what I understand about UTM maybe XG also, when you go via http proxy, this is what roughly happens.

    • A client wants to go to cnn.com, the httpproxy will make a Query to the UTM/XG DNS server for cnn.com, fetch the page on behalf of the client. That is why we need certificates for https traffic.
    • The DNS server defined in the client's machine has no effect and the hosts file has no effect on http proxy since it is using its own DNS server.

    Where I get confused is what extra steps are taken for pharming protection because the basic proxy behavior should mitigate any host files entries etc in the client machine. Obviously, XG is also intercepting DNS requests directly which generally would be a good thing if it was documented. Maybe if the web exceptions section would bypass the DNS interception like  has suggested, that would be a good compromise but that will require another feature request[:D]

  • 0 in reply to Billybob

    AFAIK what you describe is with pharming protection on.

    In a normal proxy situation, the UTM/XG does make a dns request to the local server.  It needs this for various protection enforcement.  It also always needs to do this for explicit mode since in that case the browser makes a tcp connection directly to the proxy, not to the internet server.

    However AFAIK with the pharming protection off and transparent mode, the IP address the that UTM/XG got from DNS is not used in the actual connection.  Instead the original IP that was used in the TCP connection is used.

    HTTPS is slightly more complex and changes whether you have decryption on or not.  But in this regard I think it behaves the same.


    Here would be an interesting experiment:
    Transparent mode with pharming protection off.
    Create a client host entry for doesnotexistindns.com to a valid IP
    Now browse to there.
    My guess is it will work.  Even though the XG cannot resolve the domain name, it uses the IP from the TCP request to make the connection.
    Furthermore, I think it would work whether you have the proxy not explicitly configured, or you are using configured policies.

  • 0

    Hi all,

     

    there is no issue when i disable pharming detection?