Permisos en Linux: uso de los comandos chmod y umask.

Desde que a GNU/Linux se accede con un rico interface gráfico, como Gnome o KDE, cuando necesitamos modificar los permisos de acceso a archivos o directorios lo hacemos generalmente a través de la hoja de propiedades del gestor de ficheros.

Pero, de vez en cuando, nos encontramos con que nos dan alguna instrucción del estilo; “cambia los permisos a 755″ o “ponle una máscara 022″ ¿ Pero qué es eso de 755 y 022 ? O bien quedamos algo desconcertados cuando, en Ubuntu, vemos que podemos leer los directorios home de otros usuarios ¿ Cómo es posible ?

Supongamos el siguiente directorio:

jdoe@ubuntu:~$ ls -l
drwxr-xr-x 2 jdoe migrupo 4096 2008-07-05 1:05 midirectorio
-rw-r--r-- 1 jdoe migrupo    12 2008-07-05 1:10 test

Tenemos un único fichero denominado “test” creado por nosotros al que se le han dado, por omisión, los permisos rw-r--r-- y un directorio “midirectorio” también con sus permisos por defecto rwxr-xr-x.

Observese que nos olvidamos de la primera letra o guión de la serie. En el caso del archivo, un guión “-”, y en el del directorio una “d”. Este primer carácter tiene un significado ajeno a los permisos, e indica el tipo de entrada.

Los tres primeros caracteres (-rw) representan los permisos del usuario propietario del archivo (jdoe), los tres siguientes (r- -) los del grupo al que pertenece el archivo (migrupo) y los tres últimos (r- -) al resto de los usuarios.

A su vez los permisos asignables son tres: lectura/read (r), escritura/write (w) y ejecución/execute (x). Como se intuye si aparece un guión en un lugar determinado significará que el usuario, o conjunto de usuarios afectados, no tiene ese permiso. Así los miembros del grupo “migrupo” (r - -) tienen solo permiso de lectura, pero no de escritura ni de ejecución, ya que aparece un guión en lugar de la “w” y de la “x”. 

Un poco de aritmética binaria

Tomemos los permisos y sustituyamos, por un “0″ los guiones y, por un “1″ cualquier letra que aparezca en su lugar y hagamos la conversión de binario a decimal octal (Con tres bits solo se puede representar del 0 al 7). Los permisos, para el archivo y directorio, nos quedarían de la siguiente forma:

Afecta	Permiso	Binario	Octal
usuario	rw-	110	22+21+0=6	⇒ 644
grupo	r- -	100	22+0+0=4
resto	r- -	100	22+0+0=4

Afecta	Permiso	Binario	Octal
usuario	rwx	111	22+21+20=7	⇒ 755
grupo	r-x	101	22+0+20=5
resto	r-x	101	22+0+20=5

Simplificando

Octal	Permisos
0	- - -
1	- - x
2	- w -
3	- w x
4	r - -
5	r - x
6	r w -
7	r w x

Realmente tampoco es necesario hacer este cálculo cada vez que necesitemos saber la representación numérica de los permisos.Es sencillo de recordar al adquirir mas experiencia con esto.

Otra manera de verlo más simple, si miramos la tabla adjunta, es tener solo en cuenta que 4 es el permiso de lectura, 2 el de escritura y 1 el de ejecución. Así si tenemos que conceder el permiso de lectura y escritura este sera: 4+2 = 6. Si, en vez, fuera conceder lectura y ejecución 4+1 = 5.

Los permisos más habituales son 755, 750, 644 y 640. El permiso 777 es “peligroso” ya que concedemos todos los permisos a todos.

Modificando los permisos

El comando para modificar los permisos es chmod. Como casi todos los comando *NIX , el mismo es muy flexible. Sin ánimo de hacer un tutorial exhaustivo, veamos algunos de sus usos:

Supongamos que el fichero test creado al principio, fuera un script en bash y queremos concederle permisos de ejecución al usuario y al grupo, y retirar el permiso de lectura a los otros usuarios.

Una manera sería redefinir totalmente los permisos al archivo: Es la forma “larga”, pero más intuitiva:

chmod u=rwx,g=rx,o= test

La variante es solo consignar las modificaciones sobre el estado original:

chmod ug+x,o-r test

Es decir que “sume” (+) el permiso de ejecución a usuario (u) y grupo (g), y que “reste” (-) el permiso de lectura a otros usuarios (o)

Ahora bien lo más rápido es esto:

chmod 750 test

En los tres casos el resultado será el mismo:

-rwxr-x--- 1 jdoe migrupo   12 2008-07-05 02:15 test

Como segundo ejemplo supongamos que queremos retirarle el permiso de lectura y ejecución al directorio midirectorio y también a todos los archivos y subdirectorios en él contenidos a los otros usuarios.

chmod -R o-rx midirectorio

La opción -R le indica a chmod que haga la operación recursivamente en todo su contenido.

La máscara de permisos

Al principio creamos un archivo test y un directorio midirectorio, pero al crearlos no necesitamos asignarles ningún permiso. El sistema mantiene un valor denominado umask que determina los permisos, por omisión, cada vez que creamos un archivo o directorio. Y que puede ser modificado en cualquier momento con el comando umask.

Cuando creamos el fichero test con el editor de textos este quiso asignarle, al grabarlo, unos permisos de 666. Es decir lectura/escritura para todos. Pero el valor de umask era de 022. Lo que dio como resultado unos permisos de 644 para el archivo.

De manera análoga cuando creamos el directorio con mkdir midirectorio el sistema quiso asignarle unos permisos de 777, es decir, lectura/escritura/ejecución para todos. Pero se topó con la máscara anterior (022) y dio como resultado unos permisos de 755 para midirectorio.

Un poco de lógica binaria

Este valor de umask actúa una máscara binaria, sobre los permisos máximos que intenta otorgarle el sistema:

umask 022                    000 010 010        000 010 010

complemento a 1 de umask     111 101 101        111 101 101
And (&&)                     110 110 110 (666)  111 111 111  (777)
                             ------------       ------------
                             110 100 100 (644)  111 101 101  (755)

O, mucho más sencillo, como una simple “resta” de permisos:

   666           777
   022 (-)       022 (-)
   ----          ----
   644           755

Ubuntu: umask en la práctica

La máscara 022 es la que trae preconfigurada Ubuntu para cuando se añade un usuario. Esta máscara, si es un sistema compartido, es demasiado liberal pues permite que cualquier usuario pueda leer y ejecutar los archivos de los directorios HOME de los otros usuarios.

Podemos cambiar este valor en cualquier momento. 

Para prohibir la lectura/escritura/ejecución a los otros usuarios, basta con ejecutar:

umask 027

Este valor se mantendrá activo durante la sesión del usuario, y será válido para los archivos y directorios de nueva creación, pero se restaurará a 022 la próxima vez que nos conectemos y no modificará los archivos y directorios del perfil del usuario ya creados.

Para “corregir” los perfiles existentes podríamos usar, por ejemplo en el caso del usuario “jdoe”:

chmod -R o-rwx /home/jdoe

Y editando el fichero /home/jdoe/.profile descomentar y modificar a umask 027 para hacer permanente el ajuste para el futuro. Aunque esta modificación afectaría solo al usuario “jdoe”.

Para que a partir de ahora todos los nuevos usuarios se creen sin permisos de lectura/escritura/ejecución para todos:

• Editamos el perfil común /etc/profile y hacemos la misma modificación: umask 027
• Editamos el /etc/adduser.conf y modficamos: DIR_MODE=0750. Este ajuste no es extrictamente necesario y lo que hará es que ni siquiera podamos entrar al directorio HOME del usuario con cd

Tener en cuenta que cuaquier usuario puede sobreescribir este valor de umask, ya sea desde la línea de comandos o modificándolo en su $HOME/.profile, sin el concurso del Administrador.

Puede ser que nos encontremos valores de chmod o umask con cuatro digitos. Por ejemplo umask 0022. El primer digito representa a tres bits de permisos especiales, que aquí no tratamos, y que se usan poco en la operativa normal.

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:

http://www.cisco.com/en/US/docs/ios/12_2/qos/command/reference/qrfcmd8.html

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 .

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/>