O arquivo de configuração do mod_security é bem tranquilo de entender, graças ao bom trabalho feito pela equipe de desenvolvimento, que deixou comentários explicando cada parte importante do arquivo.

Já vimos algumas das principais diretivas de configurações e suas funções/descrições, vamos continuar falando de alguns parâmetros dentro do modsecurity.conf.

Abaixo, temos uma tabela com as permissões necessárias para cada diretório, caso queira utilizar o padrão /opt, que é utilizado dentro do modsecurity.conf ou criar em um local de sua preferência.

 /opt/modsecurity                root    apache      rwxr-x---
 /opt/modsecurity/bin            root    apache      rwxr-x---
 /opt/modsecurity/etc            root    root        rwx------
 /opt/modsecurity/var            root    apache      rwxr-x---
 /opt/modsecurity/var/audit      apache  root        rwx------
 /opt/modsecurity/var/data       apache  root        rwx------
 /opt/modsecurity/var/log        root    root        rwx------
 /opt/modsecurity/var/tmp        apache  apache      rwxr-x---
 /opt/modsecurity/var/upload     apache  root        rwx------

Podemos centralizar nossas configurações no modsecurity.conf ou organizar em arquivos separados, de acordo com o as nossas regras.

Se a escolha for o padrão, que é somente o modsecurity.conf, podemos inserir as linhas abaixo dentro de httpd.conf:


E se a escolha for separar os arquivos por nomes sugestivos ou que lembrem as regras, o exemplo abaixo deve ser seguido.

Obs.: é importante lembrar que os arquivos são lidos na ordem de cima para baixo.


Obs.: é importante dizer que é apenas um exemplo, você deve usar o caminho onde suas regras se encontram.

Neste primeiro momento, vamos fazer uso da configuração default do mod_security, que é usando apenas um arquivo de configuração.

O arquivo modsecurity.conf é separado em oito partes:

• Rule engine initialization
• Request body handling
• Response body handling
• Filesystem configuration
• File uploads handling configuration
• Debug log configuration
• Audit log configuration
• Miscellaneous

Rule engine initialization

Nesta parte é onde encontramos o SecRuleEngine, é onde vamos dizer ao mod_security o que ele deve fazer, se vai bloquear ou apenas registrar.

Esta diretiva é sensitiva, com isso podemos dizer ao mod_security, por exemplo, para que monitore um VirtualHost específico, podendo definir também diferentes regras para cada um.

A diretiva SecRuleEngine aceita como parâmetro: On|Off|DetectionOnly

• On :: processa as regras;
• Off :: não processa as regras;
• DetectionOnly :: processa as regras, mas não executa as ações.

Request body handling

Nesta parte encontramos algumas diretivas, como SecRequestBodyAccess, SecRequestBodyLimit, SecRequestBodyNoFilesLimit, SecRequestBodyInMemoryLimit e SecRequestBodyLimitAction.

A diretiva SecRequestBodyAccess, que diz ao mod_security se ele pode fazer a checagem das requisições do corpo da página.

Quando habilitamos essa diretiva, ela faz um buffer completo do conteúdo das requisições, esse buffer é usado para que as regras do mod_security possam fazer a leitura desses dados e decidir se libera ou não. Aqui encontramos um problema, pois, o mod_security costuma usar a memória RAM, para fazer esse buffer, o que pode degradar o desempenho do servidor, principalmente se estivermos compartilhando o mod_security e o web server em um mesmo servidor.

A diretiva SecRequestBodyAccess, aceita como parâmetro: On|Off

• On :: faz o buffer das requisições;
• Off :: não faz buffer das requisições.

Podemos usar as diretivas SecRequestBodyLimit, SecRequestBodyNoFilesLimit, SecRequestBodyInMemoryLimit para configurarmos a maneira como esse buffer é feito.

A diretiva SecRequestBodyLimit, define um tamanho máximo para o buffer e aceita como parâmetro LIMITES EM BYTES.

Obs.: esta diretiva funciona somente no arquivo de configuração principal ou para um VirtualHost.

Toda vez que esse limite for excedido, o servidor usará o código HTTP 413*.

A diretiva SecRequestBodyNoFilesLimit também define um tamanho para o buffer, porém, ela exclui o tamanho dos arquivos que foram transportados nas requisições.

Esta diretiva é muito útil para a prevenção de ataques de negação de serviço (DoS), pois ela impede que um atacante possa fazer o envio de requisições com um tamanho muito grande. Caso o servidor vá aceitar upload de arquivos, esta diretiva deve ser configurada com um alto valor, de modo a não prejudicar essa funcionalidade.

Essa diretiva aceita como parâmetro: NÚMERO_EM_BYTES

Toda vez que esse limite for excedido, o servidor usara o código HTTP 413*.

A diretiva SecRequestBodyInMemoryLimit, configura o tamanho máximo que a requisição vai poder armazenar na memória RAM, mas quando uma requisição multipart/form-data ultrapassa esse limite, o mod_security cria um arquivo temporário no disco e ele passa a ser usado.

A diretiva SecRequestBodyInMemoryLimit aceita o parâmetro: LIMITES_EM_BYTES

A SecRequestBodyLimitAction, que diz ao mod_security o que fazer quando alguma requisição ultrapassa as configurações definidas na diretiva SecRequestBodyLimit. Por padrão, o mod_security rejeita as requisições maiores do que a configurada.

Esta diretiva se torna um problema quando desejamos usar o mod_security em modo DetectionOnly, porque ela rejeita ou faz um processamento parcial, que seria apenas a primeira parte da requisição.

A diretiva SecRequestBodyLimitAction, aceita como parâmetros: Reject|ProcessPartial

• Reject :: é o padrão e rejeita tudo que ultrapassar o limite definido;
• ProcessPartial :: Processa apenas a primeira parte das requisições.

Response body handling

Aqui encontramos diretivas como SecResponseBodyAccess, SecResponseBodyMimeType, SecResponseBodyLimit e SecResponseBodyLimitAction. Elas são muito similares as que vimos acima.

A diretiva SecResponseBodyAccess, permite ao mod_security ter acesso às respostas das requisições feitas. Esta diretiva ajuda a termos controle sobre os dados que saem nessas requisições, evitando assim, que algum dado sensível saia do nosso ambiente.

Obs.: é importante dizer que habilitando esta diretiva, estamos aumentando muito o consumo de memória de nosso servidor, então, é bom avaliarmos bem a real necessidade de a usarmos.

Esta diretiva aceita como parâmetro: On|Off

• On :: faz buffer das respostas;
• Off :: não faz buffer das respostas.

A diretiva SecResponseBodyMimeType, nos permite escolher o tipo de arquivo MIME*, que vão inspecionar.

**Podemos passar mais de um tipo.

A diretiva aceita como parâmetro: MIMETYPE MIMETYPE

A diretiva SecResponseBodyLimit, permite configurar o tamanho máximo do buffer de resposta. Qualquer coisa acima desse limite (LIMITES EM BYTES), obterá como resposta o código HTTP 500*.

Obs.: essa configuração só tem impacto nos arquivos MIME que forem citados na diretiva anterior.

A diretiva SecResponseBodyLimitAction, nos permite configurar uma ação, caso tenhamos vários web sites atrás do mod_security e algum desses sites venha a ter um tamanho maior do que o configurado na diretiva anterior. Essa diretiva nos permite configurar o mod_security para ler apenas a primeira parte da resposta, a parte que pode se encaixar no limite que configuramos na diretiva anterior.

A diretiva aceita como parâmetro: Reject|ProcessPartial

• Reject :: rejeita tudo que ultrapassar o valor;
• ProcessPartial :: processa somente a primeira parte.

Filesystem configuration

Neste bloco temos as diretivas SecTmpDir e SecDataDir, que é onde vamos definir os diretórios para arquivos temporários e arquivos persistentes.

A diretiva SecTmpDir, é o local onde o mod_security vai guardar os arquivos temporários. Por padrão, a pasta /tmp vem configurada, caso queira trocar a pasta, é importante dizer que a pasta a ser definida precisa ser configurada com permissão de escrita para o usuário apache. Este também é o local que o mod_security vai utilizar para o buffer, caso a memória se esgote.

A diretiva aceita como parâmetro: CAMINHO_DO_DIRETORIO

A diretiva SecDataDir, é o local onde o mod_security vai registrar os dados persistentes, como IPs de acesso ou sessões.

A diretiva aceita como parâmetro: CAMINHO_DO_DIRETORIO

File uploads handling configuration

Neste bloco, vamos encontrar as diretivas SecUploadDir, SecUploadKeepFiles e SecUploadFileMode. Onde é feita a configuração do local, onde o mod_security vai guardar os arquivos que são interceptados durante o upload.

A diretiva SecUploadDir, vai definir o local onde o mod_security vai armazenar os arquivos interceptados. É interessante que esse diretório possua permissão de acesso somente para o mod_security.

A diretiva aceita como parâmetro: CAMINHO_DO_DIRETORIO

A diretiva SecUploadKeepFiles, nos permite definir se vamos manter o arquivo que foi processado ou não. Para que essa diretiva funcione, precisamos que a diretiva SecUploadDir esteja configurada.

A diretiva aceita como parâmetro: On|Off|RelevantOnly

• On :: mantém todos os arquivos;
• Off :: não mantém os arquivos;
• RelevantOnly :: irá manter apenas os arquivos considerados relevantes.

A diretiva SecUploadFileMode, nos permite trocar as permissões dos arquivos que são enviados ao nosso servidor, pois estes arquivos são possuem a permissão octal 0600, como padrão. Caso queira que um terceiro tenha acesso a estes arquivos, como por exemplo um antivírus, vamos precisar alterar essa diretiva.

A diretiva aceita como parâmetro: MODO_OCTAL

Debug log configuration

Nesse bloco, temos as configurações de Debug Log, que são muito uteis na hora de resolver ou entender algum problema. Aqui, temos as diretivas SecDebugLog e SecDebugLogLevel.

A diretiva SecDebugLog, é onde vamos definir o caminho que vamos armazenar esses log de depuração.

A diretiva aceita como parâmetro: CAMINHO_DO_DIRETORIO

A diretiva SecDebugLogLevel, é o local onde vamos configurar o nível de informação que vamos ter em nosso log de debug. Para um servidor em produção, a recomendação é deixarmos em 3, para evitar a queda de performance e aumento do consumo de disco.

A diretiva aceita como parâmetro: 0|1|2|3|4|5|6|7|8|9

• 0 :: não registra o log;
• 1 :: apenas os erros (somente das requisições);
• 2 :: atenção;
• 3 :: informação;
• do 1 ao 3, o mod_security gera apenas uma cópia dos logs de erro do apache;
• 4 :: detalhes das transações;
• 5 :: como o 4, porém com informações de cada parte das transações;
• 9 :: vai gerar log de tudo e de forma bem detalhada.

É interessante usarmos o 9 quando nosso servidor está em modo de homologação, para que possamos fazer alguns ajustes finos.

Audit log configuration

Nesta parte, vamos encontrar as diretivas que são responsáveis por fazerem a análise dos nossos logs. O mod_security usa o termo audit logging, para se referir aos logs de transações que são armazenados em nosso servidor. Esse são os logs que são marcados por alguma regra, ou por uma requisição que tenha como resposta um código HTTP 500.

Aqui vamos ter as seguintes diretivas, SecAuditEngine, SecAuditLogRelevantStatus, SecAuditLogParts, SecAuditLogType, SecAuditLog e SecAuditLogStorageDir.

A diretiva SecAuditEngine, é a responsável pelo audit engine, que registra as transações que são completadas. O mod_security não consegue registrar todas as transações de erros, por exemplo os erros 400 e 404, que usam caminhos diferentes e que o mod_security não suporta.

A diretiva aceita como parâmetros: On | Off | RelevantOnly

• On :: log de todas as transações;
• Off :: não vai registrar nada;
• RelevantOnly :: vai registrar apenas as transações que forem registradas com warning, erro ou com o código HTTP considerado relevante, que podemos configurar na diretiva SecAuditLogRelevantStatus.

SecAuditEngine RelevantOnly

A diretiva SecAuditLogRelevantStatus, é onde podemos configurar os código HTTP de resposta que considerarmos relevante, para um proposito de auditoria. Esta diretiva só é usada se a diretiva anterior, SecAuditEngine, for configurada como RelevantOnly.

A diretiva aceita como parâmetro: REGEX
Exemplo: SecAuditLogRelevantStatus "^(?:5|4(?!04))"

A diretiva SecAuditLogParts, é a diretiva responsável por definir qual parte da transação será registrada para a auditoria. Cada parte da transação, tem uma letra atribuída, que são: A B C D E F G H I J K Z.

A diretiva aceita como parâmetro:

Obs.: a tradução desses parâmetros, ficou meio estranha, por isso deixei em inglês mesmo e teremos um ou dois artigos, que serão específicos sobre logging e neles veremos isso com mais detalhes.

Letras citadas:

• A :: audit log header (mandatário);
• B :: request headers;
• C :: request body (present only if the request body exists and ModSecurity is configured to intercept it);
• D :: reserved for intermediary response headers; not implemented yet;
• E :: intermediary response body (present only if ModSecurity is configured to intercept response bodies, and if the audit log engine is configured to record it);
• F :: final response headers (excluding the Date and Server headers, which are always added by Apache in the late stage of content delivery);
• G :: reserved for the actual response body; not implemented yet;
• H :: audit log trailer;
• I :: this part is a replacement for part C. It will log the same data as C in all cases except when multipart/form-data encoding in used. In this case, it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not about the files. This is handy if you don't want to have (often large) files stored in your audit logs;
• J :: this part contains information about the files uploaded using multipart/form-data encoding;
• K :: this part contains a full list of every rule that matched (one per line) in the order they were matched. The rules are fully qualified and will thus show inherited actions and default operators;
• Z :: final boundary, signifies the end of the entry (mandatário).

Exemplo: SecAuditLogParts ABCFHZ

A diretiva SecAuditLogType, nesta diretiva definimos o tipo de mecanismo audit logging, que será usado.

A diretiva aceita como parâmetros: Serial|Concurrent

• Serial :: os registros são feitos em um único arquivo, o que foi especificado em SecAuditLog. Para um uso casual, esse é o mais indicado, porém, pode deixar o servidor um pouco lento, já que pode escrever no arquivo a qualquer momento;
• Concurrent :: é feito o registro de um arquivo para cada transação. É indicado para casos onde se tem várias transações ao mesmo tempo, por que essas transações vão sendo gravadas em paralelo.

SecAuditLogType Serial

A diretiva SecAuditLog, esta diretiva define o caminho onde o arquivo de audit logging sera armazenado.

A diretiva aceita como parâmetro: CAMINHO_DO_DIRETORIO
Ex.: /var/log/mod_security/audit.log

A diretiva SecAuditLogStorageDir, esta diretiva será usada somente se na configuração do SecAuditLogType, for configurado como Concurrent, pois aqui vamos definir o caminho para o armazenamento das entradas geradas por essa configuração.

A diretiva aceita como parâmetro: CAMINHO_DO_DIRETORIO
Exemplo: /var/log/mod_security/audit/

Miscellaneous

Esta parte do arquivo de configuração, dificilmente terá impacto sobre as configurações acima, mas vamos abordá-las, já que fazem parte das configurações.

Aqui vamos encontrar as diretivas SecArgumentSeparator, SecCookieFormat, SecUnicodeMapFile e SecStatusEngine, mas vamos falar somente de duas.

A diretiva SecCookieFormat, esta diretiva define o formato de cookie que será usado em um contexto de configuração.

A diretiva aceita como parâmetros: 0|1

• 0 (Netscape) :: versão padrão e mais usada. É o valor padrão;
• 1 :: versão 1 dos cookies.

A diretiva SecStatusEngine, esta diretiva, se habilitada, vai permitir que o mod_security envie algumas informações para a equipe de desenvolvimento da SpiderLabs.

As informações enviadas são as versões dos seguintes itens:

• Mod_Sec;
• Web Server;
• APR;
• LibXML2;
• Lua;
• PCRE.

Finalizando

Para maiores informações a respeito deste código, recomendo a leitura da RFC 2616:

• RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1

Recomendo a leitura do livro HTTP: The Definitive Guide:

• HTTP: The Definitive Guide (Definitive Guides): David Gourley, Brian Totty, Marjorie Sayer, Anshu Aggarwal, Sailu Reddy: 9781565925090: Amazon.com: Books

Neste link, podemos encontrar diversos tipos MIMETYPE:

• Media Types