Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Message-ID: <f906d1786a7cd540a5e1ed705b10232e.squirrel@sellfam.com>
In-Reply-To: 
 <CACva_gFxVzgfk0jbhz0CVzyoyfoR-3GTYR-qp-Cnh3HazJW9aA@mail.gmail.com>
References: <cf7bb68e57ed0be00e04d029332469de.squirrel@www.sellfam.com>
    <CAJFC5W22-uzdfHrKcvY60L=1OuwuNTCCbjNtEqi1mEpnHsx--A@mail.gmail.com>
    <1039908e04063245c7a6192ad7c4542c.squirrel@www.sellfam.com>
    <CAHti5NFBqaA5Ggyz5K2aQLyyRWcfQx9RCKjD4280KHRcUbPb5g@mail.gmail.com>
    <8d350542bd598dce1a5abf732c5b3f71.squirrel@sellfam.com>
    <CACva_gFxVzgfk0jbhz0CVzyoyfoR-3GTYR-qp-Cnh3HazJW9aA@mail.gmail.com>
Date: Fri, 1 Dec 2017 16:11:42 +0100
From: "Timothy D Legg" <apache@timothylegg.com>
To: users@httpd.apache.org
Reply-To: apache@timothylegg.com
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [users@httpd] Best practice for restricting access to exact IP
 addresses
archived-at: Fri, 01 Dec 2017 15:11:48 -0000

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 <apache@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
>>>> <apache@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