Archivos de la categoría ‘Checkpoint’

Esta semana ha saltado la alerta debido a la vulnerabilidad CVE-2014-0160 más conocida como HeartBleed que abre un enorme agujero para el acceso a passwords, claves de encriptado… en OpenSSL.

Si has llegado hasta aquí y no tienes ni idea de qué es heartbleed, tal vez quieras leer esto: http://heartbleed.com/ y después cambiar tus passwords de sitios importantes (como el banco).

Para Checkpoint, el único producto afectado es Check Point Mobile VPN for iOS & Android. Para el resto podéis estar tranquilos. https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk100173

Si tenéis un ArcSight y estáis preocupados por su seguridad, dejad de hacerlo. La librería utilizada por los ArcSight en el mercado es openssl (version 0.9.8r) que no se encuentra afectada por la vulnerabilidad.

F5 parece tener algunos productos vulnerables a Heartbleed. El hilo de recomendaciones para su resolución es:  http://support.f5.com/kb/en-us/solutions/public/15000/100/sol15159.html

Algunos fabricantes que manejo (como Fortinet, Bluecoat o Microsoft) no han dicho “oficialmente” nada pero no parecen afectados.

Una lista no oficial de fabricantes afectados, la encontraréis aquí: http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=720951&SearchOrder=4

Si tienes un servidor SSL y quieres saber si estás afectado por el problema, puedes probar aquí: http://filippo.io/Heartbleed

Espero que os sirva de algo!

Saludillos!

 

UPDATE: Parece ser que FORTINET si que tiene productos afectados. La lista de productos y la solución, las podéis encontrar:  http://www.fortiguard.com/advisory/FG-IR-14-011/

Anuncios

Hoy, de hecho ahora mismo, he tenido que realizar la actualización de un cluster de cortafuegos UTM-1 que se encuentra configurado en full ha (o full hihg avaiability) desde su versión R70 a R75. De hecho la versión final es la R75.20 pero no es posible realizarla directamente y hay que dar el paso intermedio a la R75.

Como está siendo un infierno, os describo a continuación los pasos que deben darse, los problemas encontrados y su resolución.

Tenemos un clúster full ha con dos nodos. Fw1 es el nodo activo tanto de firewall como de management y es el que tiene una mayor prioridad y Fw2 es el nodo pasivo de ambos elementos que asumirá los roles sólo en caso de fallo del nodo principal.

Backup de los elementos:

Lo primero que debemos hacer es un backup completo de ambos nodos, así como de la base de datos de políticas en un equipo externo a los mismos. Así, nos curamos en salud y nos ahorramos disgustos.

1)      Backup de la configuración del equipo a través de la administración web de secureplatform. Esto nos guarda los datos básicos de red del equipo. Aseguraos de tener cerradas todas las GUIs de Smartdashboard o fallará.

2)      Exportado de la política en versión R70 – > #$FWDIR/bin/upgrade_tools/upgrade_export <nombredelfichero>

3)      Exportado de la política en versión R75

  • Para ello, descargamos las migration tools correspondientes a R75 del usercenter y las subimos al appliance principal (bien por SCP bien por FTP) a una carpeta temporal. “/var/tmp” es un buen punto.
  • Damos permiso de ejecución a las migration tools: #chmod a+x *
  • Generamos el fichero de políticas: #migrate export <nombrefichero>

Aseguraos de descargar las políticas generadas bien por FTP, bien por SCP.

4)      Ejecutad el verificador de actualización para comprobar que no existen errores a corregir. Este se encuentra en las migration tools. Si da un error, corregidlo antes de empezar.

Bien, hasta ahora, nada fuera de lo normal de cualquier actualización.

Actualización:

Los pasos son:

1)      Realizar un failover del tráfico al nodo secundario:

#cphaprob -d STOP -s problem -t 0 register

Para dar marcha atrás (por si fuera necesario)

# cphaprob -d STOP unregister

Nota: este paso supone un microcorte

2)      Entrar con Smartdashboard en el management secundario. Al entrar nos dirá que el nodo activo es fw1 y que si queremos cambiarlo. Hacemos que el management secundario sea el activo.

3)      Actualizamos el nodo principal, cargando el correspondiente paquete a través de la interfaz de administración web del nodo fw1. Ojo, en este paso, es recomendable realizar un snapshot y una actualización segura. Es más lento pero nos salvaguardará de errores en la actualización, asegurando la marcha atrás.

4)      Accedemos con la consola de dashboard de R75 al nodo fw1. Colocamos el objeto de clúster a versión R75 e instalamos políticas. Recordad desmarcar la opción de “For firewall cluster install on all members” o fallará.

5)      Actualizamos vía web el nodo fw2 con la imagen correspondiente. Al ejecutar un cpstop para actualizar, el tráfico pasará al nodo fw1 con un microcorte.

6)      Una vez sincronizado, abrimos smartdashboard en fw1. Instalamos políticas en ambos nodos.

7)      Abrimos Policy > Management high Availability y pulsamos el botón sincronizar.

Parece fácil y sencillo ¿verdad? Pues nada más lejos de la realidad.

Problemas, problemas, problemas.

Justo después de sincronizar, si refrescamos el estado de ambos cortafuegos, aparece el nodo fw2 como unreachable. Si tratas de comprobar la SIC de este nodo, se indica lo siguiente:

“SIC Status for : Not Communicating Authentication error [error no. 147] ** Check that peer SIC is configured properly and that system date and time on the SmartCenter Server and peer are synchronized.

Tratamos de resetar la SIC de este nodo pero no hay cambios, no se puede conectar.

Si cerramos el smartdashboard, no podremos conectar de nuevo con fw1 apareciendo un error:

“Connection cannot be initiated make sure the server “xx.xx.xx.xx” is up and running and you are defined as a GUI Client”

Si realizamos: # ps aux | grep cpca  el resultado aparecerá como cpca – readonly

Lo que ocurre es que durante la actualización se ha perdido un certificado de CA en el nodo principal fw1 y es por esto por el que no podemos conectar al smartdashboard o al otro nodo.

Para corregirlo ejecutamos en el nodo fw1:

#cd $CPDIR/conf

# cp sic_cert.p12 sic_cert.p12old

#cpca_client revoke_cert -n “CN=cp_mgmt”

#cpca_client create_cert -n “CN=cp_mgmt” -f $CPDIR/conf/sic_cert.p12

#cpstop

#cstart

Esto regenera los certificados y nos permitevolver a conectar al smartdashboard. OJO: ESTO PROVOCA CORTE TOTAL ya que paramos los servicios del nodo que gestiona el tráfico y el cluster no está montado.

Pero, ¿Qué pasa con el nodo secundario? Pues que aún no lo hemos conectado. Para ello:

Ejecutamos en ambos nodos #fw unloadlocal esto vuelve a PROVOCAR CORTE TOTAL  pero es necesario dado que las políticas no nos permiten conectar ambos nodos del cluster puesto que en este momento fw2 no forma parte del cluster. Reestablecemos la SIC e instalamos políticas. En este punto el firewall está operativo.

Sólo nos queda sincronizar ambos management, pero el del nodo 2 no se deja. Pese a que la SIC está establecida y funcionando, la sincronización de managements nos dice que el fw2 está unreachable. Para corregir esto:

#cpstop

#cd $FWDIR/conf/mgha

# rm ./*

#cd ..

#rm applications.C* CPMIL*

#cpstart

Ahora podemos realizar la sincronización y todo vuelve a la normalidad. Ya sólo queda la actualización a R75.20. Que cthulhu nos coja confesados.

Saludillos

Pese a que tengo pendiente un extenso artículo con todo lo que he aprendido de clústeres Load Balancing en modo multicast de Checkpoint, os dejo un pequeño apunte para ir abriendo boca.

Si tenéis un clúster Load balancing (es decir, activo/activo)en modo multicast en checkpoint es posible que tengais que configurar las rutas ARP de forma estática en los switches para la MAC de multicast de las interfaces del clúster (sobre todo si los switches son Cisco). Para saber cuales son estas MAC, podéis utilizar la siguiente fórmula:

En una red con un clúster cuya IP de clúster es x.y.z.w:

  • Si y<=127, La MAC de multicast será:  01:00:5e:y:z:w. Por ejemplo si la IP es 192.90.10.100 la MAC será 01:00:5e:5A:0A:64
  • Si y>127, La MAC de multicast será 01:00:5e:(y-128):z:w.  Por ejemplo si la IP es 192.168.10.100 La MAC será: 01:00:5e:28:0A:64(168-128=40 = 28 en hexadecimal) .
  • Para una red  x.y.z.0 sin IP de clúster,como la de sincronización, se usa el mismo procedimiento sustituyendo el último octeto por fa. Por ejemplo para la red 10.0.0.X la MAC será:  01:00:5e:00:00:fa

Espero que os sirva.

Hace unos días, al revisar el estado de los managements por un problema de instalación de políticas, me dí cuenta que el estado del management secundario de CheckPoint para la alta disponibilidad de las políticas era “Lagging” en lugar de “Synchronized”.

Vale. Stop. Para los que no tengan ni papa de lo que va esto una breve introducción:

Los managements (o gestores de políticas) de Checkpoint puede configurarse en alta disponibilidad. Esto es, que se dispone de un management principal que gestiona las políticas y uno secundario en standby que dispone de una copia actualizada de las políticas, listo para entrar en acción en caso de desastre. Se puede comprobar el estado de la sincronización desde el dashboard Policy > Management High Availability.

Aquí se abre una ventana que nos muestra al management principal como activo y una ventana con el estado del secundario. En esta ventana se nos indica si hay conectividad con este management (Reachable), si está en standby y el estado de la sincronización.

Los posibles estados son:

Never been synchronized – Justo después de instalar cuando aún no se ha sometido a la primera sincronización manual.

Synchronized – está bien sincronizado y tiene la misma información de bases de datos y política de seguridad instalada.

Advanced – la base de datos del management en standby tiene datos más actuales que la del management activo. Esto indica que una de las bases de datos debe ser sobreescrita.

Lagging – El secundario está preparado para sincronizar pero no se ha realizado la misma.

Collision – Hay distintos datos de políticas y de bases de datos en ambos servidores, se deben sincronizar manualmente con la información correcta.

Para realizar la sincronización manual, sólo tenemos que pulsar el botoncito de la parte interior que pone “synchronize”.

Bueno, ¿aclarado? Aclarado.

Como iba diciendo, el estado de mi servidor era “Lagging” lo cual, no es un estado muy bueno ya que, aunque no indica errores graves, significa que el secundario no tiene toda la información necesaria para funcionar. Lo primero que hice fué comprobar la conectividad (ping desde el management principal as secundario) y la sic (objeto del management secundario > Test SIC status) y todo estaba OK.

Lo siguiente fué comprobar la hora y la fecha de ambos servidores, ya que una diferencia entre ellos, es la causa más común de los errores de sincronización. Todo correcto por esta parte, así que procedo a darle al botoncito de sincronizar, pensando que se va a solucionar fácilmente.

Nada más lejos de la realidad. Tras un buen rato pensando, aparece un precioso cartel de error que dice ” Failed to Synchronize: Failed to update internal CA-DB” del management secundario.

Tras un poco de investigación de fondo y de buceo en la KB de Checkpoint, se obtienen dos procedimientos:

Procedimiento 1

En ambos managements al mismo tiempo ejecutar:

# cpstop
# cd $FWDIR/conf
# rm CPMIL*
# rm applications*
# cd mgha/
# rm *
# cpstart

Tras esto, se entra en el dashboard de management principal (a veces falla después de la actuación, así que sigue las recomendaciones del autoestopista galáctico y Don’t Panic! ) y sincroniza manualmente.

A mi este procedimiento me ha funcionado a las mil maravillas. Pero por si no va, aquí va otro:

Procedimiento 2

1. Para el management principal y borra los journals: # rm $FWDIR/conf/mgha/*

2. En el management secundario, haz un backup y borra:
InternalCa.p12
InternalCa.NDB*
InternalCa.crl
ICA.crl

3. Inicia los servidores y sincroniza manualmente.

Y eso es todo. ¡Espero que os sirva de ayuda!

¡Fantasmas! Who you gonna call? Ghostbusters!

Bueno, no hay que ser tan drásticos. En este caso nos encontramos con que tras eliminar un objeto de clúster en el SmartDashboard, uno de los nodos ha quedado como “fantasma”. Si tratamos de crear un nuevo objeto con esa IP, DahsBoard nos indica que está en uso, si hacemos una búsqueda nos aparece y está en la lista de nodos de SmartMonitor y SmartUpdate. Al tratar de borrarlo desde la ventana de búsqueda o desde Monitor o Update, nos sale un cartelito indicando que el objeto está en uso (cosa desmentida por el botón “where used”) y no nos permite borrarlo. ¡Vaya! Tenemos un poltergeist persistente.

Estás almas errantes que habitan en la base de datos de gestión, se quedan atrapadas sin poder pasar al otro lado, debido a que se ha realizado un borrado del objeto de cúster al que pertenecían sin realizar un detach de las licencias asociadas primero. Para exorcizar estos casos y ayudarlos a encontrar la paz, tenémos tres métodos:

Método 1:

1. Realizar un “Install Database”
2. Reiniciar smartview monitor y smartupdate.

Este método acaba con los más débiles, pero funciona en pocos casos. La ventaja es que es sencillo e inouo.

Método 2:

1. Dashboard -> Manage -> Network objects.
2. Si está visible, tratar de borrarlo desde ahí.

Lo más probable es que, al igual que desde la pantalla de búsqueda no nos permita borrarlo.

Método 3:

Este funciona siempre pero es el más delicado. No olvideis realizar estas técnicas bajo la supervisión de un exorcista profesional, niños y NUNCA lo realiceis sin tener un backup de la configuracion del management. (Upgrade_export del que prometo hablar pronto.)

1. Realizar un backup de $FWDIR/conf/ del management principal.
2. Ejecutar guidbedit.exe que está en: C:\Program Files (x86)\CheckPoint\SmartConsole\R70.30\PROGRAM (En mi windows 7 pero la ruta es básicamente la misma)
3. Buscar el objeto en Network objects y borrarlo. El cambio se aplica automáticamente.

Con esto os habreis librado de los fantasmas y sin gastar dinero en profesionales con mochilas de protones.

¡Hasta la próxima!

Buenas,

una minientrada para un truco en Secure platform. Para poder transferir ficheros vía SCP el procedimiento es:

1. Entrar por consola en modo experto
2. adduser
3. Meter un password válido.
4. vi /etc/passwd
5. Modificar la línea de usuario cambiando el final (cpshell por bash) ejemplo: “scp_user:x:0:0::/home/winscp:/bin/cpshell” a “scp_user:x:0:0::/home/winscp:/bin/bash”
6. Guardar :wq
7. Service sshd restart

Si con esto aún no se puede acceder con scp, es necesario realizar lo siguiente:

1. Vi /etc/scpusers
2. Añadir una línea con el username anterior
3. Service sshd restart

Estos pasos no se pueden realizar con el usuario root ya que no puede comenzar una sesión ssh directamente ( está capado por el sistema operativo)

¡¡Saludillos!!

Los equipos UTM-1 de Checkpoint son una grán elección como cortafuegos de empresas de mediano tamaño ya que, además de un magnifico rendimiento, su licencia incluye la licencia de managent en modo StandAlone. Son una gran opción cuando se  desea actualizar una infraestructura de cortafuegos obsoleta o que ya no cumple los requerimientos.

Pero, ¿Qué ocurre cuando queremos migrar de un entorno distribuído con un sólo management a uno en Standalone con un clúster? En teoría, este cambio es muy sencillo, aunque como siempre ocurre, en la vida real no es asi.

Pongámonos en situación: Tenemos un antiguo entorno formado por un clúster de cortafuegos (fwcluster) gestionados por un management(mgmt) y queremos migrar a un entorno nuevo formado por un clúster UTM-1  full HA (fwclusterha) con el tiempo mínimo de indisponibilidad.

Pero seño: ¿Qué es un clúster UTM-1 Full HA? Pues es un clúster de conmutación por error, en el que los equipos hacen las veces de clúster de cortafuegos y de clúster de management. Es decir, tenemos dos clúster en uno: el clúster de cortafuegos y el clúster de management principal y secundario alojados en la misma máquina.

Si buscamos un poco como realizar la migración, encontramos un “precioso” documento de Checkpoint sk33896: How to migrate a distributed SmartCenter to a UTM-1 Cluster y piensas “¡Estupendo! Tengo la vida solucionada. Un manual paso a paso para la migración”. ERROR. Hay un fallo en el procedimiento y dejo a mis expertos lectores que lo busquen.

Los pasos para realizar la migración son:

1) Realizar un Upgrade_export de las políticas ( si no sabes hacerlo sigue atento al blog que pronto publicaré una entrada sobre eso)
2) Realizar un backup de la configuración de los firewalls antiguos.
3) Transcribir a papel los datos básicos de los cortafuegos (por si todo lo demás falla).
4) Failover del tráfico al nodo secundario. OJO: Este paso tiene un pequeño corte.
5) Desconectar el firewall antiguo y conectar el nuevo UTM-1 (fwnodo1)
6) Instala y configura el nodo UTM-1 nuevo según la configuración deseada con dos puntualizaciones. Elige standalone (no cluster) y Locally managed en la configuración inicial.
7) Habilita SCP y copia el fichero con las políticas. (Esto también se vrá en el próximo post).
8 ) Importa las políticas con Upgrade_import
9) Accede mediante Smartdahboard a la IP del nodo fwnodo1.
10) Comprueba que la política se abre con todos los elementos.
11) Accede a la consola de fwnodo1
12) Ejecuta: cp_conf fullha enable para convertirlo en miembro de un clúster full HA.
13) Reboot de fwnodo1 para que se aplique la configuración.
14) Conecta por Dashboard de nuevo a fwnodo1
15) Sigue el wizard de clúster sin configurar el miembro secundario del clúster.
16) Cambia en la política el objeto de clúster antiguo (fwcluster) por el nuevo (fwclusterha)
17) Elimina el objeto de cluster antiguo fwcluster.
18) Aplica políticas sobre el nodo activo.
19) Haz el failover de tráfico del nodo antiguo a fwnodo1. OJO: Este paso tiene un pequeño corte.
20) Instala y configura el nodo secundario de UTM-1 (fwnodo2) teniendo precaución de conectar el cable de la interfaz de sincronización entre los nodos. Selecciona Locally managed y miembro de cluster.
21) Conecta por dashboard a fwnodo1
22) Sigue el wizar en el objeto de cluster para añadirel secundario.
23) Instala políticas y sincroniza la base de datos (Policy > Management High Availability > Synchronize).

Y ya tenemos un precioso clúster Full HA completamente funcional. Facil ¿Verdad?. Sólo añadir que las licencias de los UTM-1 en este caso no pueden ser centrales. Deben ser locales y asignadas a la IP principal de cada uno de los nodos del clúster.

Y eso es todo por hoy. Intentaré actualizar más a menudo.

Este caso es muy específico y hace referencia a un producto de Checkpoint que está a punto de desaparecer definitivamente. De hecho, actualmente ya no se encuentra soportado por el fabricante, pero me he decidido a escribir este post dado que siempre hay lugares en los que aun mantienen esta versión de firewall.

Para la comunicación VoIP, eran necesarias una serie de reglas en el cortafuegos que permitían el acceso a través del protocolo SIP al servidor destino. Para realizar las pruebas, se habilitó una regla entre origen y destino sin especificar el puerto (any) de la comunicación y asegurar que todo estaba instalado correctamente. Estos paquetes atravesaban sin problemas y la comunicación se establecía correctamente.

Una vez comprobado el correcto funcionamiento de la comunicación se restringió la regla especificacando el puerto SIP predefinido en Checkpoint y se volvió a probar. En este caso la comunicación era rechazada por el cortafuegos. Los mensajes que aparecían en el tracker, indicaban que la macheaba la regla 0 (Implied Rules). Esta regla indica que la comunicación se ha rechazado debido a una de las comprobaciones configuradas en smartdefense. El texto del mensaje era:

” Atack Info: Malformed SIP datagram, Unknown SIP message type dropped by rulebase”

Una primera búsqueda de este error nos indica que el rechazo se produce porque se encuentra activado en Smartdefense el checkeo de cabeceras SIP para VoIP, y checkpoint no reconoce las cabeceras SIP especificas del fabricante de VoIP. Estas cabeceras no son estandard, y la de este fabricante no se encuentra registrada para la versión R55 de Checkpoint por lo que no permite la conexión al considerarla un posible riesgo.

En smartdefense se encuentra la pestaña VoIP, en la que podemos habilitar o deshabilitar el checkeo de cabeceras SIP y probamos a deshabilitar el chequeo e instalar políticas pero el error vuelve a repetirse. Tras un poco de investigación exahustiva hayo la causa del problema. En R55, existen una serie de protocolos predefindos que se pueden configurar en las opciones avanzadas de los servicios. Entre estos protocolos, se encuentra el SIP_UDP que es el que usa el servicio predefinido sip. Al identificar un servicio como usuario de ese protocolo y usar dicho servicio en una regla ( no está incluído en el any) se activa por defecto el chequeo de cabeceras SIP, incluso si este chequeo se encuentra desactivado en smartdefense. Este chequeo además se activa para todas las conexiones SIP aunque correspondan a otra regla.

La solución es la siguiente: se debe crear un nuevo servicio para SIP de tipo UDP para el puerto 5060, cuyo tipo de protocolo sea none. Este servicio es el que se debe usar para todas las reglas que necesiten habilitar acceso a SIP, ya que si en alguna usamos el servicio con el protocolo específico activaremos el chequeo.

Hasta la proxima!