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

How to block login popup from remote site?

If a emote web or ftp site returns a 407 error, UTM passes it thorugh to the browser which give sthe user a login popup.   If the site is http or ftp, then the crdentials are returned unencrypted.   Because the whole pop-up is often unexpected and the site name is in relatively small letters, the user may assume that he is supposed to enter his domain user and password.   This will pass secure credentials to the remote site and will pass them insecurely.   

is there a way to configure UTM to return a status that does not permit browser authentication from being triggered by the remote site?



This thread was automatically locked due to age.
  • I wonder if I can even tell from the logs, for audit purposes, whether a 407 comes from UTM or the remote system?

  • The proxy logs will not for any 407 that it generates itself.

     

    Note:

    407 is for proxy authentication.  No websites should be sending a 407.
    401 is for Unauthorized.  Websites should be send a 401 with WWW-Authenticate header to do authentication.

    This is, of course, according to the specifications, which routinely get ignored.

     

    When the UTM is used in Standard mode the client knows there is a proxy and the UTM does a 407.

    When the UTM is used in Transparent mode the client does not know there is a proxy.  The UTM does a 302 to redirect the traffic to a local address, then 401 to authenticate, for 302 back to the original destination.

  • Thank you for clarifying.  

    This means I want to block 401, certainly if session is unencrypted and probably for anything not on a whitelist.  My guess was that it would be a feature request, but I was hopeful.

    I am using standard proxy, so I should be able to find 401 in the logs.  Of course, that does not solve the risk of data loss in the form of exposed credentials.

  • Assuming for a moment we are talking about authentication using the HTTP protocol (not web logins like Facebook) then there are these types:

    Basic - password is plaintext

    NTLM - password is encrypted

    Negotiate - Kerberos password is never sent (not even encrypted)

     

    Layered on top of this is SSL.  If the connection is HTTPS then it is encrypted at that layer.

     

    And finally layered on top of that is what the Web Browser trusts and is willing to send.  For IE, if the URI is a bare hostname (eg http://internalserver/foobar) then it will send credentials automatically (this is SSO Single Sign On).  If the URI is a full domain (eg http://internternalserver.mycompany.com/foobar) then it will not send credentials instead it will do a pop-up messagebox asking the user to fill in username and password (since it does not trust it and assumes that it does not want the computer credentials).  FF does something similar.  You can trust a site so that it will do authentication automatically.

    AFAIK almost all intranet and internet authentication occurs using web form submissions and not using the HTTP protocol.

    The only really insecure is Basic over HTTP.  However I would be suspicious of anything that goes over the internet that wants your credentials.  That being said, who knows what things like Office365 does.

  • Agreed.  Anything that produces a badic login pipup is suspicious, and the user's response is unprddictable especially because it is unusual.   All good readons to prevent it from happening.

  • So, to net this conversation out, Doug's original concern was unfounded.  The prompt he saw did not originate from the remote site.  Correct?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • So possibly this is just a thought experiment question he has.  Possibly he has some network equipment that does something wacky.  The network is a wacky place.

    For example, if I recall I had a KVM switch that you could browse to with HTTP.  I think it did a 401 Basic authentication which caused a browser pop for credentials.  Any credentials would be sent plaintext over an unencrypted connection.

    So if a user accidentally thought it was asking for windows credentials they would be sending their windows credentials in plaintext over the network.  Now if it was going through the UTM then maybe the UTM could block it (would need to be a feature request) but in that case the actual result is that your KVM doesn't work.  Probably not what you want.  Or maybe it is what he wants.  Regardless, it is something that he could probably monitor in logs but not something we can currently block.

  • Nothing unfounded, I just had my http codes comfused.

    I have a hosting service for a personal domain, which shall remain nameless because I am growing disaffected as I identify their security problems.

    They support authenticated ftp for uploading and downloading files.   If i browse to the ftp site, I see a login popup whether running through UTM or not.

    When I realized all of the problems associated with a popup login prompt, I realized that I should block the login prompt, whether coming from an ftp site or an http(s) site.   Ftp and http are a problem because it is not encrypted, and even https is a problem because the user is likely to release internal credentials as a social engineering mistake.

    I want a policy that says ftp is only allowed if it is anonymous.

  • "I want a policy that says ftp is only allowed if it is anonymous."

    That would be a feature request: Ideas.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA