Mostrando entradas con la etiqueta Firewall. Mostrar todas las entradas
Mostrando entradas con la etiqueta Firewall. Mostrar todas las entradas

20 de abril de 2010

Firewall Rules Debugger

Si hay un elemento de seguridad que lleva años acompañándonos son los firewall, estos dispositivos que en un principio trabajaban solo hasta la capa 3 de la pila de protocolos OSI poco a poco fueron ganando complejidad, empezaron a trabajar con capas superiores e incluso a nivel de aplicación. Hoy en día hay appliances que incluyen IDS/IPS, te pueden establecer VPN’s y controlar el acceso a tu red mediante la terna AAA (Autenticación, Autorización y Auditoría).

Lo malo de estos cacharros es que pasa el tiempo, se van generando reglas y reglas, se implementan caducidades que luego nadie quita y su uso se degenera en el modelo de firewall suizo que vimos hace unos meses.

Hace poco tuve que trabajar en un proyecto donde tocaba auditar la configuración de varios firewall y como no, revisar las reglas compiladas y ver su consonancia respecto a las políticas de seguridad definidas. Me tocó lidiar con varios cientos de reglas así como estudiar los hits que se producían en reglas genéricas que en algún momento se habían consolidado. Para tan ardua tarea estuve buscando Tools que pudieran ayudarme, hay millares que quizás conocereis Flint, securetrack, FW auditor, etc. El caso es que no me acababa de convencer ninguna, yo lo que necesitaba era algo para hacer búsquedas, extraer las reglas que me interesaba, si fuese posible clasificarlas según el puerto y poco más, así que me curré esto:

Búsqueda de reglas...

Clasificando reglas,,,

Una pequeña aplicación que hace exactamente eso. Basta importar el archivo de logs requerido y comenzar a hacer búsquedas. Siempre que los puertos aparezcan después de “:” no tendrá muchos problemas para clasificaros las reglas y deciros el protocolo que debería haber por ahí dentro del rango de puertos reservados. También os pondrá un Warning cuando encuentre cositas raras o protocolos considerados “inseguros”, por ejemplo, Telnet.

Os dejo este link, descomprimir, instalar y cargar el archivo de reglas de ejemplo para poder comenzar a jugar. Está Beta, así que hay algunos errores y excepciones que todavía no he controlado y depurado, también da algún problema de compatibilidad visual en Windows 7 (no soy desarrollador. pero el .NET se debería llevar bien con este sistema operativo ¬¬), con todo ello la funcionalidad a grandes rasgos está implementada. Espero que os sea útil igual que lo fue para mí.

Salu2!

5 de diciembre de 2009

Trusted Network Connect

Cuando a principios de Octubre hablamos de Trusted Execution / Trusted Plataform dentro del marco de arquitectura de procesadores segura dimos alguna pincelada de un término que a día de hoy es crucial en toda corporación, Trusted Network Connect.

Actualmente la ubicación del puesto de trabajo es dinámica, y cada vez lo es mucho más. Nuestro personal está sentado en sus oficinas, pero también está desplazado en un cliente y requiere conectividad contra servicios y recursos que tiene en su puesto de trabajo, también viaja y probablemente tanga una BlackBerry o similares con la que necesita revisar el correo corporativo, esto es solo la punta del iceberg: No todos los empleados son iguales, hay desarrolladores, gente de sistemas, comerciales, jefes, gerentes y directores. Becarios recién contratados y externos, muchos externos, ya que también hacemos Outsourcing. Este personal ajeno también necesita conectividad para dar su servicio, es más, probablemente lo hará todo desde sus propias oficinas o quizás tengamos un hueco para ellos en nuestra empresa.

El perímetro de la organización es maleable y se corre el riesgo de que no se puede dar una solución de acceso a sistemas y servicios segura y robusta. En definitiva, un problemón para los arquitectos de red y el personal de seguridad que requiere de soluciones. Es aquí cuando entran en juego los accesos de confianza.

El Trusted Computing Group da una serie de directrices genéricas independientes de la tecnología para orientarnos un poco en como deben ser esos accesos.

Network Access Control

Este concepto simplificado al extremo trata de que un “cualquiera” que llegue a tu organización no sea capaz de enchufarse a tu red bien, por que ahí hay una roseta vacía o bien por que la Wifi está abierta a invitados. Esto hoy en día es sencillamente intolerable, pero el NAC va mucho más allá definiéndose como un conjunto de medidas de seguridad que nos aseguren que solo accederá a nuestra red aquel que tenga los correspondientes permisos y cumpla con un mínimo de políticas de seguridad, NAC es:
  • 802.1X
  • DHCP
  • VPN
  • Cumplimiento GpO.
  • Actualizaciones y parches del Sistema Operativo.
  • Antivirus actualizado y homologado.
Pero esto no es todo, debemos ser capaces de proveer u
na infraestructura de acceso que a parte de cumplir con todo lo anterior sea capaz de dar acceso a los recursos necesarios según el perfil / rol del usuario, esto se debe apoyar de forma indudable en una arquitectura de red segura (con todo lo que implica a nivel de VLANs, firewall, routing, etc.). Además los permisos de acceso deben ir alineados con los recursos accedidos, probablemente una persona de desarrollo necesite ser administrador en su equipo y trabajar en un entorno aislado alejado de producción, de igual forma se debe evitar que un administrador de BBDD sea capaz de modificar los datos que gestiona, siendo esta capacidad exclusiva de sus usuarios (esto creo que lo llamaban segregación de funciones).

Ahora bien, todo esto no es nuevo, las conexiones de confianza pueden llegar mucho más lejos y alcanzar a todos los dispositivos de mi red, impresoras, telefonía VoIP, cámaras de seguridad, etc. cuya actividad también deberá estar regulada. De manera adicional se instalarán sondas, IDS/IPS que controlen y detecten la actividad de los dispositivos / usuarios en la red, aquí es cuando surge un elemento adicional, el IF-MAP (Interface Metadata Access Point) Para no perdernos echemos un ojo a la siguiente imagen:


En la misma tenemos nuestros clientes “de confianza”, seguridad a nivel de red 802.1x, switches, routers, radius, firewalls, Policy Decision Point y, como capa adicional antes de llegar a los controles de seguridad aparece IF-MAP, ¿Qué es esto?, Con IF-MAP tenemos un protocolo cliente – servidor basado en XML y que utiliza SOAP + HTTPS. Su misión principal es recolectar datos de los dispositivos de red, metadatos que nos den una idea de quien es, a qué accede, que está solicitando y haciendo, etc. La estructura de los mensajes que maneja es la siguiente:
  • ip-adddress (v4 or v6)
  • mac-address
  • identity aik-name:
  1. dns-name
  2. email-address
  3. kerberos-principal
  4. trusted-platform-module
  5. username
  6. sip-uri
  7. tel-uri
  8. other (vendor defined)
  • access-request
  • device
Como imagináis esto abre un abanico de posibilidades a la hora de controlar los accesos a la red que delega en el Metadata Access Point controles de seguridad que en tiempo real detectan accesos inapropiados, dispositivos que tratan de acceder a recursos que no deben, alarmas (falsas o no) alineadas con el resto de dispositivos, etc. No han sido pocos los fabricantes que se han subido al carro del IF-MAP, en esta pequeña diapositiva se pueden ver algunos de ellos.

El paradigma de acceso a la red seguro con un servicio de confianza está cambiando continuamente, hay mucha tela para cortar aquí ya que estamos hablando de confianza extremo a extremo, multitud de capas de acceso, ingeniería de conocimiento y redes bayesianas para decidir cómo actuar sobre un dispositivo, etc. Por suerte hay mucha información disponible en la red, herramientas Open Source como FreeRadius, OpenSea 802.1X, el proyecto libTNC, etc.

Precaución, amigo conductor (happy bridge).

Salu2!

1 de julio de 2008

Iphone, También "seguro"

Viendo el negocio del IPhone, algunos fabricantes "avispados" ya han empezado a sacar productos específicos de Seguridad, igual que los malos malosos han puesto en circulación los primeros virus específicos para este aparatito, la gente de Checkpoint ha visto un más que probable filón de oro y ha dicho, ¿cuantas compañías van a dar el Iphone a sus empleados para que los luzcan y presuman de última tecnología y de paso, dan buena imagen corporativa?
1: El cacharrito!
2: El tunel seguro!

De paso, vamos a hacerles trabajar con este aparato como si fuera una BlackBerry, y,,,¡que accedan a los recursos de la empresa!, Alehop! Añadimos a los firewall de Checkpoint un cliente que permita la compatibilidad para que desde tu aparatito puedas establecer una VPN - IPSec con IPS, Firewall y VPN.


3: Ponte a elegír!

¡Todos seguros y todos contentos!
Salu2!

8 de junio de 2008

VRRP

El otro día tuve la oportunidad de ver soluciones de Alta Disponibilidad, entonces fue cuando me comentaron si conocía cierto protocolo llamado VRRP: Virtual Redundance Route Protocol. Esto es algo así como una solución de alta disponibilidad por infraestructura donde todo está duplicado físicamente, aunque esto según el modelo de implantación puede cambiar, pueden estar duplicados los router, los switch, los firewall, los servidores, etc. Por ejemplo la siguiente imagen muestra como la gente de Cisco ofrece soluciones de este tipo para un router virtual (VPN 3000).





Si nos fijamos en lo que hacen los de Nokia con sus Firewall Checkpoint tenemos prácticamente lo mismo, en este caso lo que se duplica es el Firewall (cada uno con un ISP) pero después los servicios que cuelgan detrás no están redundados. ¿Cómo funciona este protocolo exactamente? Si nos vamos a la “interesante” RFC 3678 (digo Interesante por que he de confesar que necesito una fuerte necesidad y/ò aburrimiento para ponerme a leer estas cosas) podemos ver que un dispositivo maestro enviará periódicamente paquetes VRRP a todos los dispositivos del mismo nivel, es decir podemos redundar 1, 2, 3 y todas las veces que queramos. Los paquetes VRRP se encapsulan en paquetes IP (seguimos en el nivel 3 de la arquitectura OSI) que son enviados por multicast, en esa información el Master informa de que está vivo, la prioridad (máximo 255), Interfaz Virtual, tiempo entre mensajes y los campos habituales de todo paquete IP.



La teoría nos dice que, en la habitual Alta Disponibilidad con 2 dispositivos 1 estará UP (Master) y el otro Down (Slave). Si lo pensamos bien eso implicaría tener 1 máquina comprada, pagada, mantenida, etc. sin sacarle rendimiento alguno en el 99.9% del tiempo (se presupone). ¿Cómo explotar mejor este protocolo, conseguir Alta Disponibilidad y no tener máquinas ociosas? Esto es lo que en el negocio se llama como Alta Disponiblidad Activo – Activo, que viene a significar que ambos Firewall se encontrarán trabajando a unos niveles de carga estimados en un 50%, de esta forma si uno de ellos falla, se colapsa, es atacado o le ocurre cualquier mal que os podáis imaginar, el otro podrá asumir el servicio sin verse sobrepasado (50 + 50 = “100”).


Si bien esta redundancia es virtual en muchos casos (1 Firewall físico, 2 virtuales) suele venir apoyada por un balanceador que se ocupará de distribuir las peticiones a cada uno de los Firewall. Ni que decir tiene que las políticas de seguridad deben ser las mismas en ambos dispositivos, idem con el protocolo de enrutamiento (RIPv2 es una buena opción).

Ahora bien, si queremos llegar un poco más lejos y especializar estos dispositivos podemos usar el modo pasivo / activo. Esto es, por defecto ciertos servicios irán a la máquina FW1, y por ejemplo las peticiones al SQL Server irán al FW2, el balanceador estará configurado de esta forma, en caso de que la petición no esté especificada irá alternándose de uno a otro. Ahora bien, ¿y si FW2 falla?, no pasa nada, cuando FW1 se entere (que será exactamente cuando el tiempo de refresco expire sin novedad) comenzará a asumir las peticiones SQL Server y –si todo funciona como debería- asumirá la carga de ese servicio (u otros) hasta que FW2 se recupere, es lo que se llama Firewall Sync, las 2 máquinas conocerán en todo momento como está la otra, se podrán intercambiar las peticiones según el estado del tráfico, conocerán las rutas de encaminamiento, etc. etc.

Ni que decir tiene que estas soluciones, si los estudios de rendimiento / capacidad son acertados, desde el punto de vista de la seguridad pueden ser muy buenas, y del negocio podrá proporcionarnos confianza para comprometernos con SLAs del 99.9%.





Salu2!!