http://www.webmaster.pt/joomla-tutorial-seguranca-4.

html

10 Dicas Para Proteger O Joomla

1. As Malditas Extenses Sabor Doce, Digesto Amarga
Quantos de ns que instalamos extenses por vaidade ou para satisfazer um prazer apenas esttico? Eu sou culpado! aquela febre de conhecer as novidades, a febre dos gadgets! Mas a digesto amarga Quase todos os problemas do Joomla, de segurana, muitas vezes tambm de perfomance, acontecem por causa das extenses que instalamos. O cdigo do prprio CMS relativamente seguro. Mas, as extenses no so criadas pelos programadores do Joomla. So um contributo de programadores, quase sempre bem intencionados, mas nem sempre competentes. Voc prprio, se souber programao, pode criar uma extenso para o Joomla. Ora, o facto de serem criadas por programadores que nem sempre dominam a programao do prprio CMS e, nalguns casos, no programam cdigo competente e seguro, resulta na existncia duma lista grande de extenses inseguras. A utilizao duma nica extenso insegura coloca em perigo todo o seu site. O que fazer? Avalie cuidadosamente se precisa ou no de determinada extenso. Um dos mandamentos para manter o Joomla seguro mant-lo actualizado. Pois, quando estiver a avaliar se precisa ou no duma extenso, lembre-se do seguinte: se instalar 10 extenses, ter que manter o Joomla actualizado, mas tambm cada uma dessas 10 extenses. Se no estiver atento s novas verses de cada extenso, no fique muito admirado se acordar um dia e encontrar uma pgina dum hacker turco no lugar do seu site. Se descobriu que est a utilizar uma extenso insegura e decidiu deixar de utiliz-la, no clique apenas para unpublish a extenso. Apague os ficheiros do servidor, caso contrrio como se ainda estivesse a utilizar a extenso. Se os ficheiros estiverem no servidor, o seu site estar vulnervel. Como que sabe que apagou todos os ficheiros? Se voc instalou uma extenso 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. Cpias De Segurana No Faa O Seguro Depois Do Acidente!

Obrigue o seu webmaster, a quem voc paga 1000 EUR por ms, a criar um manual com o que deve ser feito em caso de acidente (bug no script, hacker turco, disco furado, morte sbita da empresa de alojamento ou outra tragdia). E a elaborar e executar uma estratgia de cpias de segurana, que inclua a verificao da integridade dessas cpias. Voc no tem webmaster? No se preocupe. Nesse caso, o webmaster voc. Poupe os 1000 Eur e leia com ateno.

Faa um backup total ou apenas dos ficheiros 1 x por semana ou 1 x por ms e sempre que instalar uma extenso, componente, template ou fizer qualquer alterao no cdigo. Guarde pelo menos as ltimas 4 cpias. Ou guarde-as todas. Se for como eu, guarda tanto lixo no computador, porque no guardar o que realmente importante?! Se vai guardar vrias cpias, organize as pastas de modo que fique claro a data de cada cpia de segurana. Faa um backup da base de dados com a frequncia que as actualizaes do seu site justificarem. Se o seu site for actualizado diariamente, faa actualizaes dirias da base de dados. Ou at mais do que 1 por dia. Se no for actualizado com tanta frequncia, nesse caso, ser voc a pessoa melhor informada para decidir com que frequncia que deve efectuar cpias da base de dados. No faa cpias totais todos os dias! Vai estar a abusar dos recursos do servidor e francamente se fizer isso merece um pontap no traseiro! No guarde as cpias no seu alojamento. Descarregue as cpias para o seu PC e no custa nada ter tambm um backup dos ficheiros importantes que guarda no seu PC. Se o seu site for valioso, teste a integridade dessas cpias ocasionalmente. D trabalho, no d. Pois d. Mas a responsabilidade pelas cpias de segurana e pela verificao da integridade das mesmas compete ao webmaster. E ou voc tem oramento para contratar e pagar ao webmaster para ter este trabalho ou voc que vai ter que faz-lo. Com prtica, d menos trabalho

3 No 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 acessvel a qualquer utilizador annimo. 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 tambm conseguir. Essa pasta a mais vulnervel em qualquer servidor. Portanto, boa ideia mover os ficheiros mais sensveis para uma pasta menos vulnervel. 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 cdigo:

<? require( dirname( _FILE_ ) . '/../umnomequalquerqueeuseiemaisninguemsabe.php'); ?>

Mude as permisses deste novo ficheiro para 444. Se precisar de mudar as configuraes, faa o manualmente no umnomequalquerqueeuseiemaisninguemsabe.php.

4. Actualizaes Do Joomla Trabalho Para Robot

Actualize sempre o Joomla e com urgncia. E cada extenso que voc instalou. Porqu? Imagine que tem uma vivenda magnfica (se tiver, no 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 atravs do prprio Joomla. Faa login como administrador. No menu, seleccione Extensions e depois Module Manager. Seleccione Administrator. No menu dos icons, seleccione New, depos Feeds Display. Na pgina de configurao dos Feeds, coloque como ttulo Notificaes de Segurana e seleccione a opo minimum. Coloque o feed: http://feeds.joomla.org/JoomlaSecurityNews no campo do url. Seleccione a posio cpanel. Clique Apply no menu dos icons. Clique para guardar no menu dos icons.

5. Permisses De Escrita No Deixe A Porta De Casa Aberta

Verifique se a sua empresa de alojamento corre o PHP em modo CGI com su_php. Esta opo mais segura que a instalao do PHP como mdulo do apache. Sem entrar em demasiados detalhes tcnicos, se o PHP corre modo modo CGI, no precisa de utilizar permisses 777 nalgumas pastas, onde o Joomla precisa de escrever. Se precisar de utilizar permisses 777, a sua conta fica aberta a ataques doutros utilizadores no mesmo servidor. E tambm coloca questes complicadas em termos de gesto do alojamento. Se carregar um ficheiro com o Joomla, depois no consegue alter-lo atravs de ftp e vice-versa. Num servidor onde o PHP corre como CGI, pode dar permisses 755 s pastas onde precisa de escrever e funciona tudo bem. A regra que os ficheiros tenham permisses 644 e as pastas 755. Durante o processo de instalao, o Joomla precisa de permisses de escrita nalgumas pastas. Porque razo que esse facto poder ser um risco de segurana? Este tutorial no vai tratar o tema das permisses ao nvel de ficheiros e pastas num servidor Linux. Poder consultar este tutorial, se quiser mais informao sobre esse tema, mas em termos muito sumrios, se o servidor estiver a correr o php como mdulo 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 permisses de escrita ao utilizador annimo. Desse modo, um utilizador diferente, neste caso o nobody ou apache, podero escrever numa pasta da sua conta. Mas qualquer outro utilizador, naquele servidor, poder faz-lo. Quando l nas instrues de instalao que tem que dar permisses 777 s pastas modules, templates, etc, est a dar

permisso a qualquer utilizador naquele servidor para escrever nessas pastas. E isso representa um risco em termos de segurana. Quando o php corre como cgi, porque executado pelo SEU utilizador e no pelo utilizador nobody ou apache, voc j no precisa de dar permisses ao utilizador annimo. Logo, APENAS o seu utilizador, naquele servidor, ter permisses de escrita nas suas pastas. Nesse caso, sempre que ler que tem que dar permisses 777 a determinada pasta, IGNORE essa instruo e d apenas permisses 755. E como que poder saber se o php corre como mdulo do apache ou como cgi? Pergunte empresa que lhe presta o servio de alojamento. Ou coloque este cdigo num ficheiro php, por exemplo: phpinfo.php

<? phpinfo(); ?>

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 permisses das pastas necessrios para 777 e depois, dentro da pasta do joomla, execute estes comandos atravs de ssh:

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

Se no tiver acesso ftp, coloque este cdigo num ficheiro php, exemplo permissoes.php, e abra esse ficheiro no seu browser: www.nomedoseudominio.com/permissoes.php

<? shell_exec("find . -type d -exec chmod 755 {} \\;"); shell_exec("find . -type f -name '*.php' -exec chmod 644 {} \\;"); ?>

6. Passwords Coma Menos Queijo

No se d ao trabalho de actualizar constantemente o Joomla, de seguir todas estas recomendaes, para depois deitar tudo a perder com a utilizao duma password

insegura. Preste ateno a este ponto. A password deve ter letras maisculas, minsculas, nmeros e caracteres especiais. No precisa de ser muito extensa. Utilize por exemplo 3 letras maisculas, 3 nmeros, uma letra minscula e um caracter especial. Exemplo: M82+EhY2 Verifique tambm se a empresa de alojamento tem alguma defesa contra brute force attacks. Se quiser, pode tambm proteger a pasta administrator com username e password. Se tiver acesso ao cpanel, tem uma opo chamada Password Protect Directories. Assim fica com uma dupla proteco, dado que para aceder zona de administrao, o hacker ter que efectuar um primeiro login para aceder pasta administrator, antes de efectuar o login normal no Joomla. Mas, no utilize esta dupla proteco para justificar a instalao de meia dzia de extenses.

7. O Malando Do Google
De que forma que os hackers decidem atacar o seu site? O mtodo habitual simples de explicar. Descobrem por exemplo que uma determinada verso duma extenso est vulnervel e a forma de explorar essa vulnerabilidade e depois procuram no Google atravs do comando inurl: a assinatura dessa extenso. O resultado uma lista de sites vulnerveis 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 no 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 prtica, o que acontece o seguinte: os urls do Joomla e das respectivas extenses por defeito dizem demasiado ao visitante sobre o que est instalado, que verses que esto instaladas, etc. Ao reescrever esses url, essa informao deixa de estar disponvel. E os hackers so, na maioria dos casos, tipos preguiosos. Se no fossem preguiosos, teriam um trabalho honesto.

8. Templates Uma Diva A Experimentar Roupa

O habitual quando entro na pasta de templates do Joomla encontrar l meia dzia 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 no 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 questo simples. Para entrar como administrador, necessrio 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 tambm o utilizador.

10. As Register Globals RG_EMULATION

O prprio Joomla amaldioa as Register Globals e depois pede aos utilizadores para desactivarem o RG_Emulation. O RG_ significa Register Globals. Algumas extenses precisam que o RG_Emulation esteja activado, dado que utilizam as Register Globals. O melhor desactivar e no utilizar essas extenses.