Re: httpd error.log

On 2022-09-01 13:20, Mike Fischer wrote:
>> Am 01.09.2022 um 21:49 schrieb latincom@vcn.bc.ca:
>>
>>>
>>>> Am 01.09.2022 um 11:13 schrieb latincom@vcn.bc.ca:
>>>>
>>>> historia.agroena.org
>>>
>>> Right, try something like this and watch the error.log:
>>>
>>> curl --url 'https://historia.agroena.org/i-dont-exist.php' >/dev/null
>>>
>>> HTH
>>> Mike
>>>
>>
>> ok now:
>>
>> first i stop http rcctl stop httpd, then deleted error.log; and rcctl
>> restart http! It is working correctly.
>> thanks Mike
>
> Not sure how that (or my advice for a test) would help, but I'm glad it
> did :-)
>
>
>> PS:
>> Dokuwiki was working ok, but after the test, the browser says "file
>> not
>> found" and i am not able to access install.php! i did first # rcctl
>> enable
>> php74_fpm and rcctl start php74_fpm the httpd.con says root
>> "www/dokuwiki"
>> directly using consultores.ca/install.php!
>
> root "www/dokuwiki" does not sound right. Are you using the standard
> /var/www/dokuwiki directory for DW? If so it should be:
> root "/dokuwiki"
>
> Here is a similar setup I am using with DW from ports (Hogfather):
> server "wiki.example.com" {
> listen on $my_ipv6 tls port 443
>
> tls {
> certificate "/etc/ssl/acme/fullchain.pem"
> key "/etc/ssl/acme/private/privkey.pem"
> }
>
> log style combined
>
> authenticate "Private area" with "/conf/htpasswd-admin"
>
> root "/dokuwiki"
> directory index doku.php
>
> connection max request body 2097152 # Default is 2M for
> upload_max_filesize and 8M for post_max_size.
>
> location "*.php" {
> fastcgi socket "/run/php-fpm.sock"
> }
>
> location "/*.inc" { block }
> location "/*.ht*" { block }
> location "/data/*" { block }
> location "/conf/*" { block }
> location "/bin/*" { block }
> location "/inc/*" { block }
> location "/vendor/*" { block }

The DokuWiki security page[1] states:

The following directories should not be accessible from the web:

data
conf
bin
inc (isn't dangerous when accessible, though)
vendor (leaks info about your environment)


And httpd.conf(5)[2] states:

> In case of multiple location statements in the same context, the first
> matching location statement will be put into effect, while all later
> ones will be ignored. Therefore it is advisable to match for more
> specific paths first and for generic ones later on.

In regards to the current configuration, I believe the matches that pass
should be last and matches that block directories should be listed
first. Or, alternatively, and better, would be to figure out exactly
which .php files are required for the package to run, then make a
location rule for each file (unless someone can figure out how to make
something the equivalent of a logical or statement (regex: (this|that))
in a single location or location match block to have each of the
required .php files pass.

When I read the configuration, it appears in the reverse order of what
is recommended by DokuWiki, so in the above configuration a request for:

https://wiki.example.com/data/acl.auth.php

will be passed to php-fpm.sock because that will be matched by the first
location. I have no idea the damage to be done with this or other files,
but it is against the security guidance of the project.

It seems like the correct order should be to have the following order of
locations:

location "/*.inc" { block }
location "/*.ht*" { block }
location "/data/*" { block }
location "/conf/*" { block }
location "/bin/*" { block }
location "/inc/*" { block }
location "/vendor/*" { block }
location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}

However, I have not tested this.

[1] https://www.dokuwiki.org/security#web_access_security
[2] https://man.openbsd.org/OpenBSD-7.1/httpd.conf#location

Paul

> }
>
> You can leave out the authenticate line if you don't want HTTP Basic
> authentication (on top of DokuWiki authentication). This is running
> with php74_fpm but I also have instances of DW manually updated to
> Igor running with php80_fpm. php81_fpm is probably fine as well for
> Igor but I have not tested that yet. For Hogfather (from ports) you
> need php74_fpm.
>
> Notes for Igor: Some plugins are still a WIP. You'll see some PHP
> Warnings in logs and I needed to manually patch a few things in DW and
> some of the plugins I am using. In most cases I have opened issues
> upstream an some of them are already fixed in master. So some
> post-Igor release will see those fixes. For the plugins the process
> seems slower as they are less actively maintained.
>
>
> HTH
> Mike