We are about a month away from launching a pretty important site, which comes with an admin console to help us manage the site.

Now I'm not very interested at just leaving the admin out in the open for anyone to "have a crack at" - how do large sites like ebay, facebook etc handle this kind of stuff? I'm sure they have some form of admin console for them to manage various things throughout the site, but I'm sure it's locked down in some fashion.

How does one protect an admin so only specific people can access it? I'm not talking about password protection (obviously it's already password protected), but I'm talking about actually protecting the login page so no-one else can actually have access to the page.

I think I read something awhile back about possibly using a SSL cert to only allow certain IP's? Little hard with that since most people have dynamic IP's. :(

Any ideas!?

  • 2
    I like having a VPN to access the back-of-house stuff Commented Feb 10, 2013 at 17:57

6 Answers 6


I faced the same situation, you either only allow access to the console from certain IPs and then hardcode all public IPs or ranges that should have access to it. Or restrict access to a certain LAN range and only allow access from there. You can then set up a VPN solution and give all people that need access to the admin panel access to the VPN. People will first have to authenticate to the VPN and only then can they get access to the administrative panel (which has another log in). In this way people can still access the admin panel from anywhere (in case they are working from home) but it's not reachable for everyone.

I think it might also be a good idea to implement two factor authentication (but that's up to you to decide).

Also I suggest reading this question I posted a while ago on securing admin panels: Bruteforce vs Denial of Service

  • 1
    Just to clarify: Those IP checks are just defense-in-depth, and can't replace normal authentication measures. Commented Feb 10, 2013 at 20:02
  • Can I use a proxy instead of VPN? Commented Sep 29, 2019 at 23:22

For serious sites, the biggest problem is not the existence of a path to an administration console, but the possibility of compromise due to the administrator desktop system to be malware-ridden. Both problems can be solved at once by enforcing admin logon only from specific, dedicated systems which are on the premises. This avoids all issues which can come up from the idea of allowing administrators to act from anywhere, e.g. from home or from a laptop while on holiday. Of course, this means that on-duty sysadmins must be ready to go to work at any time (or, better yet, be already there; I am ready to believe that at Ebay they always have a sysadmin on site).

For the poorer networks, you can still enforce non-password methods of logon (SSH with public key authentication, RDP with a client certificate...) which at least avoid the dreadful business of password policies.


Hide the admin interface behind cryptographic authentication. You can accomplish this a few different ways:

  • At the web server level, require SSL with a verified client certificate
  • Expose the admin service only on a private IP address which is accessible only via a VPN
  • Expose the service only on "localhost" and access it using SSH port forwarding.
  • Require 2-factor authentication within the admin app itself.
  • Some combination of the above.

It depends on how much effort you are willing to spend on protecting the admin area.

  • One simple but effective approach is to use a cryptographic URL to access the admin area. Something like a hash (e.g. "u59sOgpDJa~M" instead of simply "admin") or similar that changes on regular basis. This way an attacker can't go for it directly because he doesn't know the address and should search for it first.

  • In addition you must limit number of failed login attempts. It's very important so a brute force attack can't be performed easily. For example lock down the IP address for a few hours after a couple of failed logins. You can use Fail2ban, DenyHosts, OSSEC, etc. or you can implement your own. Moreover you can add a delay between each login attempt response, like a few seconds that users doesn't notice but slows down robots significantly.


I will not recommend using a VPN or SSH authentication, that would be secure of course, but I'll try to focus on securing a web portal only:

  1. allow each username to login from a predefined ip range only, or a single static ip. if the user has a dynamic ip do not keep his login open to all IP ranges, you know he will only be using his ISP's ip range all the time.

  2. do not use an obvious name, like domain.com/admin, try to make it sound like something else, like domain.com/betazone400 or better domain.com/SquirrelMail

  3. add an SSL certificate, and make sure that users verify that they are only entering the password after verifying that the SSL certificate is the valid one, and verifying that they are using the same domain.com spelling. a user entering his password by mistake someplace else could be a huge security issue.

  4. use obscure usernames, both usernames and password should be of random characters. most people will try to brute-force with usernames like admin.

  5. limit number of login attempts count to avoid brute-forcing, and change usernames and passwords of the usernames being tried, (if the attacker is using correct usernames).

  6. you should be logging all failed login attempts, logging bad passwords as clear text in the database could be bad, so log everything else. (Log ip addresses and usernames of bad login attempts)


I think the solution involving VPN access is the best one. You can limit access to this interface to 2-3 ip and require the admins to VPN thru one of those servers. I would avoid using only one VPN since it might go down for some reason. Also you can embed a smartcard solution to the VPN and in this case you have 2 factor authentication. don't forget to disable any non https access.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .