Restrict Plinth to be accessed locally only

I would like to limit access to parts of my Freedombox. I don’t want most of the Freedombox to be visible except from a few local IPs. Users anywhere should be able to log in to the individual webclients (like Roundcube), but I don’t want it to be possible to administer the Freedombox remotely, for instance.

Normally I’d do this using Apache’s access control functionality, with something like

<Directory "/plinth">
  Require all denied
</Directory>
<Directory "/roundcube">
  Require all granted
</Directory>

…or “Require ip [ipaddress]” or some such. But when I add a conf file with some access restrictions to the Apache server, it does not have the desired effect.

I can restrict and permit subdirectories with URL paths which I just made up (they will return either a 404 “not found” or a 403 “forbidden” error, depending on the restrictions I set). But at least many of the URL paths that the Freedombox actually uses can’t be restricted/permitted in this way (I can’t find a list of these paths; I’m sure it depends on what packages I enable). I assume my “Require” settings are overridden somewhere else, but I can’t find where.

I’m not attached to using any method here. For instance, perhaps I could rewrite some of the URLs to redirect requests to error pages? Suggestions welcome.

Hi @Falk24,

I’m sorry but I dont fully understand what it is you need.

i.e.

  • you can configure fbx so that your domain points directly to the apache server. then, anyone who doesnt know you’re running fbx will not access plinth
  • your user privilege settings can be so that your fbx users cannot access settings and so they can only login to plinth and use it as a dashboard (then, unless the user is an admin, they cant administer FBX)
  • you can restrict some apps on a user-based configuration

Can you be a bit more specific on what it is you need?

Cheers.

1 Like

Hi, Ged296123,

I think I have done or will do those things. The domain points to a webpage that replaced the Apache default page, and you would indeed need to go looking for plinth to find it. I won’t give admin privileges to everyone, and I’ll restrict apps with user permissions as needed.

I’ll try to be more specific. My use case is such that the ordinary users aren’t going to need the dashboard. The admin users, all two of them, will not need to administer the server remotely. So, on the grounds that it’s best to deny all access that isn’t actually useful, I’d like to deny access to most of the Freedombox pages for every IP except a couple of admin machines on the local network (even denying most access to everyone except localhost would be fine).

While I’m sure it works fine, I don’t need to expose most of the default content, and I’d like to keep it as simple as possible.

Thank you, and sorry to be confusing.

Hi @Falk24

Sorry, again a confusing point;

So you have two admin users (im asuming with sudo priveldedges) and you are trying to block them from administering the server? (wouldnt this create a conflict)

Thanks.

Nonono, that would indeed be a big problem, especially since one of the admins is me! I only want to block the admins from administering the server remotely. I want to allow us to administer it, but only from a couple of local machines.

so you want plinth to be accessed locally (only from some specific local ips) only? am i right there?

Yes, that’s right.
(huh, posts must be 20 chars long, minimum)

hi @Falk24

the concept behind plinth is for the average user to access their server and control it from everywhere. i dont believe it was designed to be restricted to a local only network.

no system is fool-proofed but fbx does have in place pam and fail2ban which should help cover the average users security.

so, i dont really have pointers or anything ive tried to get what you require. maybe try playing around with /etc/apache2/mods-available/freedombox.conf with deny/allow may help but truthfully, i dont know if itll work.

if anyone has any other recommendation, im sure others will be of more help. please also note that the apache conf files that you may change can be overwritten on updates.

Thank you for your help, Ged296123

It’s great that plinth can be accessed from anywhere; I can imagine that being really useful, it’s just that I don’t need it.

I’ve been adding supplemental conf files, to avoid being overwritten. I’ll play around with the settings, and have a grep through the existing conf files, and see what I can make work. I think the override order, with rewrites overriding aliasses, may be relevant. If anyone reading this has any advice or information on what the standard conf does, it would be welcome. Thanks!

1 Like

Good luck @Falk24

Please do share your experience and findings. I’m sure others with your need may come across and benefit from them.

Hi @Falk24

I assume my “Require” settings are overridden somewhere else, but I can’t find where.

You should try renaming your cusom config file so that it looks something like /etc/apache2/conf-available/90-restrict-plinth.conf The number at the beginning of the filename will get the the file processed with a higher priority.

1 Like

Thank you, nbenenek. I have made sure to name my conf file so that it gets processed first.

My understanding is that settings for more-specific directory paths will always override those for higher-level directories; that is, if I set restrictions for /adir/bdir/cdir, they will override the settings for /adir/bdir, and both of those settings will override a setting on /adir as a whole.

https://httpd.apache.org/docs/2.4/mod/core.html#directory

Notably, access to the same locations via other paths is unaffected, so that’s why I thought aliasses and redirects might be relevant as well as requires (and “Allow” and “Deny”, which are being replaced by “Require”). So I’ve been grepping for directives that might be relevant. No breakthrough yet, but I haven’t been able to spend much time on it.

There are some AllowOverride none commands that might also be relevant. I’m not sure how they affect other .conf files.

I’ll keep poking at it. I think I need to look at how Fredombox enables and disables config files.

Some stuff that is potentially useful, if not a solution to my problem:

In /etc/apache2/conf-available/roundcube-freedombox.conf (NOT roundcube.conf, which is a symlink), there is a line that says:

Alias /roundcube /var/lib/roundcube/public_html

If you replace the “/roundcube” with “/whatever”, your roundcube login will appear at www.example.com/whatever instead of www.example.com/roundcube. It seems to just work. This is a really useful functionality and should totally be surfaced in the GUI.

There are similar aliasses for /ikiwiki, /gitweb, /rss-bridge, /tt-rss and /tts-rss-app, /wordpress and /wordpress/wp-content. I have not tested what happens when you change these. The conf files are present even if you haven’t installed the associated program, but they do nothing. To get an up-to-date list, run:


cd /etc/apache2/conf-available/
grep Alias ./*

This could be useful if you want your fascinating Ikiwiki-based wiki about dustbunnies to be located at www.example.com/dustbunnywiki, not www.example.com/ikiwiki, which I would argue is good practice. After all, you might shift to some other type of wiki software, or the package might be forced to change its name after a trademark dispute; it’s more maintainable. It avoids needless astonishment (though it doesn’t always work: the jwchat-plinth.conf file appears to configure JSXC, for instance, not the defunct JWchat software which is no longer used on Freedombox, and I imagine there were good reasons for changing the name).

Similarly, the RedirectMatch line in freedombox-apache-homepage.conf might also be useful to anyone who has set the “Webserver Home page” (under [top bar]System>Configure) to “Apache default”. You can use this to change whether a visitor is sent to www.example.com/index.html (the default default) or, say, www.example.com.

Actually, the “Webserver Home page” drop-down box lists

Apache Default
Freedombox service (Plinth)
Cockpit

…and then some of the apps you have installed. For instance, if you have a mail server and Roundcube, you also get “My Email Aliases” and “Roundcube” as options.

If this dropdown box were made into an editable GUI table, it would fix my problem, and expose some of the functionality I mentioned earlier. Like this:

Service Published at Who can see it
Apache Default (HTML) www.example.com allow all
Freedombox service (Plinth) www.example.com/plinth allow localhost only
Cockpit (server manager) www.example.com/_cockpit allow localhost only
My Email Aliases www.example.com/email/aliases allow all
Roundcube (webmail) www.example.com/email allow all

Or allow by hostname or IP address. More columns could be added for more functionality (suggestions?).

This would also communicate more clearly what the setting is, especially if the URLs in the second column were links. Some users currently overlook the “Webserver Home page” setting (it took me a search to find it):