Hi there, What's the best practice to restrict umbraco backoffice to public? We found blocking /umbraco#/ in URL but not all of the firewalls capable of doing this.

Ip restriction is the main way I have done it

you could add a urlrewrite rule (for iis) or an IRule netcore to grant for specific ips and redirect for others? If you are loadbalanced... then you can disable the backoffice dependant on serverrole (subscriber vs publishing scheduler) or indeed on ip again.. conditionally commenting the useBackoffice/backoffice endpoints

app.UseUmbraco()
    .WithMiddleware(u =>
    {
      if(notGranted){
        u.UseBackOffice();
      }
        u.UseWebsite();
    })
    .WithEndpoints(u =>
    {
        u.UseInstallerEndpoints();

if (notGranted){               u.UseBackOfficeEndpoints();
}
        u.UseWebsiteEndpoints();
    });

Yes we are using api endpoints. Other case is protecting login page from a brute force, after Umbraco made things hard for changing backoffice url other than /umbraco/ we are struggling at penetration tests. In my opinion, app shouldn't be responsible for controlling access in this case. This should be handled in a lower level

though you prob know you can route your custom api endpoints away from /umbraco/api though using the route data annotation...

[Route("api/tours/getTourInfo/{uid}")]

The best way to restrict is a good question, it depends. IP address is common, but it's not a magic bullet. It also fall's down as soon as the CEO is on holiday and desperately needs to update a page at 4AM. In that particular case, a secret URL that sets a cookie to get through the WAF and then redirects to

/umbraco

was a nice solution. In terms of the best place to filter traffic, my order of preference is: 1. Rules in a WAF. Ideally you don't want this traffic touching your web server at all, and the WAF should have brute-force protection (DoS protection is relevant too, since logins touch the DB). 2. Rewrite rules in IIS (or reverse proxy of choice). You can also use rate limiting here to help mitigate brute forcing & DoS. Event if it touches the server, it will stop requests from gobbling up your .NET app's resources and will perform much better overall. 3. Last resort - ASP.NET Core Middleware, that executes as early in the chain as possible and resolves as quickly as possible, using as few resources as possible.

Are you thoughts for a single server setup? Or same applies for a subscriber (serverrole) in a loadbalanced env ?

I'd always use the same, it reduces complexity and improves flexibility.

There is also the added protection of different sql logins for loadbalanced.. where subscribers only have write perms where requireed.

Firstly UX. Ted from accounts (not their real name) never remembers to go to admin.example.com/umbraco instead of www.example.com/umbraco, so middleware detects if it's not the backoffice server and redirects (only after he's passed the WAF check!) Secondly, durability/failover - when backoffice servers go down, being able to quickly "promote" a "frontend" instance can be a lifesaver.

your first one is just a redirect though.. no need to have the backoffice actually there? and promoting a frontend.. is a serverrole change.. so the useBackoffice kicks in at that point as it's conditional on the serverrole?

Not necessarily. But that's more about nerdy load balancing concerns in high-risk sites than about OPs question.

"Other case is protecting login page from a brute force" Keep hearing this on pen tests - if accounts are locked out after x failed attempts then Brute force is not possible - or am I missing something?]

@SiempreSteve yep!!! @Jason I'd already jumped to the OP's question being nerdy 🤓 .. as Umbraco don't ever say to restrict

/umbraco/

as they have already addressed security concerns (even removing the ability to change it)? So assumed we are talking a high risk site where more is wanted.. Though as ever really interesting to see a diverse conversation around topics.. never better than when it raises the question for me as to why I just do things in a certain way without really considering alternatives.. 👍

Good point, brute forcing for access isn't really a concern BUT the lockout feature can be considered a vulnerability all on its own. If anyone has access to the login endpoint they can lock all the users out of the Backoffice.

Fair point.

You're right in that Umbraco is secure enough on its own most of the time. But, the more valuable/risky the data that lives in the Umbraco site, the more relevant even the tiniest risks can become. One site I'm working on has API access to their HR database - a lot of damage could be done there. You also have to consider the knock-on effect of what gaining access to the Backoffice means. For the florist in town, their site getting defaced is not the end of the world. For the multi billion dollar finserv's site I'm working on right now... sure it's just a marketing website but something going wrong could easily cost them and their customers millions. Tightening Backoffice access is relatively easy and helps mitigate 0-day vulnerabilities we don't know about yet. There was a talk at a Codegarden where someone went through a bunch of sites looking for clues as to what version of Umbraco, and then just trying a load of known vulnerabilities that may not have been patched. Simply hiding the fact that a site runs on Umbraco can help deter oportunists.

Sounds like @Jason has another talk to write 😄

So damn many 😁

I've usually done IP (or v4 at least, v6 is a whole other can of worms!) restriction, either done within IIS or at Cloudflare level depending on the site, something which is particularly easy if you're running all back office access off a different URL for load-balancing purposes. However in my experience, most pen testers will then just require themselves to be added to the list on that so they can bypass the restriction anyway. Resulting in a report where half your time is spent just responding with 'mitigation - a real user cannot access this area as its IP locked, we have specifically had to create an exception for this test'. But if they only accessed it like a real end user in the security testing, that might make for a very small report.

Brute force even though umbraco blocks login request, is still an option... only way to trully block brute force is having umbraoc behind Ip restriction. remember Brute force is not just about hacking account but forcing your way in, some systems under a huge traffic will start sleeping information etc. so assumption blocking logins is enough is naive or ignorant 🙂 there is always way to bruteforce way in 😛

Interesting. I usually take brute force to mean trying all password combinations. But you mean more a DDoS attack. Fair point.

I mean they still do same thing but yeah it becomes ddos with enough scale 😂 also it is really easy to create new sessions etc and sooner or later you break systems by submitting too much login tries 😂

So many things to consider.. but seems to be flipping from it's low risk so no need to ip block and (took a while for someone to mention 2FA 😉 ).. but if high risk then ip block (which is simple enough to put in place but how much protection it offers is open to debate)... but not load balance and gain extra sql login protection/backoffice removal entirely?? and high risk but CEO/admin wants to access on the subscriber url then educate not capitulate (but then Covid did come along and everyone suddenly working from home)... And if you are thinking you need to protect backoffice from a brute force attack then just remove the vector by making your scheduling publisher private. If it's DDOS implement Cloudflare (or another)? And then we're back to is it up to umbraco to protect itself or a tool upstream that fits the requirements? And I get there is lots of grey from simple to enterprise security.... We also had a client who moved over from a vpn to a new supplier that proxied though 1000's of ips that couldn't be defined in easy ranges, and was constantly changing.. so ip restriction there just couldn't work 😦 As a simple protection should we not be promoting the issue that

/umbraco/

as a fixed admin entry point is the sticking point? (should HQ core also.... add CSP and cover for all the [securityheaders.io](https://securityheaders.com/) flagged issues?) Does even the whitelabel approach require

/umbraco/

?

This is a lot but... to address all of your points at once... It depends.