Posts etiquetados ‘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

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!

Si miramos las características técnicas de los appliances (que no quiere decir nada más que cacharro grandote que está especializado en hacer de firewall) de Checkpoint UTM-1 vemos que las interfaces tienen 3 modos de velocidad 10|100|1000 full|half duplex. Cuando intentamos forzar una de las conexiones a 1000 full duplex ¡Oh sorpresa! ¡La opción no aparece vía GUI!

Conexiones de red UTM-1, velocidad

Bueno, no nos pongamos nerviosos. Aun podemos configurarlo por consola. Abres la consola:

# Expert
# ethtool -s ethX speed 1000 duplex full autoneg off

Donde ethX es la interfaz que queremos forzar. Pero esto tampoco dá resultado. Y te preguntas ¿Porqué? Pues muy sencillo, la culpa la tiene el IEEE. Sí, sí, no pongais esa cara.

Según el IEEE las conexiones a un Giga no se pueden forzar, sino que deben ser autonegociadas. Checkpoint que es muy cumplidor con la ley, sigue la normativa para IEEE en este caso, por lo que, no permite entre sus opciones esta configuración no estándar. Ni vía GUI ni via consola.

Pero, ¡yo quiero mi conexión a 1000 full duplex! ¿No hay nada que pueda hacer? Pues sí, tienes dos opciones. Conectar el UTM-1 con un equipo que realice correctamente la negociación a 1000 full duplex o usar el pequeño truco que nos explican en el sk31502 :

Entramos de nuevo en modo consola, en expert. El comando es:

#eth_set ethX 1000f

Este comando no sigue el estandar IEEE por lo que permite realizar el cambio. Sencillo ¿verdad?

Hasta la próxima que espero que sea el prometido post sobre Checkpoint.

VPN site to site en Checkpoint con NAT

Publicado: 03/12/2010 en Manual
Etiquetas:,

Esta semana hemos tenido que ayudar con una VPN site to site entre un Checkpoint y un Cisco ASA. Ha sido interesante ya que la forma en que Checkpoint configura las VPN site to site, es ligeramente distinta de la mayoría de los firewalls.

En checkpoint el dominio de encriptación (o las redes internas entre las que se establecen los túneles) de fase 2 se define a través de algo llamado communities que codicionan la selección de los paquetes que se envían a través del túnel, como veremos más adelante.

El esquema del caso es:

Se ha de establecer el tunel entre las redes LAN A y LAN B con el problema añadido de que la red 192.168.1.0/24 se encuentra en uso en la red del Peer B ya que es parte de la LAN C a la cual se accede desde LAN B a través del Checkpoint. Para solucionar el tema de solapamiento entre la LAN A y la LAN C se establece un NAT en Checkpoint enmascarando la LAN A con la red 192.168.3.0/24 que no se encuentra en uso en la red del Peer B.

La configuración del tunel en el Checkpoint quedó establecida así:

Configuracion del tunel:

Community: PeerA-B.

Nodos:

1) Nodo Peer A:

– IP Pública: 80.27.22.11

– Dominio de encriptación: 192.168.1.0/24

1) Nodo Peer B:

– IP Pública: 90.27.22.22

– Dominio de encriptación: 192.168.2.0/24

Regla de Acceso

LAN A                           LAN A

NATEO LAN A —> NATEO LAN A —> Todos los servicios —> Aceptar

LAN B                           LAN B

Configuración de NAT

IPorig                          IPdst                   TraduccOrig                TraduccionDst

192.168.1.0/24           any                       192.168.3.0/24                            =

any                             192.168.3.0/24                =                                  192.168.1.0/24

Con esta configuración, el tunel levanta si la comunicación es iniciada por  el Peer A  y los paquetes pasan encriptados a través del tunel tanto para el tráfico desde A a B como desde B a A.  El problema es que si la comunicación es iniciada por B, el túnel no levanta y los paquetes son enviados hacia la LAN C, tal y como indica la tabla de rutas de Checkpoint.

Al mirar los logs en tracker pordíamos observar entradas que aceptaban el tráfico entre los dos extremos del tunel:

192.168.2.x  —>  192.168.3.y —> UDP_200 —> ACCEPT

También podíamos observar en estos logs que el NAT se estaba realizando correctamente por lo que la comunicación, con la traduccion de direcciones quedaba:

192.168.2.x  —>  192.168.3.y (Xlatedst: 192.168.1.y) —> UDP_200 —> ACCEPT

Al mirar los logs de  la pestaña VPN, no aparecía  ninguna entrada perteneciente al tunel, lo que indica que no trata de levantar el túnel porque no considera este tráfico VPN.

Se inició la comunicación desde el Peer A para que el túnel mantuviese levantada la fase 1 y se realizaron pruebas de acceso desde el Peer B (iniciando este la comunicación) hacia el Peer A. En los logs de VPN apareció una entrada como:

Number:                                   718105
Date:                                        4Mar2010
Time:                                        18:08:05
Product:                                   VPN-1 Power/UTM
VPN Feature:                            IKE
Interface:                                  daemon
Origin:                                      CHECKPOINT
Type:                                        Log
Action:                                      Key Install
Source:                                    CISCO_ASA
Destination:                             CHECKPOINT
Encryption Scheme:                IKE
VPN Peer Gateway:                CISCO_ASA
IKE Phase2 Message ID:        14b7d641
Community:                             Peer A-B
Subproduct:                             VPN
Information:                             IKE: Quick Mode Received Notification from Peer: invalid id information
El mensaje “Invalid id Information” en el establecimiento de la fase 2 indica que existe algún error en las redes configuradas en el dominio de encriptación ya que no coinciden con los datos de los que dispone el peer remoto. Este mensaje fue la pista definitiva para dar con la solución. Había algo incorrecto en el dominio de encriptación remoto.

Para que  funcionen las VPNs de Checkpoint con NAT, hay que incluir la red del NAT en objeto que representa al PeerA en la comunity que define la VPN en checkpoint.

1) Nodo Peer A:

– IP Pública: 80.27.22.11

– Dominio de encriptación: 192.168.1.0/24; 192.168.3.0/24.

Al instalar políticas con este cambio, el checkpoint considera los accesos

192.168.2.x  —>  192.168.3.y (Xlatedst: 192.168.1.y) —> UDP_200 —> ACCEPT

como accesos de VPN y hace que los paquetes vayan por el túnel estableciendose correctamente la comunicación. Ahora aparecen entradas en la pestaña VPN del tracker que indica que el tráfico está pasando por él.

Espero que este post sea de utilidad a alguien. Más adelante escribiré algún post con el procedimiento general para configurar una VPN con Checkpoint.