Entradas populares

miércoles, 22 de junio de 2011

"Cuanto más sudes ahora, menos sangrarás en el campo de batalla". Troubleshooting Paloalto

¿Se te ha puesto esta cara con algunos problermas de PAN? Tranquilo, seguro que nadie te hará una foto ;)

Problemas inesperados entre la capa de gestión(Candidate config) y la de ejecución del Paloalto(running config).
  • No se puede sincronizar la configuración entre el activo y el pasivo.
  • No se puede hacer un commit al principal. Dice que ha perdido la conexión con el servidor de gestión(Cannot connect with the management server)
  • El commit tarda mucho o el commit cada vez es mas lento.
Solución: Resetar los procesos de management server y device server. 
Background: Los demonios no se depuran y crecen muriendo por lentos. Hay diversas causas como el navegador.
NOTA: Este reset de procesos no afecta al tráfico que pasa por el equipo. Se puede hacer sin esperar a una ventana de intervención, sería como cerrar el navegador y volverlo abrir.
Ejecutar desde CLI:(Ni caso que se llame debug)
  1. debug software restart management-server
  2. debug software restart device-server
Hacer un show system resources para verificar que los procesos se han reiniciado.

BUG, de identificación de usuarios mediante pan-agent y directorio Activo.
  • Los usuarios validados en el Directorio Activo se saltan las reglas de seguretat. Son identificados dentro del dominio pero aparecen como desconocidos(unknown). Todos los usuarios pueden hacer todo lo que permitan las reglas con usuarios.
Solución: Hacer un upgrade del agente cuando sala la nova versión. 
Mitigación, desactivar la comprobación por netbios y en el servicio de PANAGENT, configurar las tres acciones para cuando se quede colgado, como reiniciar.

Aplicaciones o comunicaciones lentas:
  • PAN, no deja pasar los paquetes ICMP code 4 type 3(Fragmentation needed) que notifican que la mtu es demasiado grande. Eso implica que ciertas conexiones(VPN, WIFI y WANs) funcionen muy lentas. 
Solución: Definir una custom application con icmp code 4 pero en la regla de seguridad definir el servicio como default-application.

Permitir toda la navegación, no solo http y https.
Crear una "application filter" por tecnología: Browser-based. Son 489 aplicaciones como web-browsing(http), ssl, flash, youtube, facebook...etc

Ver la configuración formato comando y no estructura xml (Muy útil para cisqueros)
 set cli config-output-format set


Robclav

viernes, 17 de junio de 2011

Cisco SECUREX, Next Generation....Architecture

Bien, en este blog he analizado algunos de los últimos productos que siguen la estela de Paloalto Networks.  Pero el gigante ha despertado, Cisco enseña sus cartas.(Actualización 18-06-2011)


Checkpoint por ejemplo, uno de los firewalls convencionales que más me gustan para entornos distribuídos, ha sufrido el problema de una maquinaria lenta y anquilosada.  Esto lo ha confirmado el mismo fabricante en la revista SIC. Checkpoint está dando un giro admitiendo que la visibilidad en la red tenia que ser mejorada, pero tiene varios problemas:

  1. El primero es que ha maltratado al canal con unas condiciones de mantenimiento Draconianas. Al final eso seleccionaba el canal, garantizaba unos ingresos importantes,  pero al final el cliente tenia una percepción de CP muy inferior a la calidad real, debido a la imposibilidad(a la práctica) de abrir casos directamente. Así que la mayoría de las instalaciones se aguantaban con pinzas. Y sinó, ¿cuántas veces hemos visto, firewalls CP en activo-pasivo por que el técnico no sabia solucionar el problema de mac multicast de uno de los modos de activo-activo?
  2. El segundo, que son dispositivos muy orientados a multinacionales y que en el resto de segmentos, se habían quedado muy atrás.
 Fortinet, en un artículo de su CEO, reconoce que ahora están evolucionando y que ahora quieren adquirir una empresa que les aporte futuro. Parece que solo ganan las batallas con firewalls convencionales... y cuentas pequeñas.
Pero, ahora viene el notición. Al menos para mí.(gracias VICTOR)
Parece que CISCO ya tiene su respuesta. Y no estamos hablando de una start-up de cuatro estudiantes en un garaje. La propuesta de Cisco se llama SECUREX(Sí, tiene nombre de condón). Promete hacer varias cosas que hace muy bien los PAN....y algunas más.
Seguramente, se acerca más a la seguridad normativa clásica, en la cual tiene en cuenta TODOS los activos de la red. Un ejemplo, seria si una persona está en el edificio o está de vacaciones. Y este tipo de cosas. 
Pero a parte de que solo conozco lo que dice en la web Cisco securex, la clave sería ver cuantos elementos hacen falta para que esta arquitectura funcione.  Si se trata de un ex-Cisco MARS+ASA+HIPS+IDP+Cisco Works+NAC, seguramente es más sencillo, reconfigurar una IOS para que comporte como un Paloalto.
Si es un appliance que hace todo eso, habrá que seguirlo. Evidentemente si está basado en IOS y no han hecho un refrito de FINESE(ahora ASA) versión UTM.  En la web, a veces parece una arquitectura y otras una tecnología que incorporan los ASAs(Ojo con la madurez de la solución). Los betatesters pueden sufrir bastante o cisquearse para siempre. 
Aún así tendremos que ver precios, cumplimiento de expectativas y evolución de PAN que en cada versión saca un conejo de la chistera.
Por cierto a PAN, le pediría que hubiese una parte de soporte abierta para no partners. Así como carta a los reyes. A Cisco, que alguien me aclarase las dudas.


Actualización: Me temo que los peores presagios se han confirmado. Cisco, tiene todo esto en punto muerto, http://etherealmind.com/cisco-securex-empty-words/
Robclav



jueves, 9 de junio de 2011

CISCO PFR, Balanceo de líneas por aplicación

AVISO PARA NAVEGANTES: Este post es durillo de leer y asumo ciertos conocimientos sobre funcionamiento de los protocolos dinámicos de routing y la nomenclatura de algunas herramientas de la IOS.




Hace tiempo que quería profundizar sobre OER. Una funcionalidad que creía que no había evolucionado demasiado y que al principio no aportaba demasiado diferencial al margen de control sobre la utilización de las líneas basado en criterios arbitrarios. 
El escenario donde se puede plantear OER(o su evolución PFR)  es el siguiente:
Tienes dos sedes interconectadas por varios enlaces con características diferentes. Por ejemplo una línea dedicada de dos Mbps y dos ADSL de 16 Mbps. Quieres aprovechar las tres líneas, y en el caso de que una línea falle, que el tráfico desviado hacia esta línea sea automáticamente enviado por alguna de las otras dos líneas.
¿Cómo se resuelve habitualmente este escenario?

  • Creas un túnel GRE por cada conexión que tengas. Esto permitirá encapsular protocolos de routing que utilicen multicast y otro tipos de aplicaciones que de otra forma serian descartadas.
  • Activas EIGRP, que es el único protocolo interno de routing dinámico que permite balancear tráfico por dos líneas con propiedades diferentes. Esto se realiza mediante el comando "variance". Evidentente redistribuyes las redes directamente conectadas al otro extremo mediante EIGRP.
  • Sí, las líneas no son dedicadas, cifras el túnel GRE y todo su contenido mediante un túnel IPSEC.





Esta arquitectura, nos ofrece total seguridad, alta disponibilidad y balanceo de líneas desiguales. ¿Pero cuáles son las limitaciones entonces?
  • No podemos decidir que tipo de tráfico viajará por línea.
  • No podemos decidir la carga de cada línea en función de nuestros intereses. Por ejemplo, de tarificación, de criticidad de aplicaciones, de QoS...etc
  • No podemos decidir en como el tráfico entra por estas líneas, solo como lo enviamos nosotros.
  • No podemos decidir cambiar una aplicación por criterios como el tiempo de respuesta de una aplicación o el jitter. Con EIGRP, se hace por carga global de la línea.
  • Es necesario invertir muchas semanas de trabajo para emular algo parecido utilizando: IP SLA, EEM y policy-maps para lograr tener la flexibilidad y granularidad que nos ofrece CISCO PERFORMANCE ROUTING 
¿Pero cuál es la definición de CISCO PFR?
"Performance Routing (PfR) complements traditional routing technologies by using the intelligence of a Cisco IOS infrastructure to improve application performance and availability. This technology can select the best path for each application based upon advanced criteria such as, reachability, delay, loss, jitter, and Mean Opinion Score (MOS)."

Bien, entonces el resumen de PFR es que cumple con todo aquello que la solución expuesta anteriormente no hace. Asi que, si tenemos que balancear líneas iguales o no, podemos utilizar Performance routing, que se encarga de medir el rendimiento de las líneas con variables asociadas a aplicaciones. Dejando en nuestras manos la posibilidad de aplicar críterios propios en función de aplicación o tarificación por ejemplo. También destacar que interacciona con los protocolos de routing dinámicos existentes, modificando su comportamiento.

Pero, ¿Cómo lo hace para conocer las rutas y modificar el enrutado del tráfico?
Se basa en un esquema de cliente-servidor que le permite intercambiar información entre dos routers que lo tengan habilitado, y finalmente modifica el enrutado inyectando rutas o mediante PBR(Policy Based Routing). Es capaz incluso de modificar el comportamiento del BGP añadiendo AS para penalizar la entrada de tráfico por un camino por ejemplo. 
Por otra parte, es preciso personalizar alertas y limites de IP SLA en las que se basa para la toma de decisiones, y tener activado IP CEF junto con NBAR para reconocer las aplicaciones de forma básica.

Puedes encontrar más información en la web CISCO OER

Robclav


lunes, 6 de junio de 2011

Evolución del routing I

Hace unos cuantos meses me preguntaba cuál era la evolución o el siguiente paso de los protocolos de routing. El routing predictivo. Actualmente todos los protocolos de enrutamiento dinámicos se basan en algo que conocen. Estos incorporan mejoras respecto a y que se puede intercambiar de forma más o menos eficiente, teniendo en cuenta más o menos variables. Pero que pasará cuando los sistemas aprendan y tomen decisiones en función de la experiencia? El routing predictivo is out there.
RobClav

martes, 24 de mayo de 2011

Out of Topic: Colgado el cartel de completo los siguientes tres meses




Kub Solutions tiene colgado el cartel de completo durante los siguientes tres meses. Pero estamos intentando seguir incorporando nuevos freelance. 
Debido a esto, estamos buscando freelance séniors en Barcelona en redes, seguridad, linux o HP UIX. Tenemos varios proyectos pendientes de aceptar en función de si podemos garantizar el éxito y el plazo de entrega. Por otra parte, mi socio, tiene previsto algunos proyectos en sudamérica para después del verano. Después de una conversación con un colega del sector, creo que le vamos a perder el miedo a esto de coger el avión. Así que si alguien necesita soporte avanzado en alguna de nuestras áreas, poneos en contacto con nosotros para poder planificar las agendas.
Cheers,
RobClav

Primeros pasos con Aerohive

Robclav: Flujo configuración hives
Gents(And ladies?), he recibido un correo de E.Q comentándome que no encuentra documentación aceptable de Aerohive, y veo que es verdad. Os dejo un pequeño diagrama de flujo de configuración recomendada de estos equipos, y la primera página del capítulo de configuración de los hives. Os recomiendo que pidáis esta documentación vía la web de soporte del fabricante o mayorista.

Conceptos importantes:
  1. Los equipos llevan dos radios, se pueden utilizar para acceso o para wifi mesh. Otra opción es dedicar una radio a mesh y otra a acceso.
  2. La configuración es en árbol invertido, salen pocas opciones que se van ampliando conforme vamos creando ssids, perfiles, Qos o reglas de firewall.
  3. La configuración via el hivemanager, ahora es más sencilla gracias al nuevo asistente.



Chapter 11 Basic Configuration Examples
This chapter introduces the HiveManager GUI in Enterprise mode through a series of examples showing how to create a basic configuration of an SSID, hive, and WLAN policy. It then explains how to connect several HiveAPs to HiveManager, accept them for management, and push the configuration to them over the network.
Note: Although maps provide a convenient method for organizing and managing your HiveAP deployment, they are not strictly required and are not covered in this chapter. For information about using maps, see "Example 1: Mapping Locations and Installing HiveAPs" on page 142.
You can look at any of the following examples individually to study how to configure a specific feature or view all of them sequentially to understand the basic workflow for configuring and managing HiveAPs through HiveManager. The examples are as follows:
• "Example 1: Defining an SSID" on page 124 Define the security and network settings that wireless clients and HiveAPs use to communicate.
• "Example 2: Creating a Hive" on page 127 Create a hive so that the HiveAPs can exchange information with each other to coordinate client access,
provide best-path forwarding, and enforce QoS policy. • "Example 3: Creating a WLAN Policy" on page 128
Define a WLAN policy, which contains the SSID and hive defined in the first two examples. • "Example 4: Connecting HiveAPs to HiveManager" on page 129
Cable two HiveAPs to the network to act as portals and set up a third one as a mesh point. Put the HiveAPs on the same subnet as HiveManager and allow them to make a CAPWAP connection to HiveManager.
• "Example 5: Assigning the Configuration to HiveAPs" on page 136 Assign the WLAN policy to the HiveAPs. Also, change HiveAP login settings and—if necessary—country codes.

jueves, 12 de mayo de 2011

Migración a IPv6: Si vis pacem, para bellum






"Si deseas la paz, prepárate para la guerra". O dicho de otra manera, aunque creas que ipv6 no llegará pronto ,ves creando un roadmap de migración de tu red. El camino es largo pero con bonitas vistas.

IPv4 se acaba, y los BRICS(Brasil, Rusia, India, China y Sudafrica) no perdonan. Cuándo nuestros amigos emergentes, no tengan nuevas IPv4s migrarán a IPv6, y dudo que nuestras empresas no quieran seguir en contacto.

Bien hasta aquí la bofetada de realidad, así que ¿ahora que hacemos? 

Aplicar una Estrategia de Migración a IPv6
De forma global al dept de IT:
  1. Instauración de una política para el departamento de desarrollo que tenga como prioridad substituir las llamadas a dirección IP por nombre de host para facilitar la migración o la convivencia de ambas comunicaciones.
  2. Auditar las comunicaciones locales de los servidores para detectar las llamadas por IP entre sistemas. Por ejemplo entre frontales y servidores de soporte como bases de datos o ficheros.
  3. Comprobar que los servidores, aplicaciones y  appliance que tenemos soportan IPv6.
  4. Crear un entorno de laboratorio aislado para poder poner a prueba una maqueta de nuestra red y sistemas.
  5. Empecemos migrando entornos simples, homogéneos y controlados por nosotros, para ir implicando otros departamentos que tengan entornos de laboratorios para estudiar el impacto sobre sus sistemas.

De forma específica referente a comunicaciones:

  1. Solicitamos a RIPE un pool IPv6 suficiente para cubrir nuestras necesidades para los siguientes 5 años.
  2. Sino disponemos de DNS internos, solicitamos a nuestro proveedor de este servicio que habilite la resolución dual, en función del tipo de versión IP de la petición.
  3. Si tenemos DNS internos comprobamos que funcione con IPv6. Si queréis un consejo poner un Infoblox y simplificar vuestra vida.  
  4. Habilitamos en IPv6 en nuestras conexiones externas existentes, y las nuevas las solicitamos duales.
    1. Provisionamos 1,5G de Ram para cada ruta con IPv4 e IPv6 con todas las rutas de internet. O filtramos rutas simplificando.
    2. Si disponemos de un AS, privado o no. Publicamos nuestros prefijos IPv6 bajo el mismo.
    3. Habilitamos la familia IPv6 en los peers actuales. Pedimos a nuestras operadores que lo hagan también. 
    4. Las nuevas ADSL las solicitamos IPv6 directamente.
  5. Habilitamos nuevas DMZ con IPv6, heredando la config de la misma zona ipv4. Varios firewalls soportan crear políticas por zonas, esto nos puede simplificar mucho la vida. De todos modos si pueden estar en Tablas de enrutamiento separado, mitigaremos problemas de tráfico asimétrico con sistemas microsoft, por ejemplo.
  6. Migramos nuestras redes aisladas como DMZ, transporte, invitados, wifi o laboratorio.
    1. Esto nos permite empezar a tener un entorno en IPv6 puro. Pero en un chasis con ipv4 funcionando. Migramos los servidores de la dmz.
  7. Migramos el resto de infraestrutura por VLANS. 
    1. Utilizamos el método de duplicar vlans ipv6 y ipv4 para estructurarlo.
    2. Migración de impresoras y servicios auxiliares centralizados en servidores de colas.
    3. Migración de servidores y clientes con direcciones estáticas.
    4. Activación de DHCPv6, desactivación por política de autoconfiguración.
Hth,
Robclav





viernes, 6 de mayo de 2011

Comparativa de firewalls 2011. Mi cuadrante mágico

Me ha llegado un correo de José Luís que me comenta que esta pensando en actualizar sus firewall Stonesoft y cual sería mi recomendación. En tu caso concreto la clave sería que no estuvieses utilizando el multipoint entry para vpn basada en certificados. Según el escenario que me describes, puedes aprovechar el módulo de WAF que viene con los PAN que te protege contra las vulnerabilidades de esos servicios y en concreto contra cualquier tipo de ataques de vulnerabilidad del servidor cross-site scripting, injección de SQL, pero no de la programación de la web como los intentos de escalado de privilegios. Hay muy pocos WAF que te protejan de esto. Revisa el producto de WAF de IMPERVA que es el mejor.






Fabricante
SC
ST
SD
I
RU
FC
AA
ME
IPv6
FD
IDP
VPN
SSL
GC
OP
R
D
E
H
RobClavTotal
Paloalto
4
5
5
5
4
4
4
5
4
5
5
4
2
2
4
5
5
5
4
81
Cisco ASA
3
4
2
2
3
2
3
4!
4
3
2
5
5
2
3
4
5
5
4
61+4= 65
Juniper
3
4
2
2
4
3
3
5
4
5
3
4
1
3
3
4
5
5
5
68
Checkpoint
1
3
3
5*
3
D
2
1
2
4
2
3
1
5
1
4
5
5
D
45+5+D+D= 56
Stonesoft
3
3
3
4
3
D
2
1
2
4
2
5
1
5
3
4
5
4
D
54+D+D= 60
Fortinet(UTM)
4
2
4
4*
3
4
3
1
3
2
4
4
3
4
3
1
2
2
D
49+4+D= 56
Otros UTM
5
1
3
1
3
3
4
1
1
2
4
3
4
1
3
1
1
1
1
43



Notas en la puntuación:
* Algunos de sus últimos productos, no toda la gama.
! MTE, mediante firewalls virtuales, no sobre el chasis principal
D Lo desconozco si lo permite auque sea integrando un tercer producto. Los valoro como 3, para no adulterar el resultado.


Puntuación de 1 a 5, atribuíble al producto no a la implantación de la solución.
1.     muy insatisfecho, con esta información hubiese elegido otro firewall.
2.     Insatisfecho. No cumple los objetivos marcados.
3.     Satisfecho. Cumple la mayoría de objetivos.
4.     Muy satisfecho. Cumple todos los objetivos marcados.
5.     Por encima de sus expectativas. Lo recomienda como caso de éxito.


Leyenda:
SC.-Satisfacción departamento compras
ST.-Satisfacción departamento técnico
SD.-Satisfacción dirección
I.-Inteligencia en la detección de aplicaciones, métodos de evasion/ofuscación y tunnelling.
RU.- Reglas de seguridad, nat, qos, ipsec o url filtering por usuario.
QoS.- Gestión de la utilización del ancho de banda disponible.
FC.- Capacidad de creación de reglas complejas de filtrado de contenido. (Control parental de navegación)
AA.- Antivirus, detección de ataques de dia 0, keyloggers, troyanos y virus de red.
IPv6.- Preparado para afrontar los nuevos retos de IPv6.
MT.-Múltiples tablas de enrutamiento, para implementar doble pila IPv4-ipv6 sin problemas de asimétrias por vlan. De esto puede depender el éxito de la migración a IPv6.
FD.-Funcionalidades diferenciales. En el cuadrante mágico de Gartner lo que se denomina visionarios, que viene dado por la inversion en I+D+I.
IDP.- Detección y protección ante ataques basados en firmas o comportamiento.
VPN.-VPN convencionales del tipo LAN-2-LAN o mediante  cliente,  IPSEC o SSL
SSL.-Con cliente o navegador  con presentación de portal de aplicaciones, tipo citrix.
GC.- Gestión centralizada para multiples firewalls. Reglas multifirewall, reglas expecíficas, Actualización del software desde el servidor central, centralización de logs.
OP.- Costes operacionales de licencias de mantenimiento del firewall y facilidad de encontrar personal cualificado o formarlo.
R.-Rendimiento de los equipos con todas las funcionalidades en marcha.
D.-Cumplimiento de todas las funcionalidades que anuncia el datasheet.
E.-SLA de HA, Estabilidad del producto una vez configurado.
T.-Total de puntos por firewall
H.-Seguridad desde el host que se conecta. NAC




José Luís, mi recomendación es que pidas una demo(Gratuita y sin compromiso) de Paloalto y dejarás de tener dudas. Sino tienes una integradora de confianza, envíame un correo y se lo reenvío al mayorista que te ayudará a elegir una integradora que se ajuste a tus criterios.


Me comenta JL, que StoneGate esta a punto de sacar un nuevo firewall de nueva generación, veremos  que tal.

Crear un comentario o un correo si hay alguna puntuación que no estéis de acuerdo o si conocéis algo que yo no.
HTH
RobClav