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!
Obrigado pela disponibilidade Edvan!
As portas do nosso blog estão abertas para sempre que você desejar 🙂
Disponha Autarquia! Eu que agradeço, abraços.
Obrigado pela disponibilidade Edvan!
As portas do nosso blog estão abertas para sempre que você desejar 🙂
Disponha Autarquia! Eu que agradeço, abraços.
Edvan, quando eu vou editar template ou qualquer ação que use subject meu IP é banido tambem..
Jonatas, não tem relação… exceto se conter a tag {php} daí não tem jeito!
Por favor faça um teste com o seu, edite um template de e-mail e salve
Já fiz isso e não tem nenhum erro/falha.
Conforme informei se o template possuir a tag {php} certamente dará erro.
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
Baixa novamente o arquivo disponibilizado aqui no site que corrigirá esse problema!
Edvan, quando eu vou editar template ou qualquer ação que use subject meu IP é banido tambem..
Jonatas, não tem relação… exceto se conter a tag {php} daí não tem jeito!
Por favor faça um teste com o seu, edite um template de e-mail e salve
Já fiz isso e não tem nenhum erro/falha.
Conforme informei se o template possuir a tag {php} certamente dará erro.
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
Baixa novamente o arquivo disponibilizado aqui no site que corrigirá esse problema!
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!
Sim, visite https://modulos.edvan.com.br/
É sim, no google tem N tutoriais.
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!
Sim, visite https://modulos.edvan.com.br/
É sim, no google tem N tutoriais.
Pronto Edvan, obrigado mais uma vez.
Pronto Edvan, obrigado mais uma vez.
[…] fevereiro criei um post sobre esse mesmo assunto que inclui um script para […]
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?
Anderson,
Fiz a atualização do banned.php e atualizei o arquivo do blog!
Obrigado.
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?
Anderson,
Fiz a atualização do banned.php e atualizei o arquivo do blog!
Obrigado.
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″)
O checklist foi montado na época do 5.0.3, já fiz a alteração e enviei o novo arquivo! Obrigado.
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″)
O checklist foi montado na época do 5.0.3, já fiz a alteração e enviei o novo arquivo! Obrigado.
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!
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!
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 🙂
Disponha!
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 🙂
Disponha!
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?
Você quem decide… é uma “proteção” a mais!
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?
Você quem decide… é uma “proteção” a mais!
Sensacional estas dicas fiz tudo Edvan, obrigado!
Sensacional estas dicas fiz tudo Edvan, obrigado!
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.
Marcelo,
Tenho que ver com o fabricante se essas permissões não afetam o sistema.
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..
Marcelo,
Agradeço seus comentários, irei encaminhar essa dica para WHMCS.com
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.
Marcelo,
Tenho que ver com o fabricante se essas permissões não afetam o sistema.
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..
Marcelo,
Agradeço seus comentários, irei encaminhar essa dica para WHMCS.com
parabens pelo conhecimento compartilhado, que Deus lhe de muita sabedoria sempre.
Obrigado pela visita!
parabens pelo conhecimento compartilhado, que Deus lhe de muita sabedoria sempre.
Obrigado pela visita!