Segurança no WHMCS

59

Dicas de segurança! Semana passada recebi um convite do Carlos Zamora, gerente comercial da HostDime Brasil para escrever um post no https://blog.hostdime.com.br tendo como tema  Segurança no WHMCS.

No post dei algumas dicas de como aumentar a segurança no WHMCS e criei um checklist de segurança checklist.php que possibilita verificar 10 itens que considero essenciais para reforçar a segurança do seu WHMCS. Além do hook banned.php que irá evitar tickets falsos (exploit – {php}eval(base64_decode(….);

O artigo completo você pode conferir aqui.

Em relação os arquivos citados no post  faça o download do arquivo CheckList Segurança + Hook Anti-Exploit .

Após o download envie o banned.php  para pasta/includes/hooks/ e o checklist.php para raiz do WHMCS.

Após realizar o checklist não esqueça de remover o arquivo!

Veja uma demonstração do checklist em funcionamento:


Obrigado à HostDime Brasil pelo convite!

Gostou? Comente!

59 COMENTÁRIOS

        • Caro Edvan, boa noite
          Estou enfrentando o mesmo problema ao tentar editar modelos de email meu IP é banido na hora, estou usando tags apenas do sistema ou seja chaves “}” como no exemplo abaixo:
          Plano de Hospedagem: {$service_product_name}
          Domínio: {$service_domain}
          Valor do 1º Pagamento: {$service_first_payment_amount}
          Total: {$service_recurring_amount}
          Ciclo de Faturamento(mensal): {$service_billing_cycle}
          Próximo Vencimento: {$service_next_due_date

        • Caro Edvan, boa noite
          Estou enfrentando o mesmo problema ao tentar editar modelos de email meu IP é banido na hora, estou usando tags apenas do sistema ou seja chaves “}” como no exemplo abaixo:
          Plano de Hospedagem: {$service_product_name}
          Domínio: {$service_domain}
          Valor do 1º Pagamento: {$service_first_payment_amount}
          Total: {$service_recurring_amount}
          Ciclo de Faturamento(mensal): {$service_billing_cycle}
          Próximo Vencimento: {$service_next_due_date

  1. Muito bom isso ajudou muito tirando uma duvida aqui você tem módulos do pagamento digital para a ultima versão do WHMCS? gostaria de saber se é possível retirar o .php do final das urls das paginas e como fazer isso Obrigado!

  2. Muito bom isso ajudou muito tirando uma duvida aqui você tem módulos do pagamento digital para a ultima versão do WHMCS? gostaria de saber se é possível retirar o .php do final das urls das paginas e como fazer isso Obrigado!

  3. Edvan, nesta nova versão do whmcs 5.1.2 o arquivo banned.php quando ativo causa um problema na edição de templates do whmcs. Verifiquei essa falha e cheguei nele pela seguinte forma. Importei a tabela de templates de e-mail original e continuava o erro de não salvar. Neste caso fui desativando custumizações que fiz uma a uma até desativar o banned.php arquivo que automaticamente ao tentar salvar uma personalização no template de e-mail, ele salvou … quando ativo o banned.php novamente para de salvar ou deixar editar qualquer texto dentro dos templates de e-mail! Poderia testar ai e verificar?

  4. Edvan, nesta nova versão do whmcs 5.1.2 o arquivo banned.php quando ativo causa um problema na edição de templates do whmcs. Verifiquei essa falha e cheguei nele pela seguinte forma. Importei a tabela de templates de e-mail original e continuava o erro de não salvar. Neste caso fui desativando custumizações que fiz uma a uma até desativar o banned.php arquivo que automaticamente ao tentar salvar uma personalização no template de e-mail, ele salvou … quando ativo o banned.php novamente para de salvar ou deixar editar qualquer texto dentro dos templates de e-mail! Poderia testar ai e verificar?

  5. Edvan, nota 10 esse seu tópico.
    Fica aqui mais uma dica para atualizar o checklist. A verificação 4 está considerando a versão 5.0.3 e já estamos na 5.1.2
    Eu mudei e ficou assim:

    if ($version!=”5.1.2″)

  6. Edvan, nota 10 esse seu tópico.
    Fica aqui mais uma dica para atualizar o checklist. A verificação 4 está considerando a versão 5.0.3 e já estamos na 5.1.2
    Eu mudei e ficou assim:

    if ($version!=”5.1.2″)

  7. Edvan, mais uma dica que poderia incorporar nessa verificação tem relação direta ao próprio arquivo. É extremamente interessante a alteração no nome desse arquivo checklist.php antes de enviar para o servidor. Um curioso qualquer pode executar o arquivo e daí obter algumas dicas sobre a instalação. Outra atitude segura seria não manter esse arquivo no servidor. Apenas fazer a verificação (excelente!) e em seguida apagá-lo.
    Fica a dica.
    Abraço

    • Marcos,

      Em tese a pessoa que realizou o checklist irá excluir o arquivo.

      Já coloquei uma observação no post “Após realizar o checklist não esqueça de remover o arquivo!”.

      Creio que seja o suficiente!

  8. Edvan, mais uma dica que poderia incorporar nessa verificação tem relação direta ao próprio arquivo. É extremamente interessante a alteração no nome desse arquivo checklist.php antes de enviar para o servidor. Um curioso qualquer pode executar o arquivo e daí obter algumas dicas sobre a instalação. Outra atitude segura seria não manter esse arquivo no servidor. Apenas fazer a verificação (excelente!) e em seguida apagá-lo.
    Fica a dica.
    Abraço

    • Marcos,

      Em tese a pessoa que realizou o checklist irá excluir o arquivo.

      Já coloquei uma observação no post “Após realizar o checklist não esqueça de remover o arquivo!”.

      Creio que seja o suficiente!

  9. Pessoal,

    Aqui, curiosamente estava funcionando normal (fazia um tempão que eu tinha instalado esse script, basta ver a data do post e a epoca em que tivemos o problema com o whmcs) Daquela epoca até agora, eu criei templates de email normalmente, mas desde ontem, meu whmcs começou a me banir ao criar novos templates de email…e pesquisando uma solução encontrei os colegas comentando.
    Gostaria de informar, que baixei novamente o arquivo conforme orientação do Edvan, subi p/ servidor e aparentemente o problema foi resolvido. Pois não fui mais banido.
    Esse é o tipo de problema, que ninguém quer entender, só quer resolver hehehehe

    Obrigado 🙂

  10. Pessoal,

    Aqui, curiosamente estava funcionando normal (fazia um tempão que eu tinha instalado esse script, basta ver a data do post e a epoca em que tivemos o problema com o whmcs) Daquela epoca até agora, eu criei templates de email normalmente, mas desde ontem, meu whmcs começou a me banir ao criar novos templates de email…e pesquisando uma solução encontrei os colegas comentando.
    Gostaria de informar, que baixei novamente o arquivo conforme orientação do Edvan, subi p/ servidor e aparentemente o problema foi resolvido. Pois não fui mais banido.
    Esse é o tipo de problema, que ninguém quer entender, só quer resolver hehehehe

    Obrigado 🙂

  11. bom dia Edvan, como vai?

    Obrigado pelas dicas, como sempre você nos ajudando.

    Me diz uma coisa? Na versão 5.1.3 ainda preciso do arquivo banned.php em includes/hooks?

  12. bom dia Edvan, como vai?

    Obrigado pelas dicas, como sempre você nos ajudando.

    Me diz uma coisa? Na versão 5.1.3 ainda preciso do arquivo banned.php em includes/hooks?

  13. Ola Edvan. Devido a ataques do tipo synlink nós recomendamos permissões 660 ou 640 mas não 644. Ataques via symlink permitem a um site hackeado gerar hyper links para dentro de outros sites mesmo que o servidor esteja funcionando sob suphp. Estando com permissão 640 ou 660 fará com que mesmo que seja linkado o arquivo a partir de outro site o mesmo não se torne visível ao hacker apresentando um erro de leitura.

      • Não afeta e aumenta a segurança. Se manter 644 e um site no mesmo servidor for hackeado e criar um symlink para dentro desta conta que usa o WHMCS sendo esse symlink direto para o arquivo configuration.php, o hacker poderá ver o conteúdo deste arquvio a partir do site hackeado. É uma técnica de hack desenvolvida e útil quando o servidor funciona em suphp, ou seja, mesmo estando em suphp o hacker consegue visualizar o conteúdo de qq arquivo de outra conta a parte de uma conta hackeada. Em nossa empresa temos um cron interno que muda a permissão de TODOS arquivos que são utilizados para armazenar dados como senhas. Isso roda uma vez ao dia. Observação: a permissão deve ser dado ao arquivo configuration.php que é o que deseja ter proteção. Não é em todos arquivos do site

      • Para completar. Um site é hackeado. o hacker coleta o nome de todos users do servidor ( os mesmos que dão acesso ao cpanel ). A partir desta lista ele cria diversos hyperlinks para dentro das contas imaginando que estas possam ter arquivos configuration.php, config.php, wp-config.php e etc. Ou seja, ele criar milhares de hyperlinks para cada user do servidor. Após isso ele acessa cada hyperlink para ver se existe ligação e se houver o hacker consegue ler o conteúdo do arquivo. A partir dai é possível hackear a conta. Para isso não acontecer não pode haver permissão 644. Eu fico abismado é com os fabricantes de scripts famosos que SEMPRE usam o mesmo nome do arquivo que guarda a senha. Deveria ser gerado um arquivo com nome aleatório para cada instalação e não um tradicional CONFIGURATION.PHP. Isso apenas facilita aos hackers. Basta vc instalar o wordpress. Sempre terá o arquivo wp-config.php ou o WHMCS que sempre terá o configuration.php. Alem disso a permissão 644 é um grande erro inclusive dos fabricntes destes scripts. Mas veja bem, eu apenas sei disso pq administro servidor. Eles não tem a visão que temos mas se tivessem os scripts seriam mais seguros. Hack via hyperlink é muito, mas MUITO comum. No forum do cpanel tem uma discussão sobre isso e como resolver. Na verdade não tem como, somente gambiarra. É uma falha do servidor Apache..

  14. Ola Edvan. Devido a ataques do tipo synlink nós recomendamos permissões 660 ou 640 mas não 644. Ataques via symlink permitem a um site hackeado gerar hyper links para dentro de outros sites mesmo que o servidor esteja funcionando sob suphp. Estando com permissão 640 ou 660 fará com que mesmo que seja linkado o arquivo a partir de outro site o mesmo não se torne visível ao hacker apresentando um erro de leitura.

      • Não afeta e aumenta a segurança. Se manter 644 e um site no mesmo servidor for hackeado e criar um symlink para dentro desta conta que usa o WHMCS sendo esse symlink direto para o arquivo configuration.php, o hacker poderá ver o conteúdo deste arquvio a partir do site hackeado. É uma técnica de hack desenvolvida e útil quando o servidor funciona em suphp, ou seja, mesmo estando em suphp o hacker consegue visualizar o conteúdo de qq arquivo de outra conta a parte de uma conta hackeada. Em nossa empresa temos um cron interno que muda a permissão de TODOS arquivos que são utilizados para armazenar dados como senhas. Isso roda uma vez ao dia. Observação: a permissão deve ser dado ao arquivo configuration.php que é o que deseja ter proteção. Não é em todos arquivos do site

      • Para completar. Um site é hackeado. o hacker coleta o nome de todos users do servidor ( os mesmos que dão acesso ao cpanel ). A partir desta lista ele cria diversos hyperlinks para dentro das contas imaginando que estas possam ter arquivos configuration.php, config.php, wp-config.php e etc. Ou seja, ele criar milhares de hyperlinks para cada user do servidor. Após isso ele acessa cada hyperlink para ver se existe ligação e se houver o hacker consegue ler o conteúdo do arquivo. A partir dai é possível hackear a conta. Para isso não acontecer não pode haver permissão 644. Eu fico abismado é com os fabricantes de scripts famosos que SEMPRE usam o mesmo nome do arquivo que guarda a senha. Deveria ser gerado um arquivo com nome aleatório para cada instalação e não um tradicional CONFIGURATION.PHP. Isso apenas facilita aos hackers. Basta vc instalar o wordpress. Sempre terá o arquivo wp-config.php ou o WHMCS que sempre terá o configuration.php. Alem disso a permissão 644 é um grande erro inclusive dos fabricntes destes scripts. Mas veja bem, eu apenas sei disso pq administro servidor. Eles não tem a visão que temos mas se tivessem os scripts seriam mais seguros. Hack via hyperlink é muito, mas MUITO comum. No forum do cpanel tem uma discussão sobre isso e como resolver. Na verdade não tem como, somente gambiarra. É uma falha do servidor Apache..

DEIXE UMA RESPOSTA

Please enter your comment!
Please enter your name here