You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Timothy D Legg <ap...@timothylegg.com> on 2017/12/01 10:03:21 UTC
[users@httpd] Best practice for restricting access to exact IP addresses
Hello,
I am wanting to restrict a subdirectory of a website to a single, maybe
two, IP addresses.
I will refer to this documentation:
httpd.apache.org/docs/current/howto/access.html
under the section "Access control by host".
This document suggests that 'Allow', 'Order', and 'Deny' are deprecated,
so I am avoiding using these going forwards. It decided to exercise this
restriction with mod_authz_host. I verified that authz_core_module,
authz_host_module, authz_user_module are enabled.
I added these lines inside the <VirtualHost *:443> block:
<Directory /var/www/html/graphs>
Require ip 192.168.40.80
</Directory>
But a test revealed I was able to wget graphs/test.html on a different
machine (192.168.40.81).
I've only read the documentation. Practically every non-Apache website
still uses Order-Allow-Deny methodologies, so it's still not clear how
this is actually done in practice. Why did this not work?
Thanks, Timothy D Legg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Timothy D Legg <ap...@timothylegg.com>.
I will modify my HOWTO documents to reflect the DocumentRoot location
concern today.
As far as the semi-configured 443, I have to confess I cheated. I copied
a 443-enabled virtual machine to a new VM to experiment with some-web
based dashboard tools on an air-gapped system. I forgot to disable the
443 instance of the server.
Well, I'm grateful for this experience. I love it when a simple forum
post results in a development towards improved practices. I first posted
on this list some 16 or 17 years ago and even after all this time, the
culture of the mailing list is as proactive and progressive as it's always
been.
Timothy D Legg
> On 01/12/17 18:36, Timothy D Legg wrote:
>> and then believes that running a2dissite on all these, perhaps to make a
>> backup of a php-encrusted website (such as mine) that the document root
>> will default to the top level of all these sites and perhaps reveal SQL
>> passwords in the process.
>>
>> I hope this is not true...
>
> As far as I understand it will work exactly as you described, although
> keeping virtual hosts under default document root is not a good
> practice. Also, leaving Apache listen to some port without configuring
> site on that port does not look like good practice too.
>
> I personally favour creating default virtualhost with dummy name which
> (among other things) will get shown to bots that don't provide host name
> or SNI. For instance, it may always return 403.
>
> --
>
> With Best Regards,
> Marat Khalili
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Marat Khalili <mk...@rqc.ru>.
On 01/12/17 18:36, Timothy D Legg wrote:
> and then believes that running a2dissite on all these, perhaps to make a
> backup of a php-encrusted website (such as mine) that the document root
> will default to the top level of all these sites and perhaps reveal SQL
> passwords in the process.
>
> I hope this is not true...
As far as I understand it will work exactly as you described, although
keeping virtual hosts under default document root is not a good
practice. Also, leaving Apache listen to some port without configuring
site on that port does not look like good practice too.
I personally favour creating default virtualhost with dummy name which
(among other things) will get shown to bots that don't provide host name
or SNI. For instance, it may always return 403.
--
With Best Regards,
Marat Khalili
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Timothy D Legg <ap...@timothylegg.com>.
That is almost identical to what I discovered independently. I read every
active .conf file in entirety to realize this.
I was on the assumption that from a web client perspective, a2dissite on
all sites had the same effect as stopping apache, essentially forcing it
idle. It appears that a2dissite doesn't really truly take all sites
offline, but instead defaults to a precompiled string for the document
root.
That seems to invite a hazardous situation, say for example a user is
virtual hosting n sites and uses a directory structure inside /var/www/
such as:
/var/www/www.example.com
/var/www/www.example1.com
/var/www/www.example2.com
and then believes that running a2dissite on all these, perhaps to make a
backup of a php-encrusted website (such as mine) that the document root
will default to the top level of all these sites and perhaps reveal SQL
passwords in the process.
I hope this is not true...
> On 01/12/17 15:39, Timothy D Legg wrote:
>
>> To be much more explicit, this is a conf file located in
>> /etc/apache2/sites-available and is the only file symlinked into
>> /etc/apache2/sites-enabled
> It is most likely included into /etc/apache2/apache2.conf or
> /etc/apache2/httpd.conf . Which most likely contains `Include
> ports.conf` which contains line `Listen 80`. Since no virtual host or
> DocumentRoot is defined for this port, most likely server uses compiled
> in value of DocumentRoot, which is most likely /var/www/html . Also,
> main conf most likely contains several `Require all ...` lines which
> affect all virtual hosts.
>
> --
>
> With Best Regards,
> Marat Khalili
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Marat Khalili <mk...@rqc.ru>.
On 01/12/17 15:39, Timothy D Legg wrote:
> To be much more explicit, this is a conf file located in
> /etc/apache2/sites-available and is the only file symlinked into
> /etc/apache2/sites-enabled
It is most likely included into /etc/apache2/apache2.conf or
/etc/apache2/httpd.conf . Which most likely contains `Include
ports.conf` which contains line `Listen 80`. Since no virtual host or
DocumentRoot is defined for this port, most likely server uses compiled
in value of DocumentRoot, which is most likely /var/www/html . Also,
main conf most likely contains several `Require all ...` lines which
affect all virtual hosts.
--
With Best Regards,
Marat Khalili
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Timothy D Legg <ap...@timothylegg.com>.
> On 01/12/17 15:39, Timothy D Legg wrote:
>> There is only one virtualhost active, so it is inherently unique.
>
> Just in case, verify it with: apachectl -D DUMP_VHOSTS
>
>> This is a privacy-sanitized edit of the exact conf file.
>
> This is most likely a virtual-host conf file included into the main conf
> along with tons of other things.
>
>
To be much more explicit, this is a conf file located in
/etc/apache2/sites-available and is the only file symlinked into
/etc/apache2/sites-enabled
--
>
> With Best Regards,
> Marat Khalili
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Marat Khalili <mk...@rqc.ru>.
On 01/12/17 15:39, Timothy D Legg wrote:
> There is only one virtualhost active, so it is inherently unique.
Just in case, verify it with: apachectl -D DUMP_VHOSTS
> This is a privacy-sanitized edit of the exact conf file.
This is most likely a virtual-host conf file included into the main conf
along with tons of other things.
--
With Best Regards,
Marat Khalili
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP addresses
Posted by Eric Covener <co...@gmail.com>.
On Fri, Dec 1, 2017 at 7:39 AM, Timothy D Legg <ap...@timothylegg.com> wrote:
> There is only one virtualhost active, so it is inherently unique.
>
> I tried the following:
>
> <Directory /var/www/html/graphs>
> <Directory /graphs>
> <Directory graphs/>
> <Directory /graphs/>
> <Directory graphs>
Only the first has any effect.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP addresses
Posted by Daniel <df...@gmail.com>.
Directory points to a real filesystem path and does not need trailing slashes.
Use:
<Directory /var/www/html/graphs>
AllowOverride none
Require ip 172.12.33.177
</Directory>
To make sure you are not landing in other virtualhost, check apachectl
-S output, there can be none with the same servername as this one
2017-12-01 13:59 GMT+01:00 Osama Elnaggar <oe...@gmail.com>:
> While testing, are you sure that you’re accessing it over HTTPS and not
> HTTP? If this is over normal HTTP, then none of your below configuration
> will apply.
>
> --
> Osama Elnaggar
>
> On December 1, 2017 at 11:39:11 PM, Timothy D Legg (apache@timothylegg.com)
> wrote:
>
> There is only one virtualhost active, so it is inherently unique.
>
> I tried the following:
>
> <Directory /var/www/html/graphs>
> <Directory /graphs>
> <Directory graphs/>
> <Directory /graphs/>
> <Directory graphs>
>
> I have not tried:
>
> <Directory /var/www/html/graphs/>
>
> but I suspect that this isn't where the problem lies.
>
> This is a privacy-sanitized edit of the exact conf file. By the way, I
> did reload the server on each modification.
>
>
> <IfModule mod_ssl.c>
> NameVirtualHost *:443
> <VirtualHost *:443>
> ServerName example.com
> ServerAdmin webmaster@localhost
>
> DocumentRoot /var/www/html
>
> ErrorLog ${APACHE_LOG_DIR}/error.log
> CustomLog ${APACHE_LOG_DIR}/access.log combined
>
>
> SSLEngine on
>
> SSLCertificateFile /vault/cert.pem
> SSLCertificateKeyFile /vault/key.pem
> SSLCertificateChainFile /vault/CAchain.pem
> SSLCACertificateFile /vault/2017.txt
>
> <FilesMatch "\.(cgi|shtml|phtml|php)$">
> SSLOptions +StdEnvVars
> </FilesMatch>
> <Directory /usr/lib/cgi-bin>
> SSLOptions +StdEnvVars
> </Directory>
> <Directory graphs>
> Require ip 172.12.33.177
> </Directory>
> </VirtualHost>
> </IfModule>
>
>
>
>> Make sure you are really landing in the same virtualhost with that
>> directory configuration.
>>
>> That may very well be an explanation to why it is not happening for
>> you. Remember to define a unique servername in each virtualhost,
>> different log names for each virtualhost, etc.
>>
>>
>> 2017-12-01 11:28 GMT+01:00 Timothy D Legg <ap...@timothylegg.com>:
>>> In my scenario, that might work, and I appreciate the elegance of
>>> high-order switches to access. However, my exact question would lead to
>>> a
>>> more useful solution for myself and others.
>>>
>>> Lets consider, for example, I created a dashboard in PHP for modifying
>>> my
>>> SQL database. It would be best to have a user authentication written
>>> into
>>> the PHP, but I'm in a hurry and have a static IP so I think to myself,
>>> "Hey, this IP never changes. I'm the only one on my network. Lets block
>>> this access according to path and IP address. I'll put in 192.168.40.80
>>> and nobody else can get there unless they are physically in my house or
>>> logged in my console."
>>>
>>> Another case would be I might have an embedded system on manufacturing
>>> equipment that provides access to: an operator (x.x.40.70), a supervisor
>>> (x.x.40.80) and an IT technician (v.w.y.z). They may need to access
>>> certain restricted portions of the webserver from permanently fixed
>>> terminals an a piece of machinery. It might not be in the supervisor's
>>> interest to have the operator's web-dashboard be allowed to modify the
>>> parameters of the machine. The IT administrator would probably not want
>>> the supervisor accessing admin tools, such as phpmyadmin.
>>>
>>>
>>>> you could try /etc/hosts.deny
>>>>
>>>> On Fri, Dec 1, 2017 at 4:03 AM, Timothy D Legg <ap...@timothylegg.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am wanting to restrict a subdirectory of a website to a single,
>>>>> maybe
>>>>> two, IP addresses.
>>>>>
>>>>> I will refer to this documentation:
>>>>> httpd.apache.org/docs/current/howto/access.html
>>>>> under the section "Access control by host".
>>>>>
>>>>> This document suggests that 'Allow', 'Order', and 'Deny' are
>>>>> deprecated,
>>>>> so I am avoiding using these going forwards. It decided to exercise
>>>>> this
>>>>> restriction with mod_authz_host. I verified that authz_core_module,
>>>>> authz_host_module, authz_user_module are enabled.
>>>>>
>>>>> I added these lines inside the <VirtualHost *:443> block:
>>>>>
>>>>> <Directory /var/www/html/graphs>
>>>>> Require ip 192.168.40.80
>>>>> </Directory>
>>>>>
>>>>> But a test revealed I was able to wget graphs/test.html on a different
>>>>> machine (192.168.40.81).
>>>>>
>>>>> I've only read the documentation. Practically every non-Apache
>>>>> website
>>>>> still uses Order-Allow-Deny methodologies, so it's still not clear how
>>>>> this is actually done in practice. Why did this not work?
>>>>>
>>>>> Thanks, Timothy D Legg
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>
>>
>>
>> --
>> Daniel Ferradal
>> IT Specialist
>>
>> email dferradal at gmail.com
>> linkedin es.linkedin.com/in/danielferradal
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
--
Daniel Ferradal
IT Specialist
email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Timothy D Legg <ap...@timothylegg.com>.
That is a valid, and very interesting point...
I did the request under port 80, and it loaded. I completely forgot that
I never enabled port 80.
This configuration is for port 443.
Again, I never configured it to listen to port 80.
So... where on earth did it get configured to listen on port 80 in the
first place? I never specified it to do that. There is no
NameVirtualHost *:80 anywhere in this configuration file (to clarify on
the other commenter, this is in sites-enabled/ and is the only file/link
in that folder)
Timothy D. Legg
> While testing, are you sure that youâre accessing it over HTTPS and not
> HTTP? If this is over normal HTTP, then none of your below configuration
> will apply.
>
> --
> Osama Elnaggar
>
> On December 1, 2017 at 11:39:11 PM, Timothy D Legg
> (apache@timothylegg.com)
> wrote:
>
> There is only one virtualhost active, so it is inherently unique.
>
> I tried the following:
>
> <Directory /var/www/html/graphs>
> <Directory /graphs>
> <Directory graphs/>
> <Directory /graphs/>
> <Directory graphs>
>
> I have not tried:
>
> <Directory /var/www/html/graphs/>
>
> but I suspect that this isn't where the problem lies.
>
> This is a privacy-sanitized edit of the exact conf file. By the way, I
> did reload the server on each modification.
>
>
> <IfModule mod_ssl.c>
> NameVirtualHost *:443
> <VirtualHost *:443>
> ServerName example.com
> ServerAdmin webmaster@localhost
>
> DocumentRoot /var/www/html
>
> ErrorLog ${APACHE_LOG_DIR}/error.log
> CustomLog ${APACHE_LOG_DIR}/access.log combined
>
>
> SSLEngine on
>
> SSLCertificateFile /vault/cert.pem
> SSLCertificateKeyFile /vault/key.pem
> SSLCertificateChainFile /vault/CAchain.pem
> SSLCACertificateFile /vault/2017.txt
>
> <FilesMatch "\.(cgi|shtml|phtml|php)$">
> SSLOptions +StdEnvVars
> </FilesMatch>
> <Directory /usr/lib/cgi-bin>
> SSLOptions +StdEnvVars
> </Directory>
> <Directory graphs>
> Require ip 172.12.33.177
> </Directory>
> </VirtualHost>
> </IfModule>
>
>
>
>> Make sure you are really landing in the same virtualhost with that
>> directory configuration.
>>
>> That may very well be an explanation to why it is not happening for
>> you. Remember to define a unique servername in each virtualhost,
>> different log names for each virtualhost, etc.
>>
>>
>> 2017-12-01 11:28 GMT+01:00 Timothy D Legg <ap...@timothylegg.com>:
>>> In my scenario, that might work, and I appreciate the elegance of
>>> high-order switches to access. However, my exact question would lead to
>>> a
>>> more useful solution for myself and others.
>>>
>>> Lets consider, for example, I created a dashboard in PHP for modifying
>>> my
>>> SQL database. It would be best to have a user authentication written
>>> into
>>> the PHP, but I'm in a hurry and have a static IP so I think to myself,
>>> "Hey, this IP never changes. I'm the only one on my network. Lets block
>>> this access according to path and IP address. I'll put in 192.168.40.80
>>> and nobody else can get there unless they are physically in my house or
>>> logged in my console."
>>>
>>> Another case would be I might have an embedded system on manufacturing
>>> equipment that provides access to: an operator (x.x.40.70), a
>>> supervisor
>>> (x.x.40.80) and an IT technician (v.w.y.z). They may need to access
>>> certain restricted portions of the webserver from permanently fixed
>>> terminals an a piece of machinery. It might not be in the supervisor's
>>> interest to have the operator's web-dashboard be allowed to modify the
>>> parameters of the machine. The IT administrator would probably not want
>>> the supervisor accessing admin tools, such as phpmyadmin.
>>>
>>>
>>>> you could try /etc/hosts.deny
>>>>
>>>> On Fri, Dec 1, 2017 at 4:03 AM, Timothy D Legg
>>>> <ap...@timothylegg.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am wanting to restrict a subdirectory of a website to a single,
>>>>> maybe
>>>>> two, IP addresses.
>>>>>
>>>>> I will refer to this documentation:
>>>>> httpd.apache.org/docs/current/howto/access.html
>>>>> under the section "Access control by host".
>>>>>
>>>>> This document suggests that 'Allow', 'Order', and 'Deny' are
>>>>> deprecated,
>>>>> so I am avoiding using these going forwards. It decided to exercise
>>>>> this
>>>>> restriction with mod_authz_host. I verified that authz_core_module,
>>>>> authz_host_module, authz_user_module are enabled.
>>>>>
>>>>> I added these lines inside the <VirtualHost *:443> block:
>>>>>
>>>>> <Directory /var/www/html/graphs>
>>>>> Require ip 192.168.40.80
>>>>> </Directory>
>>>>>
>>>>> But a test revealed I was able to wget graphs/test.html on a
>>>>> different
>>>>> machine (192.168.40.81).
>>>>>
>>>>> I've only read the documentation. Practically every non-Apache
>>>>> website
>>>>> still uses Order-Allow-Deny methodologies, so it's still not clear
>>>>> how
>>>>> this is actually done in practice. Why did this not work?
>>>>>
>>>>> Thanks, Timothy D Legg
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>
>>
>>
>> --
>> Daniel Ferradal
>> IT Specialist
>>
>> email dferradal at gmail.com
>> linkedin es.linkedin.com/in/danielferradal
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP addresses
Posted by Osama Elnaggar <oe...@gmail.com>.
While testing, are you sure that you’re accessing it over HTTPS and not
HTTP? If this is over normal HTTP, then none of your below configuration
will apply.
--
Osama Elnaggar
On December 1, 2017 at 11:39:11 PM, Timothy D Legg (apache@timothylegg.com)
wrote:
There is only one virtualhost active, so it is inherently unique.
I tried the following:
<Directory /var/www/html/graphs>
<Directory /graphs>
<Directory graphs/>
<Directory /graphs/>
<Directory graphs>
I have not tried:
<Directory /var/www/html/graphs/>
but I suspect that this isn't where the problem lies.
This is a privacy-sanitized edit of the exact conf file. By the way, I
did reload the server on each modification.
<IfModule mod_ssl.c>
NameVirtualHost *:443
<VirtualHost *:443>
ServerName example.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLCertificateFile /vault/cert.pem
SSLCertificateKeyFile /vault/key.pem
SSLCertificateChainFile /vault/CAchain.pem
SSLCACertificateFile /vault/2017.txt
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
<Directory graphs>
Require ip 172.12.33.177
</Directory>
</VirtualHost>
</IfModule>
> Make sure you are really landing in the same virtualhost with that
> directory configuration.
>
> That may very well be an explanation to why it is not happening for
> you. Remember to define a unique servername in each virtualhost,
> different log names for each virtualhost, etc.
>
>
> 2017-12-01 11:28 GMT+01:00 Timothy D Legg <ap...@timothylegg.com>:
>> In my scenario, that might work, and I appreciate the elegance of
>> high-order switches to access. However, my exact question would lead to
>> a
>> more useful solution for myself and others.
>>
>> Lets consider, for example, I created a dashboard in PHP for modifying
>> my
>> SQL database. It would be best to have a user authentication written
>> into
>> the PHP, but I'm in a hurry and have a static IP so I think to myself,
>> "Hey, this IP never changes. I'm the only one on my network. Lets block
>> this access according to path and IP address. I'll put in 192.168.40.80
>> and nobody else can get there unless they are physically in my house or
>> logged in my console."
>>
>> Another case would be I might have an embedded system on manufacturing
>> equipment that provides access to: an operator (x.x.40.70), a supervisor
>> (x.x.40.80) and an IT technician (v.w.y.z). They may need to access
>> certain restricted portions of the webserver from permanently fixed
>> terminals an a piece of machinery. It might not be in the supervisor's
>> interest to have the operator's web-dashboard be allowed to modify the
>> parameters of the machine. The IT administrator would probably not want
>> the supervisor accessing admin tools, such as phpmyadmin.
>>
>>
>>> you could try /etc/hosts.deny
>>>
>>> On Fri, Dec 1, 2017 at 4:03 AM, Timothy D Legg <ap...@timothylegg.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I am wanting to restrict a subdirectory of a website to a single,
>>>> maybe
>>>> two, IP addresses.
>>>>
>>>> I will refer to this documentation:
>>>> httpd.apache.org/docs/current/howto/access.html
>>>> under the section "Access control by host".
>>>>
>>>> This document suggests that 'Allow', 'Order', and 'Deny' are
>>>> deprecated,
>>>> so I am avoiding using these going forwards. It decided to exercise
>>>> this
>>>> restriction with mod_authz_host. I verified that authz_core_module,
>>>> authz_host_module, authz_user_module are enabled.
>>>>
>>>> I added these lines inside the <VirtualHost *:443> block:
>>>>
>>>> <Directory /var/www/html/graphs>
>>>> Require ip 192.168.40.80
>>>> </Directory>
>>>>
>>>> But a test revealed I was able to wget graphs/test.html on a different
>>>> machine (192.168.40.81).
>>>>
>>>> I've only read the documentation. Practically every non-Apache
>>>> website
>>>> still uses Order-Allow-Deny methodologies, so it's still not clear how
>>>> this is actually done in practice. Why did this not work?
>>>>
>>>> Thanks, Timothy D Legg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>
>>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>
>
>
> --
> Daniel Ferradal
> IT Specialist
>
> email dferradal at gmail.com
> linkedin es.linkedin.com/in/danielferradal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Timothy D Legg <ap...@timothylegg.com>.
There is only one virtualhost active, so it is inherently unique.
I tried the following:
<Directory /var/www/html/graphs>
<Directory /graphs>
<Directory graphs/>
<Directory /graphs/>
<Directory graphs>
I have not tried:
<Directory /var/www/html/graphs/>
but I suspect that this isn't where the problem lies.
This is a privacy-sanitized edit of the exact conf file. By the way, I
did reload the server on each modification.
<IfModule mod_ssl.c>
NameVirtualHost *:443
<VirtualHost *:443>
ServerName example.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLCertificateFile /vault/cert.pem
SSLCertificateKeyFile /vault/key.pem
SSLCertificateChainFile /vault/CAchain.pem
SSLCACertificateFile /vault/2017.txt
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
<Directory graphs>
Require ip 172.12.33.177
</Directory>
</VirtualHost>
</IfModule>
> Make sure you are really landing in the same virtualhost with that
> directory configuration.
>
> That may very well be an explanation to why it is not happening for
> you. Remember to define a unique servername in each virtualhost,
> different log names for each virtualhost, etc.
>
>
> 2017-12-01 11:28 GMT+01:00 Timothy D Legg <ap...@timothylegg.com>:
>> In my scenario, that might work, and I appreciate the elegance of
>> high-order switches to access. However, my exact question would lead to
>> a
>> more useful solution for myself and others.
>>
>> Lets consider, for example, I created a dashboard in PHP for modifying
>> my
>> SQL database. It would be best to have a user authentication written
>> into
>> the PHP, but I'm in a hurry and have a static IP so I think to myself,
>> "Hey, this IP never changes. I'm the only one on my network. Lets block
>> this access according to path and IP address. I'll put in 192.168.40.80
>> and nobody else can get there unless they are physically in my house or
>> logged in my console."
>>
>> Another case would be I might have an embedded system on manufacturing
>> equipment that provides access to: an operator (x.x.40.70), a supervisor
>> (x.x.40.80) and an IT technician (v.w.y.z). They may need to access
>> certain restricted portions of the webserver from permanently fixed
>> terminals an a piece of machinery. It might not be in the supervisor's
>> interest to have the operator's web-dashboard be allowed to modify the
>> parameters of the machine. The IT administrator would probably not want
>> the supervisor accessing admin tools, such as phpmyadmin.
>>
>>
>>> you could try /etc/hosts.deny
>>>
>>> On Fri, Dec 1, 2017 at 4:03 AM, Timothy D Legg <ap...@timothylegg.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I am wanting to restrict a subdirectory of a website to a single,
>>>> maybe
>>>> two, IP addresses.
>>>>
>>>> I will refer to this documentation:
>>>> httpd.apache.org/docs/current/howto/access.html
>>>> under the section "Access control by host".
>>>>
>>>> This document suggests that 'Allow', 'Order', and 'Deny' are
>>>> deprecated,
>>>> so I am avoiding using these going forwards. It decided to exercise
>>>> this
>>>> restriction with mod_authz_host. I verified that authz_core_module,
>>>> authz_host_module, authz_user_module are enabled.
>>>>
>>>> I added these lines inside the <VirtualHost *:443> block:
>>>>
>>>> <Directory /var/www/html/graphs>
>>>> Require ip 192.168.40.80
>>>> </Directory>
>>>>
>>>> But a test revealed I was able to wget graphs/test.html on a different
>>>> machine (192.168.40.81).
>>>>
>>>> I've only read the documentation. Practically every non-Apache
>>>> website
>>>> still uses Order-Allow-Deny methodologies, so it's still not clear how
>>>> this is actually done in practice. Why did this not work?
>>>>
>>>> Thanks, Timothy D Legg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>
>>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>
>
>
> --
> Daniel Ferradal
> IT Specialist
>
> email dferradal at gmail.com
> linkedin es.linkedin.com/in/danielferradal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP addresses
Posted by Daniel <df...@gmail.com>.
Make sure you are really landing in the same virtualhost with that
directory configuration.
That may very well be an explanation to why it is not happening for
you. Remember to define a unique servername in each virtualhost,
different log names for each virtualhost, etc.
2017-12-01 11:28 GMT+01:00 Timothy D Legg <ap...@timothylegg.com>:
> In my scenario, that might work, and I appreciate the elegance of
> high-order switches to access. However, my exact question would lead to a
> more useful solution for myself and others.
>
> Lets consider, for example, I created a dashboard in PHP for modifying my
> SQL database. It would be best to have a user authentication written into
> the PHP, but I'm in a hurry and have a static IP so I think to myself,
> "Hey, this IP never changes. I'm the only one on my network. Lets block
> this access according to path and IP address. I'll put in 192.168.40.80
> and nobody else can get there unless they are physically in my house or
> logged in my console."
>
> Another case would be I might have an embedded system on manufacturing
> equipment that provides access to: an operator (x.x.40.70), a supervisor
> (x.x.40.80) and an IT technician (v.w.y.z). They may need to access
> certain restricted portions of the webserver from permanently fixed
> terminals an a piece of machinery. It might not be in the supervisor's
> interest to have the operator's web-dashboard be allowed to modify the
> parameters of the machine. The IT administrator would probably not want
> the supervisor accessing admin tools, such as phpmyadmin.
>
>
>> you could try /etc/hosts.deny
>>
>> On Fri, Dec 1, 2017 at 4:03 AM, Timothy D Legg <ap...@timothylegg.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I am wanting to restrict a subdirectory of a website to a single, maybe
>>> two, IP addresses.
>>>
>>> I will refer to this documentation:
>>> httpd.apache.org/docs/current/howto/access.html
>>> under the section "Access control by host".
>>>
>>> This document suggests that 'Allow', 'Order', and 'Deny' are deprecated,
>>> so I am avoiding using these going forwards. It decided to exercise
>>> this
>>> restriction with mod_authz_host. I verified that authz_core_module,
>>> authz_host_module, authz_user_module are enabled.
>>>
>>> I added these lines inside the <VirtualHost *:443> block:
>>>
>>> <Directory /var/www/html/graphs>
>>> Require ip 192.168.40.80
>>> </Directory>
>>>
>>> But a test revealed I was able to wget graphs/test.html on a different
>>> machine (192.168.40.81).
>>>
>>> I've only read the documentation. Practically every non-Apache website
>>> still uses Order-Allow-Deny methodologies, so it's still not clear how
>>> this is actually done in practice. Why did this not work?
>>>
>>> Thanks, Timothy D Legg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
--
Daniel Ferradal
IT Specialist
email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Timothy D Legg <ap...@timothylegg.com>.
In my scenario, that might work, and I appreciate the elegance of
high-order switches to access. However, my exact question would lead to a
more useful solution for myself and others.
Lets consider, for example, I created a dashboard in PHP for modifying my
SQL database. It would be best to have a user authentication written into
the PHP, but I'm in a hurry and have a static IP so I think to myself,
"Hey, this IP never changes. I'm the only one on my network. Lets block
this access according to path and IP address. I'll put in 192.168.40.80
and nobody else can get there unless they are physically in my house or
logged in my console."
Another case would be I might have an embedded system on manufacturing
equipment that provides access to: an operator (x.x.40.70), a supervisor
(x.x.40.80) and an IT technician (v.w.y.z). They may need to access
certain restricted portions of the webserver from permanently fixed
terminals an a piece of machinery. It might not be in the supervisor's
interest to have the operator's web-dashboard be allowed to modify the
parameters of the machine. The IT administrator would probably not want
the supervisor accessing admin tools, such as phpmyadmin.
> you could try /etc/hosts.deny
>
> On Fri, Dec 1, 2017 at 4:03 AM, Timothy D Legg <ap...@timothylegg.com>
> wrote:
>
>> Hello,
>>
>> I am wanting to restrict a subdirectory of a website to a single, maybe
>> two, IP addresses.
>>
>> I will refer to this documentation:
>> httpd.apache.org/docs/current/howto/access.html
>> under the section "Access control by host".
>>
>> This document suggests that 'Allow', 'Order', and 'Deny' are deprecated,
>> so I am avoiding using these going forwards. It decided to exercise
>> this
>> restriction with mod_authz_host. I verified that authz_core_module,
>> authz_host_module, authz_user_module are enabled.
>>
>> I added these lines inside the <VirtualHost *:443> block:
>>
>> <Directory /var/www/html/graphs>
>> Require ip 192.168.40.80
>> </Directory>
>>
>> But a test revealed I was able to wget graphs/test.html on a different
>> machine (192.168.40.81).
>>
>> I've only read the documentation. Practically every non-Apache website
>> still uses Order-Allow-Deny methodologies, so it's still not clear how
>> this is actually done in practice. Why did this not work?
>>
>> Thanks, Timothy D Legg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP addresses
Posted by Kartik Vashishta <ka...@gmail.com>.
you could try /etc/hosts.deny
On Fri, Dec 1, 2017 at 4:03 AM, Timothy D Legg <ap...@timothylegg.com>
wrote:
> Hello,
>
> I am wanting to restrict a subdirectory of a website to a single, maybe
> two, IP addresses.
>
> I will refer to this documentation:
> httpd.apache.org/docs/current/howto/access.html
> under the section "Access control by host".
>
> This document suggests that 'Allow', 'Order', and 'Deny' are deprecated,
> so I am avoiding using these going forwards. It decided to exercise this
> restriction with mod_authz_host. I verified that authz_core_module,
> authz_host_module, authz_user_module are enabled.
>
> I added these lines inside the <VirtualHost *:443> block:
>
> <Directory /var/www/html/graphs>
> Require ip 192.168.40.80
> </Directory>
>
> But a test revealed I was able to wget graphs/test.html on a different
> machine (192.168.40.81).
>
> I've only read the documentation. Practically every non-Apache website
> still uses Order-Allow-Deny methodologies, so it's still not clear how
> this is actually done in practice. Why did this not work?
>
> Thanks, Timothy D Legg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Marat Khalili <mk...@rqc.ru>.
On 01/12/17 13:42, Marat Khalili wrote:
> Most likely it is overridden by other Directory or Location or some
> other kind of block somewhere in your configuration. Try to replace
> <Directory /var/www/html/graphs> with <Location /graphs> to be closer
> to the end of pipeline as described here:
> https://httpd.apache.org/docs/current/sections.html#merging
P.S. Correction: second most likely. Most likely cause is incorrect
virtualhost indeed.
>
> --
>
> With Best Regards,
> Marat Khalili
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Best practice for restricting access to exact IP
addresses
Posted by Marat Khalili <mk...@rqc.ru>.
> I added these lines inside the <VirtualHost *:443> block:
>
> <Directory /var/www/html/graphs>
> Require ip 192.168.40.80
> </Directory>
>
> But a test revealed I was able to wget graphs/test.html on a different
> machine (192.168.40.81).
>
> I've only read the documentation. Practically every non-Apache website
> still uses Order-Allow-Deny methodologies, so it's still not clear how
> this is actually done in practice. Why did this not work?
Most likely it is overridden by other Directory or Location or some
other kind of block somewhere in your configuration. Try to replace
<Directory /var/www/html/graphs> with <Location /graphs> to be closer to
the end of pipeline as described here:
https://httpd.apache.org/docs/current/sections.html#merging
--
With Best Regards,
Marat Khalili
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org