Paul,
httpd does not call php includes, period. This is processed by php alone.
On Wed, 6 Jul 2022 at 18:31, Paul wrote:
> On 2022-07-06 08:27, Frank Gingras wrote:
> > First off, I would suggest not using prefork and mod_php, unless traffic
> is
> > minimal and performance is not a concern.
On 2022-07-06 08:27, Frank Gingras wrote:
First off, I would suggest not using prefork and mod_php, unless traffic is
minimal and performance is not a concern. Nowadays, the scalable solution
is to use php-fpm, and use a threaded mpm like event.
Many thanks. Point well taken, on my "to do"
On Wed, Jul 6, 2022 at 9:08 AM KK CHN wrote:
> On Wed, Jul 6, 2022 at 8:33 AM Yehuda Katz wrote:
>
>> Your log doesn't start early enough. Someone uploaded a web shell (or
>> found an existing web shell) to your server, possibly using an upload for
>> that doesn't validate the input, then used
Happy Wednesday
Ok allow me to share some experience :
about 4 years ago 1one1 hosting, myself and a bunch of others got hacked.
this is because i was using common vhosts pointing to the web directory
because www:www were the rights (no real easy way to get around that) i
had to lock php
On Wed, Jul 6, 2022 at 8:33 AM Yehuda Katz wrote:
> Your log doesn't start early enough. Someone uploaded a web shell (or
> found an existing web shell) to your server, possibly using an upload for
> that doesn't validate the input, then used that shell to run commands on
> your server.
>
Yes,
Cross-site contamination is not the same as exploiting insecure php scripts
to upload malicious content.
I will agree that isolation is a good idea, but it really has little to do
with the thread at hand.
On Wed, 6 Jul 2022 at 06:30, Paul Kudla (SCOM.CA Internet Services Inc.) <
p...@scom.ca>
Paul,
Not sure how your example helps with the OP issue at all.
On Wed, 6 Jul 2022 at 06:40, Paul Kudla (SCOM.CA Internet Services Inc.) <
p...@scom.ca> wrote:
>
> this is how my ssl, vhosts, redirects are setup maybe this will help
>
> note any ssl website name MUST equal a valid certificate
First off, I would suggest not using prefork and mod_php, unless traffic is
minimal and performance is not a concern. Nowadays, the scalable solution
is to use php-fpm, and use a threaded mpm like event.
Secondly, for your issue, you will need to look into the php logs as php is
generating the
ok thats for more detail
ok redirects simply are considered insecure when it comes to ssl certs
ie apache serves the content under the alias redirect previous to going
towards the main site.
that will defanitely be the issue.
i ran into this myself (i have multiple domains redirected
Never had these issues at all if you set up vhosts correctly.
But agree we tend to have 2 vhosts for the domain
* vhost 1 is the real vhost and handle requests
* vhost 2 contains all the redirects from other domain names to the canonical
one
The only ServerAlias lines in vhost 1 are for
Lets encrypt is reliable from our point of view - never had an issue with it -
we occasionally have issues when renewing certs - we have about 90 of them -
but that is mainly with the "fake-manual" process of updating DNS which is not
100% reliable with the changes we make.
In use speed should
this is how my ssl, vhosts, redirects are setup maybe this will help
note any ssl website name MUST equal a valid certificate or you will get
a cert mismatch error !!
granted there are several cert authorities (free ssl etc) i have found
its just easier to get a resale account (lots of
ok may or may not be related but i found i had to lock php, wordpress
etc down heavely in apache
especially if you are using vhosts
i found one authorized site could talk to another without making things
more strict
yes its a pain to have one vhost per site but its the only way to fully
13 matches
Mail list logo
