Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Timothy D Legg]

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-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Marat Khalili]

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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Timothy D Legg]

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-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Marat Khalili]

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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Timothy D Legg]

> 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-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Timothy D Legg]

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
> (apa...@timothylegg.com)
> wrote:
>
> There is only one virtualhost active, so it is inherently unique.
>
> I tried the following:
>
> 
> 
> 
> 
> 
>
> I have not tried:
>
> 
>
> 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.
>
>
> 
> NameVirtualHost *: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
>
> 
> SSLOptions +StdEnvVars
> 
> 
> SSLOptions +StdEnvVars
> 
> 
> Require ip 172.12.33.177
> 
> 
> 
>
>
>
>> 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 :
>>> 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
 
 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  block:
>
> 
> Require ip 192.168.40.80
> 
>
> 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-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>>> For additional commands, e-mail: users-h...@httpd.apache.org
>>>
>>
>>

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Marat Khalili]

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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Daniel]

Directory points to a real filesystem path and does not need trailing slashes.

Use:

   AllowOverride none
   Require ip 172.12.33.177


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 :
> 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 (apa...@timothylegg.com)
> wrote:
>
> There is only one virtualhost active, so it is inherently unique.
>
> I tried the following:
>
> 
> 
> 
> 
> 
>
> I have not tried:
>
> 
>
> 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.
>
>
> 
> NameVirtualHost *: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
>
> 
> SSLOptions +StdEnvVars
> 
> 
> SSLOptions +StdEnvVars
> 
> 
> Require ip 172.12.33.177
> 
> 
> 
>
>
>
>> 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 :
>>> 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 
 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  block:
>
> 
> Require ip 192.168.40.80
> 
>
> 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-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>>> For additional commands, e-mail: users-h...@httpd.apache.org
>>>
>>
>>
>>
>> --
>> Daniel Ferradal
>> IT Specialist
>>
>> email dferradal at gmail.com
>> linkedin es.linkedin.com/in/danielferradal
>>
>> -
>> To unsubscribe, 

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Eric Covener]

On Fri, Dec 1, 2017 at 7:39 AM, Timothy D Legg  wrote:
> There is only one virtualhost active, so it is inherently unique.
>
> I tried the following:
>
>
>
>
>
>

Only the first has any effect.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Osama Elnaggar]

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 (apa...@timothylegg.com)
wrote:

There is only one virtualhost active, so it is inherently unique.

I tried the following:







I have not tried:



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.



NameVirtualHost *: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


SSLOptions +StdEnvVars


SSLOptions +StdEnvVars


Require ip 172.12.33.177






> 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 :
>> 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 
>>> 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  block:

 
 Require ip 192.168.40.80
 

 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-unsubscr...@httpd.apache.org
 For additional commands, e-mail: users-h...@httpd.apache.org


>>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
>
>
>
> --
> Daniel Ferradal
> IT Specialist
>
> email dferradal at gmail.com
> linkedin es.linkedin.com/in/danielferradal
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Timothy D Legg]

There is only one virtualhost active, so it is inherently unique.

I tried the following:

   
   
   
   
   

I have not tried:

   

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.



NameVirtualHost *: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


SSLOptions +StdEnvVars


SSLOptions +StdEnvVars


Require ip 172.12.33.177






> 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 :
>> 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 
>>> 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  block:

 
 Require ip 192.168.40.80
 

 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-unsubscr...@httpd.apache.org
 For additional commands, e-mail: users-h...@httpd.apache.org


>>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
>
>
>
> --
> Daniel Ferradal
> IT Specialist
>
> email dferradal at gmail.com
> linkedin es.linkedin.com/in/danielferradal
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Marat Khalili]

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 
 with  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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Marat Khalili]

I added these lines inside the  block:


Require ip 192.168.40.80


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 
 with  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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Daniel]

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 :
> 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 
>> 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  block:
>>>
>>> 
>>> Require ip 192.168.40.80
>>> 
>>>
>>> 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-unsubscr...@httpd.apache.org
>>> For additional commands, e-mail: users-h...@httpd.apache.org
>>>
>>>
>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>



-- 
Daniel Ferradal
IT Specialist

email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Best practice for restricting access to exact IP addresses

[Kartik Vashishta]

you could try /etc/hosts.deny

On Fri, Dec 1, 2017 at 4:03 AM, Timothy D Legg 
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  block:
>
> 
> Require ip 192.168.40.80
> 
>
> 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-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

[users@httpd] Best practice for restricting access to exact IP addresses

[Timothy D Legg]

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  block:


Require ip 192.168.40.80


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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org