Ajuste das Regras de Proteção

Use o Web Application Firewall para ajuste de regras de proteção.

Essas informações básicas de ajuste do WAF descrevem os fundamentos do ajuste de regras, da inspeção de logs e da configuração de exclusões de regras. O ajuste de uma política de WAF pode ser benéfico pelos seguintes motivos:

Reduz a chance de bloquear uma solicitação legítima.
Protege contra ataques a aplicativos Web padrão.
Protege contra ataques a aplicativos Web específicos.
Reduz a quantidade de varredura, o que leva a um melhor desempenho.

A tabela a seguir mostra os termos e as definições das regras de produção.

Definições de Regras de Proteção
Termo	Definição
Ajuste	O processo no qual um engenheiro ou analista modifica as regras e ações de proteção para permitir que o servidor de aplicativos seja protegido, mas permaneça funcional. Há um equilíbrio entre bloquear o servidor de aplicativos e permitir que o servidor de aplicativos execute suas tarefas. O melhor ajuste requer um conhecimento profundo do servidor de aplicativos que está sendo protegido e das regras de proteção disponíveis para proteger esse servidor de aplicativos.
Falso positivo	Um falso positivo ocorre quando uma regra de proteção é comparada com uma transação HTTP e a transação HTTP é uma transação legítima (não maliciosa).
Exclusão	Uma modificação em uma regra de proteção que permite que o valor ou o nome do valor de um cookie ou argumento HTTP seja ignorado.
Oracle Recommendation Engine (ORE)	O ORE auxilia na otimização do seu perfil de segurança do WAF, permitindo que você ative todas as regras que não são acionadas durante um período de recomendação inicial.

Visão Geral das Regras de Proteção do WAF

O WAF protege seus aplicativos Web contra ameaças. O WAF é baseado na nuvem e oferece suporte a mais de 500 conjuntos de regras e conjuntos de regras para o OWASP (Open Web Application Security Project). Use essas regras para proteger seus aplicativos Web críticos contra ataques cibernéticos mal-intencionados. Essas regras são comparadas com as solicitações de entrada para determinar se a solicitação contém um payload de ataque. Se for determinado que a solicitação é um ataque, o WAF bloqueará ou alertará você sobre essa solicitação. Esses ataques são variados e incluem ameaças, como injeção de SQL, cross-site scripting e injeção de HTML, sendo que todas podem ser detectadas e bloqueadas pelos conjuntos de regras do WAF.

A proteção do WAF é um kit de ferramentas projetado para monitoramento, registro em log e controle de acesso em tempo real de aplicativos Web. O kit de ferramentas permite que você decida como deseja aproveitar todas as regras de proteção disponíveis. Essa flexibilidade é um elemento básico das regras de proteção do WAF, pois estamos constantemente enviando atualizações para aumentar o escopo da segurança de nossas regras.

Observação

As regras de proteção do WAF adicionam ciclos de CPU extras a cada transação; portanto, recomendamos ativar somente as regras projetadas para a sua topologia de aplicativo web.

Para identificar e defender aplicativos Web contra ataques, as regras de proteção do WAF executam verificações em qualquer solicitação ao servidor Web e em todas as respostas associadas do servidor em relação ao conjunto de regras. Depois que as verificações forem bem-sucedidas, a solicitação HTTP será enviada ao site para recuperar o conteúdo relevante. Se as verificações falharem, as ações predefinidas apropriadas serão iniciadas.

Os princípios básicos das regras de proteção do WAF são os seguintes:

Passividade: Você decide quais regras são necessárias, portanto, você tem controle total.
Flexibilidade: As regras de proteção do WAF foram criadas por um especialista em segurança que forneceu mais de 250 regras e a capacidade de introduzir regras de proteção personalizadas.
Qualidade não quantidade: as regras de proteção do WAF são um módulo dedicado projetado para inspecionar o tráfego HTTP que funciona com os outros recursos do WAF (por exemplo, controle de acesso e gerenciamento de bots).
Previsibilidade: Ter controle total das regras de proteção do WAF permite controlar os resultados esperados. Você pode definir e ajustar suas regras de proteção e deixar a configuração sem supervisão, sabendo que ela continua funcionando conforme foi configurada.

Familiarização e Ajuste Inicial

Primeiro, você precisa ter algum conhecimento sobre o aplicativo web para o processo de ajuste. Caso contrário, você pode ativar regras específicas do Linux para seu servidor Windows ou origem e regras que verificam desnecessariamente seu tráfego, causando degradação do desempenho. O ORE ajuda você a fornecer um conjunto sólido e seguro de regras de proteção. O período de recomendação é uma definição configurável com um padrão de 10 dias. Recomendamos aumentar esse valor para 15 dias para obter uma grande amostra de logs para tráfego normal no aplicativo web. Aproximadamente vinte e quatro horas após a criação da política de WAF, as recomendações da regra de proteção aparecerão na guia de recomendações. As recomendações são regras escolhidas por especialistas em WAF para abranger o documento OWASP Top Ten. Essas regras recomendadas foram selecionadas porque geralmente geram o menor número de falsos positivos e ainda fornecem boa proteção.

Alterando o Período de Recomendação e Aceitando as Recomendações

Seguindo as etapas abaixo, você ativa as regras recomendadas no modo de detecção. Depois que as regras estiverem no modo de detecção, recomendamos aguardar 15 dias para alterá-las para o modo de bloqueio.

Observação

Durante o período de avaliação, todas as regras estão no modo de detecção. O modo de detecção significa que não haverá bloqueio pelas regras de proteção. Recomendamos executar o teste de aceitação do usuário e o uso normal do aplicativo para ajudar no processo de ajuste gerando logs. Revise os logs e verifique se há falsos positivos enquanto as regras estiverem no modo de detecção. Ao verificar os logs que acionam as regras de proteção, você tem uma ideia de qual tráfego causaria um bloqueio quando as regras fossem ativadas para o modo de bloqueio. Durante o período de avaliação, o aplicativo deve receber o mais próximo possível do tráfego normal ou de produção. O tráfego normal mostra quais regras são acionadas por meio de logs e os falsos positivos podem ser filtrados.

Para alterar o período de recomendações

Abra o menu de navegação e selecione Identidade e Segurança. Em Firewall de Aplicativo Web, selecione Políticas.
Clique no nome da Política de WAF para a qual você deseja configurar definições de regras. A visão geral da Política de WAF é exibida.
Clique em Regras de Proteção.
Clique na guia Definições.
Clique em Editar Definições de Regras.
Na caixa de diálogo Editar Definições de Regra, aumente o Período de Recomendações de 10 para 15 dias.
Clique em Salvar Alterações.

Para aceitar as recomendações

Abra o menu de navegação e selecione Identidade e Segurança. Em Firewall de Aplicativo Web, selecione Políticas.
Clique no nome da Política de WAF para a qual você deseja configurar definições de regras. A visão geral da Política de WAF é exibida.
Clique em Regras de Proteção.
Clique na guia Recomendações.
Clique em Aceitar Recomendações.
Clique em Alterações Não Publicadas.
Clique em Publicar Tudo.
Na caixa de diálogo Publicar Alterações, clique em Publicar Tudo.

Usando a API para Consultar Logs Específicos

A API fornece a maioria das opções para regras de filtragem. A seguir estão exemplos de como usar a CLI para filtrar logs.

Para filtrar logs por ID de regra de proteção:

oci waas waf-log list --waas-policy-id <WASS Policy OCID> --protection-rule-key <protection rule id number>

Para filtrar logs por tipo de regra (por exemplo, tipos de regra de proteção ou acesso):

oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --log-type PROTECTION_RULES
oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --log-type ACCESS

Para filtrar logs por URL de solicitação:

oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --request-url <request url>

Configurando o Log Analytics

O Log Analytics ajuda a restringir as regras de proteção que exigem atenção. Use as informações a seguir para configurar o serviço Log Analytics com o WAF. Consulte Security Insights for your web apps with OMC Log Analytics para obter mais informações.

Criando Exclusões em Regras de Proteção

A revisão de logs é uma parte crítica do processo de ajuste. Os logs mostram qual regra teve correspondência e em qual parte da transação HTTP ocorreu a correspondência. Consulte a tabela a seguir para obter amostras de logs e saber como usá-las para criar uma exclusão.

O objeto protectionRuleDetections em WafLog fornece um mapa de chaves de regra de proteção para detectar detalhes da mensagem. A tabela a seguir mostra quatro possíveis exclusões que podem ser configuradas para uma regra de proteção.


Valor do log	Valor de exclusão	Descrição
ARGS	Parâmetros de solicitação	Usado para valores de um argumento específico.
ARGS_NAMES	Nomes de parâmetros de solicitação	Usado para o nome do argumento.
REQUEST_COOKIES	Valores de cookie de solicitação	Usado para valores de um cookie específico.
REQUEST_COOKIES_NAMES	Nomes de cookie de solicitação	Usado para o nome do cookie.

Exclusões de Amostra com Logs

A seção a seguir fornece amostras de log bruto e exemplos de qual deve ser o valor de exclusão para cada regra.

ID da Regra 9411000 - ARGS
Neste exemplo, os Dados Correspondentes foram encontrados no argumento ARGS:foo. A exclusão é para o ID da regra 9411000. A exclusão a ser criada é para Parâmetros de Solicitação com o valor foo.
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS:foo: <script>xss"
},
```

ID da Regra 9411000 - ARGS_NAMES
Neste exemplo, os Dados Correspondentes foram encontrados no argumento ARGS_NAMES. A exclusão é para o ID da regra 9411000. A exclusão a ser criada é para Nomes de Parâmetros de Solicitação com o valor <script>xss.
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS_NAMES:<script>xss: <script>xss"
},
```

ID da Regra 9411100

Neste exemplo, os Dados Correspondentes foram encontrados no argumento REQUEST_COOKIES:a . A exclusão é para o ID da regra 9411100. A exclusão a ser criada é para Valores de Cookie de Solicitação com o valor a.

"protection-rule-detections": {
 "9411100": {
  "Message": "Pattern match \"(?i)([<\\xef\\xbc\\x9c]script[^>\\xef\\xbc\\x9e]*[>\\xef\\xbc\\x9e][\\\\s\\\\S]*?)\" at REQUEST_COOKIES:a.",
  "Message details": "Matched Data: <script> found within REQUEST_COOKIES:a: <script>xss"
},

Para criar exclusões

Abra o menu de navegação e selecione Identidade e Segurança. Em Firewall de Aplicativo Web, selecione Políticas.
Clique no nome da Política de WAF para a qual você deseja configurar definições de regras. A visão geral da Política de WAF é exibida.
Clique em Regras de Proteção.
Clique na guia Regras.
Localize a regra de proteção à qual deseja aplicar uma ação.
Clique no menu Ações (três pontos) e selecione Exclusões. Inclua as exclusões usando as informações obtidas na seção Exclusões de Amostra com Logs anterior.
Clique em Salvar Alterações.
Clique em Alterações Não Publicadas.
Clique em Publicar Tudo.
Na caixa de diálogo Publicar Alterações, clique em Publicar Tudo.

Mais Informações sobre Regras de Proteção

Regras de Proteção Individuais Versus Regras de Proteção Colaborativas

Para limitar falsos positivos, há regras de proteção especiais marcadas como "colaborativas". Esses grupos de regras operam de forma diferente do restante das regras de proteção, pois usam um sistema de pontuação e limite para avaliar o tráfego. As regras individuais funcionam pela correspondência de elementos da transação HTTP com a assinatura da regra. Se uma correspondência for feita, a regra executará sua ação (por exemplo, detectar ou bloquear). Cada uma das regras de proteção colaborativas usa um grupo de regras individuais. As regras de proteção colaborativas requerem várias correspondências de elementos da transação HTTP em relação a regras individuais para executar sua ação (por exemplo, detectar ou bloquear). Para que uma regra colaborativa execute sua ação, pelo menos três elementos da transação HTTP devem corresponder às regras individuais no grupo colaborativo. Depois que a exclusão for adicionada ao grupo de regras de proteção colaborativas, ela será aplicada a todas as regras nele contidas. A seguir, há uma lista dos IDs de regra de proteção colaborativa.

IDs de Regra de Proteção Colaborativa

9300000 - Grupo Colaborativo de Inclusão de Arquivo Local (LFI) - Categorias de Filtro de LFI
9320000 - Grupo Colaborativo de Execução Remota de Código (RCE) - Categorias de Filtro de RCE do UNIX
9320001 - Grupo Colaborativo de Execução Remota de Código (RCE) - Categorias de Filtro de RCE do Windows
9330000 - Grupo Colaborativo de Ataques de Injeção de PHP - Categorias de Filtros de PHP
9410000 - Grupo Colaborativo XSS (Cross-Site Scripting) - Categorias de Filtros XSS
9420000 - Grupo Colaborativo de Injeção de SQL (SQLi) - Categorias de Filtros de SQLi

IDs da Regra de Inspeção do Corpo da Solicitação

As regras a seguir exigem que a inspeção do corpo da resposta seja ativada. Lembre-se de que a inspeção do corpo da resposta atrasa a transação, já que ela verifica todas as informações contidas na transação. Ative somente as regras necessárias.

970014, 90005, 120133, 970008, 970016, 981080, 920020, 920006, 920008, 920010, 920012, 920014, 920016, 920018, 90017, 90018, 90020, 90019, 90014, 90021, 90015, 90016, 920021, 920022, 920023, 90024, 90022, 90023, 970013, 970011, 981177, 981000, 981001, 981003, 970018, 970004, 970904, 970010, 970118, 2100090, 970012, 970903, 970009, 970015, 970902, 981005, 981004, 981007, 981006, 970003, 970002, 950110, 950921, 950922, 90002, 90025, 970021, 970007

Sem Regras de Exceção

As regras a seguir criam valores de log brutos distintos de ARGS, ARGS_NAMES, REQUEST_COOKIE e REQUEST_COOKIE_VALUE. Não existem exclusões para essas regras, pois as regras se baseiam no fato de o elemento estar ou não presente. Por exemplo, se o cabeçalho content-type estiver presente, a única opção para excluir essa regra é abrir uma solicitação de serviço com o My Oracle Support para solicitar uma regra personalizada do WAF que exclua qualquer uma das regras a seguir.

960020, 960015, 960009, 950103

Essas regras são facilmente detectadas, pois os valores de log são REQUEST_URI, REQUEST_PROTOCOL e REQUEST_HEADERS.

Outras Regras de Proteção

A seguir, há uma lista de regras de proteção indesejadas, com algumas descrições e recomendações que ajudam a entender a correspondência que a regra tenta fazer. As exclusões não podem ser aplicadas a algumas dessas regras.


ID da Regra	Nome da Regra	Observações
981318	Término da String/Final da Instrução	Essa regra é importante, pois alerta para qualquer caractere de escape detectado em qualquer campo de entrada e queryString [ARGS] ou cookie. Revise as validações feitas no aplicativo e certifique-se de que ele só permita os caracteres de entrada adequados, por exemplo, letras e números. Se outro valor de entrada for necessário, uma exclusão na regra poderá ser aplicada no WAF para permitir o novo valor de entrada.
960015 960021	Cabeçalho Accept Ausente	Mesmo quando as solicitações sem aceitar cabeçalhos não significam uma violação do protocolo HTTP, as solicitações sem aceitar cabeçalhos na maioria das vezes não são solicitações genuínas. A regra pode estar alertando para solicitações de API ou aplicativos personalizados. Para evitar a varredura de solicitações de API ou aplicativos personalizados, colete uma lista dos aplicativos conhecidos que enviam tráfego e solicitam regras personalizadas. Para obter mais informações, consulte RFC 7231, seção-5.3.2.
960007 960008	Cabeçalho do Host Ausente	Conforme descrito na RFC 7230, seção-5.4 "Um servidor deve responder com um código de status 400 (Solicitação Inválida) para qualquer mensagem de solicitação HTTP/1.1 que não tenha um campo de cabeçalho de Host e para qualquer mensagem de solicitação que contenha mais de um campo de cabeçalho de Host ou um campo de cabeçalho de Host com um valor de campo inválido." Este é um método essencial de proteção e, ao mesmo tempo, garante que os servidores WAF identifiquem corretamente para qual política de WAF a solicitação se destina. Como o WAF requer um cabeçalho de host para passar o tráfego para a origem apropriada, essa regra pode causar uma alta taxa de falsos positivos.
960009 960006	Cabeçalho User-Agent Ausente	Essa regra impede que usuários não identificados acessem seu aplicativo web. User-Agent é um dos cabeçalhos de solicitação definidos em várias RFCs que fornecem informações do usuário. Mesmo quando uma solicitação contém um agente do usuário, isso não significa que ela venha de um ser humano real. Esta regra funciona como um primeiro nível de mitigação para ataques "fictícios" que se originam de possíveis bots ou aplicativos "não compatíveis com a RFC". Observação: Algumas APIs podem não incluir o cabeçalho User-Agent. Se forem esperadas solicitações de API, adicione o endereço IP da API à lista de permissões ou tenha uma regra de WAF personalizada que exclua esse tráfego da inspeção. Para obter mais informações, consulte RFC 7231, seção-5.5.3. Esta regra é um indicador de tráfego inválido ou mal-intencionado, mas é possível que aplicativos legítimos não tenham um User-Agent. Peça aos proprietários do aplicativo que usem User-Agents quando aplicável.
960011	Validação de Solicitações GET/HEAD	Conforme descrito na RFC 7231, seção-4.3.1 e seção-4.3.2, HEAD e GET são métodos HTTP destinados a recuperar informações do servidor de origem. Mesmo quando não é proibido pela RFC, enviar corpo ou payload por meio desses tipos de métodos não é uma prática comum. Isso geralmente é causado por aplicativos definidos incorretamente que não seguem as melhores práticas da RFC e podem ser usados por usuários mal-intencionados como uma técnica de bypass. Ela também é definida na RFC 2616, seção-4.3 "se o método de solicitação não incluir semântica definida para um corpo de entidade, o corpo da mensagem deverá ser ignorado ao tratar a solicitação".
960904	Cabeçalho Content-Type Ausente	Conforme definido na RFC 2616, seção-7.2.1, "Qualquer mensagem HTTP/1.1 contendo um corpo de entidade deve incluir um campo de cabeçalho Content-Type que defina o tipo de mídia desse corpo." Se essa melhor prática não for seguida, isso pode levar a ataques de sniffing do tipo MIME.
960032	Métodos HTTP permitidos	Os métodos HTTP padrão permitidos são GET, HEAD, POST e OPTIONS. OPTIONS é conhecido como um método não seguro porque é altamente usado por invasores para coletar informações do servidor de origem. Esse método também é necessário para que alguns aplicativos funcionem corretamente. Se esse método não for necessário, crie uma solicitação de serviço com o My Oracle Support para desativá-lo. Outros métodos também podem ser adicionados, conforme necessário, a uma solicitação de serviço.
960335	Quantidade máxima de argumentos	A RFC não impõe o número de argumentos que uma solicitação deve ter, mas o uso de muitos argumentos pode ser um método usado por usuários mal-intencionados que tentam transbordar um aplicativo web. Para proteger contra esses tipos de ataques, recomendamos limitar o número máximo de ARGs permitidos por solicitação. O valor padrão é 255.
960208	Tamanho máximo de um argumento	A RFC não impõe o comprimento por argumento que uma solicitação deve ter, mas o uso de um comprimento de argumento grande pode ser um método usado por usuários mal-intencionados que tentam transbordar um aplicativo web. Para proteger contra esses tipos de ataques, recomendamos limitar o tamanho máximo permitido de ARGs por solicitação. O valor padrão é 400.
960341	Tamanho total máximo do argumento	A RFC não impõe o tamanho total (combinado) do argumento que uma solicitação deve ter, mas valores de argumentos combinados grandes podem ser um método usado por usuários mal-intencionados que tentam transbordar um aplicativo web. Para proteger contra esses tipos de ataques, recomendamos limitar o valor máximo de argumento combinado permitido por solicitação. O valor padrão é 64000.
92035032	O Cabeçalho Host É Endereço IP	Essa regra geralmente não é acionada, pois o WAF precisa de um cabeçalho de host para enviar tráfego à origem.
941120	Tentativa de XSS (Cross-Site Scripting): Filtros XSS - Categoria 2	Essa regra leva muito tempo para ser processada se houver um payload grande. Por exemplo, um payload com 64.005 bytes leva cerca de 32 segundos para ser processado.

Documentação do Oracle Cloud Infrastructure