Is it reasonable to keep control panel in separate subdomain or domain?

Question

Since I'm quite beginner to information and websites security, I'd like to ask more experienced people about and idea, that just crossed my mind (probably isn't my original discovery! :]).

With introduction of so many new top-level domains, would it increase my website security, if I would move "control panel" to a separate subdomain or even top-level domain? For example:

• all-users frontend: http://www.example.website,
• admins-only backend: http://www.example.management.

Users are using first link only. They may even not be aware of the fact, that the other domain exists, as it can be further secured on server side, to disallow all traffic from outsite company network. Plus you don't have access to even a piece of management tools, if you login through first domain, you have access to your account's control panel only. But, never to anything related to entire website management.

For obvious reasons, both websites would use the same database (I don't take replication as an option here -- see end of text) and both top-level domains would most likely be parked on the same server / hosting (low cost project -- see end of text), but with a complete separation of each other.

This is proposed as contrary to "standard" websites, with RBAC system implemented, where -- if admin-level user logs in, he or she gains access not only to his or her account control panel, but also to entire website management tools, system toys etc. all based on determining his or her access rights.

Would implementation of separation of frontend and backend increase website security in any noticeable or reasonable way? Or would that be just a waste of time, money and resources?

One of my colleges claims, that nowadays intruders doesn't care for something like breaking into account or control panel or gaining someone's password. Nowadays intrusions are based on DDoS attacks and physically "killing" server. If that is true, then my proposed solution brings nothing. An effective attack would put down entire server, with both frontend and backend, no matter, how many domains it uses.

BTW: We're talking about low-class website, with up to 10k-100k users, a home-grown project, that turned out to become a bit more interesting. Hosted on one server. Without multi-server hosting, without database replication, without DDoS attack mittigation etc. We're not talking about another Facebook or this class service, as in this case they most likely have much, much better solutions than multi-domain.

Answer 1

Would implementation of separation of frontend and backend increase website security in any noticeable or reasonable way?

Yes. Splitting the interfaces over two hostnames—or indeed two port numbers or protocols (HTTP/HTTPS)—would give you two different JavaScript origins. This prevents any cross-site-scripting (XSS) attacks that are accessible on one site from automatically infecting into the other site.

For example if you had an HTML-injection vulnerability in your public site, it could include some JavaScript that automatically loaded the admin interface and simulated the user pressing the big red destroy-the-site button (or whatever other sensitive feature is there). If an administrator browsed the compromised public page whilst they had an active session on the admin site, the site goes boom.

With two different origins, the injected JavaScript on one origin cannot interact with the controls on the other, so the damage is limited to whatever can be done on the public site.

(As a side issue, having separate login sessions for each interface can also mitigate XSS and cross-site request forgery vulnerabilities, in that the administrator is less likely to be logged in to the admin site at the time they browse the public site. It's possible to have separate or combined login sessions either with or without different hostnames, but usually separate hostnames would give you separate logins unless you specifically worked around that.)

Separating internal-audience interfaces by hostname is generally a helpful mitigation for this reason, but of course cross-site scripting is only one minor facet of webapp security and you shouldn't imagine it gives you any protection against the other application and infrastructure security issues like DDoS.

(And yes, the comment about access control security being irrelevant because of DDoS is completely nonsensical. They are almost entirely unrelated attacks, done by different people for different reasons. How much you want to concentrate on countering each should be driven by the threat model for your application, but both kinds of attacks are commonplace and the existence of one is not an excuse to ignore the other. Typically a DoS alone is considered a lesser attack than intrusion or data loss, but again that would depend on the threat model—does an attacker have anything to gain by making your service unavailable? is it critical enough to cause serious inconvenience when it is down?)

Answer 2

Putting the admin interface on a different domain is pure security-by-obscurity. It doesn't matter how obscure you make the URL, as long as it can be reached from the public Internet, you have to take the possibility into account that it will one day become public knowledge.

But even when you assume that SbO could be an advantage for you, registering another domain just for your admin console might be counter-productive for maximum obscurity. Keep in mind that domain-registrations are public. Someone might accidently find that the domain example.management is registred, and that the domain owner is you, which could attract their attention. But an admin interface placed on an obscure URL on the domain itself leaves no public record of its existence anywhere (as long as the server is configured properly).

Bottom-line: Don't try to hide your admin interface. You should rather invest that energy into developing it in a secure way so that even when the whole world tries to access it they won't be successful.

One of my colleges claims, that nowadays intruders doesn't care for something like breaking into account or control panel or gaining someone's password. Nowadays intrusions are based on DDoS attacks and physically "killing" server.

That's incorrect. There were lots of break-ins into high-profile service with the intention to obtain users email addresses and passwords lately. One can only guess how many such breaches occur daily, but are never detected or reported to the public. However, a vulnerable admin interface is only one of many potential attack vectors which can lead to a data breach. For information about the most common mistakes which lead to website vulnerabilities, consult the OWASP top ten list.

A denial-of-service (DoS) attack is a way to cause some trouble to a website owner, but it does not "physically kill" a server. It only makes the server hard to reach while the attack takes place, but causes no lasting damage and, most importantly, does not compromise any data on your server. They are frequently performed because they require next to no technical expertise to perform, but they are far from a serious security threat.