[cisco-voip] DNS Friendly Names and URL Paths

[Anthony Holloway]

Ok, I see now what your argument is about.  And I would be against training
users on bad habits too, but I don't feel that this is a bad habit we
should be avoiding.

Enter the world of URL shortening services
<https://en.wikipedia.org/wiki/URL_shortening> out there, training users
every single day.  Or the fact that this is the type of redirect, which
Cisco supports for Finesse load balancing
<https://supportforums.cisco.com/discussion/13095011/cisco-finesse-failover-behavior>
?

On Thu, Oct 20, 2016 at 6:27 PM, Norton, Mike <mikenorton at pwsd76.ab.ca>
wrote:

> It is not so much about compromising the redirect server, or cloud vs
> in-house, as compromising users' behaviour. Phishing is an attack on user
> behaviour (getting them to believe a fake site is real). By teaching users
> that it is perfectly normal to be redirected from the officially documented
> URI that they remember, to some complicated technical-looking URI that they
> don't comprehend, you are leaving them vulnerable to phishing. You want the
> normal user experience to be immediately obviously different than that link
> in the email message from "I.T. Department" asking to "verify your
> account," that redirects to some sneaky obfuscated URI hosting a fake login
> page. Redirects make it hard for users to tell if they actually ended up at
> the page they intended to, thus it is a way by which they could be tricked
> into using a fake page (phishing).
>
> -mn
>
> Sent from my Windows Phone
> ________________________________
> From: Anthony Holloway
> Sent: 20/10/2016 5:05 PM
> To: Norton, Mike
> Cc: Cisco VoIP Group
> Subject: Re: [cisco-voip] DNS Friendly Names and URL Paths
>
> So the cloud is a scary place, I see that.  I wouldn't want to expose
> anyone to an extra risk.  You could just avoid the whole attack vector
> thing by deploying a 100% on-prem solution though, no?  And if you cannot
> trust your internal servers, then you're screwed either way.
>
> Also, you cannot just throw out "attack vector" and "phishing" without
> backing that up.  What sources can you cite that URL redirects are security
> risks?  And not open redirect services either.  The services I am referring
> to would not be open redirects<https://en.wikipedia.org/wiki/URL_
> redirection#Security_issues>, rather they are protected/private, because
> you have to configure your own DNS to make it happen.  URL shortening
> services are in use in our daily lives and they rely on the same exact
> techniques<https://en.wikipedia.org/wiki/URL_shortening#Techniques> I'm
> talking about here: HTTP 3XX Redirects.  So, I'm not saying I'm a security
> expert, but I don't think it's fair to just say "It might get compromised,
> therefore it's bad."  Otherwise, everything we do is bad, because
> everything is at risk.  Even SSL itself<http://heartbleed.com/>.
>
> The problem with the reverse proxy/L7 load balance might be seen at the
> finesse level, as only a simple redirect is supported today, but otherwise,
> I would love more intelligence in the routing decision versus static
> redirects.
>
> And yes, of course, you could simply not bother, but seriously, I have yet
> to see an environment where bookmarks are pushed and documentation says
> "Look at your bookmarks to login to finesse."  Instead, it has been a URL
> given to the users via documentation.
>
> Perhaps a landing page akin to Google's old iGoogle<https://en.wikipedia.
> org/wiki/IGoogle> could be used to ease the distribution and launching of
> app URLs.  Some apps already have something simliar.  Like when you go to
> the UCCX landing page there's a link for AppAdmin and CUIC.  Too bad
> there's no link for Finesse.  And too bad it looks like garbage.  And too
> bad there's not like a single landing page for CUCM, CUC, UCCX, etc.
>
> On Thu, Oct 20, 2016 at 5:14 PM, Norton, Mike <mikenorton at pwsd76.ab.ca<
> mailto:mikenorton at pwsd76.ab.ca>> wrote:
> I would be a bit wary of HTTP redirects being a convenient attack vector
> for phishing. Especially if they are happening over unencrypted HTTP and
> across the Internet. But even just behaviorally, I don’t think it is a good
> practice to get users comfortable seeing the “official” URIs be redirected
> to ugly technical-looking URIs. Makes it easier to trick them into using a
> fake page. If they’re used to always seeing a memorable simple and pretty
> URI, then they’re more likely to notice when something is amiss.
>
> An alternative would be to rewrite URIs with a reverse proxy (or L7 load
> balancer). This would avoid the need for redirects and would keep the
> user’s browser pointed at a nice pretty URI. As a security bonus, you’d be
> able to firewall direct L3 access to the application service, and also your
> client machines wouldn’t need to be allowed to access weird ports.
>
> Another option is to just not bother with friendly names, push
> favourites/bookmarks into users’ browsers (e.g. via group policy, mdm) and
> train them to get to the applications that way.
>
> -mn
>
>
> From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-
> voip-bounces at puck.nether.net>] On Behalf Of Anthony Holloway
> Sent: October-20-16 1:07 PM
> To: Cisco VoIP Group <cisco-voip at puck.nether.net<mailto:
> cisco-voip at puck.nether.net>>
> Subject: [cisco-voip] DNS Friendly Names and URL Paths
>
> Since the list is slow this week....
>
> Ever since the push for DNS and FQDN over IP Address, I have been giving
> application servers a Subject Alternative Name (SAN) so that users
> accessing Self-Care Portal, Finesse, etc. do not have to be bothered with
> server names.
>
> E.g.,
> Instead of this:
>
> https://mspvmcucm001.company.com/ucmuser
>
> They would be able to use this:
>
> https://myphone.company.com/ucmuser
>
> That works pretty well, and Tomcat certs are easily signed to support the
> extra alias.
>
> However, when it comes to UCCX, it's a little more complicated with the
> following example:
>
> https://finesse.company.com:8445/desktop
>
> Because the alias is not exactly fitting for all things on UCCX, such as:
>
> https://finesse.company.com:8444/cuic
>
> That's confusing, and also because the user still has to remember the port
> and path on the end.
>
> https://finesse.company.com will not automatically take you to
> https://finesse.company.com:8445/desktop
>
> Today I had a co-worker ask me how it might be possible to have both:
>
> A) A different alias for each sub-component of the application server
> (E.g., Finesse vs CUIC)
>
> B) Have the port and path appended automatically
>
> I decided that a shim would be appropriate here.  We would take the
> various aliases, send them to a web server, which would then initiate an
> HTTP Header Location redirect to the appropriate port and path.
>
> A PHP example could be:
>
> URL: https://agent.company.com/
> PHP: <?php header('Location: https://mspvmuccx001.company.
> com:8445/desktop''); exit; ?>
>
> This uses the HTTP Location<https://en.wikipedia.org/wiki/HTTP_location>
> header, which sends an HTTP 3XX response code to the client and let's them
> know where to go to get the "right" page.  Unfortunately, that does mean
> that the address changes in your browser from the first URL to the second
> URL.  This isn't terrible, but it does mean that you'll still want a
> friendly looking CNAME record for your host still, as I described above.
>
> But, this would require me to install a web server in each environment and
> configure it, or ask for shared web server space.  A better solution?  The
> cloud!
>
> I stumbled across a public service that does just this.  The cloud service
> I found is:
>
> https://www.easyredir.com/
>
> They have both paid and a free plans:
>
> https://www.easyredir.com/free-url-redirection
>
> I was able to set this up in about 10 minutes and it works exactly like I
> have explained above.  I have no affiliation to them, and I'm sure there's
> other services out there.
>
> Icing on the cake I suppose, I was even able to take a public domain
> record (E.g., company.com<http://company.com>) and redirect it to a
> private domain record (E.g., company.local), proving that your application
> servers need not be accessible from the internet.
>
> In fact, your target url doesn't even have to be a public domain either.
>
> E.g.,
> https://agent.company.local can point to https://mspvmuccx001.company.
> local:8445/desktop
>
> The only requirement is that your client PC can resolve the private record
> (.local) to the public service host (on easyredir.com<http://easyredir.com>),
> and that the returned redirect location (.local again) is also accessible
> to your client PC.
>
> Has anyone come across something like this before?  How are you solving
> all the different ports and paths now under your administrative domain?
>
> This does not replace your need for a smart load-balancer in the case of a
> server failure, though Finesse should at least redirect you to the Master
> node, should your DNS record point to the Slave.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161021/cfa83e7c/attachment.html>