Conflito: Cloudflare x Servidor x Virusdie

Olá Gabriel,

Minhas instalações de servidor e na Cloudflare seguem as configurações do curso SS.

Eu também adotava o Cerber como meio de segurança, com as configurações do curso SS, porém, neste projeto que estou estruturando necessito adotar um plugin pago de checkout com funcionalidades bastante pertinentes ao que necessito, incluíndo compra com 1 click em LP de upsell. Ocorre que esse plugin deu conflito com o Cerber e como o Cerber está atualmente fora do repositório do Wordpress, a empresa que desenvolve o plugin de checkout não aceita solucionar esse conflito.

Para resolver, resolvi abandonar o Cerber e adotar o Vitusdie a partir de várias consultas positivas que fiz, que me indicaram ser uma opção muito boa. Embora pago, a simplicidade e a eficácia do serviço me parecem valer a pena.

Ontem tentei instalar o Virusdie num site novo que criei seguindo as configurações do SS, sem o Cerber.

Grosso modo, o Virusdie funciona assim:

Ao cadastrar o site no sistema deles, eles geram um arquivo exclusivo a ser inserido na pasta raiz do site no servidor. Esse arquivo possibilita a sincronização do site com o Virusdie, que executa seus serviços completamente em nuvem, sem nenhuma instalação pelo lado do servidor do cliente requisitante dos seus serviços de proteção.

O video nessa página da virusdie explica esse processo de conexão do site ao serviço deles:

https://br.virusdie.com/faq/add/

Seguindo essas instruções deles, instalei manualmente (via SFTP) esse arquivo na pasta raiz do meu site:

image

Em seguida, inseri os dois IPs da virusdie na lista de permissão da Cloudflare:

Feito isto, era pra funcionar a sincronização, porém ela não se estabelece e na plataforma da virusdie aparece esse aviso:

Ao tentar verificar se o arquivo de sincronização deles carrega no meu site, conforme teste que eles indicam, dá erro 404:

*Perceba que nessa página de erro 404 aparece o termo “nginx”.

No site da virusdie é indicada essa falta de sincronização:

Contatei o suporte da virus die, me responderam assim:

Após eu ter retornado que já inseri os 2 IPs deles na lista branca da Cloudflare, me responderam assim, fazendo referência ao erro 520 que atualmente é relacionado ao bloqueio da sincronização entre o site e o virusdie:

Renovei o cache do servidor. O problema permanece.

Não sei como proceder para solucionar.

DÚVIDAS:

1 - Será que esse problema tem a ver com as configurações de segurança do nginx no servidor?

2 - Você consegue me informar o caminho da solução?

Desde já,
Obrigado.

Neste caso, acredito que deve apenas mover o arquivo do Virusdie para dentro da pasta htdocs

1 curtida

Gabriel,

Segui sua instrução.

Daí o arquivo de sincronização do virusdie sinalizou como carregado, indicando a conexão do site com o virusdie. :+1:

Porém, no dashboard do virusdie permanece indicando o mesmo erro 520 (CDN Cloudflare), que impossibilita a sincronização.

image

Passei a tarde tentando e nada. Desliguei e liguei o servidor, o “always online” da Cloudflare, renovei cache,… nada.

Vi esse artigo da cloudflare sobre esse erro 520. Minha suspeita é que é algo relacionado às configurações de segurança na instalação do wordpress com wordops.

https://community.cloudflare.com/t/community-tip-fixing-error-520-web-server-is-returning-an-unknown-error/44205

Nesse tópico do fórum da cloudflare apontam também algo relacionado às configurações de portas no servidor com nginx resultando nesse erro 520:

https://community.cloudflare.com/t/blocking-access-over-port-80-with-nginx-444-results-in-520-error/159916/17

Você suspeita de algum destes atributos ou outro que possa estar gerando este problema, além do que você indicou anteriormente (já corrigido) ?

Primeiramente desabilita o proxy do CloudFlare, aguarda algumas horas e tenta novamente.

1 curtida

Gabriel,

Passado um tempo após eu ter desabilitado o proxy do CloudFlare, no dashboard do virusdie sumiu o aviso de erro 520 (cloudflare CDN) e apareceu o erro indicado no print abaixo:

image

Considerando o que li no fórum do Cloudflare, aparenta que o erro 520 que é indicado pelo Cloudflare se refere de fato a algo no servidor, como aponta esse print acima.

Curioso é que o arquivo de sincronização do Virusdie inserido na pasta .htdocs está carregando normalmente no meu site e indicando que o site está conectado com o Virusdie:

Pelo que li também no fórum da Cloudflare, pode ser algo relacionado ao bloqueio de portas, às limitações do servidor quanto ao volume do tráfego de dados nessa conexão ou outras configurações de segurança no servidor.

Que você me recomenda nesta etapa?

Novamente,
Obrigado pelo apoio.

Pessoalmente não trabalho com o VirusDie. Não sei quais são os requisitos dele.
Mas vamos pelo mais básico.

Como alterou arquivos logado como root
Tenta corrigir permissões.

De momento, até resolver isso mantem o CloudFlare desabilitado.

1 curtida

Gabriel,

Atualizei as permissões.

De fato, o arquivo de sincronização do Virusdie estava com as permissões ao root na pasta htdocs.

Feita a atualização das permissões, passou para www-data

Porém, depois dessa atualização da permissões, mesmo mantido desabilitado o Cloudflare para este site, que é um sub domínio, permanece o problema, conforme consta ao tentar sincronizar no dashboard do Virusdie:

image

*o arquivo de sincronização hospedado na pasta htdocs continua sendo acessado normalmente, indicando que o site está conectado com o Virusdie.

Bom dia Gabriel,

O que posso testar agora?

Abraço

Como eu não trabalho com VirusDie também estou um pouco perdido.
Não sei bem como lhe orientar.

Se quiser, envia o acesso SSH ao server, aos sites Wordpress e também a conta do VrusDie para [email protected]
Desta forma posso investigar.

Olá Gabriel,

Consegui enviar todos acessos agora (tive dia conturbado).

Obrigado

Recebi o acesso e segui as instruções deste link do Virus Die.
Liberei a porta 7000
Também liberei os IPs 51.81.107.180, 135.148.103.139 do VirusDie no firewall.

Mesmo assim não conectou.
Acredito que seja necessário abrir um ticket de suporte com o VirusDie.

1 curtida

Obrigado Gabriel,

Vou repassar essas informações ao Virusdie no ticket que já tenho aberto.

Informo quando tiver retorno.

1 curtida

Gabriel,

O suporte deles agora enviou essa mensagem:

Será que são os protocolos de segurança da instalação com o WordOps que bloqueiam essa conexão?

Putz, sem poder utilizar o Cerber (devido conflito com o plugin de checkout) e também o Virusdie minhas opções destes tipo de serviço de segurança ficam bem limitadas. Você tem alguma outra sugestão pra isso?

Novamente,
Obrigado.

Precisaria o acesso a um log do VirusDie para entender.
Mas sim, provavelmente tem alguma regra de segurança no Nginx que está bloqueando essa solicitação.

1 curtida

Sobre o cerber, me fala mais deste conflito.
Acredito que pode ser necessário apenas configurar uma exceção no cerber.

1 curtida

Gabriel,

Já tem um tempo que tudo isso ocorreu e o suporte do plugin de checkout após realizar testes com acesso ao meu site e servidor concluiu que era o Cerber que estava bloqueando. Após desabilitar funcionou.

Daí por diante deixei o Cerber desabilitado porque essa instalação era só para testes.

Tempo depois me enviaram um email informando que tinham atualizado o plugin deles para suprir o problema que eu tinha enfrentado. A informação ficou confusa e não sei se queria dizer se era sobre a incompatibilidade com o Cerber. Como eu iria instalar tudo novamente para produção mais a frente (que estou fazendo agora) deixei o assunto parado sem testar novamente com o Cerber.

Vou fazer o seguinte.

Vou reinstalar o Cerber nesse site de testes no qual está o plugin de checkout e ver como estão rodando juntos.

Assim que eu tiver esse diagnóstico te informo.

O problema basicamente era o seguinte.

Esse gateway de pagamento tem configuração para permitir que tanto usuários logados como não logados no site possam realizar a compra.

Após eu ter instalado e testado todas as opções que esse plugin permite e já integrado com o Stripe via woocommerce, o gateway de pagamento carregava normalmente na página de checkout e a finalização do pagamento transcorria normalmente inclusive com pagamento com um só click na página seguinte de upsell, desde que o visitante estivesse logado no site.

Todavia, na página de checkout os campos do gateway de pagamento não carregavam (ficavam em carregamento infinito) se o usuário não estivesse logado.

Fica totalmente inviável às vendas exigir login para finalizar compra.

Assim que eu tiver reinstalado/habilitado o Cerber e testado novamente te informo.

Obrigado

1 curtida

Gabriel,

Aparentemente consegui resolver o problema de bloqueio pelo Cerber.

Para tentar retornar ao Cerber, o reinstalei esta noite e iniciei os testes.

Logo após o reinstalar e adotar as configurações do SS, a página de checkout voltou a apresentar o não carregamento dos dados referentes aos produtos listados no checkout.

Daí fui desta vez checar as atividades no Cerber.

Percebi a recusa de formulário e bloqueio do IP no qual eu estava acessando a página de checkout, pelo meu celular.

Lembrando que esse bloqueio só ocorre quando o usuário não está logado.

Percebido isto, suspeitei da ativação no Cerber do antispam para todos formulários do site, além dos formulário de registro e comentários. Então a desabilitei, conforme abaixo.

Pelos testes que acabei de realizar, aparentemente, era exatamente essa configuração que impedia o carregamento adequado da página de checkout.

Vou permanecer nos testes estes dias para ver se surge algo novo, mas acho que era isso mesmo.

Só uma dúvida adicional, desabilitar essa função do Cerber aumenta muito os riscos ao site? (pelo que lembro existem configurações a respeito na instalação do wordops)

Obrigado pelo apoio.

Sua sugestão de verificar as configurações do Cerber foi fundamental.

Abraço.

Muito bom, obrigado pelo feedback.

1 curtida

Desabilitar essa configuração possibilita que bots enviem os formulários.
O que provavelmente vai acontecer serão comentários spam em paginas e posts que estão com comentários ativos.

1 curtida