¡Hola, colegas! Hoy me gustaría discutir un tema muy relevante para muchos administradores de Check Point: «Optimización de CPU y RAM». No es raro que la puerta de enlace y/o el servidor de gestión consuman inesperadamente muchos de estos recursos, y nos gustaría entender a dónde se “escapan” y, en la medida de lo posible, usarlos de manera más eficiente.
1. Análisis
Para analizar la carga del procesador, es útil utilizar los siguientes comandos, que se ingresan en modo experto:
top muestra todos los procesos, la cantidad de recursos CPU y RAM consumidos en porcentaje, el tiempo de actividad, la prioridad del proceso y en tiempo realy
cpwd_admin list Check Point WatchDog Daemon, que muestra todos los módulos del appliance, su PID, estado y cantidad de ejecuciones
cpstat -f cpu os uso de CPU, su número y distribución del tiempo de procesador en porcentajes
cpstat -f memory os uso de RAM virtual, cuánto hay de activa, RAM libre y otros datos
Un comentario acertado es que todos los comandos cpstat se pueden ver con la herramienta cpview. Para ello, simplemente hay que ingresar el comando cpview desde cualquier modo en una sesión SSH.
ps auxwf lista larga de todos los procesos, sus ID, la memoria virtual ocupada y la memoria en RAM, CPU
Otra variación del comando:
ps -aF mostrará el proceso más intensivo
fw ctl affinity -l -a distribución de núcleos entre las diferentes instancias del firewall, es decir, tecnología CoreXL
fw ctl pstat análisis de RAM y estadísticas generales de conexiones, cookies, NAT
free -m memoria caché
Es importante destacar el comando netsat y sus variaciones. Por ejemplo, netstat -i puede ayudar a resolver la tarea de monitoreo de buffers. El parámetro RX dropped packets (RX-DRP) en la salida de este comando suele aumentar por sí solo debido a drops de protocolos ilegítimos (IPv6, Bad / Unintended VLAN tags y otros). Sin embargo, si los drops ocurren por otra razón, se debe consultar esta , para comenzar una investigación y entender por qué esta interfaz de red está descartando paquetes. Al identificar la causa, también se puede optimizar el funcionamiento del appliance.
Si el blade Monitoring está habilitado, se pueden ver estos indicadores gráficamente en SmartConsole, al hacer clic en el objeto y seleccionar la opción «Información del Dispositivo & Licencia».
No se recomienda habilitar el blade Monitoring de forma permanente, pero para pruebas durante un día es completamente aceptable.
Además, se pueden agregar más parámetros para el monitoreo, uno de los más útiles es Bytes Throughput (capacidad de procesamiento del appliance).
Si hay algún otro sistema de monitoreo, por ejemplo, uno gratuito , basado en SNMP, también servirá para identificar esos problemas.
2. "Fuga" de RAM con el tiempo
A menudo surge la pregunta de que, con el tiempo, el gateway o el servidor de gestión comienzan a consumir cada vez más RAM. Quiero tranquilizar: esto es normal en sistemas similares a Linux.
Al observar la salida de los comandos free -m y cpstat -f memory os en el appliance desde el modo experto, se pueden contar y observar todos los parámetros relacionados con la RAM.
En realidad, la memoria disponible en el gateway en este momento Memoria libre + Memoria de buffers + Memoria cacheada = +-1.5 Gb, por lo general.
Como dice el S.R., con el tiempo el gateway/servidor de gestión se optimiza y usa cada vez más memoria, alcanzando aproximadamente el 80% de uso, y se detiene. Puede reiniciar el dispositivo y entonces el indicador se restablecerá. 1.5 Gb de RAM libre es más que suficiente para ejecutar todas las tareas, y el servidor de gestión rara vez llega a esos valores máximos.
Además, las salidas de los comandos mencionados mostrarán cuánto tiene Baja memoria (memoria RAM en espacio de usuario) y Alta memoria (memoria RAM en espacio del kernel) utilizada.
Los procesos del kernel (incluidos los módulos activos, como los módulos del kernel de Check Point) solo utilizan memoria baja. Sin embargo, los procesos de usuario pueden utilizar tanto memoria baja como alta. Además, la memoria baja es aproximadamente Memoria total.
Solo se debe preocuparse si en los registros aparecen errores "módulos reiniciados o procesos siendo asesinados para recuperar memoria debido a OOM (Fuera de memoria)". Entonces se debe reiniciar el gateway y contactar con soporte, si el reinicio no ayuda.
Una descripción completa se puede encontrar en y .
3. Optimización
A continuación se presentan preguntas y respuestas sobre la optimización de CPU y RAM. Es importante que se responda honestamente y escuche las recomendaciones.
3.1. ¿Se eligió correctamente el appliance? ¿Hubo un proyecto piloto?
A pesar de un dimensionamiento adecuado, la red podría haber crecido y este hardware simplemente no puede soportar la carga. La segunda opción es que, efectivamente, no hubo dimensionamiento.
3.2. ¿Está habilitada la inspección HTTPS? Si es así, ¿está configurada de acuerdo con las mejores prácticas?
Consulte el , si usted es nuestro cliente, o el .
El orden de las reglas en la política de inspección HTTPS es muy importante para la optimización de la apertura de sitios HTTPS.
Orden recomendado de las reglas:
- Reglas de bypass con categorías/URL
- Reglas de inspección con categorías/URL
- Reglas de inspección para todas las demás categorías
De manera similar a la política de cortafuegos, Check Point busca coincidencias en los paquetes de arriba hacia abajo, por lo que es mejor ubicar las reglas de bypass en la parte superior, ya que el gateway no gastará recursos procesando todas las reglas si se debe omitir este paquete.
3.3 ¿Se utilizan objetos de rango de direcciones?
Los objetos con rango de direcciones, por ejemplo, la red 192.168.0.0-192.168.5.0, consumen significativamente más RAM que 5 objetos de red. En general, se considera una buena práctica eliminar objetos no utilizados en SmartConsole, ya que cada vez que se aplica una política, el gateway y el servidor de gestión gastan recursos y, lo que es más importante, tiempo en verificar y aplicar la política.
3.4. ¿Cómo está configurada la política de Prevención de Amenazas?
En primer lugar, Check Point recomienda colocar IPS en un perfil separado y crear reglas específicas para este blade.
Por ejemplo, el administrador considera que es necesario proteger el segmento DMZ únicamente con IPS. Por lo tanto, para que el gateway no gaste recursos procesando paquetes con otros blades, es necesario crear una regla específicamente para este segmento con un perfil que incluya solo IPS.
En cuanto a la configuración de perfiles, se recomienda configurarlo siguiendo las mejores prácticas de este (páginas 17-20).
3.5. En la configuración de IPS, ¿cuántas firmas están en modo Detect?
Se recomienda trabajar intensamente en las firmas en el sentido de que se deben desactivar las no utilizadas (por ejemplo, las firmas para la explotación de productos de Adobe requieren mucha potencia de cálculo, y si el cliente no tiene tales productos, tiene sentido desactivarlas). Luego, establecer Prevent en lugar de Detect donde sea posible, porque el gateway gasta recursos en procesar toda la conexión en modo Detect; en modo Prevent, descarta inmediatamente la conexión y no gasta recursos en el procesamiento completo del paquete.
3.6. ¿Qué archivos son procesados por los blades de Emulación de Amenazas, Extracción de Amenazas, Anti-Virus?
No tiene sentido emular y analizar archivos de extensión que sus usuarios no descargan, o que usted considera innecesarios en su red (por ejemplo, los archivos bat, exe se pueden bloquear fácilmente con el blade de Content Awareness a nivel de firewall, por lo que los recursos del gateway se utilizarán de manera más eficiente). Además, en la configuración de Threat Emulation, se puede elegir el Environment (sistema operativo) para emular amenazas en la sandbox, y establecer el Environment Windows 7 cuando todos los usuarios están en la versión 10 tampoco tiene sentido.
3.7. ¿Están las reglas del firewall y las reglas de nivel de aplicación en línea con las mejores prácticas?
Si una regla tiene muchas coincidencias, se recomienda colocarla en la parte superior, mientras que las reglas con pocas coincidencias deben ir en la parte inferior. Lo principal es asegurarse de que no se crucen ni se superpongan. La arquitectura recomendada de la política del firewall es:
Explicaciones:
First Rules — aquí se colocan las reglas con la mayor cantidad de coincidencias
Noise Rule — regla para descartar tráfico parásito, como NetBIOS
Stealth Rule — prohibición de accesos a gateways y administraciones para todos, excepto aquellos orígenes que se indicaron en las reglas de Authentication to Gateway Rules
Clean-Up, Last y Drop Rules, generalmente se combinan en una sola regla para prohibir todo lo que no se permitió previamente
Estos Best practices se describen en .
3.8. ¿Qué configuraciones tienen los servicios creados por los administradores?
Por ejemplo, se crea algún servicio TCP en un puerto específico, y tiene sentido en las configuraciones avanzadas del servicio desmarcar la opción “Match for Any”. En este caso, el servicio se ajustará específicamente a la regla en la que aparece, y no participará en las reglas donde está en la columna Services 'Any'.
Hablando de servicios, es importante mencionar que a veces es necesario ajustar los timeouts. Esta configuración permitirá utilizar mejor los recursos del gateway, para no mantener sesiones TCP/UDP de protocolos que no requieren un timeout largo. Por ejemplo, en la captura de pantalla a continuación, reduje el timeout del servicio domain-udp de 40 segundos a 30 segundos.
3.9. ¿Se está usando SecureXL y cuál es el porcentaje de aceleración?
Se puede verificar la calidad del funcionamiento de SecureXL con los principales comandos en modo experto en el gateway. fwaccel stat y fw accel stats -s. Luego, es necesario investigar qué tráfico se está acelerando, qué templates se pueden crear adicionalmente.
Por defecto, las Plantillas Drop no están habilitadas, habilitarlas beneficiará el funcionamiento de SecureXL. Para ello, acceda a la configuración del gateway y a la pestaña Optimizations:
Además, al trabajar con un clúster, para optimizar la CPU, se puede desactivar la sincronización de servicios no críticos, como UDP DNS, ICMP y otros. Para esto, es necesario ingresar en la configuración del servicio → Avanzado → Sincronizar conexiones de State Synchronization en el clúster.
Todas las Mejores Prácticas están descritas en .
3.10. ¿Cómo se utiliza CoreXL?
La tecnología CoreXL, que permite usar múltiples CPU para instancias de firewall (módulos de firewall), definitivamente ayuda a optimizar el funcionamiento del dispositivo. Primero, el comando fw ctl affinity -l -a mostrará las instancias de firewall utilizadas y los procesadores asignados para las necesidades de SND (el módulo que distribuye el tráfico a las entidades del firewall). Si no se utilizan todos los procesadores, se pueden añadir con el comando cpconfig en el gateway.
Otra buena opción es instalar para habilitar Multi-Queue. Multi-Queue resuelve el problema cuando el procesador con SND se utiliza en muchos porcentajes, mientras que las instancias de firewall en otros procesadores están inactivas. Entonces, SND tendría la oportunidad de crear múltiples colas para una NIC y establecer diferentes prioridades para el tráfico en el nivel del núcleo. Por lo tanto, los núcleos de CPU serán utilizados de manera más eficiente. Las metodologías también están descritas en .
En conclusión, me gustaría decir que este no es el único conjunto de Mejores Prácticas para optimizar el funcionamiento de Check Point, pero sí las más populares. Si desea solicitar una auditoría de su política de seguridad o resolver un problema relacionado con Check Point, no dude en contactar a sales@tssolution.ru.
¡Gracias por su atención!
Fuente: habr.com
