Tienda Wifi

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

Entradas Mensuales

Suscripción

¿Quieres recibir las últimas novedades del blog en tu correo?

¡Suscríbete al feed!

Entradas populares

PostHeaderIcon Configuración Avanzada de CloudFlare




Ya hemos hablado anteriormente en el blog del funcionamiento y las opciones de configuración 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, carcterísticas y nuevas opciones 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.


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 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. 
  • 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) por ejemplo.
  • Errores por pantalla del servidor web muestren información real de la IP
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 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.


Analytics



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 ell ASN, sólo País, HTTP Version, TLS Version, etc

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
  • Hostname --> (si tenemos varios subdomnios pues un host sería elhacker.net ,otro foro.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 -->
  • URI --> 
  • Path -->
  • 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)
  • Known Bots -->
  • Threat Score --> CloudFlare asigna una puntuación a una IP según su "comportamiento"


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


¿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 problamente 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.

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


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


Managed Rules - WAF

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

Web CloudFlare Application Firewall detiene los ataques en tiempo real como la inyección SQLcross-site scripting (XSS), los comentarios no deseados y otros abusos en el borde de la redLos ajustes por defecto incluyen cobertura para las vulnerabilidades fundamentales de OWASPPuedes 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
  • Simulate
  • Block
  • Challenge
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

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)

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

Status codes (Códigos de estado)


  • 200 OK (petición normal de tráfico)
  • 206 Partial Content 
  • 301 Moved Permanently (Redirección)
  • 302 Found
  • 304 Not Modified 
  • 400 Bad Request
  • 403 Forbidden (Prohibido, normalmente regla firewall, WAF o similar)
  • 404 Not Found (Página, url no encontrada)
  • 500 Internal Server Error  (Error interno servidor)
  • 503 Service Unavailable 
  • 499 Client Closed Request (típico ataques DDoS, mandan petición y no esperan la respuesta)
  • 520 Origin Error 
  • 521 Origin Down (Servidor origen caído)
  • 522 Origin Connection Time-out (Servidor origen caído o no responde)
  • 525 Origin SSL Handshake Error 

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



0 comentarios :

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.