Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 8 replies
  • Subscribers 4 subscribers
  • Views 22779 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

Webserver IP visible in website links when published through WAF

mahaddon

Just curious to see if anyone else has had this issue.  I'll apologise in advance for any errors because I'm not a Web Dev  :)

I'm starting to test using WAF to reverse proxy internal websites.  I have a software UTM running v9.411-3.

I've published a couple of websites and they work fine but one site wouldn't load up the css style config when testing from my android phone.  I asked the Web Devs to check it out and they spotted something that's pretty worrying.

He found out that his phone was trying to load internal resources using the ip address, ie: @import url("https://"WEBSERVERIP"/modules/comment/comment.css?on3ztz but if he tested from in internal pc it would be @import url("www.DOMAIN/.../comment.css certificate is for the domain, so it doesn’t load the css.

For info, internal access isn't reverse proxied so that's just a windows pc accessing an internal website directly from the wenserver.

What worries me is that UTM is apparently allowing public visibility of the webserver internal IP address.  I'm assuming that this is a configuration on the webserver but it probably means that the Web Devs will have to check every single site that we have for IP addresses in links before I can migrate them from TMG rev proxy to UTM WAF.

I'm not using Rewrite HTML (the site also used javascript) and I'm testing with a custom WAF firewall policy that's just Basic profile + Block clients with bad reputation - Cookie signing.  My Virtual Webservers are using Encrypted (HTTPS) & redirect over port 443.  Curiously an SSL Labs site check gives the site an A rating



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

    "What worries me is that UTM is apparently allowing public visibility of the webserver internal IP address."

    I doubt that.  You could do a packet capture on the external interface to prove it, but my guess is that even if some WAF<->webserver traffic included the local IP, that wouldn't ever go to the external client as it would "break" the browsing session.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    thanks for the reply Bob.

    My web dev tested accessing the rev proxied site through his smart phone over his personal phone connection i.e. not touching or internal networks.  He then connected his phone to his pc using USB and ran the dev tools in Google Chrome from his pc to view the browser data on the phone and this is where he saw the IPs.

    https://developers.google.com/web/tools/chrome-devtools/remote-debugging/

    Now I'm assuming that this browser data would still have been collected over his personal mobile phone carriers network and not somehow starting to connect to the internal network through his pc?

  • 0 in reply to mahaddon

    What I don't understand is how his phone and the other routers on the Internet "knew" where to route packets with destinations of private IPs.  Was he connected to your network via remote access?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    No he was connected to his mobile phone carriers data network.  Wasn't until he used Chrome's mobile device USB debugging that he spotted the IPs in the URLs that his phone was trying to load up.  He was connected to the public IP of the website as usual but the website was loading up CSS and javascript files and the link in the css file was showing as @import url("https://WEBSERVER_IP/modules/comment/comment.css?on3ztz)

    I can't comment on the webserver config but I can only think that UTM is passing through the actual URL?  My web devs did say that the links on the website didn't contain the webserver IP but I don't know enough to be able to verify that.  I did open up the website internally and checked "view source" and the link contained the website domain and not the webserver IP @import url(https://WEBSITE_DOMAIN/modules/system/system.base.css?on3ztz);

     

  • +1 in reply to BAlfson

    OK a bit of progress.

    I spoke to my web devs and enabled Rewrite HTML and also Rewrite cookies and it looks as if this resolved the issue [I had misremembered reading a warning about Rewrite HTML breaking javascript when I'd actually read that in the URL Hardening help text].  Web dev confirmed no IPs in the browser content and I saw the following in the UTM WAF logs (sanitised).

    reverseproxy: [Tue Apr 11 10:09:40.513196 2017] [proxy_http:error] [pid :] ()End of file found: [client 149.###:###:###:46450] AH01102: error reading status line from remote server WEBSITE_IP:443, referer: https://WEBSITE_URL/sites/all/themes/css/h.css?on3ztz

    reverseproxy: srcip="149.###:###:###" localip="UTM_VIRTUAL_SERVER_IP" size="0" user="-" host="149.###:###:###" method="GET" statuscode="200" reason="-" extra="-" exceptions="-" time="3538" url="/sites/all/themes/images/PoT.gif" server="WEBSITE_URL referer="https://WEBSITE_URL/sites/all/themes/css/h.css?on3ztz" cookie="has_js=1; _ga=############" set-cookie="-"

    Looks as if the webserver IP is sent with the css file URL which fails and then UTM rewrites it with the website domain which works but I admit that's just my uninformed interpretation of the WAF log entries

    Note I didn't create any definitions on UTM resolving the website domain to the public IP.

Reply
  • +1 in reply to BAlfson

    OK a bit of progress.

    I spoke to my web devs and enabled Rewrite HTML and also Rewrite cookies and it looks as if this resolved the issue [I had misremembered reading a warning about Rewrite HTML breaking javascript when I'd actually read that in the URL Hardening help text].  Web dev confirmed no IPs in the browser content and I saw the following in the UTM WAF logs (sanitised).

    reverseproxy: [Tue Apr 11 10:09:40.513196 2017] [proxy_http:error] [pid :] ()End of file found: [client 149.###:###:###:46450] AH01102: error reading status line from remote server WEBSITE_IP:443, referer: https://WEBSITE_URL/sites/all/themes/css/h.css?on3ztz

    reverseproxy: srcip="149.###:###:###" localip="UTM_VIRTUAL_SERVER_IP" size="0" user="-" host="149.###:###:###" method="GET" statuscode="200" reason="-" extra="-" exceptions="-" time="3538" url="/sites/all/themes/images/PoT.gif" server="WEBSITE_URL referer="https://WEBSITE_URL/sites/all/themes/css/h.css?on3ztz" cookie="has_js=1; _ga=############" set-cookie="-"

    Looks as if the webserver IP is sent with the css file URL which fails and then UTM rewrites it with the website domain which works but I admit that's just my uninformed interpretation of the WAF log entries

    Note I didn't create any definitions on UTM resolving the website domain to the public IP.

Children
Unfiltered HTML