Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Configuración Avanzada de CloudFlare

martes, 18 de agosto de 2020 | Publicado por el-brujo | Editar entrada

Ya hemos hablado anteriormente en el blog del funcionamiento y las opciones de configuración de WAF de CloudFlare, como servicio de CDN, para, por ejemplo, detener ataques DDoS en la capa 7 (layer 7) cuando se realizan las peticiones del navegador a nuestro servidor. Pero aunque la idea y el funcionamiento sigue siendo la misma, CloudFlare ha añadido muchas novedades, características y nuevas opciones avanzadas de configuración en su servicio. Veamos ahora las novedades y todas sus posibilidades.




No vamos a explicar como configurar las DNS de CloudFlare para tu dominio. ni los pasos iniciales con CloudFlare. La documentación de CloudFlare es abundante.

CloudFlare sigue teniendo 3 planes de acceso:
  • Free (Gratuito)
  • Pro 20$ mes, incluye (WAF), Cache Analytics, errores personalizados
  • Business (200$ mensuales)
  • Enterprise

CloudFlare es un Proxy Inverso

¿Qué es un proxy inverso? Un proxy inverso es un servidor que se encuentra frente a los servidores web y reenvía las solicitudes del navegador web del cliente  al servidores web de origen.




Un proxy inverso es un servidor que se encuentra frente a uno o más servidores web, interceptando las solicitudes de los clientes.  Con un proxy inverso, cuando los clientes envían solicitudes al servidor de origen de un sitio web, esas solicitudes son interceptadas en el borde de la red por el servidor proxy inverso. El servidor proxy inverso enviará solicitudes y recibirá respuestas del servidor de origen.

CloudFlare AnyCast


Las solicitudes a un sitio web protegido por Cloudflare se dirigen a los datos más cercanos. Esto se puede hacer de varias formas, a menudo diferentes de una CDN a otra, pero la forma Cloudflare eligió (y que probablemente sea la más eficiente) es la tecnología Anycast: la mayoría de las IP externas de Cloudflare se envían por cualquier medio, lo que significa que cualquier solicitud a dichas direcciones llegará al centro de datos más cercano a la fuente de la solicitud de acuerdo con el enrutamiento BGP. En otras palabras, es el proceso de decisión de BGP el que decidirá qué centro de datos será afectado, según en factores como los parámetros de preferencia local, la ruta AS más corta y, dentro de un único AS, la ruta más corta Lo podemos llamar a esto "WAN Anycast", porque Cloudflare también usa Anycast localmente en cada centro de datos enpara seleccionar el servidor más apropiado, también conocido como "LAN Anycast"-

Las redes Anycast proporcionan protección DDoS porque el tráfico puede extenderse por toda la red. Para decirlo de otra manera, una solicitud a una dirección IP puede ser respondida por muchos servidores, por lo que miles de solicitudes que abrumarían a un servidor se dividen entre muchos servidores.

Recordemos que CloudFlare sólo sirve y hace de escudo, filtrar y aceptar peticiones web, no cubre o funciona con otros servicios, sólo páginas web. CloudFlare no sirve para servidores de juegos, TeamSpeak, u otro servicios aunque sean basados en TCP. Sólo peticiones web. Capa (Layer 7)


Las opciones de "I'm under attack" (UAM, Under Attack Mode) (muestran JS de 5 segundos al visitante) no son efectivas. Ya se ha demostrado que existen diferentes métodos de bypass UAM que funcionan correctamente.

Es decir, aunque actives la protección recomendada de "Estoy bajo ataque" puede que sigas sin poder detener la protección (JS Challenge es muy fácil de saltar hoy en día). "Under Attack Mode" no es muy efectivo en ataques DDoS más avanzados.

Los parámetros __cf_chl_jschl_tk__ y __cf_chl_captcha_tk__ se agregan a la URL después de que un visitante supera con éxito un desafío o Captcha, respectivamente. Estos parámetros aseguran que los visitantes desafiados a través de JavaScript o Captcha no necesiten rellenar y volver a enviar los datos del formulario (HTTP POST) después de superar un desafío.


Por ejemplo en los dos últimos días hemos recibido layer 3/4 15TB de tráfico entrante usando servidores abiertos DNS (recursivos) (UDP 53) y layer 7 33 millones de peticiones (hits). Aunque los atacantes, como es normal, tienen diferentes métodos de ataque. Pero siguen siendo ataques ya muy conocidos y bien documentados.


Los ataques más habituales son:

  • Layer 7 --> usando open proxys (proxys abiertos) realizan peticiones masivas de ip's reales de proxys utilizando User-Agent válidos y aleatorios. No es una botnet, ni ordenadores infectados, ni nada similar. son proxys (squid o similares). El atacante tiene un listado enorme de servidores proxy ip:puerto (socks 4 o socks 5) que utiliza para hacer peticiones legítimas. El problema es que manda muchas y desde diferentes (muchas) ip's. Veremos la regla apropiada para mitigar éste problema con el firewall. Éste tipo de ataque se llama Challenge Collapsar (CC)
  • Layer 3/4 --> utilizando DrDDoS lanza ataques de tráfico spofeado amplificado (DrDDoS) con tu dirección IP para que el tráfico generado de respuesta lo recibas tu.

Es muy importante que los atacantes o atacante no conozcan nuestra dirección IP detrás de CloudFlare para que no puedan realizar ataques layer 4




Para evitar Leak (fuga) de la IP real detrás (behind) de CloudFlare

  • Registros DNS (registros SPF), evitar que cualquier subdominio apunte a la IP real del servidor. Típicamente ftp.elhacker.net, ns.elhacker.net, etc. Recuerda que el servidor DNS del hosting original puede seguir existiendo y revelar con un CNAME la IP real. Gracias al CNAME Flattening podemos desactivar el servidor DNS original.
  • Servidor de correo (correos internos mandados desde la propio servidor). Utilizar otro servidor o una cuenta de webmail (gmail) (smtp:ssl) por ejemplo.
  • Errores por pantalla del servidor web muestren información real de la IP
Algunos de los métodos para descubrir la IP real del servidor de origen detrás de CloudFlare son:

Métodos para descubrir la IP Real CloudFlare


Nota: Desde el año 2014 elhacker.net utiliza los servicios de CloudFlare

Recordar también la opción de utilizar la API de CloudFlare, muy útil para automatizar acciones y denegar todo el tráfico https con iptables, firewalld, pfSense o el firewall que sea, que no sea de las ip's de CloudFlare. De esta manera no aceptaremos ninguna petición http o https que no sea de CloudFlare.


Si tenemos todos los dominios bajo CloudFlare podemos añadir reglas iptables o FirewallD para bloquear todo el tráfico http y https que no sea de CloudFlare.

 Fichero

/etc/sysconfig/iptables

Añadir

#denegar grafico udp sobre puerto 80
-A INPUT -p udp -m udp --dport http -j DROP
# cloudflare ips range
# http cloudflare puerto 80
-A INPUT -p tcp -s 173.245.48.0/20 --dport http -j ACCEPT
-A INPUT -p tcp -s 103.21.244.0/22 --dport http -j ACCEPT
-A INPUT -p tcp -s 103.22.200.0/22 --dport http -j ACCEPT
-A INPUT -p tcp -s 103.31.4.0/22 --dport http -j ACCEPT
-A INPUT -p tcp -s 141.101.64.0/18 --dport http -j ACCEPT
-A INPUT -p tcp -s 108.162.192.0/18 --dport http -j ACCEPT
-A INPUT -p tcp -s 190.93.240.0/20 --dport http -j ACCEPT
-A INPUT -p tcp -s 188.114.96.0/20 --dport http -j ACCEPT
-A INPUT -p tcp -s 197.234.240.0/22 --dport http -j ACCEPT
-A INPUT -p tcp -s 198.41.128.0/17 --dport http -j ACCEPT
-A INPUT -p tcp -s 162.158.0.0/15 --dport http -j ACCEPT
-A INPUT -p tcp -s 104.16.0.0/12 --dport http -j ACCEPT
-A INPUT -p tcp -s 172.64.0.0/13 --dport http -j ACCEPT
-A INPUT -p tcp -s 131.0.72.0/22 --dport http -j ACCEPT
# https cloudlfare 443
-A INPUT -p tcp -s 173.245.48.0/20 --dport https -j ACCEPT
-A INPUT -p tcp -s 103.21.244.0/22 --dport https -j ACCEPT
-A INPUT -p tcp -s 103.22.200.0/22 --dport https -j ACCEPT
-A INPUT -p tcp -s 103.31.4.0/22 --dport https -j ACCEPT
-A INPUT -p tcp -s 141.101.64.0/18 --dport https -j ACCEPT
-A INPUT -p tcp -s 108.162.192.0/18 --dport https -j ACCEPT
-A INPUT -p tcp -s 190.93.240.0/20 --dport https -j ACCEPT
-A INPUT -p tcp -s 188.114.96.0/20 --dport https -j ACCEPT
-A INPUT -p tcp -s 197.234.240.0/22 --dport https -j ACCEPT
-A INPUT -p tcp -s 198.41.128.0/17 --dport https -j ACCEPT
-A INPUT -p tcp -s 162.158.0.0/15 --dport https -j ACCEPT
-A INPUT -p tcp -s 104.16.0.0/12 --dport https -j ACCEPT
-A INPUT -p tcp -s 172.64.0.0/13 --dport https -j ACCEPT
-A INPUT -p tcp -s 131.0.72.0/22 --dport https -j ACCEPT
# Block HTTPS from other sources 
-A INPUT -p tcp --dport http -j DROP
-A INPUT -p tcp --dport https -j DROP
Mejor usar la configuración multi puerto:

Para rangos de direcciones IPv4:

 iptables -I INPUT -p tcp -m multiport --dports http,https -s $ip -j ACCEPT

Para rangos de direcciones IPv6:

 ip6tables -I INPUT -p tcp -m multiport --dports http,https -s $ip -j ACCEPT


O usar un script automático:

for i in `curl https://www.cloudflare.com/ips-v4`; do iptables -I INPUT -p tcp -s $i --dport http -j ACCEPT; done

for i in `curl https://www.cloudflare.com/ips-v4`; do iptables -I INPUT -p tcp -s $i --dport https -j ACCEPT; done 

FirewallD

for i in $(curl "https://www.cloudflare.com/ips-v4"); do sudo firewall-cmd --permanent --zone=public --add-rich-rule 'rule family="ipv4" source address="'$i'" port port=80 protocol=tcp accept'; done
for i in $(curl "https://www.cloudflare.com/ips-v4"); do sudo firewall-cmd --permanent --zone=public --add-rich-rule 'rule family="ipv4" source address="'$i'" port port=443 protocol=tcp accept'; done
firewall-cmd --permanent --zone=public --add-rich-rule 'rule family="ipv4" source address="myip" port port=22 protocol=tcp accept'
firewall-cmd --permanent --change-zone=eth0 --zone=public
sudo firewall-cmd --reload
Sólo faltaría añadir Ipv6 si lo usamos:

# for i in $(curl "https://www.cloudflare.com/ips-v6"); do echo "firewall-cmd --zone=cloudflare --add-source=$i --permanent" >> ./cloudflare_init.sh; done

Si es el puerto 80 o el 443, dependerá de la configuración SSL/TLS de CloudFlare

  • Si usamos "Off" --> puerto 80 (todo en http) (no recomendado)
  • Si usamos opción "Flexible" --> https visitantes, pero http puerto 80 servidor de origen, permite además http2
  • Si usamos la opción "Full" --> puerto 443 certificado https (puede estar  caducado o autofirmado)
  • Si usamos la opción "Full (Stritct)" --> puerto 443 y certificado válido servidor origen
Nota: si usamos "Full" pero justamente queremos que un subdominio utilice puerto 80, podemos elegir "Flexible", ya que es posible utilizando una regla de página (Page rule). Elegimos subdomnio.elhacker.net/* y elegimos SSL: Flexible en vez de Full


En caso de tener algunos dominios que no usen CloudFlare podemos utilizar el módulo de CloudFlare para denegar las peticiones al servidor web de ip's que no sean del  Proxy de CloudFlare.

mod_cloudflare vs mod_remoteip

Hay dos módulos para restaurar las ip's de los visitantes originales y que no aparezcan las ip's de CloudFlare

Para obtener la ip real del visitante o el país:

$country_code = $_SERVER["HTTP_CF_IPCOUNTRY"];
$ip  = $_SERVER['CF-CONNECTING-IP'];

<?php if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP']; 


Cloudflare ya no actualizará ni proveerá asistencia técnica para mod_cloudflare a partir de las versiones Debian 9 y Ubuntu 18.04 LTS del sistema operativo Linux. Ahora brindamos asistencia a mod_remoteip para clientes que usan los servidores web Apache. Los clientes que estén interesados ​​en compilar el paquete mod_cloudflare pueden descargar el código base de GitHub.

Con el mod_cloudflare se puede usar una directiva en Apache para denegar acceso a todas las ip's menos la de CloudFlare

DenyAllButCloudFlare

Ejemplo:


<IfModule cloudflare_module>

CloudFlareRemoteIPHeader X-Forwarded-For

CloudFlareRemoteIPTrustedProxy [insert your load balancer’s IP address]

DenyAllButCloudFlare

</IfModule>


En mod_remoteip esta directiva no existe (fichero /etc/apache2/conf-available/remoteip.conf)

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22
RemoteIPTrustedProxy 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 190.93.240.0/20
RemoteIPTrustedProxy 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22
RemoteIPTrustedProxy 198.41.128.0/17
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/12
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 131.0.72.0/22
RemoteIPTrustedProxy 2400:cb00::/32
RemoteIPTrustedProxy 2606:4700::/32
RemoteIPTrustedProxy 2803:f800::/32
RemoteIPTrustedProxy 2405:b500::/32
RemoteIPTrustedProxy 2405:8100::/32
RemoteIPTrustedProxy 2a06:98c0::/29
RemoteIPTrustedProxy 2c0f:f248::/32

Añadir en el vhost que queramos recuperar las ip's reales: 

LogFormat Apache

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

o bien:

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

La variable  %h es la IP remota del visitante.


Cambiar si usamos CloudFlare por:

LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combinedcloudflare

Solo necesitamos cambiar esto %h por % a, que es la IP del cliente definida por el módulo mod_remoteip. 

Asegúrate de que la IP de Cloudlfare Proxy no aparezca en el registro de acceso, sino tu propia IP de cliente.

Si Apache no detecta CF-Connecting-IP en el encabezado HTTP (por ejemplo, si Cloudflare está apagado o no configurado para un host virtual (vhost) en particular), el registro recurrirá a la dirección remota (REMOTE_ADDR).

Si Apache detecta CF-Connecting-IP pero proviene de una IP no definida en RemoteIPTrustedProxy (por ejemplo, alguien que intenta falsificar los encabezados), el registro recurrirá a la dirección remota (REMOTE_ADDR).

Analytics - Analíticas



En el ejemplo podemos ver 33 millones de peticiones en los dos últimos días:


7 millones de peticiones en una hora (5 a 6 AM) y 12 millones de peticiones las últimas 24 horas.

Lamentablemente la información de las analíticas de CloudFlare es escasa, no incluye las direcciones IP que más peticiones hacen, ni el ASN, sólo País, HTTP Version, TLS Version, etc

Nivel de seguridad (Security Level)

cf.threat_score  (Ip Reputation)

Security Level is based on:
  • High - for scores greater than 0 
  • Medium - for scores greater than 14 
  • Low - for scores greater than 24 
  • Essentially off - for scores greater than 49

La reputación de IP se calcula en base al proyecto Project Honeypot,  información de IP pública externa, así como inteligencia de amenazas internas del WAF y DDoS de CloudFlare.

Security Level Threat Scores Description
Essentially off greater than 49 Only challenges IP addresses with the worst reputation.
Low greater than 24 Challenges only the most threatening visitors.
Medium greater than 14 Challenges both moderate threat visitors and the most threatening visitors.
High greater than 0 Challenges all visitors that exhibit threatening behavior within the last 14 days.
I’m Under Attack! N/A Only for use if your website is currently under a DDoS attack.

Cloudflare establece el Nivel de seguridad en Medio (Medium) de forma predeterminada.

Solo deberías usar  IUAM (I'm Under Attack!) modo cuando un sitio web está bajo un ataque DDoS. ya que el modo puede afectar algunas acciones en su dominio, como el tráfico de su API o de robots no incluidos en la whitelist. Se mostrará JS 5 segundos de espera.

Rate Limit (429) Too many requests

Rate-limiting-rules (Reglas de limitación de tasa

Protege tu sitio web y API del tráfico malicioso con reglas de limitación de tasa

Configura criterios y acciones de mitigación para mejorar la seguridad.

Por ejemplo banear una IP durante x tiempo (segundos o minutos) si hace más de x peticiones en x segundos si cumple x condiciones.

When rate exceeds > Requests 

  • "requests_to_origin": true
  1. (Opcional) En Estado de la caché (Cache status), desactive Aplicar también limitación de velocidad a los activos almacenados en caché para tener en cuenta sólo las solicitudes que llegan al origen a la hora de determinar la velocidad.

Firewall



Por eso la mejor manera sigue siendo utilizar una regla del Firewall de CloudFlare. Con la regla adecuada evitaremos que el atacante consiga llegar al destino de nuestro servidor y su petición se encontrará block (bloqueada) por CloudFlare (sin pasar o llegar a nuestro servidor).

CloudFlare es capaz de bloquear millones de peticiones por segundo, cosa que seguramente nuestro servidor web no es capaz de hacer sin saturarse.

Recordemos que en el gráfico (OverView) del Firewall, sólo veremos los eventos que cumplan alguna regla del Firewall, no aparece todo el tráfico que recibe nuestro sitio web. Para ello debemos ir a "Analytics" o bien la nueva opción de "Caching".

El problema es que en Analytics no aparecen la ip's de las peticiones, son analitcas muy genericas que no dan mucha información. Ahora el panel de Caching ofrece algo más de información.

El plan gratuito sólo puedes añadir 5 reglas, mientras que el primer plan de pago (pro) puedes usar hasta 20 reglas activas.

Las opciones que tenemos son muchas (con todos sus condicionales que son aún más)

Una regla del cortafuegos podemos filtrar por:

  • AS Num --> Número de ASN (Cada ISP, Hosting tiene su propio ASN)
  • Cookie  --> (nombre de la cookie, valor, etc)
  • Country --> (País con código 2 letras) T1 es Tor
  • Continent --> Continente     AF – Africa, AN – Antarctica, AS – Asia, EU – Europe, NA – North America, OC – Oceania, SA – South America, T1 – Tor network
  • Hostname --> (si tenemos varios subdomnios pues un host sería elhacker.net ,otro foro.elhacker.net, blog.elhacker.net)
  • IP Address --> (Dirección IP real visitante que realiza la petición)
  • Referer --> el "referer" de la página de entrada
  • Request Method --> GET (el más usado), POST (formularios), PURGE, PUT, HEAD. OPTIONS, DELETE y PATCH
  • SSL/HTTPS --> on or off (si usa https o no)
  • URI Full --> /seccion/fichero.php?variable=1
  • URI --> podemos usar contains (contiene) o equal (es igual) /seccion/fichero.php
  • URI Path --> /seccion/
  • URI Query String --> 
  • HTTP Version --> HTTP 1.0 (casi no usado), HTTP 1.1 (muy usado, cuidado bots buenos o malos, o proxys usan 1.1), HTTP 1.2 (no muy usado), HTTP 2 (el más habitual en navegadores modernos), HTTP 3 y SPDY/3.1
  • User-Agent --> el string Navegador (incluye sistema operativo) , versión completa o parcial que incluya letras o excluya
  • X-Forwarded  --> (si es un proxy) podemos poner contains . y cumplirá siempre la condición sea ipv4 o ipv6)
  • Client Certificate verified --> (cf.tls_client_auth.cert_verified)
  • Known Bots --> (cf.client.bot) cuando es true es un bot "bueno" (bing, google, baidu, yandex, apple, etc)
  • Threat Score --> CloudFlare asigna una puntuación a una IP según su "comportamiento" badscore (cf.threat_score)


Las reglas del firewall permiten si se cumple las condiciones de la expresión regular 5 acciones:


  • Log (sólo versión de pago Enterprise)
  • Allow (permitir)
  • Block (Bloquear) (Muestra un http status code 403 Forbidden)
  • Challenge (Captcha) (mostrar captcha, antes reCAPTCHA ahora hCaptcha)
  • Js Challenge (Mostrar JS de espera de unos 5 segundos y redireccionar)
  • Bypass (deja pasar pero logea)

Listados de IP'S

Podemos utilizar un listado de ip's subido previamente con formato CSV para una regla del firewall.

Por ejemplo podemos extraer las ip's con más peticiones después de un ataque del fichero access.log de Apache o Nginx

Para crear el listado de ip's (hasta 10 listas con 10 mil ip's cada una) tenemos que ir a la página principal (ningún dominio) e ir a Configuraciones, Listas (Lists)

  • Nombre de la lista
  • Descripción (opcional)
  • Valores -> Dirección IP (ipv4 o ipv6) También acepta rangos no más grandes de /64

CloudFlare tiene ya un lista creada (managed list) de Open Proxys, llamada cf.open_proxies pero es sólo para Plan Enterprise

Cloudflare Open Proxies
IP addresses of known open HTTP and SOCKS proxy endpoints, which are frequently used to launch attacks and hide attackers identity


To create a new rule via API using the Cloudflare Open Proxies Managed List use the following expression: (ip.src in $cf.open_proxies) Important Access to the Open Proxy List requires a Cloudflare Enterprise plan. 


Regla del Firewall con lista de ip's

  • is in list
  • is not in list
Por ejemplo

Si la IP Origen (IP Source Address) está en la lista con nombre ips_proxy_ban denegar (Block)

(ip.src in $ips_proxy_ban)

"is not in list" sería:

(not ip.src in {ips_proxy_ban})



API CloudFlare


Es muy útil utilizar la API de CloudFlare y activar reglas del firewall sólo cuando las cargas del servidor suban (por ejemplo usando módulo Webmin "System and Server Status". Y cuando bajen las cargas desactivar las protecciones automáticamente:

  1. If monitor goes down, run command --> activar protecciones
  2. If monitor comes up, run command --> desactivar protecciones

Podemos usar:

o bien usando scripts bash shell (.sh) (necesitarás obtener los datos de la API key (x-auth-key) y otros valores. Consulta la documentación.

Ejemplo activar under_attack vía API

sh under_attack.sh
under_attack.sh

#!/bin/sh
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/XXX/settings/security_level" \
-H "X-Auth-Email: webmaster@elhacker.net" \
-H "X-Auth-Key: XXX" \
-H "Content-Type: application/json" \
--data '{"value":"under_attack"}'


Ejemplo  activar regla Firewall 

#!/bin/sh
curl -X PUT \
     -H "X-Auth-Email: webmaster@elhacker.net" \
 -H "X-Auth-Key: XXXX" \
     -H "Content-Type: application/json" \
     -d '{
      "id": "XXX",
      "paused": false,
      "description": "Open Proxy X-Forwarded-For",
      "action": "block",
      "priority": 1,
      "filter": {
        "id": "XXX",
        "expression": "(http.x_forwarded_for contains \".\")",
        "paused": false,
        "description": "Open Proxy X-Forwarded-For"
      }
  }' "https://api.cloudflare.com/client/v4/zones/XXX/firewall/rules/XXXX"
Para desactivar cambiar el primer paused: por true con ("paused": true,)

Para ver todas las reglas del firerwall y poden obtener su ID:

#!/bin/sh
curl -X GET \
-H "X-Auth-Email: webmaster@elhacker.net" \
-H "X-Auth-Key: XXX" \
-H "Content-Type: application/json" \
"https://api.cloudflare.com/client/v4/zones/XXX/firewall/rules"

¿Cómo detener un ataque DDoS en el que están usando servidores Proxy?


Si analizas las ip's que hacen más peticiones y ves que son servidores proxy muy probablemente estés sufriendo un ataque de éste tipo.



Todas las peticiones con proxy tienen dos cosas en  común incluyen la cabecera X-Forwarded-For y son del tipo HTTP Version 1.1
  •  X-Forwarded-For
  • HTTP Version 1.1


La regla adecuada sería:

(http.x_forwarded_for contains "." and http.request.version eq "HTTP/1.1")

Dónde estamos diciendo x-forwarded-for  contiene "contains" un punto (ipv4 e ipv6 cumplen) y la http versión sea (equals) del tipo 1.1 HTTP 1.X es un protocolo de texto, con HTTP 2.X  las cabeceras viajaban en formato binario.

Cuidado porque esta regla puede contener y contiene muchos falsos positivos. Es decir, visitantes válidos que están navegando con proxy (por el motivo que sea, en el trabajo, etc) y no puedan entrar. Estamos asumiendo que todos los visitantes X-Forwarded-For (HTTP_X_FORWARDED_FOR) no son legítimos. Muchos bots (robots de rastreo usan HTTP 1.1)

Podemos añadir a la regla el argumento (cf.client.bot); bloquear HTTP 1.1 y no es un bot conocido:


(http.request.version eq "HTTP/1.1" and not cf.client.bot)
Bots Conocidos por CloudFlare

BotDescripción

ahrefs

Ahrefs SEO bot

apple

Applebot is the web crawler for Apple, for products like Siri and Spotlight Suggestions

archive.org

Archive.org bots

baidu

Baidu search engine bots

bing

Bing search engine bots

feedbin

Feedbin.com bots

google

Google search engine bots

grapeshot

Grapeshot (Oracle) SEO bots

linkedin

LinkedIn bots

mail.ru

Mail.ru bots

naver

Naver (South Korean) search engine bots

pingdom

Pingdom.com monitoring bots

pinterest

Pinterest bots

seznam

Seznam search engine bots

sogou

Sogou search engine bots

uptimerobot

Uptime Robot monitoring bots

yahoo

Yahoo! search engine bots

yandex

Yandex search engine bots


Todas las peticiones con proxy "anónimos" no incluye la ip real de x-forwarded-for, por eso son llamados anonynoums, elite, etc. No incluyen la IP real del que lanzó la petición.


  1. Proxy Transparente
  • REMOTE_ADDR = proxy IP
  • HTTP_VIA = proxy IP
  • HTTP_X_FORWARDED_FOR = tu IP

  1. Proxy anónimo
  • REMOTE_ADDR = proxy IP 
  • HTTP_VIA = proxy IP
  • HTTP_X_FORWARDED_FOR = proxy IP
  1. Proxy realmente (high) anónimo
  • REMOTE_ADDR = proxy IP 
  • HTTP_VIA = not determined
  • HTTP_X_FORWARDED_FOR = not determined

HTTP/2 con CloudFlare

Es muy recomendable activar la configuración http2 en CloudFlare, pero recuerda que antes las conexiones desde Cloudflare's Edge a su (s) servidor (es) de origen solo admitían HTTP / 1.1.
 
HTTP / 2 y HTTP / 3 aceleran la carga de la página y son gratuitos para todos los planes de Cloudflare. HTTP / 2 está habilitado de forma predeterminada pero requiere un certificado SSL en la red de borde (edge) de Cloudflare. Configure HTTP / 2 y HTTP / 3 a través de la aplicación Cloudflare Network. Los dominios en planes gratuitos no pueden deshabilitar HTTP / 2.

HTTP/2 es la evolución del protocolo de la capa de aplicación con más éxito, HTTP. Se centra en hacer un uso más eficiente de los recursos de red. No cambia la característica fundamental de HTTP, la semántica. Todavía hay olicitudes, respuestas, cabeceras y todo los elementos típicos de HTTP/1. Así que, si ya conoce HTTP/1, también conoce el 95% de HTTP/2.


  • HTTP/2 es un protocolo binario, al contrario que HTTP 1.1 que es texto plano. La intención para HTTP 1.1 es que sea legible (por ejemplo capturando el tráfico de red) mientras que para HTTP/2 no. Más información en el FAQ oficial ¿Por qué es binario HTTP/2?
  • h2 es HTTP/2 sobre TLS (negociación de protocolo a través de ALPN).
  • h2c es HTTP/2 sobre TCP.
  • HTTP/2 es capaz de llevar múltiples streams de datos sobre la misma conexión TCP, evitando la clásica solicitud lenta "head-of-line blocking" de HTTP 1.1 y evitando generar múltiples conexiones TCP para cada solicitud/respuesta (KeepAlive en Apache parcheó el problema en HTTP 1.1 pero no lo resolvió completamente). 

Cloudlare también soporta HTTP3. 


HTTP / 3 permite conexiones rápidas, confiables y seguras. HTTP / 3 cifra el transporte de Internet de forma predeterminada mediante un protocolo de Google llamado QUIC. Habilite HTTP / 3 a través de la aplicación de red Cloudflare

 Si estamos usando CloudFlare y queremos ver si nuestro navegador soporta http2 o el nuevo http/3:

 Debería responder http3:

http=http/3
 
Con http no es posible http2 (sólo en https). El campo http=http2+quic/99 sería equivalente a HTTP/3. Recuerda que no todos los navegadores admiten HTTP / 2 y en su lugar utilizan HTTP 1.x.

¿Cómo saber si una web usa CoudFlare? Sin mirar ni las dns ni nada, simplemente añade /cdn-cgi/trace al dominio

dominio.com/cdn-cgi/trace
Si responde verás todas las variables de información.

fl=XXX
h=www.elhacker.net
ip=IP Visitante
ts=XXX
visit_scheme=https
uag=UserAgent
colo=MAD
http=http/3
loc=ES
tls=TLSv1.3
sni=encrypted
warp=off
gateway=off

¿Cómo saber si una web usa plan de pago de CloudFlare?

Según el Datacenter donde esté alojado.

Errores 520 aleatorios con http/2 con CloudFlare

LoadModule http2_module modules/mod_http2.so
<IfModule !mpm_prefork>
    Protocols h2 h2c http/1.1
</IfModule>

Si tu sitio web padece de errores 520 aleatorios y estás usando nginx o apache con protocolo http/2 debes añadir la siguiente directiva:

Header unset Upgrade

WordPress


Podemos crear una sencilla regla en el firewall de CloudFlare para prevenir ataques de fuerza bruta de la página de login del CMS Wordpress

Ejemplo regla:

(http.request.uri.path contains "/wp-login.php" and http.host eq "hwagm.elhacker.net" and ip.geoip.country ne "ES") 

Si el request URI (si la URL) incluye wp-login.php y el host es hwagm.elhacker.net y la IP no sea de España pues podemos mostrar un captcha Challenge (Captcha) o bloquear (Block) directamente.

O instalar plugins como:

  • Limit Login Attempts Reloaded
  • WP Limit Login Attempts

Recuerda que recientemente CloudFlare ha publicado un plugin para mejorar notablemente la velocidad de sitios con WordPress llamado APO  Automatic Platform Optimizations (APO). 



Managed Rules - WAF  (Web Application Firewall)

Estas son reglas "manejadas" automáticas, aunque pueden desactivarse.




Web CloudFlare Application Firewall detiene los ataques en tiempo real como la inyección SQL, cross-site scripting (XSS), los comentarios no deseados y otros abusos en el borde de la red. Los ajustes por defecto incluyen cobertura para las vulnerabilidades fundamentales de OWASP. Puedes activar o desactivar reglas individuales a continuación.

Permite CloudFlare para CMS y motores PHP

  • CloudFlare Plone
  • CloudFlare Php
  • CloudFlare Whmcs
  • CloudFlare Joomla
  • CloudFlare Magento
  • CloudFlare Plone
  • CloudFlare WordPress
  • CloudFlare Flash
  • CloudFlare Drupal
 Reglas OWASP ModSecurity Core Rule Set

  • OWASP ModSecurity Core Rule Set 
  • OWASP Protocol Violations
  • OWASP Bad Robots 
  • OWASP Protocol Anomalies
  • OWASP Slr Et PhpBB Attacks
  • OWASP Request Limits
  • OWASP HTTP Policy
  • OWASP Generic Attacks
  • OWASP XSS Attacks
  • OWASP Slr Et SQLi Attacks
  • OWASP Slr Et Lfi Attacks
  • OWASP Slr Et WordPress Attacks
  • OWASP Slr Et XSS Attacks
  • OWASP Common Exceptions
  • OWASP Slr Et RFI Attacks
  • OWASP Tight Security
  • OWASP Trojans
  • OWASP Slr Et Joomla Attacks
Ejemplo "CloudFlare Specials"

  • Empty User-Agent
  • IE6 Binary POST Botnet
  • CtrlFunc Botnet
  • Numbers Botnet
  • Uppercase Letters Botnet
  • Six or more numbers
  • Missing or Empty User-Agent and Referer
  • Generic LFI against common paths
  • Newsletter Tailor RFI
  • Generic RCE against common commands
  • SQLi probing
  • SQLi attempt
  • SQLi probe
  • Request arguments containing NUL byte
  • 80 legs crawler
  • Filter out any HTML links
  • Block X-Forwarded-Host header
  • Block requests on non standard ports
  • Block requests to version control systems
  • Block Wow! Signal Comment Bot
  • Generic LFI against common paths
  • Request arguments containing NUL byte (nyet.gif (PUT request))
  • Generic RCE against common commands
  • Common DDoS flood
  • Empty User-Agent
  • Missing or Empty User-Agent and Referer


En el "event log" llamado "Activity log" del firewall podemos ver si una regla se ha cumplido y si es un falso positivo. Filtrar por tipo WAF (Service Equals WAF) y buscar el "Rule ID) si es un falso positivo basta con cambiar la configuración

  • Default (mirar default mode que indica)
  • Disable
  • Log/Simulate (Simular: se permite la solicitud, pero se registra en el registro de actividad (log))
  • Block (Bloquear, servido por CloudFlare)
  • Challenge (CaptCha)
Recordemos que Cloudflare cambió el sistema de reCAPTCHA de Google por hCaptcha en abril de 2020

Incluidas en el plan gratuito:


  • HTTP Flood Prevents attacks caused from a flood of HTTP requests
  • UDP Flood Prevents attacks caused from a flood of UDP packets.
  • SYN Flood Prevents attacks caused from a flood of TCP packets sent with SYN flag.
  • ACK Flood Prevents attacks caused from a flood of TCP packets sent with ACK flag
  • QUIC Flood Prevents attacks caused from a flood of QUIC requests.

IP Access Rules

Incluir en lista blanca (Whitelist) tiene prioridad sobre el bloqueo sobre de las reglas de firewall
Pero la inclusión en una lista blanca de un código de país no omite el WAF de Cloudflare.

Es muy importante recalcar y recordar que si tenemos una regla aquí hará un bypass (caso omiso) de las reglas del firewall.

Me explico y pongo un ejemplo real.

Supongamos que decidimos añadir el ASN de Google a la whitelist (ahora llamada allow)

Y al mismo tiempo en las reglas del Firewall (Firewall rules) añadimos
(http.request.uri eq "/.xml.html" and http.host eq "foro.elhacker.net")

En la regla hemos dicho que si alguien visita foro.elhacker.net/.xml.html pues block (por ejemplo).

Pues cualquier IP de Google hará caso omiso a esta regla porque hay un "WhiteList" allow y las reglas del firewall no se le aplican.

En el ejemplo real, una IP de Google que la regla del Firewall no bloqueaba y seguía llegando la petición al servidor. Pensaba que ninguna IP de Google podía ser "maligna" Pero resulta que la IP  35.247.96.150 con reverso 150.96.247.35.bc.googleusercontent.com es de Google Cloud y tiene instalado un squid proxy (un servidor proxy).En apenas unos pocos minutos bloqueada hizo un total 31.2k peticiones, casi 6k (6 mil peticiones) por minuto.

Así que es muy importante añadir aquí sólo IP's de confianza.


  • Rango 66.249.0.0/16 (Google Bots reales)
  • IP's fijas nuestra de confianza
  • IP's fijas de servicios de terceros confiables


Por ejemplo sería peligroso añadir un WhiteList a un país, por ejemplo España, porque sólo con que varias ip's de España nos atacaran, se saltarían el firewall sin problemas.

Mucho cuidado del mismo modo, con añadir rangos de Ip's.

Permiten añadir:

  • IP
  • Rango de IP (rango /16, /24)
  • País
  • ASN

No podemos crear reglas por navegador, ni por referer, ni por http version,  etc

Las reglas de acceso sólo permiten 4 opciones


  • Block
  • Allow
  • JS Challenge
  • Challenge


Caching - Cache Analytics



Antes la opción de Caching sólo permitía cambios de configuración, pero ahora hay un panel gráfico de "overview" con  gráficos "Cache Performance". Ahora con el plan "Pro" de pago o superiores tienes un panel de control.

Ahora en la opción de Caching tenemos disponibles los dos tipos de peticiones (hits):
  • Served by CloudFlare (servidas por CloudFlare, no llegan al destino del servidor)
  • Served by origin (Servidas por el servidor de origen, nuestro servidor)



Lo importante en un ataque DDoS es que las peticiones las responda sólo CloudFlare (gráfico naranja) y no lleguen a impactar al servidor de origen (gráfica azul). Si una regla del Firewall es aplicada siempre será "Served by CloudFlare"
  • 503 Service Unavailable ( (JS Challange)
  • 403 Forbidden

El caching no permite ver las direcciones IP's que hacen más peticiones, ni el ASN, pero sí Países

Podemos filtrar por

  1. Tipo de contenido:
  • html 
  • Empty (típtico ataques DDoS)
  • gif 
  • png 
  • xml 
  • js 
  • Unknown 
  • txt
  • jpeg 
  • css 
  • ico 
  • rss 
  • json
  1. Tipo dispositivo ( Device types )
  • Desktop 
  • Mobile
  • Tablet

HTTP Status codes (Códigos de estado) CloudFlare

  •     1xx Informational
  •     2xx Success
  •     3xx Redirect
  •     4xx Client Error
  •     5xx Server Error

  • 200 OK (petición normal de tráfico)
  • 206 Partial Content 
  • 301 Moved Permanently (Redirección)
  • 302 Found
  • 304 Not Modified 
  • 400 Bad Request
  • 401 Unauthorized
  • 402 Payment Required
  • 403 Forbidden (Prohibido, normalmente regla firewall, WAF o similar)
  • 404 Not Found (Página, url no encontrada)
  • 405 Method Not Allowed
  • 406 Not Acceptable
  • 408 Request Timeout
  • 409 Conflict
  • 413 Payload Too Large
  • 414 Request-URI Too Long
  • 416 Range Not Satisfiable 
  • 429 Too Many Requests (Rate Limited)
  • 451 Unavailable For Legal Reason
  • 499 Client Closed Request (típico ataques DDoS, mandan petición y no esperan la respuesta)
  • 500 Internal Server Error  (Error interno servidor)
  • 502 Bad Gateway
  • 503 Service Unavailable 
  • 504 Gateway Timeout error
  • 520 Origin Error
  • 521 Origin Down (Servidor origen caído)
  • 522 Origin Connection Time-out (Servidor origen caído o no responde)
  • 523 origin is unreachable
  • 524 Timeout occurred - 524: Tiempo de espera agotado
  • 525 Origin SSL Handshake Error
  • 526 invalid SSL certificate

Cloudflare permite enviar alertas cuando tu sitio web está bajo un ataque DDoS

Tienes que crear alertas de ataques DDoS. Sólo en los planes de pago.
 
Para crear notificaciones de Cloudflare para que nos avise de ataques DDoS hay que llevar a cabo una serie de pasos. Debemos iniciar sesión en la cuenta, hacer clic en la sección de notificaciones, darle a crear y posteriormente seleccionar el tipo que queremos y posteriormente ponemos los datos necesarios, como el correo electrónico, para recibir esa notificación.

DDoS Attack Alert    HTTP DDoS Attack Alerter

Informes Bots

CloudFlare envía un informe mensual de tráfico de robots




elhacker.net bot vs human requests


El producto Bot Management de Cloudflare analiza y puntúa cada solicitud en nuestra red para determinar la probabilidad de que la solicitud provenga de un bot o un humano.

Aprovechando la escala de la red de Cloudflare, la solución de gestión de bots de Cloudflare utiliza análisis de comportamiento, aprendizaje automático y huellas digitales para identificar solicitudes provenientes de bots.


Este informe muestra cómo se distribuyeron las solicitudes en sus zonas el mes anterior:

elhacker.net

  • Porcentaje de tráfico definitivamente automatizado
  • Porcentaje de tráfico probablemente automatizado
  • Porcentaje de tráfico probablemente humano

 

No todo el tráfico automatizado es igual. Algunos bots, como el motor de búsqueda de Google o las solicitudes de API, son buenos.

Pero algunos bots son malos: pueden afectar la infraestructura, lo que genera una mala experiencia del usuario y mayores costos de red y CDN.


Y ahora también avisa si tu web está caída por e-mail:

  • [Cloudflare]: Server Unreachable for elhacker.net
Server Unreachable
Requests to the following origin have been failing for at least five minutes:

https://foro.elhacker.net: IP_REAL:443
Check out this article from our help center:

Error 521: Web server is down
Error 521 occurs when the origin web server refuses connections from Cloudflare. Security solutions at your origin may block legitimate connections from certain Cloudflare IP addresses.

The two most common causes of 521 errors are:

Offlined origin web server application
Blocked Cloudflare requests

Etiquetas: , , , , , , , , , , ,

11 comentarios :

Miguel dijo...

Muchas gracias por tantísima información útil aunque todavía me queda mucho por aprender para comprender todo.
Os escribo porque tengo una tienda online en Prestashop con Redsys y hosting en loading. Todo va perfecto pero si activo cloudflare, la notificación de pago de Redsys devuelve: (com.ibm.jsse2.util.h No trusted certificate found)

Desde Redsys y desde loading no pueden ayudarme, ¿sabéis qué más puedo probar?

17 de febrero de 2022, 17:50
el-brujo dijo...

¿Qué tipo de SSL utilizas, Flexible, Full?

Puedes añadir una regla para excluir SSL (HTTPS) en algunos subdominios o paths. En la pasarela de pago (URL, o Path) puedes poner SSL Flexible, o incluso off, ya que esos paths ya tienen https seguro y no quieren "interferencias" de terceros.

17 de febrero de 2022, 18:53
Miguel dijo...

Muchas gracias, estaba intentando crear una regla de página con la parte de Redsys pero no sé si no lo estoy haciendo bien o no lo pilla porque sigo igual.

https://midominio.com/index.php?fc=module&module=redsys&controller=ipn

es la url que estoy configurando porque es la que me muestra el error de cetificado en el TPV

18 de febrero de 2022, 12:22
Miguel dijo...

Por cierto, lo tengo en full el SSL porque si le meto flexible me da error Too many redirects la página

18 de febrero de 2022, 13:00
el-brujo dijo...

Entiendo que la pasarela de pago Redsys suelta un error al pasarle la petición, ¿es un formulario POST?

Para crear la regla (rules) yo uso *

*index.php?fc=module&module=redsys&controller=ipn*
SSL: Flexible


Si te da error de "Toot Many Redirects" es porque en tu http ya tienes puesto redireccionar a https, entonces ya haces bien de hacer servir SSL Full (sólo https)

18 de febrero de 2022, 13:09
Miguel dijo...

El error me lo devuelve Redsys en el Administrador "No trusted Cerificate found" pero sólo sale este error si tengo Cloudflare activado, con mi hosting no pasa, por eso quería, de algún modo, evitar que la llamada de Redsys a Prestashop no paase por Redsys porque ni completa pedido ni informa correctamente

Mil gracias

18 de febrero de 2022, 13:49
Miguel dijo...

Quería decir evitar que la llamada de Redsys a Prestashop no pase por Coloudflare porque ni completa pedido ni informa correctamente

He puesto midominio.com*index.php?fc=module&module=redsys&controller=ipn*

Con SSL off y sigue igual...es una desesperación

18 de febrero de 2022, 15:13
el-brujo dijo...

Comprueba realmente la petición que estás haciendo a Redsys sea con ese referrer o URL

Quizás la URL que tu ves en el navegador es:
*index.php?fc=module&module=redsys&controller=ipn*

Pero la petición a Redsys se realiza con otra URL. Las reglas SSL off y demás funcionan.

Yo puse un ejemplo con un subdoominio entero SSL OFF y efectivamente CloudFlare hace las peticiones http en el puerto 80 y no en el https 443

Si desactivando SSL (https) de CloudFlare funciona entonces el problema es ése seguro, es sólo encontrar la URL correcta.

18 de febrero de 2022, 18:04
Miguel dijo...

Muchas gracias por tu ayuda, llevas toda la razón. Acabo de probar con https://midominio.com/es/module/redsys/okpayment* y en SSL Flexible y el problema es que ahora me da Too many redirects en esa llamada
Quizás si quito el forzado en mi server a https al estar el resto a full en cloudflare funcione?

19 de febrero de 2022, 14:15
el-brujo dijo...

Ahora acabo de leer el problema en Twitter, es culpa de Redsys que debe aceptar los nuevos certificados wildcard https://twitter.com/josecontic/status/1495356576462426113?t=bu6KDjmpasMdXmeCEw9a_Q&s=19

20 de febrero de 2022, 18:34
Miguel dijo...

Wow! Te agradezco muchísimo tu ayuda, voy a volver a insitir al banco que decían que era cosa de mi certificado. A ver si de esta se arregla, mil gracias!!

20 de febrero de 2022, 19:59

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.