Securing the panel - good or bad practice?

Kirby 2 Solved ✅
1

Okay, so we all love Kirby… and some of us use the “panel” to populate a Kirby-site in stead of plain (s)FTP.

Sounds good! :stuck_out_tongue: But the problem is… everyone can access the panel-login of a Kirby site, just by entering /panel/login after the site root-url.

I mean, let’s assume Google is using Kirby (hell, why not!) - one can try to enter the login-panel by simply navigating to http:// google.com/panel/login

That’s why I’m protecting ALL my panel-URI’s with an extra protection-layer; simply a .htpasswd, triggered by a custom-set .htaccess

This is working nice, but I want more… more protection! :smile:

So I decided “why not change the panel-slug” … I mean… it’s always http:// site.tld/panel no matter what… very easy to use and abuse.

Simply renaming the directory “panel” to something like “backdoor” didn’t quite work out, so I had to try something different; adding a pass-phrase to the URI.

I ended up with the code, below… In the “index.php” of “/panel” I simply included an external credentials.php file (located in “/controllers” - so it wouldn’t be overwritten by an update of the Kirby-core).

The “credentials.php” file contains both an unique security key- and value for the “/panel” directory.

So if one navigates to this URL;

http://site.tld/panel/ he or she is redirected to the sites homepage (well, actually he / she has to enter the .htpasswd first, LOL).

And one is only given access to the login-form, with this URL;

http://site.tld/panel/login/?WhoAreYou=JamesBond

It’s a simple, extra security layer… but it prevends brute-force attacks from the default login-form.

Is this a good, or bad implementation (it works for me, so I guess it’s good :stuck_out_tongue: )

2

Well, a login form is a login form. Protecting it with another login form is fine, but I think a bit paranoid. :wink:

You can do that, but since it only checks for /login you can’t be sure either whether access to the Panel is completely blocked.

I think that adding two layers is a bit crazy. If you care about security that much, I’d consider using a staging site for the Panel that is separated from your production site.

3

Thanks for the answer.

The reason I added an extra security layer, is because of brute-force attacks to my admin-panel.

I have a lot of bots trying to access “/panel” - so I created a basic firewall, using a default .htpasswd layer.

But some bots even can get through that identification-layer… so now they can only access the form when knowing the unique URI of that form - the brute-force attacks of my clients side has been down from 100% to 0% afterwards :smile:

The panel is now only accessible using this URI;

http://site.tld/panel/?sl;kfdsmlfdsml234#$#+$$#$#$$@_=FfsdjkfdsjkfdsjkfsaFSD!!~

Which is a lot more secure, I guess…

(…and off course a .htpasswd and a 264-character long encrypted username AND password for the form itself).

Or to be more complete;

With the default login, a burglar can see the door of your house - and he can try every key he has to enter it…

…with my solution, even the door is not visible - so no one can try his key to get in.

I mean - even the Kirby site has some sort of protection… just try to open this URL;

http://getkirby.com/panel/

4

I think @bastianallgeier does not use the panel for the getkirby.com website, and for other websites (or maybe even for the getkirby website), he uses a staging server, as @lukasbestle suggested above.

5

No, the Panel is not being used for the Kirby site. It is being edited directly using Git. But in situations where the Panel is useful, just use a staging site for that.

PS: Hiding stuff does not make anything secure. It may block access from bots, but people who know what they are doing will see your tricks and find the door in your garden’s jungle. But hiding has one major disadvantage: You feel secure. And that’s bad.

6

Thanks for the response, but I can enter ALL the Kirby sites on the internet, using the /panel - right now, because all sites use the same slug, e.g. those three featured ones on the homepage of Kirby;

So to clear things up to me, which of the following options is the most secure;

  1. http:// site.com/panel
    username : lkfsdklf;s@!+$@#+$)#@+
    password: $#@rfewlkfsdl;kfdlks    $#@$

  2. http:// site.com/panel
    .htpasswd username : lsfdksfl;#$#@$$#@(
    .htpasswd password : fdf9f9fsdf    +fsdfdsnfnj
    username : lkfsdklf;s@!+$@#+$)#@+
    password: $#@rfewlkfsdl;kfdlks    $#@$

  3. http:// site.com/panel/?uniqueKey=klfsdklfs$_$#@$#@$#43_24--032/?90fehfha$!34!!
    .htpasswd username : lsfdksfl;#$#@$$#@(
    .htpasswd password : fdf9f9fsdf    +fsdfdsnfnj
    username : lkfsdklf;s@!+$@#+$)#@+
    password: $#@rfewlkfsdl;kfdlks    $#@$

7

Alternatively, just use a whitelist for your IP (ie. deny all, allow only your home IP), or as others have suggested, don’t use the panel on your production server at all.

1 Like
8

For some clients I did whitelist the IP, for sure :smile:

But not all clients / server-situations / work-flow allow this (some clients have dynamic IP, while updating their content from a phone on the road).

So it’s good practice, but not always applicable… and for myself, I work with production / development / staging servers - but non of my clients wants a staging server;

They “just” want to log in, update there content and log out again… it’s sad, but true (and well… I can understand it, 'cause of the workflow).

9

It’s an interesting discussion. I saw too many access logs full of bots looking for the wp-login.php. In general any CMS suffers from that issue. In fact any login protected site or service suffers from it. If you are afraid of the panel login being exposed, what about the Facebook login, Google login, Dropbox login, etc.?

Though I agree with @lukasbestle that hiding can give you a false sense of security, I think it’s still a good first measure to protect you from unwanted login attempts to move your login page to a different URL. That’s why you can simply change the panel folder name in the upcoming release to anything you want and it will still work (you need to adjust the rewrite rules of course) Once the version is out I will also add this to one of the recommended steps to secure the installation.

Additionally the new version will have brute-force detection built-in, which you can configure to limit the number of allowed login attempts.

If you change your folder name to a long random string in addition to extra brute-force protection you should not need to password protect via htpasswd additionally. In such a case I’d really recommend to move your panel to a staging server and go without the panel on your production environment.

In general most hacks of content management systems I’ve seen so far are actually made through weak FTP accounts without encryption or with a super short password. There’s no need to hack the web interface of the CMS in such a case.

3 Likes
10

I totally agree - maybe my three-level of protection is too much…

But I do like the .htaccess /.htpasswd protection (for most bots / scripts can not enter any credentials in the password-popup that is triggered).

So that must be strong enough, together with a unique and strong username / password for the log-in form itself.

I also create sites in Wordpress (sorry…) and the first thing I do, is change “/wp-admin” in to another slug - so no one can ever try to access the back-end, without knowing where the door is…

11

Been waiting for this :grinning:

Great news …