Configuring Webapps to listen on specfic port

[rgmhtt]

We have a rather large security hole in our webapps in that some rather powerful apps like phpyadmin can be installed and then anyone getting access to the server can get in and change tables. If the user has set up their server to be publicly accessible, there is on easy way to limit the access. An attacker can just put an entry into their host file for phpmyadmin.foo.com and they are in.

So for the first step to limit exposure I propose to allow controlling ports for webapps. The user can then via firewall rules (whereever the firewall is) can then control access to that port.

After a bit of twiddling i got phpmyadmin to listen on port 5180 by adding to /etc/http/conf.d/1001-phpmyadmin.conf:

listen 5180
<VirtualHost *:5180> # this is an edit to an existing line

I had tried 'NameVirtualHost *:5180' as the docs seem to imply, but this did not work. Listen DOES work. And it can be slipped into the specific webapps .conf file, so this can be controlled by exception.

I can start building a Wiki page on securing webapp access and public access. Does anyone have a better way to do this and/or more to add?

I NEED this as I will have an Amahi mail server that will be publicly accessable and will want to block public access to some webapps.

[bigfoot65]

What about using .htaccess files with auth/password files. Something similar to this http://wiki.amahi.org/index.php/Passwor ... etup_pages.

We have a few apps that use .htaccess files and it can be easily added to apps on install in the script.

[rgmhtt]

What about using .htaccess files with auth/password files. Something similar to this http://wiki.amahi.org/index.php/Passwor ... etup_pages.

We have a few apps that use .htaccess files and it can be easily added to apps on install in the script.

This protects your whole system, doesn't it? I don't know how to configure it for virtual hosts. It could be one more line of defence.

An install script can easily move a virtual host to a different port too.

[bigfoot65]

Here is what I mean. This was done in Nagios and protects with user/password auth:

htpasswd -c -b ../http.users username password;

Then add .htaccess file inside the app dir:

AuthName "App Access"
AuthType Basic
AuthUserFile $PWD/../http.users
require valid-user

I am sure this could be done better, but it forces a pop up box that asks for user name and password. If you don't provide the correct one, then you do not gain access.

Here is another way from the wiki:

http://wiki.amahi.org/index.php/Require_Login

Hope this helps.

[rgmhtt]

I will work with this a bit. After I figure out why I am getting a kernel panic on my system rebuild.

But there are some critical webapps, like phpmyadmin and phpmybackup that can totally destroy an Amahi server.

.htaccess is known to be attackable. There is no rate limiting or other controls from constant pecking at the app. But with port selection you can set up your firewall that these critical apps are just not publicly accessible, as their ports are shut down.

Put a little depth into our defence.

[luvmnky2]

Has this been discussed further? I'm trying to do the same thing, move ALL webapps off port 80. I got the HDA dashboard off, to port 8888. Now I have a few apps, but I'm focusing in on one at a time, finding what the technique is, then I'll apply same to all webapps.

I'm starting with transmission, an innocent enough app, and I'll put that one on 8889. I tried the trick mentioned above:

listen 8889
<Virtual Host *:8889>

Now if I click the transmission link from the dashboard, I'm brought to the "dummy" Fedora 14 page (I have plans for a real website soon, that's why I'm locking everything down now).

Even if I type http://transmission (which I have as a server alias in the Virtual host configuration) I get the same result.

Any ideas? I have googled myself senseless trying to figure this one out.

[luvmnky2]

I've been working on this 23 hours straight, and I just don't see it. This is a major security flaw in the software. Each webapp MUST have the ability to select a launch port, for this to be viable.

[jayrock]

Hi,

I haven't looked much into the Amahi security concepts before, and I'm far from being a Linux security expert. However my impression is that instead of filling individual holes we need to figure out a more complete security strategy. The parts I find not properly addressed is

(i) more flexible authentication, such as RADIUS, plus a clear preferred authentication method - passwords, certificates, etc. I also see potential problems that the administrator in every case has access to all shares.
(ii) share / file encryption
(iii) more granular roles

Other opinions?

Brgs

jayrock

[sputnikk23]

i just manually added transmission to the webapp list.

I foudn the transmission web files, copied them to /var/hda/web-apps/trans/html (also made a log folder, just look at the other apps for examples) and made a symbolic link from the directory they used to be in to here so nothing broke

THen I installed it as a custom app on Amachi

Then I edited the httpd.conf file belonging to the app in /etc/httpd/conf.d/100x-blah.conf and added:


ProxyPass / http://hda:9091/
ProxyPassReverse / http://hda:9091/

Just like the other apps were setup.

Done and done!

[bigfoot65]

Thanks for your contribution. Would you mind adding the steps we may have missing in the wiki? Near the bottom you will see the heading "Manual Install Transmission".

http://wiki.amahi.org/index.php/Transmission

Thanks!