lunes, 5 de enero de 2015

Limitar ancho de banda en interfaces de equipos CISCO

Dimensionar el Ancho de Banda de un interfaz de red nos sirve fundamentalmente para repartirlo de tal manera que puedan garantizarse los niveles de calidad de servicio deseados. Es decir, limitar el Ancho de Banda permitido para un servicio implica que los servidores dedicados a él no saturarán el interfaz y por lo tanto se mantendrán todos los servicios que lo necesitan.
Normalmente limitaremos el ancho de banda de los servicios que más tráfico requieren, por ejemplo tráfico web o correo.
La forma de hacerlo en CISCO es a través de rate-limit. La sintaxis de este comando la encontramos en:
Para el ejemplo que nos ocupa, hemos de definir unas listas de acceso extendidas y a continuación aplicarlas en el interfaz correspondiente:
Para correo entrante una limitación de 10Mbps .
Para correo saliente una limitación de 8Mbps .
Para tráfico Web una limitación de salida de 20Mbps .
Para restringir el ancho de banda a los servicios se utilizara una ACL.
Configuración:
Router(config)# access-list 100 permit tcp any <o IPs Web> eq www any  (trafico Web saliente)
Router(config)# access-list 101 permit tcp any any <o IPs POP3> eq pop3 (trafico smtp entrante)
Router(config)# access-list 102 permit tcp any <o IPs SMTP> eq smtp any (trafico smtp saliente)
A continuación, hay que implementar el comando rate-limit en la interfaz que conecta a internet o a cualquier otro Router los servidores conectados:
Router(config)# interface GigabitEthernet0/1
Router(config-if)#rate-limit output access-group 100 20000000 3750000 7500000 conform-action transmit exceed-action drop (limitado el ancho de banda del trafico Web saliente)
Router(config-if)#rate-limit input access-group 101 10000000 1875000 3750000 conform-action transmit exceed-action drop (limitado el ancho de banda del correo entrante)
Router(config-if)#rate-limit output access-group 102 8000000 1500000 3000000 conform-action transmit exceed-action drop (limitado el ancho de banda del correo saliente)
Para configurar el rate-limit hemos necesitado dos valores más que se recomienda calcular con la formula proporcionada por Cisco. Estos valores son el "normal burst" y el "extended burst".
Según Cisco estos valores se calculan de la siguiente manera:
 "normal burst" = rate * (1 byte)/(8 bits) * 1.5 seconds
"extended burst" = 2 * "normal burst"

 
Comando para verificación:
show interfaces rate-limit


Mejores prácticas en Checkpoint Firewall

Nivel: - Intermedio

Plataformas: - Todas

S.O: - Checkpoint R61, R62, R65, R70, R77

En este artículo discutiremos (y recomendaremos) algunas mejores prácticas que deben seguirse mientras creamos una rulebase en Checkpoint Firewall. Basada en nuestra experiencia e investigación, no hemos encontrado fuentes fluidas, mucho menos libros que hablen sobre la mejor forma de tener organizada las reglas para sacar el mayor beneficio y performance posible de nuestros equipos.

Si podemos afirmarles que siguiendo estas best practices pueden esperar lo que buscamos todos: mayores rendimientos y facilidades en la administración.

Para empezar, identificaremos las recomendaciones generales que deben ser seguidas para crear una poderosa rulebase:

1) La rulebase debe ser lo más simple que se pueda .Cuanto más pocas reglas tengamos, más eficiente y con menor tendencia a errores estará la lista de filtros.

2) Evitar el uso de Any en el campo de servicios: Simple, si habilitamos todos los puertos de un origen a un destino y no solo los necesarios abriremos una brecha de seguridad que puede ser explotada por usuarios inescrupulosos (o malware´s, virus, etc.-).

3) Utilizar objetos Network en las reglas en vez de objetos host, cuando se trate de una regla que será accedida por más de un usuario del mismo rango de red: Esencial para el buen funcionamiento de la rulebase. La recomendación que damos es que siempre que un rango de red quiera acceder a un destino, este puede hacerlo a cualquier puerto, excepto a los de administración (standard´s como rdp, ssh, telnet) o de servicios específicos (1521, 1433). Dejemos las reglas de administración lo más segregada posible, que a esta solo puedan acceder ciertos hosts o la red de administración, jamás las redes de usuarios en sí.

4) Utilizar objetos Groups cuando existan varias redes o usuarios que precisen acceder a un mismo destino o viceversa.

5) Configurar el antispoofing para todas las interfaces del firewall, delimitando cuales son las internas, externas o las que dejemos en la DMZ: Con esto conseguimos que solo las redes o hosts que nosotros deseemos tengan permiso para "pasar" por la interface del firewall donde se ha definido el antispoofing.

6) Mover las reglas más accedidas entre las primeras de la rulebase: Esta mejor práctica puede ser aplicada rápidamente con el hit count introducido a partir de la versión R75.40, que permite medir cuales son las reglas más accedidas mediante el conteo de matcheo de reglas. Esto mejorara la performance y la eficiencia del firewall. Como el software Checkpoint busca en la rulebase de forma secuencial, la primera regla que matchee a una conexión entrante es aplicada, no a la mejor regla existente para esa conexión. Este modelo de aplicación de reglas es la genérica para cualquier ACL y es usada en cualquier FW, ya sea Cisco ASA, Netscreen, Fortinet, Juniper, Palo Alto, Iptables, etc.-

7) Definir una nomenclatura genérica para los nombres de hosts, redes y grupos, etc. Por ej. : una nomenclatura recomendada es la del hostname + la ip del equipo (DomainServer01.100.100.100.150) o el tipo de equipo + la ip (Server.100.100.100.150). También podemos definir una nomenclatura de colores, por ej. : color rojo para hosts externos o redes de desarrollo .

8) Crear la regla Stealth para bloquear conexiones directas a los firewalls.

9) Preferir reject a drop para algunos servicios, como ident para permitir mejor rendimiento de la aplicación. Ident es un servicio usado por el protocolo SMTP para tratar de identificar los clientes de email. Si se usa reject en vez drop, la aplicación smtp ganara performance porque no debe esperar a la conexión ident para declarar timeout. Cuando una acción Drop es tomada, el host origen no es notificado, en cambio para la opción reject varias acciones pueden ser tomadas, como las que se describen en la siguiente tabla:

Servicio

Reject

TCP

El origen es notificado

UDP

Se envía un mensaje de ICMP port unreachable error al origen.

Otros protocolos

Misma acción que drop

10) Crear la regla Cleanup siempre al final de la rulebase para bloquear y loguear todo el tráfico rechazado por no aplicarse a regla alguna.

11) No usar objetos domain en la rulebase: objetos domain pueden causar cuellos de botella.

12) Para evitar mucho tráfico de logging o broadcast como bootp y NBT es necesario crear una regla que dropee estos paquetes sin loguear nada en el servidor de logs .

13) Deshabilitar decrypt en las propiedades accept si no usamos VPN.


 

Con estas recomendaciones básicas estamos encaminados a mantener de forma eficiente nuestra rulebase , elevando la performance de nuestro Firewall Checkpoint .

domingo, 4 de enero de 2015

Uso efectivo de CheckPoint IPS Blade para minimizar los ataques DDOS a una red

Los ciberataques se están convirtiendo en un problema común en estos días. La mayor parte de nuestras infraestructuras son vulnerables a este tipo de situaciones, aunque pensemos que estamos en un lugar seguro con las mejores tecnologías en el mundo. Una cosa que solemos olvidar es que todos estos productos tecnológicos de alta gama no tienen ningún valor si no son configurados correctamente. Estudiaremos algunas de las configuraciones disponibles de los equipos de red más importantes y destacados del mercado que tenemos en nuestras infraestructuras.

En este artículo vamos a hablar acerca del CheckPoint Firewall-1 (CheckPoint VPN-1) y su configuración IPS Blade para evitar ataques DDOS. Especialmente, nos centraremos en las funciones de geoprotección del IPS Blade. Algunos podríais plantearos si es posible bloquear un ataque DDOS de 100 Gbps solo mediante configuraciones en el firewall o el IPS. ¿Cómo puede un firewall lidiar, con sus limitadas CPU y memoria con cientos y miles de conexiones abiertas por atacantes de todo el mundo al mismo tiempo? Podríamos estar de acuerdo en que es muy complicado, aunque como siempre, una buena preparación nos dará más tiempo para analizar los vectores de tráfico y poder así desplegar las reglas de bloqueo adecuadas o dejar caer el tráfico en un router tipo agujero negro.

Como los niveles de severidad de Check Point IPS están altamente ligados con los niveles de rendimiento de la puerta de enlace, en la primera etapa se pueden utilizar las siguientes configuraciones. Las configuraciones de directivas se han propuesto basándose en los métodos de ataque recientes más destacados y en los ataques que pudieran aparecer en un futuro próximo.



Desglose de los sitios atacados por áreas de actividad y tipos de ataques DDoS

Por otro lado, las configuraciones de directivas propuestas hacen uso de la siguiente información obtenida de Kaspersky Lab para minimizar los problemas de rendimiento y aumentar al máximo los niveles de seguridad de las puertas de enlace:



Ataques DDoS por hora del día



Tipos de Flood HTTP

Por lo tanto , las configuraciones de directivas se centrarán en los siguientes vectores de ataque:

1. HTTP Flood

2. UDP Flood

3. TCP SYN Flood

4. ICMP Flood

5. DNS Flood

6. TCP Full Connect

7. TCP ACK / FIN / RST Flood

8. Non TCP , UDP & ICMP Flood


Sobre este artículo

En este artículo vamos a revisar la configuración de geoprotección que nos ofrece el CheckPoint Firewall-1 + IPS Blade, centrándonos en un defecto que lo hace especialmente vulnerable a ataques de denegación de servicio distribuidos (DDOS) organizados por atacantes que conocen esta vulnerabilidad, consistente en la rigidez de la lista de países disponible, y especialmente en la no inclusión de Korea del Norte en la lista de países quedando todo su rango de IPs asignadas fuera del alcance de la geoprotección que ofrece el IPS Blade.

Paso 1: Configurar el bypass bajo carga

Para minimizar los problemas de integración que pudieran surgir cuando se configura el IPS, la activación de la función de Bypass bajo carga (Bypass Under Load) desactivará las actividades de IPS. Por tanto, el IPS permitirá que el tráfico pase a través del gateway sin inspección .

1. En la ficha IPS , seleccionar Enforcing Gateways.

2. Seleccionar una puerta de enlace con carga crítica o el gateway que activa las licencias IPS y hacer clic en Editar.

3. Seleccionar Bypass SmartDefense cuando la puerta de enlace se encuentra bajo carga de trabajo alta, o seleccionar un método de seguimiento para registrar la actividad, mientras que la inspección IPS está apagada.

4. Para configurar la definición de la carga alta, hacer clic en Avanzado .

5. Especificar a qué umbral de carga se desea que la inspección IPS sea excluida . Aquí hay que configurar el gateway para pasar por alto todo el tráfico sin ningún tipo de inspecciones.

6. Especificar cuándo reanudar la inspección IPS.

7. Haga clic en Aceptar .

Paso 2: Configurar la Geoprotección

La siguiente sección muestra la configuración de las características de geoprotección del CheckPoint IPS. Durante los últimos 6 meses, 201 países de todo el mundo han registrado y monitorizado gran cantidad de ataques DDOS. Sin embargo, estos ataques provenían principalmente de solo 23 países.



Procedencia de los ataques DDOS a nivel global

Por lo tanto, la configuración de la geoprotección debe tener en cuenta esta información y centrarse en bloquear ataques viniendo de estos países, teniendo en consideración los requisitos e intereses particulares de cada corporación con cada uno de estos países.

Limitaciones encontradas durante la configuración del IPS Blade :
1. Los propios Firewalls deben descargarse actualizaciones regularmente, conectados directamente a Internet o mediante un proxy.
2. Si la geoprotección está configurada para bloquear tráfico de un país, pero el Mobile Access está configurado para permitir tráfico de una aplicación o sitio de ese país, no sé podrá evitar tráfico proviniendo de dicho país.
3. No se puede modificar la lista de países que viene en el sistema de geoprotección del IPS Blade (Nota: pero se puede descargar la lista de países desde su base de datos y revisarla para buscar los rangos de IPs y la tabla con los países, para posibles bloqueos).
4. Korea del Norte no está en la lista de países en versiones anteriores a la actual del IPS Blade (existen workarounds: leer a continuación).

Uso creativo del IPS Blade y otros recursos :
1. Existe un pequeño workaround para modificar la lista de IPs manualmente, que permite usar uno de los países existentes —uno pequeño, como Reunión (isla de Reunión, departamento de Francia)—, modificando su lista de IPs asignadas.
2. Para este propósito podemos utilizar el CIDR (base de datos de países desarrollada por Maxmind, o la de CheckPoint, bajo licencias open source.
3. Podéis echar un ojo también a cómo habilitar las funcionalidades DShield/Storm Center de CehckPoint, sobre cómo restringir IPs de las listas de bloqueo de IPs.

Habilitando la Geoprotección
Para poder utilizar correctamente la geoprotección del IPS Blade, es necesario:
1. Disponer de un contrato válido de IPS.
2. Una licencia de software Blade para cada una de las puertas de enlace en las que desea activar la geoprotección, y otra para el Security Management Server.
Nota 1: Este tipo de protección solo está disponible en versiones R70.20 y posteriores.
Nota 2: El control de conexiones de CheckPoint (tales como las conexiones entre los Security Gateways y el Security Management Server) están siempre activas, independientemente de las directivas de la geoprotección.

Configuración de la Geoprotección (bloquear/permitir/monitorizar)
1. En la pestaña SmartDashboard IPS, ir a Geo Protection desde el árbol de navegación.
2. En la página de Geo Protection, elegir un perfil de IPS.
· Nota: las configuraciones de geoprotección son dependientes de cada perfil. Debe configurarse esta protección en el perfil utilizado por cada puerta de enlace.
3. Marcar la acción Detect temporalmente (Prevent/Detect/Inactive) para este tipo de protección. Hay que tener en cuenta que cuando la protección está en modo Detect, todo el tráfico está permitido (incluso para las reglas donde la acción está puesta para bloquear), pero el tráfico que no pasa los filtros es loggeado. Cuando está marcada como Prevent, las reglas aplican tal y como se han configurado, como es esperado.
4. Definir una directiva para países específicos. Para configurar una directiva para un país diferente de la del resto de países:
· Hacer click en Add. La ventana de geoprotección se abre.
· En la ventana de geoprotección, elegir un país. Escribiendo un par de letras en el campo que aparece, la herramienta busca patrones de países coincidentes.

· Elegir:
o Dirección. Bien desde país hacia el gateway, o bien hacia país desde el gateway, o bien desde y hacia país. Si cualquiera de las dos primeras opciones es marcada, las conexiones en la dirección opuesta se regirán según las directivas marcadas en Other Countries.
o Acción: Bloquear o permitir.
o Track: cualquier configuración diferente de None genera un log para cada conexión que está monitorizada por esta protección. Si un patrón es coincidente con dos o más reglas, solo la primera coincidente es loggeada.
· Hacer click en OK.
5. Configurar las directivas para Other Countries (otros países). Estas directivas aplican para cualquier conexión/país que no esté incluido en las directivas para países específicos. Al igual que antes, hay que configurar para permitir, bloquear, o monitorizar.
6. Si fuera necesario, se pueden aplicar Excepciones (a través de la configuración de las Network Exceptions). Las excepciones se evalúan antes que cualquier otra regla en la cadena de filtros.
7. Aplicar las directivas a los firewalls. Para ver qué firewalls están afectados por las políticas recién creadas, comprobar la lista Enforcing Gateways.
8. Comprobar los logs (el SmartView Tracker y el SmartEvent Intro), y la vista de rendimiento (SmartView Monitor).
9. Asegurarse de que las actualizaciones diarias están funcionando ($FWDIR/tmp/geo_location_tmp/updates/ en los gateways).
10. Utilizar el SmartEvent Intro para ver todas las alertas de IPS por país de procedencia, y añadir nuevos países a las listas de bloqueo si fuera necesario y acorde con los requerimientos de negocio.
11. Una vez se ha comprobado bien todo (es decir, se ha comprobado que no se está bloqueando tráfico legítimo), actualizar en las directivas anteriores la acción desde Detecta Prevent, y aplicar los cambios a los firewalls (push policies to the firewalls).



Captura de pantalla del Blade IPS CheckPoint

Comprobaciones tras los cambios de configuración
1. Examinar el mapa en Policy Preview. Los países en rojo están configurados para bloquear tráfico; los verdes para permitirlo.
2. Dejar un tiempo operar al sistema de protección y posteriormente revisar los logs.
3. Para revisar los Geo Logs, hay que ir a la página de geoprotección del IPS, y hacer click en View Logs. Los logs que aparecen son tanto para las acciones para países específicos, como para las acciones para otros países.

Bloqueando países que no están en la lista
Dado que Korea del Norte no está en la lista de países del IPS Blade (al igual que puede ocurrir con otros países, o zonas en disputa), y ya que de esto precisamente se aprovechan muchos atacantes, una manera sencilla para estar protegidos usando el IPS Blade de CheckPoint es mediante la creación de un firewall object para la pequeña red asignada a Korea del Norte (175.45.176.0/22 [máscara 255.255.252.0], o el rango 175.45.176.0-175.45.179.255), y luego añadir una regla para bloquear el tráfico procedente de este rango.

Fuente : <http://hard2bit.com/blog/uso-efectivo-de-checkpoint-ips-blade-para-minimizar-los-ataques-ddos-a-un-red/>