10 Dicas Para Proteger O Joomla

Publicamos uma versão atualizada (3 de Julho de 2013) sobre segurança do Joomla:

Guia Prático Sobre Segurança Do Joomla

1. As Malditas Extensões – Sabor Doce, Digestão Amarga

Quantos de nós é que instalamos extensões por vaidade ou para satisfazer um prazer apenas estético? Eu sou culpado! É aquela febre de conhecer as novidades, a febre dos gadgets! Mas a digestão é amarga… Quase todos os problemas do Joomla, de segurança, muitas vezes também de perfomance, acontecem por causa das extensões que instalamos.

O código do próprio CMS é relativamente seguro. Mas, as extensões não são criadas pelos programadores do Joomla. São um contributo de programadores, quase sempre bem intencionados, mas nem sempre competentes. Você próprio, se souber programação, pode criar uma extensão para o Joomla. Ora, o facto de serem criadas por programadores que nem sempre dominam a programação do próprio CMS e, nalguns casos, não programam código competente e seguro, resulta na existência duma lista grande de extensões inseguras. A utilização duma única extensão insegura coloca em perigo todo o seu site.

O que fazer? Avalie cuidadosamente se precisa ou não de determinada extensão. Um dos mandamentos para manter o Joomla seguro é mantê-lo actualizado. Pois, quando estiver a avaliar se precisa ou não duma extensão, lembre-se do seguinte: se instalar 10 extensões, terá que manter o Joomla actualizado, mas também cada uma dessas 10 extensões. Se não estiver atento às novas versões de cada extensão, não fique muito admirado se acordar um dia e encontrar uma página dum hacker turco no lugar do seu site.

Se descobriu que está a utilizar uma extensão insegura e decidiu deixar de utilizá-la, não clique apenas para unpublish a extensão. Apague os ficheiros do servidor, caso contrário é como se ainda estivesse a utilizar a extensão. Se os ficheiros estiverem no servidor, o seu site estará vulnerável.

Como é que sabe que apagou todos os ficheiros? Se você instalou uma extensão chamada mod_ext1, procure um ficheiro chamado mod_ext1.xml. Abra esse ficheiro e verifique se apagou todas as pastas e ficheiros que constam nessa lista.

2. Cópias De Segurança – Não Faça O Seguro Depois Do Acidente!

Obrigue o seu webmaster, a quem você paga 1000 EUR por mês, a criar um manual com o que deve ser feito em caso de acidente (bug no script, hacker turco, disco furado, morte súbita da empresa de alojamento ou outra tragédia). E a elaborar e executar uma estratégia de cópias de segurança, que inclua a verificação da integridade dessas cópias.

Você não tem webmaster? Não se preocupe. Nesse caso, o webmaster é você. Poupe os 1000 Eur e leia com atenção.

Faça um backup total ou apenas dos ficheiros 1 x por semana ou 1 x por mês e sempre que instalar uma extensão, componente, template ou fizer qualquer alteração no código. Guarde pelo menos as últimas 4 cópias. Ou guarde-as todas. Se for como eu, guarda tanto lixo no computador, porque não guardar o que realmente é importante?! Se vai guardar várias cópias, organize as pastas de modo que fique claro a data de cada cópia de segurança.

Faça um backup da base de dados com a frequência que as actualizações do seu site justificarem. Se o seu site for actualizado diariamente, faça actualizações diárias da base de dados. Ou até mais do que 1 por dia. Se não for actualizado com tanta frequência, nesse caso, será você a pessoa melhor informada para decidir com que frequência é que deve efectuar cópias da base de dados. Não faça cópias totais todos os dias! Vai estar a abusar dos recursos do servidor e francamente se fizer isso merece um pontapé no traseiro!

Não guarde as cópias no seu alojamento. Descarregue as cópias para o seu PC e não custa nada ter também um backup dos ficheiros importantes que guarda no seu PC.

Se o seu site for valioso, teste a integridade dessas cópias ocasionalmente. Dá trabalho, não dá. Pois dá. Mas a responsabilidade pelas cópias de segurança e pela verificação da integridade das mesmas compete ao webmaster. E ou você tem orçamento para contratar e pagar ao webmaster para ter este trabalho ou é você que vai ter que fazê-lo. Com prática, dá menos trabalho…

3 – Não Deixe O Cofre No Jardim – configuration.php

Quando carregou o seu site para o servidor, teve que efectuar o upload dos ficheiros para um determinada pasta. Nos servidores com cpanel, é a pasta public_html. Nos servidores com Plesk, é a pasta httpdocs. Ora, essa pasta é aquela que está acessível a qualquer utilizador anónimo. Se você colocar um ficheiro index.html nessa pasta, eu vou conseguir aceder a este ficheiro. O meu sobrinho de 3 anos vai conseguir. E qualquer outra pessoa com um browser vai também conseguir.

Essa pasta é a mais vulnerável em qualquer servidor. Portanto, é boa ideia mover os ficheiros mais sensíveis para uma pasta menos vulnerável. É o caso do ficheiro configuration.php.

Mova esse ficheiro para uma pasta acima da public_html ou httpdocs. Mude o nome do ficheiro para umnomequalquerqueeuseiemaisninguemsabe.php e coloque um novo ficheiro configuration.php no lugar do anterior, com o seguinte código:

Mude as permissões deste novo ficheiro para 444. Se precisar de mudar as configurações, faça o manualmente no umnomequalquerqueeuseiemaisninguemsabe.php.

4. Actualizações Do Joomla – Trabalho Para Robot

Actualize sempre o Joomla e com urgência. E cada extensão que você instalou. Porquê? Imagine que tem uma vivenda magnífica (se tiver, não precisa de imaginar), e descobre que uma das suas janelas no R/C está partida, tem um buraco enorme. Quando é que você vai reparar a janela?

Subscreva à Joomla Security Mailing List. Poderá fazê-lo através do próprio Joomla. Faça login como administrador. No menu, seleccione Extensions e depois Module Manager. Seleccione Administrator. No menu dos icons, seleccione New, depos Feeds Display. Na página de configuração dos Feeds, coloque como título Notificações de Segurança e seleccione a opção minimum. Coloque o feed: http://feeds.joomla.org/JoomlaSecurityNews no campo do url. Seleccione a posição cpanel. Clique Apply no menu dos icons. Clique para guardar no menu dos icons.

5. Permissões De Escrita – Não Deixe A Porta De Casa Aberta

Verifique se a sua empresa de alojamento corre o PHP em modo CGI com su_php. Esta opção é mais segura que a instalação do PHP como módulo do apache. Sem entrar em demasiados detalhes técnicos, se o PHP corre modo modo CGI, não precisa de utilizar permissões 777 nalgumas pastas, onde o Joomla precisa de escrever. Se precisar de utilizar permissões 777, a sua conta fica aberta a ataques doutros utilizadores no mesmo servidor. E também coloca questões complicadas em termos de gestão do alojamento. Se carregar um ficheiro com o Joomla, depois não consegue alterá-lo através de ftp e vice-versa.

Num servidor onde o PHP corre como CGI, pode dar permissões 755 às pastas onde precisa de escrever e funciona tudo bem. A regra é que os ficheiros tenham permissões 644 e as pastas 755.

Durante o processo de instalação, o Joomla precisa de permissões de escrita nalgumas pastas. Porque razão é que esse facto poderá ser um risco de segurança?

Este tutorial não vai tratar o tema das permissões ao nível de ficheiros e pastas num servidor Linux. Poderá consultar este tutorial, se quiser mais informação sobre esse tema, mas em termos muito sumários, se o servidor estiver a correr o php como módulo do apache, o php será executado pelo utilizador nobody ou apache. A sua conta de alojamento é representada pelo utilizador que você utiliza para fazer login no control panel ou por ftp, no cpanel é habitual que seja as asprimeirasoitoletrasdoseudominio. Portanto, o php é executado por um utilizador diferente (nobody) do seu utilizador (asprimeirasoitoletrasdoseudominio). Ora, para que o apache ou o nobody possa escrever dentro de pastas que pertencem ao seu utilizador, precisa que você dê permissões de escrita ao utilizador anónimo. Desse modo, um utilizador diferente, neste caso o nobody ou apache, poderão escrever numa pasta da sua conta. Mas qualquer outro utilizador, naquele servidor, poderá fazê-lo. Quando lê nas instruções de instalação que tem que dar permissões 777 às pastas modules, templates, etc, está a dar permissão a qualquer utilizador naquele servidor para escrever nessas pastas. E isso representa um risco em termos de segurança.

Quando o php corre como cgi, porque é executado pelo SEU utilizador e não pelo utilizador nobody ou apache, você já não precisa de dar permissões ao utilizador anónimo. Logo, APENAS o seu utilizador, naquele servidor, terá permissões de escrita nas suas pastas. Nesse caso, sempre que ler que tem que dar permissões 777 a determinada pasta, IGNORE essa instrução e dê apenas permissões 755.

E como é que poderá saber se o php corre como módulo do apache ou como cgi? Pergunte à empresa que lhe presta o serviço de alojamento. Ou coloque este código num ficheiro php, por exemplo: phpinfo.php

Abra o ficheiro no browser e veja você mesmo: www.oseudominiolindo.com/phpinfo.php

Como gerir o risco, se o servidor correr o php com o utilizador nobody ou apache? Sempre que tiver que instalar alguma coisa, mude as permissões das pastas necessários para 777 e depois, dentro da pasta do joomla, execute estes comandos através de ssh:


find . -type f -exec chmod 644 '{}' \;
find . -type d -exec chmod 755 '{}' \;


Se não tiver acesso ftp, coloque este código num ficheiro php, exemplo permissoes.php, e abra esse ficheiro no seu browser: www.nomedoseudominio.com/permissoes.php

6. Passwords – Coma Menos Queijo

Não se dê ao trabalho de actualizar constantemente o Joomla, de seguir todas estas recomendações, para depois deitar tudo a perder com a utilização duma password insegura. Preste atenção a este ponto. A password deve ter letras maiúsculas, minúsculas, números e caracteres especiais. Não precisa de ser muito extensa. Utilize por exemplo 3 letras maiúsculas, 3 números, uma letra minúscula e um caracter especial. Exemplo: M82+EhY2

Verifique também se a empresa de alojamento tem alguma defesa contra brute force attacks.

Se quiser, pode também proteger a pasta administrator com username e password. Se tiver acesso ao cpanel, tem uma opção chamada Password Protect Directories. Assim fica com uma dupla protecção, dado que para aceder à zona de administração, o hacker terá que efectuar um primeiro login para aceder à pasta administrator, antes de efectuar o login normal no Joomla.

Mas, não utilize esta dupla protecção para justificar a instalação de meia dúzia de extensões.

7. O Malando Do Google

De que forma é que os hackers decidem atacar o seu site? O método habitual é simples de explicar. Descobrem por exemplo que uma determinada versão duma extensão está vulnerável e a forma de explorar essa vulnerabilidade e depois procuram no Google através do comando inurl: a assinatura dessa extensão. O resultado é uma lista de sites vulneráveis e se o seu site estiver nessa lista, advinhe o que vai acontecer.

Utilize um componente SEF (Eearch Engine Friendly) de modo a rescrever o seu url. Assim não aparecerá naquelas listas e terá mais sucesso nas pesquisas que lhe interessam no Google, dado que o seu site ficará mais optimizado para o Google.

Na prática, o que acontece é o seguinte: os urls do Joomla e das respectivas extensões por defeito dizem demasiado ao visitante sobre o que está instalado, que versões é que estão instaladas, etc. Ao reescrever esses url, essa informação deixa de estar disponível. E os hackers são, na maioria dos casos, tipos preguiçosos. Se não fossem preguiçosos, teriam um trabalho honesto.

8. Templates – Uma Diva A Experimentar Roupa

O habitual quando entro na pasta de templates do Joomla é encontrar lá meia dúzia de templates abandonados. Quando instalamos o Joomla pela primeira vez, parecemos uma diva a experimentar roupa. E depois deixamos os templates espalhados pelo quarto.

Apague os templates que não está a utilizar. Quantos é que sobraram? Apenas um.

9. O User Admin – A Chave Na Fechadura

Seleccione o User Manager. Seleccione o registo do utilizador admin. Altere o valor do utilizador. Guarde.

A questão é simples. Para entrar como administrador, é necessário advinhar o username e a password. Qualquer hacker sabe que por defeito existe um utilizador admin. Se mantiver este utilizador, o hacker já terá completado 50% do trabalho. Se alterar o utilizador, o hacker terá que advinhar a password, mas também o utilizador.

10. As Register Globals – RG_EMULATION

O próprio Joomla amaldiçoa as Register Globals e depois pede aos utilizadores para desactivarem o RG_Emulation. O RG_ significa Register Globals. Algumas extensões precisam que o RG_Emulation esteja activado, dado que utilizam as Register Globals. O melhor é desactivar e não utilizar essas extensões.