Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 6920 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

Port 80 and 443 open from external if using external IP address. Support says it goes to first rule that matches the port and ignores host name???

AllanD

We just had a PCI compliance scan and we failed because HTST wasn't enabled.  Looking through everything HTST is enabled on all of our Web Server Protection rules including the default one.  The PCI scanning company said the server replying is using apache which we do not use internally at all. So I opened up a support ticket with Sophos.

After they looked at my system they told me that someone trying to access https://External-IP/ will match the first rule that matches port 443.  Our first rule matching 443 is for our Exchange server and the WAF rule specifically states only accept 443 if it matches mail.domain.com.  But they said if the IP address is used it simply matches the first rule with the same port:  Per them:

"Please be informed that the firewall is doing packet forwarding based on the destination IP address, so the WAF rule will work with both the domain name and the IP address as an expected behavior."

WHAT?!?  That makes no sense to me, a rule that specifies a exact host name should not also accept no host name.  And even if this is true, which it seems to be, we have HTST properly setup on our Exchange server but since it's not using the domain name it's not being used.  And again the scanning company said the reply is coming from apache.

How do I stop this and block incoming traffic on port 80 and 443 unless it actually matches our host names?  This seems like a security issue.

EDIT:  For those finding this after searching for a answer:  I still don't understand why WAF is accepting a request without a explicitly matching firewall rule but I guess thats how it works and when it finds no rule matches the host name it gives a 403 Forbidden.  This isn't great but it is what it is.  As for my PCI compliance scan I submitted for a false positive based on the fact that HTST does not apply for IP addresses and shouldn't be used as a basis for a failure.  I was able to show that a valid URL, our exchange server at https://owa.Doamin.com/owa on the same external IP does properly have the HTST header, and based on those two things my false positive was granted.



This thread was automatically locked due to age.
  • 0

    If I understand you correctly, you direct you browser to IP address (https://xx.xx.xx.xx/) instead of domain name and expect it to obey HSTS rule?

    But RFC 6797 Appendix A explicitly exclude IP addresses:

    HSTS Hosts are identified only via domain names -- explicit IP address identification of all forms is excluded.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to PhilippRusch

    No, I understand how hsts works. My issue is why is a WAF rule accepting traffic for a IP address and not only the host explicitly listed in the rule?  Again tech support said that incoming traffic directly to an IP address will match any WAF rule ignoring the host name and I believe that's not right and want to prevent that.

    If someone connects to port 80 or 443 directly on our external IP address and there is no matching rule it should be blocked.  It's not and goes to whatever is the first WAF rule that matches port 80 or 443 regardless of the FQDN.

  • 0 in reply to AllanD

    OK, next idea:
    I just shut down our internal webservers and still get the message "Forbidden -  you don't have the permission to access this resource" if accessing form external with both of our external IPs. So this is coming from WAF-rules.

    Thus I do not think his is a security issue. It is blocked. I admit, it is not blocked like you would like it to be blocked, but it is not passing through anyhow. So it is secure to me.

    Just my two cents without further knowledge about the internals of WAF.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to PhilippRusch

    So that's the exact message we also get. We get the forbidden message. The problem is security metrics, doing the PCI scans, is saying that's not good enough because the port is still open and replying. Sophos technical support is claiming, possibly incorrectly, that the traffic is being forwarded to our exchange server. The problem is the Nmap scan is saying the thing giving that forbidden message is an Apache web server. We do not have an Apache web server internal to our Network which means it's the firewall. And I can't seem to get Sophos Tech Support to understand that. Which is why I'm now posting here.

  • 0 in reply to AllanD

    I can confirm, that this is not a reply from an internal webserver. This is coming from the firewall itself.

    So you are absolutely right and I would be interested in an explanation how to improve or avoid that as well.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to PhilippRusch

    I am not sure, how this should be preventable.

    Because the get command, which includes the IP / server is late in the tcp handling. So to speak: If you do a IP or a hostname request, it looks the same in a wireshark dump until the GET but at this stage, it is already picked up by apache. 

    You could prevent it by using the SNI, but there is no subsystem in SFOS to do that right now. Because again at this stage, WAF already picked it up. 

    You can compare both via wireshark and it looks the same in there. 

    The WAF not supporting HSTS is your problem here - Because as far as i know, we do not support HSTS on WAF. And HSTS is also not enabled on the WAF itself for your Exchange - Why did that not raise concernes but your IP based access did? Which again - It is dropped by the Apache as 403 - that is normal? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    I'm not sure why you say WAF does not support HSTS when in the web server protection policies you can enable HSTS and then apply that protection policy to your firewall rule.  isn't that the entire point of it being in there?

    And again I don't think the rules should match if I'm explicitly specifying a hostname yet just because it's first in the list it's getting applied because the port number matches. That makes no sense.

  • 0 in reply to AllanD

    Yeah i missed the setting in my WAF a while ago. So you can setup HSTS in the protection setting. 

    What is the problem here: SFOS uses the Firewall rule to match to the WAF to the incoming traffic. You see this in the reverseproxy.log --> ruleid="1" 

    The Firewall Rules are only aware on IP, means if a client comes with your WAN IP OR the Hostname in the firstplace, it is the same in terms of request. This means, the Firewall rule forwards the traffic to the WAF. 

    The waf will then figure out, which policies and protection policies to use. 

    I tried multiple scanner --> all scanners use path " / " to figure out, if there is HSTS. So by using the / path in WAF, you see with the Hostname request the HSTS enabled. 

    About the WAN_IP Request: I am not sure why this should be a problem in the first place.

    If you request the WAF via IP Address, WAF will present a 403 not permitted to the Client.
    [Sat Mar 02 16:47:11.603702 2024] [url_hardening:error] [pid 31118:tid 140285929428736] [client ClientWAN:40824] Hostname in HTTP request (WAF_IP) does not match the server name (Hostname), referer: https://WAF_IP/
    [Sat Mar 2 16:47:11.602910 2024] timestamp="1709398031" srcip="ClientWAN" localip="192.168.0.4" user="-" method="GET" statuscode="403" reason="-" extra="-" exceptions="-" duration="1000" url="/favicon.ico" server="WAF_IP" referer="">https://WAF_IP/" cookie="-" set-cookie="ydcseffrizknyhu_cookie=;Max-Age=0;path=/;httponly;secure" recvbytes="676" sentbytes="526" protocol="HTTP/1.1" ctype="text/html" uagent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" querystring="" websocket_scheme="-" websocket_protocol="-" websocket_key="-" websocket_version="-" ruleid="1"

    This 403 page does not include the HSTS Flag, which is true, but still, it is a blocked page without anything else. 

    https://security.stackexchange.com/questions/189520/does-strict-transport-security-header-hsts-need-to-be-applied-to-non-200-respo

    Because if you think about HSTS: It is to prevent the client to use this sites on this domain with something other than HTTPS, But on the domain is no page available anyway. 

    Another point to consider here: https://www.rfc-editor.org/rfc/rfc6797#appendix-A

       4.  HSTS Hosts are identified only via domain names -- explicit IP
       address identification of all forms is excluded.  This is for
       simplification and also is in recognition of various issues with
       using direct IP address identification in concert with PKI-based
       security.

    From my understanding, the RFC explicitly exclude the IP Hostnamens from the usage of HSTS. 

    __________________________________________________________________________________________________________________

  • +1 in reply to LuCar Toni

    So the first issue I guess is Sophos tech support giving me incorrect information.  They told me that a request to https://External-IP/ will go to the first rule and BE PROCESSED and forwarded to the host listed which is my Exchange server.  I told them that the scan indicates a apache server is responding (the firewall) and it can't be my Exchange server running IIS 10.  They said that how it works.  So tech support is incorrect.

    Second issue is Security Metrics saying this is still a vulnerability.  I will request this as a false positive and see where it goes.  Thanks for your help   and  

  • +1 in reply to AllanD

    So technically the support is right: The request is going to the first Rule, which matches the IP. This is your IP. But the Apache is blocking it here with code 403 - as you can see in your situation. 

    The question about your report is, how they measure it. You find other vendors giving "hints how to interact with this situation": https://support.alertlogic.com/hc/en-us/articles/115002333326-Dispute-HSTS-Failed-PCI-Scans

    __________________________________________________________________________________________________________________

Unfiltered HTML