Ajuste de reglas de protección

Utilice el firewall de aplicaciones web para el ajuste de reglas de protección.

Esta información básica de ajuste de WAF describe los conceptos fundamentales del ajuste de reglas, la inspección de logs y la configuración de exclusiones de reglas. El ajuste de una política de WAF puede ser beneficioso por los siguientes motivos:

Reduce la posibilidad de bloquear una solicitud legítima.
Protege contra ataques de aplicaciones web estándar.
Protege contra ataques de aplicaciones web específicos.
Reduce la cantidad de exploraciones, lo que conduce a un mejor rendimiento.

En la siguiente tabla, se muestran las definiciones y los términos de las reglas de protección.

Definiciones de reglas de protección
Término	Definición
Ajuste	Proceso en el que un ingeniero o un analista modifica las reglas de protección y las acciones para permitir que el servidor de aplicaciones esté protegido pero siga siendo funcional. Existe un equilibrio entre bloquear el servidor de aplicaciones y permitir que el servidor de aplicaciones realice sus tareas. El mejor ajuste tiene un conocimiento exhaustivo del servidor de aplicaciones que se está protegiendo y de las reglas de protección disponibles para proteger dicho servidor de aplicaciones.
Falso positivo	Se produce un falso positivo cuando se establece una coincidencia de una regla de protección con una transacción HTTP y esta última es una transacción legítima (no maliciosa).
Exclusión	Modificación de una regla de protección que permite ignorar el valor o nombre de valor de una cookie o argumento HTTP.
Oracle Recommendation Engine (ORE)	ORE ayuda a optimizar su perfil de seguridad de WAF al permitirle disparar todas las reglas que no se disparan durante un periodo de recomendación inicial.

Visión general de las reglas de protección de WAF

WAF protege sus aplicaciones web frente a amenazas. WAF se basa en la nube y soporta más de 500 juegos de reglas y juegos de reglas para Open Web Application Security Project (OWASP). Utilice estas reglas para proteger sus aplicaciones web esenciales contra ciberataques maliciosos. Estas reglas se comparan con las solicitudes entrantes para determinar si la solicitud contiene una carga útil de ataque. Si determina que la solicitud es un ataque, WAF la bloquea o le avisa de esta. Estos ataques son variados e incluyen amenazas como la inyección SQL, los scripts de sitios y la inyección HTML, que pueden detectarse y bloquearse mediante los juegos de reglas de WAF.

La protección de WAF es un kit de herramientas diseñado para la supervisión de aplicaciones web en tiempo real, el registro y el control de acceso. El kit de herramientas le permite decidir cómo desea utilizar todas las reglas de protección disponibles. Esta flexibilidad es un elemento central de las reglas de protección de WAF, ya que lanzamos actualizaciones constantemente para aumentar el ámbito de seguridad de nuestras reglas.

Nota

Las reglas de protección de WAF agregan ciclos de CPU adicionales a cada transacción, por lo que recomendamos activar solo las reglas diseñadas para la topología de la aplicación web.

Para identificar los ataques y defender a las aplicaciones web de estos, las reglas de protección de WAF ejecutan comprobaciones en cualquier solicitud enviada al servidor web y en todas las respuestas asociadas del servidor con respecto al juego de reglas. Una vez que las comprobaciones se realizan correctamente, la solicitud HTTP se envía al sitio web para recuperar el contenido relevante. Si las comprobaciones fallan, se inician las acciones predefinidas adecuadas.

Los principios básicos de las reglas de protección de WAF son los siguientes:

Pasividad: el usuario decide qué reglas son necesarias, por lo que tiene el control total.
Flexibilidad: las reglas de protección de WAF fueron creadas por un experto en seguridad que proporcionó más de 250 reglas y la capacidad de introducir reglas de protección personalizadas.
Calidad antes que cantidad: las reglas de protección de WAF son un módulo dedicado diseñado para inspeccionar el tráfico HTTP que funciona con las otras funciones de WAF (por ejemplo, control de acceso y gestión de bots).
Previsibilidad: tener un control total de las reglas de protección de WAF le permite controlar los resultados esperados. Puede definir y ajustar las reglas de protección y olvidarse de la configuración, sabiendo que seguirá funcionando tal y como se configuró.

Incorporación y ajuste inicial

En primer lugar, debe conocer algunos aspectos de la aplicación web para el proceso de ajuste. De lo contrario, puede activar las reglas específicas de Linux para el servidor o el origen de Windows, de manera que las reglas exploren innecesariamente el tráfico y causen una degradación del rendimiento. ORE pone a su disposición un conjunto sólido y seguro de reglas de protección. El periodo de recomendación es un ajuste configurable con un valor por defecto de 10 días. Recomendamos aumentar este valor a 15 días para obtener una muestra amplia de logs del tráfico normal en la aplicación web. Aproximadamente veinticuatro horas después de crear la política de WAF, las recomendaciones de reglas de protección aparecerán en el separador de recomendaciones. Las recomendaciones son reglas seleccionadas por expertos de WAF para cubrir los diez principales aspectos de OWASP. Estas reglas recomendadas se han seleccionado porque, normalmente, producen el menor número de falsos positivos y siguen ofreciendo una buena protección.

Cambio del periodo de recomendación y aceptación de las recomendaciones

Siga los pasos descritos a continuación para activar las reglas recomendadas en modo de detección. Una vez que las reglas están en modo de detección, recomendamos esperar 15 días antes de cambiarlas al modo de bloqueo.

Nota

Durante el periodo de evaluación, todas las reglas están en modo de detección. El modo de detección significa que las reglas de protección no realizarán ningún bloqueo. Recomendamos realizar pruebas de aceptación del usuario y un uso normal de la aplicación para ayudar con el proceso de ajuste mediante la generación de logs. Revise los logs y compruebe si hay falsos positivos mientras las reglas están en modo de detección. Al comprobar los logs que disparan las reglas de protección, obtiene una idea de qué tráfico podría causar un bloqueo cuando las reglas se activan en modo de bloqueo. Durante el periodo de evaluación, la solicitud debe recibir un tráfico lo más normal o similar a la producción posible. El tráfico normal muestra qué reglas se disparan mediante los logs, mientras que los falsos positivos se pueden filtrar.

Para cambiar el periodo de recomendaciones

Abra el menú de navegación y seleccione Identidad y seguridad. En Firewall de aplicaciones web, seleccione Recursos de política de perímetro.
Se abre la lista Políticas. Todas las políticas de perímetro se muestran en una tabla.
Seleccione la política de perímetro para la que desea configurar los valores de regla.
Se abre la página de detalles de la política de perímetro.
Seleccione Reglas de protección.
Se abre el panel Reglas de protección.
Seleccione el separador Valores.
Seleccione Editar configuración de regla.
Se abre el panel Editar configuración de regla.
Aumente el período de recomendaciones de 10 a 15 días.
Seleccione Save Changes.

Para aceptar las recomendaciones

Abra el menú de navegación y seleccione Identidad y seguridad. En Firewall de aplicaciones web, seleccione Recursos de política de perímetro.
Se abre la lista Políticas. Todas las políticas de perímetro se muestran en una tabla.
Seleccione la política de perímetro para la que desea configurar los valores de regla.
Se abre la página de detalles de la política de perímetro.
Seleccione Reglas de protección.
Se abre el panel Reglas de protección.
Seleccione el separador Recomendaciones.
Se abre el panel Recomendaciones.
Seleccione Aceptar recomendaciones.
Seleccione Cambios no publicados.
Seleccione Publicar todo.
En el panel Publicar cambios, seleccione Publicar todo.

Uso de la API para consultar logs específicos

La API proporciona el mayor número de opciones para filtrar las reglas. A continuación, se muestran ejemplos de cómo usar la CLI para filtrar logs.

Para filtrar logs por ID de regla de protección:

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

Para filtrar logs por tipo de regla (por ejemplo, tipos de reglas de protección o acceso):

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 solicitud:

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

Configuración de Log Analytics

Log Analytics le ayuda a acotar las reglas de protección que requieren atención. Utilice la siguiente información para configurar el servicio Log Analytics con WAF. Consulte Security Insights para sus aplicaciones web con OMC Log Analytics para obtener más información.

Creación de exclusiones en reglas de protección

La revisión de logs es una parte fundamental del proceso de ajuste. Los logs muestran la regla que coincide y la parte de la transacción HTTP con la que se ha establecido la coincidencia. Consulte la siguiente tabla para ver ejemplos de logs y cómo utilizarlos para crear una exclusión.

El objeto protectionRuleDetections de WafLog proporciona un mapa de claves de reglas de protección para los detalles del mensaje de detección. En la siguiente tabla, se muestran cuatro posibles exclusiones que se pueden configurar para una regla de protección.


Valor de log	Valor de exclusión	Descripción
ARGS	Parámetros de solicitud	Se utiliza para valores de un argumento específico.
ARGS_NAMES	Solicitar nombres de parámetros	Se utiliza para el nombre del argumento.
REQUEST_COOKIES	Solicitar valores de cookies	Se utiliza para valores de una cookie específica.
REQUEST_COOKIES_NAMES	Solicitar nombres de cookies	Se utiliza para el nombre de la cookie.

Exclusiones de ejemplo con logs

En la siguiente sección, se proporcionan ejemplos de logs no procesados y ejemplos de cuál debe ser el valor de exclusión para cada regla.

ID de regla 9411000 - ARGS
En este ejemplo, se encontraron datos coincidentes dentro del argumento ARGS:foo. La exclusión es para el ID de regla 9411000. La exclusión que se va a crear es para los parámetros de solicitud con un valor foo.
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS:foo: <script>xss"
},
```

ID de regla 9411000 - ARGS_NAMES
En este ejemplo, se encontraron datos coincidentes dentro del argumento ARGS_NAMES. La exclusión es para el ID de regla 9411000. La exclusión que se va a crear es para los nombre de parámetros de solicitud con un 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 de regla 9411100

En este ejemplo, se encontraron datos coincidentes dentro del argumento REQUEST_COOKIES:a . La exclusión es para el ID de regla 9411100. La exclusión que se va a crear es para los valores de cookie de solicitud con un 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 crear exclusiones

Abra el menú de navegación y seleccione Identidad y seguridad. En Firewall de aplicaciones web, seleccione Recursos de política de perímetro.
Se abre la lista Políticas. Todas las políticas de perímetro se muestran en una tabla.
Seleccione la política de perímetro para la que desea configurar los valores de regla.
Se abre la página de detalles de la política de perímetro.
Seleccione Reglas de protección.
Se abre el panel Reglas de protección.
Seleccione el separador Reglas.
Busque la regla de protección a la que desea aplicar una acción.
Seleccione el menú Acciones (tres puntos) y seleccione Exclusiones. Incluya las exclusiones mediante la información que obtiene de la sección Exclusiones de ejemplo con logs anterior.
Seleccione Save Changes.
Seleccione Cambios no publicados.
Seleccione Publicar todo.
En el recuadro de diálogo Publicar Cambios, seleccione Publicar Todos.

Más información sobre reglas de protección

Reglas de protección individuales frente a reglas de protección colaborativas

Para limitar los falsos positivos, existen reglas de protección especiales etiquetadas como "colaborativas". Estos grupos de reglas funcionan de forma diferente al resto de las reglas de protección, ya que utilizan un sistema de puntuación y umbral para evaluar el tráfico. Las reglas individuales funcionan estableciendo coincidencias de los elementos de la transacción HTTP con la firma de la regla. Si se establece una coincidencia, la regla realiza su acción (por ejemplo, detección o bloqueo). Cada una de las reglas de protección colaborativas utiliza un grupo de reglas individuales. Las reglas de protección colaborativas requieren varias coincidencias de elementos de la transacción HTTP con reglas individuales para realizar su acción (por ejemplo, detección o bloqueo). Para que una regla colaborativa realice su acción, al menos tres elementos de la transacción HTTP deben coincidir con las reglas individuales del grupo de colaboración. Después de agregar la exclusión al grupo de reglas de protección colaborativas, se aplicará a todas las reglas que contenga. A continuación, se muestra una lista de los ID de reglas de protección colaborativas.

ID de reglas de protección colaborativas

9300000 - Local File Inclusion (LFI) Collaborative Group - LFI Filter Categories
9320000 - Remote Code Execution (RCE) Collaborative Group - UNIX RCE Filter Categories
9320001 - Remote Code Execution (RCE) Collaborative Group - Windows RCE Filter Categories
9330000 - PHP Injection Attacks Collaborative Group - PHP Filters Categories
9410000 - Cross-Site Scripting (XSS) Collaborative Group - XSS Filters Categories
9420000 - SQL Injection (SQLi) Collaborative Group - SQLi Filters Categories

ID de regla de inspección de cuerpo de solicitud

Las siguientes reglas requieren que se active la inspección del cuerpo de respuesta. Recuerde que la inspección del cuerpo de respuesta retrasa la transacción, ya que explora toda la información que contiene. Active solo las reglas necesarias.

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

Ninguna regla de excepción

Las siguientes reglas crean valores de log no procesado diferentes de ARGS, ARGS_NAMES, REQUEST_COOKIE y REQUEST_COOKIE_VALUE. No existen exclusiones para estas reglas, ya que las reglas se basan en si el elemento está presente o no. Por ejemplo, si la cabecera content-type está presente, la única opción para excluir esta regla es abrir una solicitud de servicio con My Oracle Support para solicitar una regla de WAF personalizada que excluya cualquiera de las siguientes reglas.

960020, 960015, 960009, 950103

Estas reglas se pueden detectar fácilmente, ya que los valores de log son REQUEST_URI, REQUEST_PROTOCOL y REQUEST_HEADERS.

Otras reglas de protección

A continuación, se muestra una lista de reglas de protección que causan "ruido", con algunas descripciones y recomendaciones que le ayudarán a comprender la coincidencia que intenta establecer la regla. Las exclusiones no se pueden aplicar a algunas de estas reglas.


ID de regla	Nombre de regla	Notas
981318	String Termination/Statement Ending	Esta regla es importante, ya que alerta de cualquier carácter de escape detectado en cualquier campo de entrada y queryString [ARGS] o cookie. Revise las validaciones realizadas en la aplicación y asegúrese de que solo permite los caracteres de entrada adecuados, por ejemplo, letras y números. Si se necesita otro valor de entrada, se puede aplicar una exclusión a la regla en WAF y dejarlo pasar.
960015 960021	Missing Accept Header	Incluso cuando las solicitudes sin cabeceras accept no implican una violación del protocolo HTTP, estas solicitudes no suelen ser auténticas. La regla podría estar alertando sobre las solicitudes de API o de aplicación personalizada. Para evitar la exploración de solicitudes de aplicaciones personalizadas o API, recopile una lista de las aplicaciones conocidas que envían tráfico y solicitan reglas personalizadas. Para obtener más información, consulte el RFC 7231, sección 5.3.2.
960007 960008	Missing Host Header	Como se describe en el RFC 7230, sección 5.4, un servidor debe responder con un código de estado 400 (solicitud errónea) a cualquier mensaje de solicitud HTTP/1.1 que carezca de un campo de cabecera Host y a cualquier mensaje de solicitud que contenga más de un campo de cabecera Host o un campo de cabecera Host con un valor de campo no válido. Este es un método esencial de protección y, al mismo tiempo, asegura que los servidores WAF identifiquen correctamente la política de WAF a la que está destinada la solicitud. Dado que WAF requiere que una cabecera host transfiera tráfico al origen adecuado, esta regla podría causar una alta tasa de falsos positivos.
960009 960006	Missing User-Agent Header	Esta regla evita que los usuarios no identificados accedan a su aplicación web. La cabecera de agente de usuario es una de las cabeceras de solicitud definidas en varios RFC que proporciona información del usuario. Incluso cuando una solicitud contiene un agente de usuario, no implica que provenga de un humano real. Esta regla funciona como un primer nivel de mitigación para ataques "ficticios" que se originan desde posibles bots o aplicaciones "no compatibles con RFC". Nota: Es posible que algunas API no incluyan la cabecera User-Agent. Si se esperan solicitudes de API, asegúrese de agregar la dirección IP de API a la lista de permitidos o de tener una regla de WAF personalizada que excluya este tráfico de la inspección. Para obtener más información, consulte el RFC 7231, sección 5.5.3. Esta regla es un indicador del tráfico erróneo o malicioso, pero es posible que las aplicaciones legítimas no tengan un agente de usuario. Pida a los propietarios de la aplicación que utilicen agentes de usuario cuando corresponda.
960011	GET/HEAD Requests Validation	Como se describe en las secciones 4.3.1 y 4.3.2 del RFC 7231, HEAD y GET son métodos HTTP destinados a recuperar información del servidor de origen. Incluso cuando no está prohibido por el RFC, el envío del cuerpo o carga útil a través de estos tipos de métodos no es una práctica común. Por lo general, se debe a aplicaciones mal definidas que no siguen las mejores prácticas del RFC y que pueden ser utilizadas por usuarios maliciosos como técnica de bypass. También se define en la sección 4.3 del RFC 2616 que, si el método de solicitud no incluye una semántica definida para un cuerpo de entidad, el cuerpo de mensaje se debe ignorar al manejar la solicitud.
960904	Missing Content-Type Header	Según se define en la sección 7.2.1 del RFC 2616, cualquier mensaje HTTP/1.1 que contenga un cuerpo de entidad debe incluir un campo de cabecera Content-Type que defina el tipo de medio de ese cuerpo. Si no se sigue esta mejor práctica, podría provocar ataques de interceptación de tipo MIME.
960032	Allowed HTTP methods	Los métodos HTTP permitidos por defecto son GET, HEAD, POST y OPTIONS. OPTIONS se conoce como un método no seguro porque los atacantes lo utilizan en gran medida para recopilar información del servidor de origen. Algunas aplicaciones también necesitan este método para funcionar correctamente. Si este método no es necesario, cree una solicitud de servicio con My Oracle Support para desactivarlo. También se pueden agregar otros métodos según sea necesario con una solicitud de servicio.
960335	Max amount of arguments	RFC no indica el número de argumentos que debe tener una solicitud, pero el uso de muchos argumentos podría ser un método utilizado por usuarios maliciosos que intentan desbordar una aplicación web. Para protegerse ante estos tipos de ataques, recomendamos limitar el número máximo de ARG permitidos por solicitud. El valor por defecto es 255.
960208	Max length of an argument	RFC no indica la longitud máxima por argumento que debe tener una solicitud, pero el uso de una longitud de argumento excesiva podría ser un método utilizado por usuarios maliciosos que intentan desbordar una aplicación web. Para protegerse ante estos tipos de ataques, recomendamos limitar la longitud máxima de ARG permitida por solicitud. El valor por defecto es 400.
960341	Max total argument length	RFC no indica el tamaño total (combinado) de argumento que debe tener una solicitud, pero el uso de grandes valores de argumento combinados podría ser un método utilizado por usuarios maliciosos que intentan desbordar una aplicación web. Para protegerse ante estos tipos de ataques, recomendamos limitar el valor máximo de argumento combinado permitido por solicitud. El valor por defecto es 64000.
92035032	Host Header Is IP Address	Esta regla no se suele disparar, ya que WAF necesita una cabecera host para enviar tráfico al origen.
941120	Cross-Site Scripting (XSS) Attempt: XSS Filters - Category 2	Esta regla tarda mucho tiempo en procesarse si hay una carga útil grande. Por ejemplo, una carga útil con 64 005 bytes tarda alrededor de 32 segundos en procesarse.

Documentación de Oracle Cloud Infrastructure