08 septiembre 2011

La nueva política ¿radical? de disclosure de Digital Bond

Digital Bond es una empresa que, si bien dispone de varios tipos de servicios en su portfolio, su investigación en el ámbito de vulnerabilidades en sistemas SCADA/ICS destaca entre el resto, sobretodo en estos últimos años. La empresa ha modificado su política de publicación de información de vulnerabilidades, eliminando puntos y siendo más radicales en su nueva visión, ya que desde el 1 de septiembre de este año: ellos decidirán que hacen con las vulnerabilidades que encuentren, si informar de ellas totalmente, parcialmente, con algunos detalles, con menos...lo que les de la gana. ¿Marketing? Quién sabe...

Las vulnerabilidades en sistemas SCADA bien sabemos que no son como el resto de vulnerabilidades, sobretodo atendiendo a su posible impacto, que a veces podría resultar incluso fatal. Debido a su criticidad, los investigadores de seguridad que han centrado sus últimas actividades en esta línea de trabajo, como por ejemplo Rubén Santamarta de sobra conocido por todos nosotros, siempre han ido con pies de plomo, con máximo respeto hacia el fabricante y con todos sus esfuerzos depositados en llevar a cabo una solución conjunta si es necesario, ya sea colaborando con CERTs o contactando directamente con los afectados. Cada fabricante se toma las vulnerabilidades de formas diversas, y Rubén seguro que nos podría contar mil anécdotas de este tipo, como muchas que ha relatado ya en 48Bits o su blog Reversemode. Algunas se merecerían incluso un Pwnie Award a "respuesta desternillante por parte de un fabricante". 

Sobre el tema de publicación de información o disclosure, podréis volver a echar un ojo tanto a este post como al video del RootedPanel: Full-Disclosure que tuvo lugar en la pasada Rooted CON 2011. Si todavía no habéis tenido oportunidad de verlo, merece la pena escuchar los puntos de vista de todos los integrantes de la mesa.

En el siguiente post de Errata Security (traducido al castellano a continuación), Robert David Graham nos resume a la perfección el estado actual en el que se encuentran muchos investigadores los cuales, la mayoría de las veces que intentan ir con la bondad y responsabilidad por delante, se encuentran con un muro de muchos metros de altura construido por unos fabricantes con mezcla de miedo y en algunos casos, prepotencia.


Digital Bond, que investiga vulnerabilidades SCADA/ICS, ha publicado una de las políticas de vulnerabilidades más responsables: http://www.digitalbond.com/about-us/vulnerability-disclosure-policy/

En resumen, vendría a decir que:
- Respetamos los acuerdos con los clientes.
- Por otra parte, haremos lo que nos da la gana con las vulnerabilidades descubiertas.

Estos últimos años, los investigadores de vulnerabilidades (o los no-investigadores que quieren ser tenidos en cuenta por los investigadores) han intentado proponer maneras de minimizar el daño de lo obtenido tras la investigación de vulnerabilidades, maximizando el bien. No lo han conseguido. En su lugar, han cumplido reglas que únicamente serían de provecho para los fabricantes de los productos vulnerables, que se aferran a la "publicación responsable" para encubrir o retrasar la publicación de la vulnerabilidad. Después de tener al FBI llamando a nuestras puertas amenazándonos en su intento de prevenir la publicación de información sobre vulnerabilidades, se acabó el ser amables con los fabricantes.

Podréis consultar la política de publicación de vulnerabilidades de Digital Bond actualizada en este enlace. Como veréis, ahora ocupa mucho menos que la de antes, pero el mensaje es mucho más claro y directo.
Leer más...

07 septiembre 2011

Reflexiones sobre DigiNotar

Mucho se ha escrito ya sobre el impacto del 'hackeo' de Diginotar, en concreto se ha hecho hincapié en los cientos de dominios afectados (de todo tipo y de diversa índole).

Pero hasta ahora no he sido capaz de encontrar información realmente profunda sobre los matices a nivel PKI de todo este asunto.

Como punto de partida vamos a usar el informe preliminar de la empresa que está llevando a cabo la auditoría de la intrusión (disponible aquí)

Empezamos:

En el punto 3.2 'Compromised CAs' aparece lo siguiente:

'Due to the limited time of the ongoing investigation we were unable to determine whether all CA servers were used by the attacker(s)' que traducido vendría a decir: en realidad desconocemos cuales CAs han sido utilizadas por los atacantes. No obstante dan una lista de CAs comprometidas, y en la lista aparece:

- DigiNotar Root CA
- DigiNotar Root CA Administrative CA
- DigiNotar Root CA G2
- DigiNotar Root CA System CA

¿Perdón? ¿ he leído DigiNotar Root CA ? increíble, una de las CAs comprometidas es la propia CA raíz, el que debería ser el eslabón mas duro e inexpugnable.

Una CA raíz únicamente se emplea en dos ocasiones, o bien para crear CAs subordinadas o en caso de compromiso de esas CAs, para invalidar las CAs subordinadas. Si este eslabón está comprometido, bye bye, no hay otro mecanismo de salvaguarda.

Grosso modo un esquema PKI funciona así:
  • Existe una CA raíz 'madre' 
  • Esta CA raíz crea otras CAs subordinadas (de nivel 2)
  • Las CAs subordinadas son las que firman y generan los certificados para usuarios / servidores finales
  • Las solicitudes de certificados se tramitan mediante una RA (registration authority)
Y esto pone sobre la mesa otra pregunta mas inquietante: ¿Habrá sido empleada la CA raíz para crear CAs subordinadas pirata? Esta pregunta no es baladí, los certificados SSL 'normales' emitidos durante el hackeo se pueden revocar, pero si alguien tiene un certificado y la clave privada de una CA subordinada, puede crear bajo demanda y sin control los que quiera

Si seguimos leyendo el informe nos encontramos con esto en el punto 4.4:

The most critical servers contain malicious software that can normally be detected by anti-virus software. The separation of critical components was not functioning or was not in place. We have strong indications that the CA-servers, although physically very securely placed in a tempest proof environment, were accessible over the network from the management LAN.

The network has been severely breached. All CA servers were members of one Windows domain, which made it possible to access them all using one obtained user/password combination. The password was not very strong and could easily be brute-forced.

Lo que quiere decir que, tanto las CAs subordinadas como la ¡ CA raíz ! eran fácilmente accesibles vía red e incluso todas formaban parte de un dominio Windows.

Y ahora me toca la tarea mas difícil: intentar recuperar la credibilidad del mundo PKI.

A tenor de lo expuesto previamente, supongo -y con razón- que mucha gente puede creer que implementar una PKI es 'un cachondeo' y que no existe rigor alguno en este campo. Pero esto no es así

De entrada, existen dos normativas que regulan como implementar una PKI y que medidas de seguridad hay que aplicar

'Policy requirements for certification authorities issuing qualified certificates' de ETSI

'Program for Certification Authorities' de Webtrust


Por ejemplo, Microsoft exige que una PKI debe estar certificada con una de esas dos normativas para añadir el certificado de la CA raíz a Internet Explorer

Ambas guías exponen de una forma MUY clara los niveles de seguridad que debe contar una PKI. Diré a modo de ejemplo que la PKI del DNI electrónico (que cuenta con ambas certificaciones) tiene la CA raíz encerrada en una celda (sí una celda con barrotes) Totalmente offline, inaccesible física o electrónicamente

Normalmente, para realizar una auditoría de este estilo se suelen crear 'check lists' con cosas a analizar, aquí se puede ver un típico check list para realizar una auditoría ETSI

De el voy a sacar unos cuantos párrafos:

'The CA shall carry out a risk assessment to evaluate business risks and determine the necessary security requirements and operational procedures. The risk analysis shall be regularly reviewed and revised if necessary'

'The CA shall have a system or systems for quality and information security management appropriate for the certification services it is providing'

'The CA shall ensure that its assets and information receive an appropriate level of protection'

'The CA shall ensure that the CA systems are secure and correctly operated, with minimal risk of failure'

'The integrity of CA systems and information shall be protected against viruses, malicious and unauthorized software'

'Audit logs shall be monitored or reviewed regularly to identify evidence of malicious activity'

'Controls (e.g. firewalls) shall be implemented to protect the CA's internal network domains from external network domains accessible by third parties'

'Continuous monitoring and alarm facilities shall be provided to enable the CA to detect, register and react in a timely manner upon any unauthorized and/or irregular attempts to access its resources'

Según el informe de la intrusión tenemos: Logs borrados e imposibilidad de tener trazabilidad en el uso de la CA, software como Cain & Abel instalado en las propias máquinas, CAs dentro de un mismo dominio Windows, etc etc.

Y la pregunta final: ¿Quien hizo la auditoría a DigiNotar y certificó que cumplían ETSI?

Leer más...

06 septiembre 2011

HideMyPHPShell, ofuscador de código PHP

Son ya muy conocidas las clásicas shells escritas en PHP, que comúnmente se utilizan para aprovechar vulnerabilidades del tipo Arbitrary File Upload.

También pueden ser utilizadas para administrar ciertos aspectos en caso de que sólamente tengamos acceso vía web a nuestro servidor.

Es muy común que cuando un atacante consigue subir una shell a un servidor para comprometerlo, ofusque el código fuente de la misma para hacerla más difícil de detectar. De hecho, muchas de estas shells que se han encontrado "in the wild", cuentan con algún tipo de ofuscación.

La herramienta HideMyPHPShell, que os presentamos hoy, permite ofuscar código PHP de cualquier tipo, de una manera rápida, y con varios métodos diferentes.

HideMyPHPShell help
./hidemyphpshell.py method_number php_file
1 eval() base64
2 eval() gzip + base64

En su primera versión soporta ofuscación mediante Base64, o mediante compresión gzip con un grado de compresión aleatorio. La idea es, en un futuro, incluir más métodos, incluso utilizando algoritmos de cifrado más avanzados, aunque la clave esté en el propio fichero y se utilice en la rutina de descifrado.

Podemos ver un ejemplo de uso con PHPShell.

Si la descargamos y vemos el código fuente, es demasiado ruidoso:

$ head phpshell.php
<?php // -*- coding: utf-8 -*-


define('PHPSHELL_VERSION', '2.2');
/*


  **************************************************************
  *                     PHP Shell                              *
  **************************************************************


  PHP Shell is an interactive PHP script that will execute any command

En cambio, si la pasamos por el programa:

./hidemyphpshell.py 2 phpshell.php
Obfuscating phpshell.php with method 2 ...
Done, dumped to phpshell.php.obfuscated.php


cat phpshell.php.obfuscated.php
<?php eval(gzuncompress(base64_decode("eF7lXO1z20Zz/2zP+H84oaxJ2nyR7HSaSiL9KLL8WK0seyS5mYzscCAQFBGBAAOAovUkz//e3+7eHQ4gKTlOpv1QxxOTwN3e3t6+7x5fDfdfzadz1e+r7rOuCtJxlFzvqkUx6X5PT548fvJ4HE6iJGw1P7z9cP726ORk9N9HZ+fH70+bHdV80XvRbO89edx/RiOVevan/jAEte4P...

Además, al utilizar el segundo método compresión gzip, el tamaño del fichero PHP ha sido reducido de 20 KB a 9.1 KB.

Ya podéis descargar HideMyPHPShell (hidemyphpshell.py) desde el repositorio oficial de SbD.
Leer más...

05 septiembre 2011

Rooted CON 2012: Call For Papers


Se llevaba anunciando por twitter y en la lista de distribución de Rooted CON, y finalmente llegó el 5 de Septiembre: Ya tenemos fechas para Rooted CON 2012, y se ha abierto el proceso de solicitud de ponencias para esta nueva edición.

En primer lugar, se confirma que Rooted CON 2012 tendrá lugar el 1, 2 y 3 de Marzo de 2012 en Madrid. El congreso sigue fiel al mes de Marzo y seguirá celebrándose desde el jueves hasta el sábado, tres días llenos de charlas que abarcan multitud de temáticas, con un aforo de 600 personas aproximadamente.

Además, con el anuncio oficial de las fechas, se abre el proceso de inscripción de ponencias o "Call For Papers", dónde cualquiera podrá proponer su charla o charlas, y poder formar parte del elenco de ponentes de esta nueva edición.

En la página oficial, además de los anuncios pertinentes y enlaces al CFP, se ha dejado un video en el que se ve como Hitler se entera de algo que no le hará mucha gracia para esta próxima Rooted CON 2012 (con suerte, es una broma...)




Sin más, a continuación adjuntos las indicaciones de este Call For Papers para Rooted CON 2012:

------------------------------------------------

Rooted CON 2012 - 'Call for Papers'

-=] Acerca de Rooted CON

RootedCON es un Congreso de seguridad que se realizará en Madrid (España) desde el 1 al 3 de marzo de 2012.

Con un aforo estimado de 650 personas, es uno de los congresos especializados más grandes que se realizan en el país y uno de los más grandes de Europa, con perfiles de asistentes que varían desde estudiantes, a fuerzas del estado, pasando por profesionales dentro del mercado de la Seguridad en TI o, simplemente, por entusiastas de la tecnología.

-=] Tipos de charlas

Se aceptarán dos tipos de charlas:

- Charlas rápidas: 20 minutos.
- Charlas estándar: 50 minutos.

Habrá un número limitado de cada uno de los tipos pudiendo, incluso, adaptarse el calendario para que una charla interesante se extienda más allá de los 20 minutos o, por necesidades concretas, reducir una de 50 minutos.

-=] Temas que buscamos

Cualquier tema relevante asociado con el Concepto de Hacking, por ejemplo y no siendo éstos los únicos temas que nos interesan:

- Hacking, cracking, phreaking, virii, WiFi, VoIP, GSM...
- Terminales móviles: android, iOS, Windows7 mobile, maemo,...
- Hacking de consolas y de videojuegos.
- Ingeniería inversa, debugging, hooking, fuzzing, exploiting,...
- Técnicas y herramientas innovadoras tanto en defensa como en ataque.
- APT, botnets y malware.
- Hacking en hardware y firmware.
- (In)seguridad "en la nube", seguridad en entornos virtuales,...
- Técnicas de criptografía, esteganografía, canales subliminales,...
- Forense y antiforense.
- Comunicaciones, capa2 y capa3,...
- Charlas (muy) originales que gusten al tipo de público que tenemos...

Para esta edición nos gustaría especialmente ver charlas relacionadas con "Hardware Hacking", ideas de modificación del comportamiento de robots, hardware especializado o, incluso, creación de aparatos. Palabras clave relacionadas: Arduino, *cópteros, Rumba, alarmas, cámaras...

*Se valorarán especialmente aquellas charlas que se consideren EXCLUSIVAS, es decir, que no se hayan presentado anteriormente en ningún otro foro, blog, web, evento o congreso*.

-=] Procedimiento para el envío de ponencias

Solamente se aceptarán charlas que se inscriban a través del formulario de ponentes que se ha preparado para tal efecto:

https://www.rootedcon.es/cfp2012-es/ (español)
https://www.rootedcon.es/cfp2012-en/ (inglés)

Cualquier otro método de envío de charlas no se considerará como "oficial" y no será valorado por el equipo de selección.

-=] Calendario e hitos principales

05 Sep 2011 - Apertura de las inscripciones de charlas.
31 Dec 2011 - Cierre del plazo de inscripción.
Ene 2012 - Publicación de la agenda final de ponentes.

6 Feb 2012 - Entrega de todo el material del ponente.

1-3 Mar 2012 - /Rooted CON2012

-=] Beneficios y privilegios como ponente

Cada ponente recibirá los siguientes beneficios y privilegios:

- Una cena con el resto de los ponentes, los profesores de Rooted Labs y el equipo de Rooted CON.
- Alojamiento (costes a cargo de la organización)
- Viaje (costes a cargo de la organización)
- Acceso completo al Congreso en sus tres días
- Bebidas gratis en la fiesta ;)

*POR FAVOR*, es muy importante que se indique *CLARAMENTE* si se necesita o no el alojamiento y los viajes cuando se inscriba la ponencia; en caso de no hacerlo y se solicite posteriormente, Rooted se reserva el derecho a rechazar la ponencia por problemas de logística.

-=] Obligaciones y deberes del ponente

Todos los ponentes que presenten charla para RootedCON 2012 y sean seleccionados, deberán:

a) Confirmar que la ponencia presentada es TÉCNICA y que está acompañada de PRUEBAS DE CONCEPTO.

b) Enviar el material de la ponencia PREVIAMENTE a las fechas de realización del Congreso. Dentro del envío del material es importante incorporar detalles sobre las demostraciones que se van a realizar.

c) Desarrollar el material de acuerdo con las plantillas oficiales de RootedCON 2012.

d) Aceptar de forma explícita que los materiales presentados, así como las grabaciones de video y audio
que se realicen se publicarán, ya sea en los mecanismos de gestión de contenidos de RootedCON o en
otros medios en el futuro.


-=] Patrocinadores y colaboradores

Rooted CON siempre está buscando patrocinadores y colaboradores de calidad. Si tienes una propuesta o crees que tu empresa puede estar interesada, por favor contacta con nosotros en:

patrocinadores-EN-rootedcon.es

*IMPORTANTE* debido al fuerte contenido técnico del Congreso se valorarán los patrocinios tanto en su apartado económico como en el aporte técnico de las charlas del patrocinador, considerándose mejor un patrocinador que aporte contenido técnico o de hacking frente a uno que de una charla comercial.

Cualquier ayuda, comentario, ideas, propuestas o colaboraciones que nos hagáis llegar serán consideradas y valoradas con toda su importancia: es muy importante para el Congreso recibir este tipo de propuestas, ya que dependemos de vosotros para organizar el mejor evento posible.

-=] Cómo contactar:

info-EN-rootedcon.es

-=] Nuestros enlaces

- Web: http:/ /www.rootedcon.es/en/
- Twitter: @rootedcon
- Facebook: http://bit.ly/fbookrooted
- LinkedIn: http://bit.ly/linkedinrooted
- Rooted mailing-list (español): rootedcon@listas.rooted.es
- Vimeo: http://www.vimeo.com/rootedcon
- Slideshare: http://www.slideshare.net/rootedcon
Leer más...

04 septiembre 2011

Enlaces de la SECmana - 87


Leer más...

03 septiembre 2011

Epic Fail de Ebay

El huracán Irene, catalogado como uno de los peores de los últimos siete años, está causando estragos en EEUU obligando incluso a Nueva York a encontrarse en estado de emergencia.

Como era de esperar, Irene está afectando también a compañías como Ebay, quien ha mandado un email a ciertos usuarios (los que hayan realizado algún pedido durante todo este periodo de "inestabilidad") explicándoles la situación y comentándoles las medidas que van a tomar al respecto.

Cual ha sido mi sorpresa cuando un amigo me ha reenviado el email que ha recibido por parte de Ebay, conteniendo el nombre y apellidos, identificador, nombre de usuario y dirección de correo de 608 usuarios de Ebay (y no hay más porque parece que el sistema ha cortado al alcanzar un determinado tamaño).

Las estadísticas de los datos comprometidos en este email (que habrán sido diferentes en cada uno de los enviados) son:
Yahoo.com : 128
Gmail.com : 104
Aol.com : 62
Hotmail.com : 58
Us.army.mil : 1
Fcc.gov : 1




Ya nos hemos encontrado casos en España en la que se ha multado a personas que han enviado correos "masivos" utilizando CC en vez de CCO, ¿ocurrirá lo mismo en este caso? ¿se tomará alguna medida al respecto? No lo creo, pero deberían dar explicaciones de porqué se ha filtrado tanta información.

Contribución por Luis Delgado
Leer más...

02 septiembre 2011

Firewall Builder: la GUI para tu cortafuegos

Cuando me preguntan: profesionalmente, en el mundo de la seguridad perimetral ¿en qué aspecto sientes que te desenvuelves mejor? Mi respuesta suele ser que en el diseño y gestión de políticas y soluciones de seguridad y cortafuegos. Precisamente esta fue mi especialidad a partir del 2001 cuando empecé a dedicarme a "esto de la seguridad".

En estos 10 años he tenido la oportunidad de trabajar con unos cuantos fabricantes de cortafuegos. De los conocidos, de corte comercial, entre otros: Checkpoint Firewall-1 (en alguna entrevista de trabajo he llegado a bromear con que, menos en el microondas de casa, lo instalé sobre cualquier plataforma), Stonegate, Juniper/Netscreen, Fortinet, NetASQ, Watchguard, Sonicwall, Gauntlet, Cisco PIX…

Sin embargo, las empresas no siempre eligen estas tecnologías, ya sea por disponer de un presupuesto cerrado y estricto, en el que los servicios de diseño, despliegue e implantación para una política de seguridad adecuada, ya se llevan una buena parte del presupuesto como para pagar también por hardware específico. En otros casos, por filosofía de compañía, muchas veces se prefiere utilizar software libre y evitar "atarse" a un fabricante de dispositivos determinado que en un momento dado, por una mala fusión pueda llegar a hacer inútil una inversión de muchos miles de euros. Por ello, se prefiere comprar servidores de propósito general y utilizar toda una "suite" de productos libres que permitan proporcionar los mismos servicios que un UTM comercial, pero con un coste fijo y mantenimiento, mucho menores.

En este tipo de situaciones, para la gestión de la política de cortafuegos, quizá sea poco amigable, la gestión de reglas en base a un fichero de comandos de sistema operativo. Para ello se hace imprescindible utilizar una GUI o Front-end adecuado.

Aunque ya hemos hablado en SbD de diferentes proyectos libres de gestión de cortafuegos, quiero hoy analizar en mayor medida el que, para mi gusto se lleva la palma en funcionalidad, diseño y versatilidad: Firewall Builder.

Desde el punto de vista de la administración, cortafuegos hay fundamentalmente dos tipos:
  • Los que pueden gestionarse vía web: por tanto, multiplataforma desde el punto de vista de la gestión.
  • Los que utilizan una herramienta cliente: en los que generalmente, bajo Windows funciona al 100%, pero en los que tienen clientes para otras plataformas, éstas suelen ir un paso por detrás en cuanto a la versión Windows o está menos probada y se pierde buena parte de su funcionalidad.
En el caso de Firewall Builder, se trata de una aplicación cliente que permite diseñar cómodamente la política de seguridad y luego aplicarla a la máquina cortafuegos de forma directa, mediante una conexión SSH. Dispone de una versión libre y funcional para Linux, así como versiones de pago, aunque con un coste muy bajo, para Windows y Mac OS X.

Firewall Builder es una GUI multifirewall. No está enfocada únicamente a permitir la gestión de IPTables en Linux, sino que permite además ipfilter, ipfw o PF como cortafuegos en Linux, Mac OS X, OpenBSD, Solaris y FreeBSD, entre otros; además permite gestionar otros cortafuegos como CISCO (ASA/PIX, ACLs en IOS, etc,…), HP Procurve (supongo que se referirá a ACLs en switches HP), etc,…


La GUI, permite crear un dispositivo cortafuegos y a partir de ahí, especificar el número y tipo de interfaces de red que tiene. Indicaremos si el interfaz es de gestión, externo o interno (importante para controlar el spoofing por ejemplo), pudiendo configurar además diferentes opciones como las que ya detallamos en cómo securizar y optimizar parámetros del kernel mediante sysctl.conf.


Podemos partir de de una política de cortafuegos en blanco o ayudarnos de diversas plantillas ya hechas basadas en escenarios típicos con uno, dos o tres interfaces de red. En mi caso, empiezo siempre con una en blanco y aplico mi propia plantilla mental de diseño de política de seguridad. Sin embargo, "cada maestrillo tiene su librillo" y habrá consultores de seguridad que prefieran partir de una plantilla prediseñada y retocarla a posteriori en vez de enfrentarse a lienzo en blanco.

Firewall Builder permite configurar interfaces de red "normales", interfaces de tipo Bond, así como Bridge e incluso dividir el interfaz en modo lógico usando 802.1Q mediante VLAN tagging. De esta manera será el propio Firewall Builder quien incluya en el script a ejecutar en el cortafuegos los comandos necesarios para levantar y configurar los módulos e interfaces adecuados. Recientemente he tenido que configurar un interfaz PPP también sin problemas.


La pantalla de creación de reglas es sencilla, disponemos de los objetos a la izquierda y las reglas en el panel principal, de manera que se pueda ver de una forma bastante clara cómo va quedando la política de reglas. En la definición de objetos podremos incluso indicar la dirección MAC de cada dispositivo, de manera que forcemos a que una IP lleve asociada una MAC, haciendo más complicado el bypass de la política de seguridad a atacantes.


Viene con los servicios más comunes ya predefinidos, de manera que simplemente arrastremos hacia las reglas lo que queremos permitir/denegar/rechazar de una forma bastante cómoda. Si un servicio o grupo no viene por defecto, podemos definir, en un área específica de objetos de usuario, aquello que necesitemos, permitiéndonos incluso indicar si el servicio será válido si lleva activos o no algunos flags TCP (como SYN, ACK, RST, PUSH, URG, FIN).

 
El logging producido por el cortafuegos será ejecutado via syslog según los parámetros que tenga la máquina predefinidos a nivel de demonio syslog, siendo éste local, remoto o ambos, seleccionando el nivel deseado para poder ser clasificado por el colector de eventos en caso que así lo deseemos.

Desde Firewall Builder podremos también generar la política de NAT, permitiendo ajustar el tipo de publicación de servicios al exterior, así como ocultar o "enmascarar" IPs internas utilizando una o varias direcciones IP del cortafuegos.


Podemos además definir otro tipo de cosas interesantes como intervalos de tiempo entre los cuales queremos que la regla sea o no válida, parámetros de QoS, etc,… en definitiva todo aquello que permita el cortafuegos de forma nativa configurar mediante comandos en un fichero, tiene su correspondencia visual directamente, sin tener que utilizar módulos diferentes como en el caso de otras GUIs más limitadas que para la parte de Traffic Shapping o QoS por ejemplo, hay que basarse en otros proyectos.

Por  supuesto, Firewall Builder viene preparado para generar las reglas para IPv6, de manera que la actualización a lo que se supone que iba a ser el pasado-presente (que personalmente aún veo como futuro - muy futuro) no resulte más traumática que añadir/modificar la configuración IP y se nos generen todas las reglas ad-hoc.  

Conclusiones
  • Firewall Builder es una herramienta de acabado completamente profesional para la gestión de cortafuegos que no tiene nada que envidiar a las GUIs de cortafuegos comerciales, siendo incluso, en algunos casos, más potente que éstas.
  • Está pensado para la gestión de reglas de una única máquina, por lo que si disponemos de un clúster, y efectuamos una modificación, habrá que replicar los cambios en todos los nodos, generando políticas separadas para cada uno de los mismos.
  • La herramienta de gestión es casi idéntica y con las mismas funcionalidades en las plataformas soportadas: Linux, Windows y Mac; cubriendo con estas plataformas el 99% de las utilizadas por los administradores de sistemas y responsables de seguridad.
  • La configuración de cortafuegos es un fichero XML que puede quedarse en el PC local del administrador, con lo que se hace complicado una co-administración por parte de un equipo, por lo que la configuración debería estar en algún recurso compartido por red. El punto negativo es que dicho fichero de configuración se encuentra en claro, por lo que si cae en malas manos, la política de configuración del cortafuegos puede ser conocida por público no autorizado. Podemos complementar esta carencia guardando la política de cortafuegos en un contenedor cifrado, del tipo Truecrypt por ejemplo.
  • Será porque empecé con Checkpoint y Stonegate, cuya administración es vía herramienta cliente también, que me acostumbré a utilizar este tipo de herramientas y me gusta menos las GUIs de cortafuegos vía web, como pueden ser el caso de Shorewall.
  • Llevo desde 2002 utilizando la versión Linux (desde que empecé a usar Linux) y al pasarme a Mac, lo que solía hacer era exportar las X del firewall (Linux) a mi Mac y controlar la GUI remotamente. Esto en una red local funciona "bien", con ciertos lags en cuanto al refresco de la pantalla, haciéndolo un poco incómodo en algunas ocasiones. A la hora de hacerlo remotamente, se hace prácticamente imposible a no ser que el acceso desde Internet sea muy bueno y los planetas estén alineados. La herramienta en local para Windows o Mac, en estos casos funciona perfectamente, permitiendo definir lo que queramos en la política del firewall y luego con la orden Instalar, se envía y se ejecuta vía SSH el fichero con la configuración (en mi caso IPTables) en el dispositivo.
Leer más...