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 .