I'm not sure if I'm missing anything here, but is it intended that webapps should not be accessible from anywhere but localhost by default? This seems to be the case for at least wordpress - which is my kind of 'gold standard' for webapp packaging on Fedora, I use it as a reference - and roundcubemail. They both have this block in their /etc/httpd/conf.d/name.conf file:
<Directory /usr/share/name> AllowOverride Options <IfModule mod_authz_core.c> # Apache 2.4 Require local </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Deny from All Allow from 127.0.0.1 Allow from ::1 </IfModule> </Directory>
Which pretty clearly disallows access from anywhere but localhost. It seems an odd default configuration, in that if you ever want to allow anyone to actually access your webapp you're going to have to change it, which will prevent it ever being automatically updated again (you'll always get a .rpmnew file). I have to change the 'Require local' to 'Require all granted' and restart httpd in order to actually let anything but localhost access the site.
Am 20.07.2013 21:53, schrieb Adam Williamson:
I'm not sure if I'm missing anything here, but is it intended that webapps should not be accessible from anywhere but localhost by default?
with my web-developer / admin hat on - yes!
you do not want to expose unconfigured webapp-packages to the world and having undefind behavior until it is configured - hence for many packages you need to find out yourself their URL while any bot is knowing it
<Directory /usr/share/name> AllowOverride Options
<IfModule mod_authz_core.c> # Apache 2.4 Require local </IfModule> </Directory>
Which pretty clearly disallows access from anywhere but localhost. It seems an odd default configuration, in that if you ever want to allow anyone to actually access your webapp you're going to have to change it, which will prevent it ever being automatically updated again
you can override this with any .conf file included after it /etc/httpd/conf.d/*.conf is included in alphabetial order
/etc/httpd/conf.d/z-name-allow.conf <Directory /usr/share/name> whatever you need to override </Directory>
On Sat, Jul 20, 2013 at 3:53 PM, Adam Williamson awilliam@redhat.com wrote:
I'm not sure if I'm missing anything here, but is it intended that webapps should not be accessible from anywhere but localhost by default? This seems to be the case for at least wordpress - which is my kind of 'gold standard' for webapp packaging on Fedora, I use it as a reference
- and roundcubemail. They both have this block in
their /etc/httpd/conf.d/name.conf file:
<Directory /usr/share/name> AllowOverride Options
<IfModule mod_authz_core.c> # Apache 2.4 Require local </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Deny from All Allow from 127.0.0.1 Allow from ::1 </IfModule> </Directory>
Which pretty clearly disallows access from anywhere but localhost. It seems an odd default configuration, in that if you ever want to allow anyone to actually access your webapp you're going to have to change it, which will prevent it ever being automatically updated again (you'll always get a .rpmnew file). I have to change the 'Require local' to 'Require all granted' and restart httpd in order to actually let anything but localhost access the site.
It's a vastly safer initial setup than leaving it wide open, by default. this applies to many tools such as Nagios and cacti, that may share information about your system that you really should review before exposing.
You should also be albe to use a reload, not necessarily a restart, to get it working. (Although I've not been trying this with systemd!)
On Sat, 2013-07-20 at 16:10 -0400, Nico Kadel-Garcia wrote:
On Sat, Jul 20, 2013 at 3:53 PM, Adam Williamson awilliam@redhat.com wrote:
I'm not sure if I'm missing anything here, but is it intended that webapps should not be accessible from anywhere but localhost by default? This seems to be the case for at least wordpress - which is my kind of 'gold standard' for webapp packaging on Fedora, I use it as a reference
- and roundcubemail. They both have this block in
their /etc/httpd/conf.d/name.conf file:
<Directory /usr/share/name> AllowOverride Options
<IfModule mod_authz_core.c> # Apache 2.4 Require local </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Deny from All Allow from 127.0.0.1 Allow from ::1 </IfModule> </Directory>
Which pretty clearly disallows access from anywhere but localhost. It seems an odd default configuration, in that if you ever want to allow anyone to actually access your webapp you're going to have to change it, which will prevent it ever being automatically updated again (you'll always get a .rpmnew file). I have to change the 'Require local' to 'Require all granted' and restart httpd in order to actually let anything but localhost access the site.
It's a vastly safer initial setup than leaving it wide open, by default. this applies to many tools such as Nagios and cacti, that may share information about your system that you really should review before exposing.
You should also be albe to use a reload, not necessarily a restart, to get it working. (Although I've not been trying this with systemd!)
'apachectl reload' didn't seem to do the job.
It's a 'safer' default in the same way that a computer that's turned off is safer than one that's turned on, I guess...though I suppose lots of webapps do have initial configuration that you want to make sure is not run remotely, obviously. But it does leave the rpmnew problem.
Am 20.07.2013 22:59, schrieb Adam Williamson:
You should also be albe to use a reload, not necessarily a restart, to get it working. (Although I've not been trying this with systemd!)
'apachectl reload' didn't seem to do the job.
because it does not exist
"apachectl graceful" or "systemctl reload http.service" http://httpd.apache.org/docs/2.2/programs/apachectl.html
[root@srv-rhsoft:~]$ apachectl reload Usage: /usr/sbin/httpd [-D name] [-d directory] [-f file] [-C "directive"] [-c "directive"] [-k start|restart|graceful|graceful-stop|stop] [-v] [-V] [-h] [-l] [-L] [-t] [-T] [-S] [-X]
It's a 'safer' default in the same way that a computer that's turned off is safer than one that's turned on, I guess...though I suppose lots of webapps do have initial configuration that you want to make sure is not run remotely, obviously. But it does leave the rpmnew problem
besides that these are config *examples* and not for production means they should not be overwritten after configuration:
/etc/httpd/conf.d/z-name-allow.conf <Directory /usr/share/name> whatever you need to override </Directory>
On Sat, 2013-07-20 at 23:07 +0200, Reindl Harald wrote:
Am 20.07.2013 22:59, schrieb Adam Williamson:
You should also be albe to use a reload, not necessarily a restart, to get it working. (Although I've not been trying this with systemd!)
'apachectl reload' didn't seem to do the job.
because it does not exist
"apachectl graceful" or "systemctl reload http.service" http://httpd.apache.org/docs/2.2/programs/apachectl.html
[root@srv-rhsoft:~]$ apachectl reload Usage: /usr/sbin/httpd [-D name] [-d directory] [-f file] [-C "directive"] [-c "directive"] [-k start|restart|graceful|graceful-stop|stop] [-v] [-V] [-h] [-l] [-L] [-t] [-T] [-S] [-X]
It's a 'safer' default in the same way that a computer that's turned off is safer than one that's turned on, I guess...though I suppose lots of webapps do have initial configuration that you want to make sure is not run remotely, obviously. But it does leave the rpmnew problem
besides that these are config *examples* and not for production means they should not be overwritten after configuration:
/etc/httpd/conf.d/z-name-allow.conf <Directory /usr/share/name> whatever you need to override
</Directory>
If they are intended as examples they should be packaged as such; they are not.
On Sat, Jul 20, 2013 at 5:28 PM, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2013-07-20 at 23:07 +0200, Reindl Harald wrote:
besides that these are config *examples* and not for production means they should not be overwritten after configuration:
/etc/httpd/conf.d/z-name-allow.conf <Directory /usr/share/name> whatever you need to override
</Directory>
If they are intended as examples they should be packaged as such; they are not.
Most of them are configuration starting places. Nagios and Icinga and cacti are all examples of this, where the minimal access to localhost is enough to get a testable setup started. They're all *working* examples, and as such need to be in /etc/httpd/conf.d, not hidden somewhere else waiting for you to deduce a relevant installation.
Am 20.07.2013 23:28, schrieb Adam Williamson:
On Sat, 2013-07-20 at 23:07 +0200, Reindl Harald wrote:
Am 20.07.2013 22:59, schrieb Adam Williamson:
You should also be albe to use a reload, not necessarily a restart, to get it working. (Although I've not been trying this with systemd!)
'apachectl reload' didn't seem to do the job.
because it does not exist
"apachectl graceful" or "systemctl reload http.service" http://httpd.apache.org/docs/2.2/programs/apachectl.html
It's a 'safer' default in the same way that a computer that's turned off is safer than one that's turned on, I guess...though I suppose lots of webapps do have initial configuration that you want to make sure is not run remotely, obviously. But it does leave the rpmnew problem
besides that these are config *examples* and not for production means they should not be overwritten after configuration:
/etc/httpd/conf.d/z-name-allow.conf <Directory /usr/share/name> whatever you need to override
</Directory>
If they are intended as examples they should be packaged as such; they are not
why?
a local setup for testing and development is pretty satisfied with only rechable from localhost, 1 out of 1000 users have the intention to run these packages in production and if so they need a lot more to care starting with open_basedir and disable_functions
the other 999 doing their work local and move it later on a public server
On Sat, Jul 20, 2013 at 2:10 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
It's a vastly safer initial setup than leaving it wide open, by default. this applies to many tools such as Nagios and cacti, that may share information about your system that you really should review before exposing.
Right. Cacti's particularly bad. One example is the installation UX: When you install Cacti, Cacti does not display the normal web interface. Instead, it will show you (and everyone else who loads /cacti/) an upgrade UI, allowing you to change or confirm the binary paths to several the tools that run every five minutes in cron. The same thing happens when you upgrade the RPM: an admin could inadvertently allow anyone the opportunity to change those tools' paths. This means that you not only have to watch out for Cacti installs that haven't been clicked-through, but you have to do the same click-through process after every update too.
At least Wordpress requires you to log into the web interface as an admin to finish an upgrade (eg from 3.5.1 -> 3.5.2). If you don't do that right away, it's ok, because the frontend will still continue to operate. If only more web apps worked that way.
The bad security in the installer, plus the long track record of vulnerabilites in Cacti itself, convinces me that restricting web access to Cacti by default is a good idea.
I do agree that the .rpmnew thing is annoying, and I wish there was a better way to handle that.
- Ken
On Mon, Jul 22, 2013 at 01:16:30AM -0600, Ken Dreyer wrote:
I do agree that the .rpmnew thing is annoying, and I wish there was a better way to handle that.
I think in general, packaging webapps into RPM is of low value. I've tried to use these packages in production several times over the years, and inevitably become frustrated and which I'd just installed from upstream as upstream expects. Not coincidentally, see the presentation I just posted in a another thread. :)
On Mon, 2013-07-22 at 09:40 -0400, Matthew Miller wrote:
On Mon, Jul 22, 2013 at 01:16:30AM -0600, Ken Dreyer wrote:
I do agree that the .rpmnew thing is annoying, and I wish there was a better way to handle that.
I think in general, packaging webapps into RPM is of low value. I've tried to use these packages in production several times over the years, and inevitably become frustrated and which I'd just installed from upstream as upstream expects. Not coincidentally, see the presentation I just posted in a another thread. :)
FWIW I have the exact opposite experience; I run some webapps from RPM packages and some installed directly and I far prefer the RPM packaged ones. I only wish there were packages of the ones I have to install and maintain manually.
I even prefer the experience of running a webapp from a package *when I have to do a lot of the maintenance on the package* (Roundcube).
Le Lun 22 juillet 2013 15:40, Matthew Miller a écrit :
On Mon, Jul 22, 2013 at 01:16:30AM -0600, Ken Dreyer wrote:
I do agree that the .rpmnew thing is annoying, and I wish there was a better way to handle that.
I think in general, packaging webapps into RPM is of low value. I've tried to use these packages in production several times over the years, and inevitably become frustrated and which I'd just installed from upstream as upstream expects.
I have the reverse experience. More to the point, with my former startup operator hat on, I would say that packaged webapps is the only reason a startup would be interested in Fedora (though to be honest it would probably run at least part of its infra on centos)
On Mon, Jul 22, 2013 at 7:40 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Jul 22, 2013 at 01:16:30AM -0600, Ken Dreyer wrote:
I do agree that the .rpmnew thing is annoying, and I wish there was a better way to handle that.
I think in general, packaging webapps into RPM is of low value. I've tried to use these packages in production several times over the years, and inevitably become frustrated and which I'd just installed from upstream as upstream expects. Not coincidentally, see the presentation I just posted in a another thread. :)
For a couple years, I managed five distinct Cacti installs across five geographically separated systems. RPM and yum makes this task far easier. Thankfully it's down to two now, but even if it were just one, I'd still go with the OS packages.
I understand how "ship it via Git" looks attractive to cloud folks, particularly for web apps. But to be honest, I want my boring web apps like Cacti, WebSVN, and phpMyAdmin to come to me through the same distribution mechanism that I get everything else: yum. Thankfully, enough people agree with that approach that we have willing Fedora packagers on hand who have made this work for many years.
- Ken
On Sat, Jul 20, 2013 at 12:53 PM, Adam Williamson awilliam@redhat.comwrote:
I'm not sure if I'm missing anything here, but is it intended that webapps should not be accessible from anywhere but localhost by default?
That's my understanding, yes. It follows from the general understanding that network-accessible daemons (with perhaps the exception of sshd) should not be accessible from outside of localhost by default.
Now I'm curious... do you have a particularly strong reason why web apps should be different than any other network daemon?
-- Jared Smith
On Sun, Jul 21, 2013 at 6:47 PM, Jared K. Smith jsmith@fedoraproject.org wrote:
On Sat, Jul 20, 2013 at 12:53 PM, Adam Williamson awilliam@redhat.com wrote:
I'm not sure if I'm missing anything here, but is it intended that webapps should not be accessible from anywhere but localhost by default?
That's my understanding, yes. It follows from the general understanding that network-accessible daemons (with perhaps the exception of sshd) should not be accessible from outside of localhost by default.
Now I'm curious... do you have a particularly strong reason why web apps should be different than any other network daemon?
Because they aren't. The daemon in this case is httpd, not the webapps.
Am 21.07.2013 19:39, schrieb drago01:
On Sun, Jul 21, 2013 at 6:47 PM, Jared K. Smith jsmith@fedoraproject.org wrote:
On Sat, Jul 20, 2013 at 12:53 PM, Adam Williamson awilliam@redhat.com wrote:
I'm not sure if I'm missing anything here, but is it intended that webapps should not be accessible from anywhere but localhost by default?
That's my understanding, yes. It follows from the general understanding that network-accessible daemons (with perhaps the exception of sshd) should not be accessible from outside of localhost by default.
Now I'm curious... do you have a particularly strong reason why web apps should be different than any other network daemon?
Because they aren't. The daemon in this case is httpd, not the webapps
but the danger is not a up-to-date httpd
the danger is blindly installed and not proper configured web-apps on default path's - it takes *minutes* before the first bot will find your application
what attack should happen to a naked httpd?
On Sun, Jul 21, 2013 at 07:39:50PM +0200, drago01 wrote:
On Sun, Jul 21, 2013 at 6:47 PM, Jared K. Smith jsmith@fedoraproject.org wrote:
On Sat, Jul 20, 2013 at 12:53 PM, Adam Williamson awilliam@redhat.com wrote:
I'm not sure if I'm missing anything here, but is it intended that webapps should not be accessible from anywhere but localhost by default?
That's my understanding, yes. It follows from the general understanding that network-accessible daemons (with perhaps the exception of sshd) should not be accessible from outside of localhost by default.
Now I'm curious... do you have a particularly strong reason why web apps should be different than any other network daemon?
Because they aren't. The daemon in this case is httpd, not the webapps.
I guess each web app increases the attack surface (versus just httpd serving only flat files).
Returning to the .rpmnew point, isn't it possible to have the web service include an alternative configuration file which would override the defaults? That way the "pristine" configuration file from RPM would be unchanged, and therefore upgradable.
Rich.
Le Dim 21 juillet 2013 23:54, Richard W.M. Jones a écrit :
On Sun, Jul 21, 2013 at 07:39:50PM +0200, drago01 wrote:
On Sun, Jul 21, 2013 at 6:47 PM, Jared K. Smith jsmith@fedoraproject.org wrote:
On Sat, Jul 20, 2013 at 12:53 PM, Adam Williamson
wrote:
I'm not sure if I'm missing anything here, but is it intended that webapps should not be accessible from anywhere but localhost by
default?
That's my understanding, yes. It follows from the general
understanding
that network-accessible daemons (with perhaps the exception of sshd)
should
not be accessible from outside of localhost by default.
Now I'm curious... do you have a particularly strong reason why web
apps
should be different than any other network daemon?
Because they aren't. The daemon in this case is httpd, not the webapps.
I guess each web app increases the attack surface (versus just httpd serving only flat files).
Returning to the .rpmnew point, isn't it possible to have the web service include an alternative configuration file which would override the defaults? That way the "pristine" configuration file from RPM would be unchanged, and therefore upgradable.
Another possibility would be to deploy the default confs in a separate dir, with a symlink to the effective dir. Want to change the default conf, break the symlink, rpm can continue to update the link target with no side effects.
On Sun, 2013-07-21 at 09:47 -0700, Jared K. Smith wrote:
On Sat, Jul 20, 2013 at 12:53 PM, Adam Williamson awilliam@redhat.com wrote: I'm not sure if I'm missing anything here, but is it intended that webapps should not be accessible from anywhere but localhost by default?
That's my understanding, yes. It follows from the general understanding that network-accessible daemons (with perhaps the exception of sshd) should not be accessible from outside of localhost by default.
Now I'm curious... do you have a particularly strong reason why web apps should be different than any other network daemon?
Not really, it just seemed odd, but after thinking about it a bit more the reasons are valid. It might be nice if this was explicitly explained somewhere, though, and Harald's suggestion of using separate files to override the values in the shipped config files was explained; perhaps a README file in /etc/httpd/conf.d ?
Am 22.07.2013 18:10, schrieb Adam Williamson:
On Sun, 2013-07-21 at 09:47 -0700, Jared K. Smith wrote:
Now I'm curious... do you have a particularly strong reason why web apps should be different than any other network daemon?
Not really, it just seemed odd, but after thinking about it a bit more the reasons are valid. It might be nice if this was explicitly explained somewhere, though, and Harald's suggestion of using separate files to override the values in the shipped config files was explained; perhaps a README file in /etc/httpd/conf.d?
thank you for your constructive input
i appreciate it really in the context of the one started the "Request: ban Harald Reindl from devel@" i have googled and see that not all i do in the community is faced as bad
-
Adam Williamson -
drago01 -
Jared K. Smith -
Ken Dreyer -
Matthew Miller -
Nico Kadel-Garcia -
Nicolas Mailhot -
Reindl Harald -
Richard W.M. Jones