(Continuamos hoy con la entrada de ayer, sobre la importancia de las pruebas de restauración en dispositivos de red)
Backup del sistema
Según nuestra política de seguridad, lo habitual es que se realicen copias de seguridad periódicas de los sistemas, incluyendo por supuesto, la electrónica de red, de forma que, ante una caída, sea posible restaurar el sistema en el mínimo tiempo posible para garantizar el menor impacto a la organización. El proceso de backup del sistema depende del operativo sobre el cual hemos instalado Firewall-1, no obstante, a través de la variable de entorno FWDIR, es posible acceder al directorio donde el sistema esta instalado, siendo <systemroot>\fw1 en sistemas Windows y /opt/CPfw1-65 (dependiendo de la versión) en sistemas Unix/Linux.
Aunque la política de seguridad corporativa especifique que se deben realizar copias periódicas de los elementos de red, es posible que éstas no se realicen correctamente, por lo que, ante un problema con los equipos, el impacto sería crítico para la organización.
Para nuestro ejemplo de recuperación en caso de desastre, vamos a basarnos en una arquitectura distribuida de Firewall-1. Al tener una instalación distribuida, los Enforcement Modules mantienen la última política de seguridad instalada (actualizada), sin embargo, el SmartCenter Server tiene una política obsoleta y todas nuestras copias de seguridad del propio SmartCenter Server están corruptas.
Una vez asumimos que solo tenemos las reglas actualizadas en el propio Enforcement Module, debemos intentar recuperar la mayor información posible sobre la política de reglas instalada. Para ello, debemos procurar recuperar los ficheros de objetos y reglas instalados en el Enforcement Module e intentar restaurarlos en el SmartCenter Server. Para ello llevar a cabo dicha tarea, debemos tener presentes los siguientes ficheros del Enforcement Module:
- objects.C: fichero que contiene la definición de objetos (hosts, redes, servicios). Se genera a partir del fichero de objetos objects_5_0.C del SmartCenter Server.
- Rules.C: fichero que contiene las reglas de la política de seguridad y resto de políticas del sistema. Se genera a partir del fichero rulebases_5_0.fws del SmartCenter Server.
Checkpoint nos da la posibilidad a través de la utilidad dbedit (o GUIdbedit si deseamos entorno gráfico) de acceder a la base de datos interna del SmartCenter Server, a partir de cual el sistema crea los ficheros objects_5_0.C y rulebases_5_0.fws, siendo posible crear nuevas entradas en la base de datos.
Para llevar a cabo la recuperación del sistema, usaremos la herramienta Object Filler creada por Martin Hoz, con la cual realizaremos dos pasos: primero recuperamos los objetos y a continuación, las propias reglas de la política de seguridad.
Recuperación de objetos
Lo primero que necesitamos es copiarnos el fichero de objetos ubicado en el Enforcement Module. Para ello, nos conectamos al sistema y copiamos el fichero objects.C
ssh admin@firewall-1 This system is for authorized use only.admin@firewall-1 password: Last login: Wed Jun 23 10:52:57 2010 from 192.168.1.1 IPSO 4.2-BUILD069 #1515: 10.27.2007 035617 You have logged into Nokia IPSO Security Appliance. Terminal type? [xterm] firewall-1 [admin]# cd $FWDIR firewall-1 [admin]# cd database firewall-1 [admin]# ls –la objects.C -rw-rw---- 1 root wheel 2726042 Jul 1 08:46 objects.C firewall-1 [admin]# file objects.C objects.C: ASCII text scp objects.C jvillalon@192.168.1.1: jvillalon@192.168.1.1’s password: objects.C 100% |*****************************| 2662 KB 00:00
Una vez recuperamos el fichero, usamos la herramienta odumper del paquete descargado anteriormente, para convertirlo a CSV.
C:\OFiller>odumper.exe -f objects.C -o recovery.csv Unofficial/Unsupported Object Dumper v2.4 - Developed by Martin Hoz (c) 2003-2006 by Check Point Software Technologies, Inc. =============================================== * Processing objects... .............................................................. =============================================== Processed 103992 possible objects and found 1011 valid ones. It took 3.0 seconds on quiet mode. Total successfully processed CP Gateways = 3 Total successfully processed Check Point Clusters = 1 Total successfully processed Hosts = 575 Total successfully processed Networks = 106 Total successfully processed Groups = -49 Total successfully processed Group Elements = 403 Total successfully processed TCP Services = 279 Total successfully processed UDP Services = 43 Total successfully processed Other Services = 1 =============================================== Task done successfully! - Thank you for using Object Dumper v2.4!
Como podemos ver, la recuperación de los objetos del sistema parece correcta. También podemos hacer un diferencial del fichero recuperado con los objetos ya existentes para comprobar los que no están creados. Una vez tenemos generado el fichero CSV, mediante la herramienta ofiller, convertimos el fichero a código capaz de ser interpretado por la herramienta dbedit de forma que podamos cargarlo directamente en la base de datos del sistema:
C:\OFiller >ofiller.exe -i csv -f recovery.csv -o recdbedit.txt Unofficial/Unsupported Object Filler v2.4 - Developed by Martin Hoz (c) 2003-2006 by Check Point Software Technologies, Inc. ============================================== Processing objects... .............................................................. ============================================== It took 3.0 seconds of total processing time on QUIET Mode. Processed 2102 possible objects and/or rules. Found 1050 total valid (or successfully processed) objects/rules. ----------------------------------------------------------- Total successfully processed CP Gateways = 3 Total successfully processed Hosts = 573 Total successfully processed Networks = 102 Total successfully processed Groups = 53 Total successfully processed Group Elements = 396 Total successfully processed TCP Service objects = 273 Total successfully processed UDP Service objects = 43 ---------------------------------------------------------------------- Please review that all DBedit output commands were written correctly. Please remember DBedit commands are imported into SmartCenter directly. If you wish to review first, the use of CSV mode (-a switch) is suggested. ======================================================= Task done successfully! - Thank you for using Object Filler v2.4!
Finalmente, usamos la propia herramienta dbedit para cargar en la base de datos de Firewall-1 los objetos obtenidos desde el Enforcement Module:
C:\OFiller >dbedit –s firewall-1 –u admin –p password –f recdbedit.txt
Una vez ejecutado el comando anterior, podemos conectarnos al sistema mediante la aplicación SmartDashboard y comprobar la presencia de los nuevos objetos. Llegados a este punto, podríamos comenzar la importación de las reglas de la política de seguridad.
Recuperación de la política
Por defecto, Firewall-1 crea una política de seguridad llamada Standard. Para recuperar el sistema sin modificar la política existente, crearemos una nueva política de seguridad llamada Recovery. La recuperación de la política es algo distinta al proceso anterior, ya que no es posible crear un CSV a partir del fichero importado desde Firewall-1, por lo tanto, nos crearemos nuestros propios scripts para realizarlo. Para ello, lo primero que debemos hacer es obtener el fichero de reglas del Enforcement Module al igual que en el paso anterior:
ssh admin@firewall-1 This system is for authorized use only.admin@firewall-1 password: Last login: Wed Jun 23 10:52:57 2010 from 192.168.1.1 IPSO 4.2-BUILD069 #1515: 10.27.2007 035617 You have logged into Nokia IPSO Security Appliance. Terminal type? [xterm] firewall-1 [admin]# cd $FWDIR firewall-1 [admin]# cd database firewall-1 [admin]# ls –la rules.C -rw-rw---- 1 root wheel 85668 Jul 1 08:46 rules.C firewall-1 [admin]# file rules.C rules.C: ASCII text scp rules.C jvillalon@192.168.1.1: jvillalon@192.168.1.1’s password: rules.C 100% |*****************************| 2662 KB 00:00
A partir del fichero obtenido, el script que hemos creado parseará el fichero de reglas, identificando la acción a realizar, el origen y destino de la conexión y el puerto destino, generando una entrada similar a la siguiente:
<action>accept</action><dst>red_srv</dst><services>http</services><src>proxy</src>
Según la regla anterior, existe una regla en la política de seguridad que permite el tráfico http desde la red de servidores hacia el Proxy corporativo. Una vez tenemos un formato estándar de reglas para cargar, podemos crearnos de nuevo un script que, para cada una de las reglas anteriores, genere un listado de instrucciones capaces de ser interpretadas por la herramienta dbedit, por lo que crearemos la política de seguridad Recovery y asociando las reglas a ella. Por ejemplo, la salida de la regla anterior seria la siguiente:
create policies_collection Recovery modify policies_collections Recovery comments Recovery_jvillalon_2010 update policies_collections Recovery create firewall_policy ##Recovery modify fw_policies ##Recovery collection policies_collections:Recovery addelement fw_policies ##Recovery rule security_rule addelement fw_policies ##Recovery rule:1:src:'' network_objects:red_srv addelement fw_policies ##Recovery rule:1:dst:'' network_objects:proxy addelement fw_policies ##Recovery rule:1:through:'' globals:Any addelement fw_policies ##Recovery rule:1:services:'' services:http addelement fw_policies ##Recovery rule:1:action accept_action:accept rmbyindex fw_policies ##Recovery rule:1:track 0 addelement fw_policies ##Recovery rule:1:track tracks:None addelement fw_policies ##Recovery rule:1:install:'' globals:Any update fw_policies ##Recovery
Como podemos ver, principalmente hemos creado una nueva política llamada Recovery, asignándole como primera regla, la regla descrita anteriormente. Finalmente, al igual que en el proceso de recuperación de los objetos, usamos la herramienta dbedit para cargar en la base de datos de Firewall-1 las nuevas reglas:
C:\OFiller >dbedit –s firewall-1 –u admin –p password –f reglas.txt ##Recovery updated suscesfully. ##Recovery updated suscesfully. …………………………………
Una vez ejecutado, nos podemos conectar por SmartDashboard al sistema y abrir la nueva política de seguridad para comprobar que tenemos las reglas correctamente importadas.
Para finalizar nuestro proceso de recuperación, podemos ejecutar desde el propio SmartCenter Server una verificación de la consistencia de la política de seguridad y en caso de no obtener ningún error, proceder a aplicarla.
Una vez concluida nuestra recuperación del sistema y tras comprobar que todo funciona correctamente, nuestra tarea no ha finalizado. Es en este momento de calma cuando debemos llevar a cabo algunas acciones para evitar la situación en un futuro. Dichas acciones van desde la documentación de todo el proceso de restaurado realizado hasta la revisión de la política de copias de seguridad para indicar que se deben realizar copias de la electrónica de red (si no estaba incluida ya), y en la medida de lo posible, realizar pruebas de restauración de dichos sistemas (por ejemplo, disponiendo de hardware de backup en stock para este tipo de situaciones). Una vez que todo lo anterior este funcionando correctamente, podremos dormir algo más tranquilos. Pasen un buen fin de semana.
