SuEXEC , SuPHP e ModSecurity

Aos que administram e utilizam servidores web com Apache, seguem alguns detalhes úteis sobre este módulos que ajudam a incrementar a segurança em todas as contas (Virtual hosts).

O que são?

SuEXEC, SuPHP e ModSecurity são módulos para o servidor web Apache que podem ser utilizados sem grandes modificações ou custos computacionais. Tais módulos já são instalados por padrão em servidores que utilizam WHM/cPanel e alguns outros painéis de controle de servidores para Web Hosting.

SuEXEC e SuPHP

Possuem similaridade em seus nomes por se tratarem de uma mesma implementação, porem de abrangência diferenciada. O SuEXEC é utilizado para qualquer aplicação externa que utilize CGI ou SSI (como Perl, por exemplo) enquanto o SuPHP é específico para scripts em PHP. Em ambos os casos a restrição é feita sobre as mesmas regras gerais:
O script a ser executado deve ter owner e grupo do usuário que possui o virtual host (que é o mesmo usuário do cPanel).
As permissões não devem ser superiores a 644 para arquivos e 755 para pastas que contenham os arquivos (exceto a pasta public_html, que deve ter no máximo permissão 750, owner igual ao usuário e grupo nobody).
Estas configurações são necessárias pois ao executar um script PHP ou CGI o usuário definido no virtual host será utilizado para executar o processo, ao invés do usuário do servidor Apache.  Isso evita que usuários tenham acesso ou até mesmo executem scripts de outros usuários hospedados no mesmo servidor.
Estas regras são gerais, outras regras se aplicam especificamente para o SuPHP:
Definições de directivas e paramentos de configuração do PHP como php_flag e php_value não podem ser utilizadas em arquivos .htaccess.
Visto que a opção acima implica na falta de configuração personalizada para o PHP, outra alternativa é disponibilizada que é a criação de um arquivo de nome php.ini contendo as configurações personalizadas do PHP, idealmente é utilizado uma cópia do php.ini principal do servidor e modificado apenas as configurações desejadas. Note que este método se diferencia muito do utilizado pelo .htaccess pois é necessário que haja uma cópia do arquivo php.ini dentro de cada diretorio que necessite das configurações do PHP, a fim de evitar o doloroso processo de cópia de arquivo dentre os sub diretórios a seguinte configuração pode ser feita no arquivo .htaccess:
[code]suPHP_ConfigPath /diretorio/que/contem/[/code]
Atente que esta linha espera que seja informado apenas o caminho do diretorio que possui o arquivo php, não deve ser informado o caminho completo para o arquivo, exemplo:
[code]suPHP_ConfigPath /home/cpaneluser (Correto)
suPHP_ConfigPath /home/cpaneluser/php.ini (Incorreto)[/code]
Neste exemplo basta que exista apenas um arquivo de nome php.ini dentro do diretório /home/cpaneluser.
Ao falhar em qualquer um dos requisitos acima o servidor Apache irá retornar erro 500, os erros mais comuns são de permissão de diretórios e arquivos que em muitos casos estão erroneamente definidos como 777 e em raros casos de owner e grupo de arquivos copiados de outras contas pelo administrador do servidor.

ModSecurity

Em contraste com os outros módulos acima, o ModSecurity é um WAF (Web Application Firewall) que aplica regras e filtros para requisições antes e depois de serem recebidas pelo Apache.
Esta técnica ajuda evitar tentativas de acesso a endereços (URI) inválidos considerados pontos de falha de scripts desatualizados ou até mesmo mal desenvolvidos, técnica muito utilizada para SQL Injenction. Os filtros utilizados são definidos por um conjunto de expressões regulares e são atualizados frequentemente pela comunidade que desenvolve e mantem este módulo, e contem filtros para falhas conhecidas de diversos CMS como WordPress, Joomla e outros bem como possui filtros mais genéricos que evitam o acesso a endereços possivelmente maliciosos como por exemplo endereços que contem o trecho “../../” que normalmente indica uma tentativa de passar um argumento a um script para acesso a arquivos em diretórios 2 ou mais níveis acima do atual.
Além dos filtros de URI, uma grande outra gama de fatores de conexão são analisados como dados de cabeçalho,
“mime type” da requisição, tipo de requisição (GET,POST ou PUT) entre outros, evitando assim tentativas de acesso utilizando métodos que possam explorar falha em scripts que aceitam dados além dos informado pela URI.
Ao interceptar requisições indesejadas (que não são aprovadas pelos filtros) é retornado um erro 500 da mesma forma que o erro 500 retornado pelo SuEXEC e SuPHP. Infelizmente não há nenhuma informação adicional retornada no erro 500 indicando exatamente qual filtro foi utilizado ou qual módulo disparou o erro, este comportamento é proposital e previne que sejam informados informações de restrição de segurança a um possível usuário mal intencionado. Informações mais específicas estão disponíveis nos logs de erro do servidor Apache e logs específicos de cada módulo.
Caso seja extritamente necessário, é possível desabilitar o ModSecurity para um domínio específico porem esta modificação só pode ser feita pelo administrador do servidor pois requer modificação no arquivo de configuração do módulo , adicionado a seguinte linha:
[code]SecRule SERVER_NAME "DOMINIO_DO_DESEJADO" chain,phase:1,nolog,allow,ctl:ruleEngine=off[/code]
Tenha em mente que este procedimento deve ser evitado ao máximo pois permite o acesso a qualquer endereços sob este domínio.
Todos os servidores compartilhados (Hospedagem e revenda) utilizam este módulos e estão sujeitos as mesmas restrições e regras.

Artigo escrito especialmente por Igor Nogueira, Unix Sys Admin da HostDime Brasil.