Checklist de segurança Joomla!

Algumas dicas de segurança mais ou menos avulsas para Joomla.

A. Geral

1. Aplicam-se as regras de segurança genéricas para o Apache, PHP e MySQL.

B. Instalação

1. Não usar o prefixo de tabela MySQL "jos_".
2. Definir as permissões do configuration.php para 444 (ou pelo menos 644).
3. Em geral, os ficheiro PHP precisam de permissões 644 (preferencialmente 444) e as diretorias 755 (ou preferencialmente 555).
4. De forma geral é boa ideia mover as diretorias /tmp, /log e todas as diretorias que precisem permissão de escrita (caches, imagens, uploads, etc) para FORA da diretoria pública (public_html), retirando-lhes portanto a possibilidade de acesso através de HTTP. No entanto isto pode causar problemas com a diretiva open_basedir do PHP e com algumas extensões.
5. Não permitir o upload de scripts
6. Renomear o ficheiro htaccess.txt para .htaccess e ligar o RewriteEngine.
7. A adição destas linhas ao .htaccess bloqueia alguns exploits mais comuns:

########## Begin - Rewrite rules to block out some common exploits
#
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*(.*) [OR]
# Block out any script that includes a < script> tag in URL
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2}) [OR]
# Block out any script that tries to set CONFIG_EXT (com_extcal2 issue)
RewriteCond %{QUERY_STRING} CONFIG_EXT([|%20|%5B).*= [NC,OR]
# Block out any script that tries to set sbp or sb_authorname via URL (simpleboard)
RewriteCond %{QUERY_STRING} sbp(=|%20|%3D) [OR]
RewriteCond %{QUERY_STRING} sb_authorname(=|%20|%3D)
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
#
########## End - Rewrite rules to block out some common exploits

C. Utilizadores e passwords

1. Usar passwords não triviais.
2. Criar uma conta de administrador com um username não trivial (ou seja, diferente de admin, administrator, root, etc). Promover esse utilizador a super-user e apagar a conta de admin. Além de ser um username conhecido, a conta de admin tem sempre o id 42 (homenagem ao Hitchhicker's Guide to The Galaxy), por isso é uma vulnerabilidade potencial (para Joomla anterior a 2.5.5).

D. Extensões

1. Não instalar extensões desnecessárias.
2. A extensão sh404SEF adiciona mais um nível de segurança e capacidades SEF (Search Engine Friendly). Esta extensão é vulnerável nas versões < 3.7.0.
3. A extensão Admin Tools Core permite aplicar num único local várias das proteções aqui referidas.
4. A extensão Akeeba Backup Core permite fazer backups completos de forma simples.
5. Há outras extensões que melhoram a segurança (mas ver regra D.1).

E. Não fornecer informação gratuita

1. Não publicitar o nome e versão do Joomla. Remover a meta tag "Generator".
2. Não publicitar o nome e versão das extensões.

F. Ações periódicas

1. Fazer backups regulares (por exemplo com o Akeeba Backup)
2. Fazer regularmente uma "inspeção visual" e eliminar ficheiros suspeitos/desnecessários.
3. Fazer testes de vulnerabilidades (com o nikto, joomscan, etc) e corrigir as vulnerabilidades detetadas.
4. Manter-se atualizado sobre as novas vulnerabilidades descobertas consultando sites especializados (http://secunia.com/search/?search=joomla, http://www.frsirt.com/english, http://www.milw0rm.com/, por exemplo)

G. Atualizar

1. Manter o Apache, PHP e MySQL atualizados.
2. Manter o Joomla atualizado. A partir da versão 1.6 há a opção de o Joomla se autoatualizar (mas é necessário verificar a disponibilidade das extensões). Não usar Joomla 1.5 ou anterior.
3. Manter as extensões atualizadas. Mesmo as extensões mais conhecidas e populares têm problemas de segurança.

Referências

http://docs.joomla.org/Security

http://docs.joomla.org/Security_Checklist/Joomla!_Setup
http://docs.joomla.org/Joomla_Administrators_Security_Checklist
http://www.marcofolio.net/joomla/7_tips_to_optimize_joomla_security.html

logwatch, fail2ban, molly-guard

Mais umas excelentes ferramentas para sistemas linux

logwatch

Instala-se com o habitual

apt-get install logwatch

E já está.
A instalação cria um script em /etc/cron.daily que se encarrega de correr o logwatch e enviar um email para o root.

Para modificar as opções pré-definidas é preciso copiar o ficheiro de configuração de exemplo para /etc/logwatch/conf:


cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/

E editar o ficheiro. No Debian a opção TmpDir estava mal configurada, deve ser mudada para /tmp.

Todas as opções podem ser sobrepostas através de parâmetros na linha de comandos.

O logwatch apenas cria o relatório com os eventos mais significativos do sistema, é responsabilidade do administrador ler o relatório e agir em conformidade.

fail2ban

apt-get install fail2ban

E já está.
A configuração básica está em /etc/fail2ban/fail2ban.conf e a configuração mais específica em /etc/fail2ban/jail.conf.

Apenas a proteção das ligações SSH está pré-definida, para outros protocolos/aplicações é preciso editar o /etc/fail2ban/jail.conf.

molly-guard

apt-get install molly-guard

E já está.
O molly-guard pede o nome da máquina quando tentamos desligar uma máquina através de SSH.

rkhunter

Um caçador de rootkits para linux e BSD

Para instalar o rkhunter pode fazer-se o download a partir do site oficial e correr o script de instalação, mas como de costume prefiro os repositórios Debian:

apt-get install rkhunter

Ou para quem prefere otimizar o código (e tiver o apt-build instalado):

apt-build install rkhunter

Para correr manualmente, convém fazer uma atualização e só depois fazer a verificação:

rkhunter --update
rkhunter --check

Também podemos correr o comando:

rkhunter --propupd

Que cria uma base de dados com as propriedades dos ficheiros executáveis presentes no sistema. Das próximas vezes que o rkhunter for executado (SEM a opção --propupd) compara os ficheiros com a informação guardada e avisa se ocorreu alguma alteração. É claro que:

1. É da responsabilidade do utilizador assegurar que todos os executáveis são legítimos quando se executa o --propupd;
2. O rkhunter apenas avisa se ocorrer alguma alteração dos ficheiros, não tem forma de saber se essa alteração é fidedigna ou não (por exemplo, um apt-get upgrade altera as propriedades dos ficheiros).

O rkhunter costuma gerar alguns avisos 'falsos positivos', mas devem ser investigados, porque às vezes um verdadeiro positivo está escondido atrás de um falso.

A instalação do rkhunter cria os scripts /etc/cron.daily/rkhunter e /etc/cron.weekly/rkhunter que se encarregam de correr o rkhunter diariamente e de o atualizar semanalmente.
Os ficheiros /etc/default/rkhunter e /etc/rkhunter.conf têm as configurações a usar, mas as que estão pré-definidas são normalmente suficientes.

Referências

http://rkhunter.sourceforge.net/

rssh no OpenPanel

O OpenPanel é um competente painel de controlo para servidores web. Permite definir acesso de shell aos utilizadores, o que é ótimo para usar com SFTP e deixar o arcaico e inseguro FTP de lado. Mas seria ainda melhor se fosse possível definir a shell rssh para os utilizadores, pois a rssh só permite mesmo a utilização do SFTP.
Segundo este fórum http://forum.openpanel.com/viewtopic.php?f=9&t=440#p918 faz-se assim:
Instalar o rssh no servidor:
apt-get install rssh
Editar /etc/rssh.conf e descomentar a linha
allowsftp
Editar /etc/shells e acrescentar a linha
/usr/bin/rssh
Editar /var/openpanel/modules/SSH.module/module.xml e acrescentar a linha

<value id="rssh" val="rssh">rssh</value>
à lista das outras shells (~ linha 44)

Reiniciar o OpenPanel com

/etc/init.d/openpanel restart

Segurança básica de um webserver

Algumas configurações simples e rápidas para tornar um servidor web um pouco mais seguro e resistente a ataques.
Assume-se que o servidor é Ubuntu 10.04 (lucid lynx) Server, mas a maior parte das definições funciona sem alterações na maior parte de outras distribuições linux.
Estas definições não asseguram a total segurança do servidor, pois o único computador seguro é o que está desligado (e mesmo assim...) mas aumentam a resistência da máquina a potenciais ataques.
Nenhuma das configurações aqui indicadas deve ser seguida 'cegamente', pois têm influência no funcionamento da máquina. Por isso cada definição é seguida de uma breve (brevíssima) descrição para ajudar na decisão de aplicar ou não essa definição. Para mais informação, o Google é teu amigo.

SSH

Editar o ficheiro de configuração em /etc/ssh/sshd_config e alterar as seguintes definições:
Port 2222
Esta definição muda o porto usado pelo SSH do 22 (padrão) para o 2222. É uma alteração simples, mas exige que nos lembremos de indicar manualmente o porto 2222 quando queremos fazer uma ligação. É também preciso abrir o porto 2222 na firewall e é conveniente fechar o 22.
Protocol 2
Indica que o SSH só aceite ligações com a versão 2 do protocolo, mais segura (é a definição padrão e não se deve alterar).
PermitRootLogin = no
Não permitir ue o utilizador root faça login diretamente.
AllowUsers = user1 user2
Só permite que o user1 e user2 façam login através de SSH. Usar com cuidado, podemos trancar-nos a nós próprios fora do servidor ou causar problemas aos utilizadores (podem por exemplo deixar de poder usar o SFTP).
Reiniciar o serviço com /etc/init.d/ssh restart para tornar as definições ativas.

MySQL

A forma mais eficaz de manter o MySQL seguro é bloquear o acesso ao porto 3306 a partir do exterior.

Bind

A forma 'tradicional' de tornar o bind mais seguro é colocá-lo a correr dentro de uma jail, que o isola do resto do sistema, mas no Ubuntu 10.04 este método NÃO é aconselhado, pois o AppArmor já fornece segurança ao bind e seriam necessárias alterações de configuração para que o bind funcionasse dentro de uma jail com o AppArmor, por isso o melhor é 'não mexer' e deixar o AppArmor tratar do bind.

Apache

Editar o /etc/apache2/apache2.conf:
ServerTokens ProductOnly
ServerSigature off
Estas duas linhas impedem que o Apache forneça informação sobre a versão, que poderia ser usada em ataques dirigidos.
TraceEnable off
O TraceEnable é um método usado para determinar se o Apache está a funcionar. Normalmente não é necessário, por isso deve ser desligado.

PHP

Editar /etc/php5/apache2/php.ini
safe_mode=off
safe_mode_gid=off
Contrariamente ao que parece ter estas duas diretivas ligadas não torna o servidor mais seguro e podem introduzir efeitos indesejados em muitas aplicações, por isso convém colocá-las em off.
display_errors=off
display_startup_errors=off
Estas duas linhas evitam que o PHP mostre mensagens de erro que poderiam revelar informação para ser usada num ataque.
register_globals=off
Evita que se usem variáveis fora do script onde foram definidas.
session.use_cookies=1
session.use_only_cookies=1
session.cookie_http_only=1
Usar cookies para armazenar as variáveis de sessão.
disable_functions=phpinfo, system, proc_open, proc_close, popen, passthru, shell_exec, dl, show_source, highlight_file, pcntl_exec
Desliga estas funções do PHP, que são potencialmete inseguras. Algumas (poucas) aplicações podem deixar de funcionar com algumas destas funções desabilitadas.
error_reporting=E_ALL & ~E_NOTICE
log_errors=on
log_errors_max_len=1024
error_log=/var/log/php5.log
Definições sobre o logs do PHP. Não são exatamente definições de segurança, mas são úteis.
magic_quotes_gpc=off
magic_quotes_runtime=off
magic_quotes_sybase=off
As magic quotes foram uma tentativa de tornar mais seguro o acesso a dados de um formulário, mas trouxeram mais problemas que benefícios. Convém desligar.
expose_php=off
Não informa sobre a versão de PHP.
file_uploads=on
Permitir que os utilizadores enviem ficheiros é um problema de segurança, mas se não permitirmos que os utilizadores enviem ficheiros o servidor será relativamente inútil...
post_max_size=32M
upload_max_filesize=32M
Estas duas definições controlam o tamanho máximo dos ficheiros que os utilizadores podem enviar. Podem ser alteradas para outros valores, mas devem ser iguais.
Reiniciar apache com /etc/init.d/apache2 restart

Pure-ftp

O servidor de FTP pure-ftp é um dos servidores ftp mais usados e mais seguro, mas o protocolo FTP em si é bastante inseguro. O melhor mesmo é NÃO usar o FTP e usar o SFTP com a shell rssh.

Prevenção de intrusões - fail2ban

O fail2ban analisa os registo de login do ssh, apache e outros e se deteta que um determinado IP tentou fazer vários logins com a password errada num curto espaço de tempo, bloqueia esse IP durante alguns minutos. É um método de proteção simples e eficaz. O maior risco que corremos é ser colocados durante alguns minutos em 'quarentena' se nos esquecermos da nossa password.
Para o instalar basta fazer:
apt-get install fail2ban
O serviço fica imediatamente ativo para SSH. Para mudar a configuração é preciso editar /etc/fail2ban/jail.conf.

Anti-rootkit -  rkhunter

Os rootkits são conjuntos de ferramentas usadas pelos hackers para ganhar privilégios de root num sistema. A presença de um rootkit indica que o sistema está comprometido e normalmente a única medida a tomar é formatar o disco. O rkhunter analisa o sistema à procura dos rootkits mais conhecidos. Atenção, não protege contra nem elimina rootkits, apenas deteta alguns rootkits.
Para instalar fazemos:
apt-get install rkhunter.
Antes de usar convém atualizar as definições com:
rkhunter --update
Para analisar o sistema fazemos:
rkhunter --checkall
Convém que ocasionalmente se corra o rkhunter, manualmente.

Auditoria - nikto

O nikto é uma ferramenta de auditoria a servidores web. Funciona melhor se for corrido a partir de outra máquina que não o servidor, para simular um 'ataque externo'.
Instala-se com:
apt-get install nikto
Para o executar fazemos:
nikto -h MAQUINA
Em que MAQUINA é o IP ou hostname da máquina a analisar.