Ponle gafas a tu Paloalto

Paloalto nace miope y tienes que ponerle gafas para no volverte loco. Y son demasiadas situaciones en las cuales tienes la sensación de no ver todo el tráfico, y tienes razón. Aquí van cinco de las más habituales, pero no las únicas.
Por defecto no dejan log:

1. Tráfico que pasa el firewall sin establecer la sesión.
2. Tráfico redireccionado desde una interfaz de servicio a la de gestión o Tráfico originado desde la interfaz de gestión pero que utiliza una ip de servicio del firewall.
3. Tráfico redireccionado en una interfaz de servicio por la activación de un servicio como GlobalProtect.
4. Tráfico de descubrimiento de red. 
5. El cajón desastre, Tráfico descartado por cualquier otro motivo que no sea la política de seguridad. Problemas de rendimiento en el dataplane, controlplane, saturación del interfaz, buffers llenos, políticas de protección de DDOS, protección a nivel de zona, PBF...etc 

Paloalto no ve todo el tráfico! En este caso, sí que ve el tráfico pero no deja ningún registro (log) de esos paquetes que ha permitido o denegado.
Por defecto las reglas solo dejan log del tráfico una vez ha pasado y has sido identificado en una clase de aplicación. Si el primer paquete o paquetes se permiten o descartan sin llegar a ser identificada una aplicación, entonces el firewall NO mostrará NADA en el LOG.  Esto a nivel de regla se traduce en la casilla de log at Session END marcada y la de START no marcada. Como recomendación para troubleshooting dejaría la de START marcada y la de END no marcada (al revés). Básicamente porque entonces tendrás log de TODOS los paquetes que crucen el Palo.

Inconveniente: cuando quieras hacer informes de navegación o el tiempo que tarda una aplicación, no podrás a no ser que tengas el inicio de sesión y el final.

La gestión de Palo es una caja negra para el usuario.

Pero de qué estoy hablando? Pues estoy hablando del tráfico que no queda registrado cuando utilizas una interfaz de servicio para gestionar el firewall. Puedes permitir el tráfico ser enrutado hacia la interfaz de gestión via el propio firewall y verás ese tráfico, aunque necesitarás una regla de seguridad para permitirlo a parte de las ACLs de gestión. Si por el contrario utilizas la ip de una de tus interfaces para gestionar el firewall, ese tráfico realmente es redireccionado mediante una policy based forwarding rule hacia la interfaz de gestión, y eses tráfico NO deja log.
Un ejemplo sería la activación de Global Protect en una interfaz de servicio que estés utilizando para gestionar el firewall también, como puede ser la interfaz externa o pública. Esto mueve el puerto de gestión automáticamente al puerto 4443, pero no deja ninguna política, o opción activa para notificarlo.

A la inversa, es otro ejemplo de tráfico interno al cual se le aplica una PBF pero que no queda ningún registro del mismo. Dicho de otra manera, este el tráfico originado desde la interfaz de gestión pero que puedes elegir la interfaz e ip que quieres que utilice. 

Muy bien, pero todo esto es interno y no puede ser afectado por nada, no? Pues No, bajo algunas circunstancias te puede afectar y necesitarás ver que pasa con el tráfico. Así que SOLO se puede ver el tráfico hacia y desde la int. de gestión con el TCPDUMP que no tiene NADA que ver el Packet Capture del tab de monitor o CLI.

 Admin@paloalto1(active)# tcpdump filter "src net 192.168.0.0/24 and port 443"
Press Ctrl-C to stop capturing
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel

 De este modo, con TCPDUMP solo se puede capturar el tráfico de gestión y desde packet capture el tráfico de servicio. Pero No son lo mismo.

La penúltima categoría es incluso más rara que las anteriores, y se trata de tráfico por ejemplo de TRACEROUTE que atraviesa el firewall pero deja log en el firewall, pero que FALSEA el resultado que te dá la herramienta, o mejor dicho, oculta la existencia del Palo al mundo:
How to hide Palo Alto Networks firewall from trace route


Para esta categoría de tráfico descartado por otros motivos ajenos a la política de seguridad, hay toda una serie de herramientas, técnicas y contadores a tener en cuenta que voy a explicar en el siguiente post.

Ipv6: ¿Dónde estás? ¿Hola?

Hace tiempo que no comento nada sobre IPv6 y os advierto que viene una serie completa del tema. Eso sí, ahora le ha tocado a la Internet de las cosas (Todo aquello que no tiene que ver con los usuarios) ser el epicentro de las entradas de IPv6.
Pero vamos, contestando a la pregunta, dónde está IPv6 y cómo podemos seguir el avance. Espero excuséis el lenguaje formal....

La objetivación del estado de adopción de IPv6 de forma única o en modo de pila compartida la podemos obtener de dos tipos de Fuentes.

La primera fuente serían los organismos encargados de asignar IPv6 a los dispositivos o que lo monitorizan. Sin embargo esta fuente, ofrece una visión sesgada de la información. Esta afirmación se sostiene por el hecho de que un dispositivo que tenga asignado direccionamiento IPv6, no implica incondicionalmente que esté utilizando este protocolo de comunicación con otros dispositivos.

La organización que asigna direccionamiento IPv6, muestra el porcentaje de sistemas autónomos BGP con el protocolo activo. [6]

En la web, muestra un mapa interactivo con el número exacto de AS duales. España ostenta 378 AS IPv6 registrados comparado con 1197 de Alemania.

Algunas estadísticas de organizaciones que monitorizan el estado de despliegue puede ser el estudio llevado a cabo por la NIST (National Institute of Standars and Tecnology). La metodología de dicho estudio, se puede leer aquí. http://fedv6-deployment.antd.nist.gov/govmon.html

Las estadísticas son recogidas activamente, comprobando el grado de adopción en su entorno.

La segunda fuente del grado de penetración de IPv6 serían aquellos que tienen acceso a las estadísticas del tráfico real. Sin embargo esta fuente, también ofrece una visión sesgada de la información. En esta ocasión cabe observar que aquellos dispositivos pertenecientes a redes internas, traducidas a IPv4, o con comunicaciones transportadas sobre IPv4 de forma cifrada, no son visibles a las operadoras.

Clarificar que las redes internas,  pueden ser tan grandes como la propia internet, algunos ejemplos de redes “internas” de gran tamaño pueden ser:

·       Redes internas de empresas multinacionales que se comunican mediante redes privadas cifradas.

·       Redes IPv6 de servicio de las mismas operadoras.

·       Redes de transporte de operadoras independientes de los protocolos basadas en conmutación de circuitos.

·       Redes de telefonía para dispositivos inteligentes.

·       Redes M2M no contabilizadas como redes de clientes.

En referencia a la segunda fuente, podríamos distinguir cuatro bloques:

·       Empresas proveedoras de servicio online como Google, Yahoo, Microsoft, Amazon o Facebook .

·       Empresas proveedoras de conectividad como ISP u operadoras de telefonía como AT&T, NTT, Movistar, Vodafone o  Verizon.

·       Empresas de distribución de contenido(CDN) y protección anti-dDOS a nivel mundial como Akamai o Arbor Networks.

·       Organizaciones gubernamentales con competencias en las comunicaciones.

Entre estas fuentes, he escogido a Google por considerarla una de las fuentes más fiables para tomar el pulso al despliegue de IPV6, y lo hace en tiempo real. En la gráfica se distingue los usuarios de internet con tráfico nativo con IPv6 y aquellos que utilizan IPv6 pero utilizan como transporte entre sus redes IPv4 mediante túneles Teredo. Introducir una precaución en la interpretación de los datos mostrados, Google desde Europa parece omnipresente, pero en otros países los lideres del mercado son otros como puede ser Yahoo para EEUU o Baido en China.

En otra de sus gráficas se muestra el grado de despliegue IPv6 por países.

[7]

Referencias

 [6] [Artículo en línea][Fecha de consulta 14 Marzo de 2015]

<http://www.ipv6actnow.org/info/statistics/>

[7] [Artículo en línea][Fecha de consulta 14 Marzo de 2015]

<http://www.google.com/intl/en/ipv6/statistics.html>

Susto o muerte: Hacking ético o Intrusión

Habeis realizado alguna notificación a terceros de una vulnerabilidad de su web, su

aplicación o servidor ? En mi caso, lo he hecho en dos ocasiones. La primer vez fue tras visitar la web de un grupo de música. Lo primero que me llamo la atención fue la tienda online. Esta tienda permitía comprar productos del grupo ya que la música es gratuita.

Al ver el formulario, ya vi que la seguridad no era su fuerte. Permitía sin casi conocimientos de hacking:

• Fijar tu el precio de los productos mediante manipulación de parámetros (Proxificando).
• Revisar las compras de terceros.
• Ver los pedidos anteriores
• Manipular todo el código de la web para inyectar 

Bien, vista la gravedad de los problemas identificados pensé como notificarlo. Evidentemente no había ninguna opción para notificar un problema de seguridad. De forma que decidí enviar un correo que me respondieron sorprendidos pero agradecidos.

La segunda vez que he notificado vulnerabilidades graves, mi sorpresa ha sido identificarlo en una organización grande con reputados expertos. Evidentemente estos expertos no han participado en el ciclo de desarrollo seguro, ni han realizado ninguna auditoría de seguridad de caja gris.

El asunto es bastante grave porque la información que gestiona tiene precio en el mercado, existe una canal B donde venderla y la impunidad para hacerlo es absoluta. Por otra parte, las diferentes brechas permiten acceder a información critica por una parte pero sobretodo a información especialmente protegida por la agencia española de protección de datos. Aspectos como personas que han sufrido violencia de género, bajos ingresos, minusvalias... Etc.

La respuesta a la notificación, que moralmente debía hacer, pero que sabia que iba a causar malestar en la organización, fue políticamente correcta inicialmente. No proporcione los posibles vectores de ataque y el resultado hasta que estuve seguro que proporcionaba la información a personal interno y no a una tercera empresa que gestionaba el contacto center.

La respuesta a este segundo mensaje tardo en llegar. Además de la respuesta institucional, incluía un aviso para navegantes. En concreto me recordaba la política de uso y que existían sanciones para los infractores. Supongo que era una forma de solicitar que no comprobase ningún vector adicional. En uno de esos paragrafos hacia mención de que tenían identificados los vectores menos importantes y minimizaban los graves con un argumentaría propio de tertulianos de un canal de entretenimiento.

http://www.fbi.gov/news/stories/2014/june/gameover-zeus-botnet-disrupted

Resumen: Es cuestión de tiempo que tengan un incidente grave de seguridad al tener muchos atacantes con motivación económica que pueden acceder a sus plataformas y en segundo lugar, por la gravedad de las brechas y la facilidad de explotarlas (5 minutos).

Como sobrevivir (legalmente) a la contratación de servicios Cloud

Todo el mundo tiene en mente la nueva panacea, aquello que acaba con los problemas de los departamentos IT. Pago por uso, recursos hardware ilimitados, operación 24x7, backups, monitorización y cualquier requerimiento técnico que se nos ocurra. Pagas y lo tienes

http://sdtheory.s3.amazonaws.com

inmediatamente. ¿Pero donde está el truco? Si compro una infraestructura la amortización es muy corta, y luego no tengo coste, pero no tienes flexibilidad para adaptarte a nuevas demandas, recortas al máximo en servicios, el mantenimiento es reactivo y plazos de proyectos muy largos. 

Ahhh! entonces los SaaS, IaaS, PaaS,  y lo que se te ocurra, como Service no tiene contrapartidas?

Si no pagas se acaba la fiesta, pagas por todos y cada uno de los servicios extra, y muchas veces al tratarse de infraestructura compartida te pueden estrangular el tráfico o verte afectado por problemas de terceros.

Pero lo peor (también te puede pasar en tu infraestructura) son las Transferencias de Datos Internacionales con infracciones punibles y perseguidas por la Agencia Española de Protección de Datos(AEPD). Las multas pueden llegar a 600.000€

¿Que son las TDI?, cualquier tipo de información que viajen fuera de España. Eso incluye desde servicios como gmail, amazon, Office 360, pero también un CPD operado desde India, aunque los datos estén en España. Pero existen excepciones y acuerdos que nos permiten notificar que datos se van a transmitir, pero no es necesario esperar autorizaciones. Os adjunto las principales excepciones:

* Requieren de registro de los ficheros pero no petición de autorización Artículos 26 Directiva 95/46 y 34 LOPD)
*Servicios médicos
*Auxilio judicial
*Tratados o convenios internacionales.
*Transferencias dinerarias de acuerdo a su legislación
* Consentimiento inequívoco. (No confundir con expreso)
*Solo si lo acepta ambas partes.
*Aplicación típica en los empleado propios, que no necesariamente es por escrito.
*Información artículo 5 LOPD articulo 27 LOPD    
*Se debe informar expresamente que se va a ceder a un tercer país que no asegura la protección de sus datos. Artículo 44 del nuevo borrador.
*Se piden por escrito, locución o cualquier soporte duradero.    
*Consentimiento libre y revocable (No confundir con una información cualificada).
* NO PUEDE SER CASILLA PREMARCADA (o equivalente) porque requiere una acción simple por parte del usuario.
*Celebración o ejecución contrato celebrado o por celebrar
*Interés público necesario o legal (Legal o aduanero)
*Reconocimiento, ejercicio o defensa de un derecho en proceso.
*Desde un registro público a petición personas con interés legítimo
*País adecuado a nivel de protección

OT: Je suis Charlie

http://www.charliehebdo.fr/index.html

Cisco Nexus II;lejos de Blade Runner

·         Nexus 6000 cumplen con las funcionalidades de la familia 5000, siendo considerados puramente para Core o Agregación. Proporcionan soporte multicast, FCOE, VxLAN, baja latencia, 31 puertos de span, 256k de entradas para mac, arp , ipv6, multicast tipo 6500 y de rutas a host. El 6004 es un equipo modular que ocupa cuatro unidades de rack y el 6001 es compacto utilizando 2 unidades de rack. Soportan FCoE a 40GE, siendo puertos 10/40/100GE con un rendimiento máximo de 7,68 Tbps. No soportan puertos nativos Fiber Channel. Disponen de un completo juego de funcionalidades Layer 2 y Layer 3.

La familia 600 está compuesta por:

o   Nexus 6001 con capacidad para  48 puertos de 10GE y cuatro 40GE

o   Nexus 6004 con capacidad máxima de 384 puertos a 10GE o 96  puertos 40GE.

·         Nexus 7000 son equipos orientados a grandes Datacenter que requieran de capacidades avanzadas de routing en el core y virtualización. Un ejemplo de funcionalidades de este tipo que soportan son; mpls, lisp, vpc, fex, pbr, QoS, VDC o OTV. Sin embargo soportan 36 Tbps, siendo mucho más caro que el 6000, soporta ciertos módulos software de servicio como la NAM-NX1 o  ISSU  (Actualización en caliente del firmware). Resaltar que estos equipos soportan albergar subsistemas virtualizados y hasta 24 FEX conectados por chasis.

·         Nexus 9000 Es la familia equivalente a los Nexus 7000 siendo más económicos y con mayor capacidad de puertos. Estos equipos al ser tan nuevos e incorporar hardware no propietario de Cisco como ASICS Broadcom, no soportan ciertas funcionalidades que si realizan los Nexus 7000. Por el contrario es la familia indicada por Cisco para integración con la SDN denominada CISCO ONE estructurada sobre el estándar framework OPENSTACK www.openstack.org (Cloud software).

hth,

Robclav

Elige tu Cisco Nexus y hazte una polaroid !!

http://www.thecitrusreport.com/2011/headlines/behind-the-scenes-polaroids-behind-the-scenes-blade-runner/

"nexus m (genitive nexūs); fourth declension

1. The act of binding, tying or fastening together."http://en.wiktionary.org/wiki/nexus

Cisco Nexus, nexus, nexa, nexum, nexī, nexae, nexa(verbo). Es evidente que no es una palabra más, ni una escogida al azar por Cisco o por Google.  Nexus es una palabra con historia que viene del latín con fuerza, de la misma manera que palabras griegas utilizadas comercialmente como Nike(Naikí=victoria), Meraki-Hacer las cosas con decisión adecuadamente-(gracias Panos)...etc.

Pues esa palabra con tanto peso esconde tanto a los famosos replicantes de sexta y séptima generación como a la familia mimada de Cisco. Buscando fotos para esta entrada he encontrado estas fotos del rodaje que se hicieron sin caracterizar, pero muy autenticas, y que explica que el casting de los actores fue tan decisivo como el guión o la atmosfera de la película.

Creo que en nuestro día a día, como pasa con los cocineros los ingredientes son esenciales, y saberlos elegir y combinar, la diferencia entre el éxito y el fracaso de la arquitectura de la red. Pues para eso os doy desde mi punto de vista las claves de elección de las principales subfamilias de Nexus.

• Nexus 2000 conocidos como Fabric Extenders, se trata de simples "tarjetas" externas dependientes de un Nexus como el 5000, 6000 o 7000 que se encargan del control y data plane. No son capaces de pasar paquetes entre puertos, y hasta hace poco no soportaban FCoE, ahora sí. Se configuran desde el Nexus mayor, y no tienen ningún tipo de inteligencia.
• Nexus 3000 son equipos autónomos con conectividad Gigabit/10Gigabit y uplinks a 10/40GB, dependiendo de los modelos. Están diseñados para ser utilizados como switch “Top of the Rack” (ToR) en la capa de acceso del CPD para aplicaciones como High Frequency Trading o Web 2.0. Son sensiblemente más caros que la familia Nexus 2000.
•          Nexus 5000, formada por las familias 5500 y 5600. Tienen conectividad Gigabit/10Gigabit y uplinks a 10/40GB, con diferentes densidades dependiendo de los modelos. Pueden soportar routing mediante una daughter card. Una de sus características principales es que soportan puertos nativos Fiber Channel (hasta 96, dependiendo del modelo). Se trata de equipos pensados para situarlos en cada Rack como acceso (TOR) y en CPD pequeños. 

To be continued...

Google's Pluto Switch: SDN previo a Arista

Google es mucho más que unos locos que hicieron un buscador minimalista. Esto a estas alturas creo

que lo tiene claro todo el mundo. Creadores del mejor GPS navegador para coche que ha habido, creador de un nuevo sistema de indexación que en España llega a un 90% de utilización, google street view, google apps....es inacabable la lista de aplicaciones maduras que han llegado y las han desbancado desde la primera versión de producto. Pues en uno de esos ejercicios de creatividad y de punto de vista multidisciplinar, han creado su propia plataforma de switching con
inteligencia distribuída, fuera del hierro. Sí, una verdadera SDN con hardware que han comprado aquí y allá(broadcom como muchos otros para las ASICs).
http://www.wired.com/wiredenterprise/2013/03/big-switch-indigo-switch_light/
En este sentido os recomiendo mirar las webs de pica8.com o http://cumulusnetworks.com que son soluciones parecidas.  Según Wired este proyecto es la chispa que enciende el proyecto que hoy en día conocemos como Arista.
Hth,
Robclav

SDN: En la "Arista" de la Ola

Tengo que entonar el mea culpa respecto a Arista. Yo como muchos de los partners tradicionales de networking hemos estado anclados a la solidez y la solución de caja negra que eran los switches/routers. Se nos ha abierto una nueva forma de entender el networking, pasando el control a centros de toma de decisión
en equipos externos de orquestración o aplicaciones creadas ex-profeso.

https://gregness.wordpress.com/2008/10/24/recession-induced-network-innovation/

Cambiar de pronto tu forma de entender las redes es cambiar la medida de los proyectos, los conocimientos necesarios para abordarlos, la forma de realizar troubleshooting e incluso el interlocutor a quien le explicas el proyecto.
Hemos discutido habitualmente si era mejor JUNOS que IOS, por que IOS ha evolucionado a NX-OS o
IOS-Xr, pero cual es el motivo de fondo?
En mi caso parte del diagnostico era correcto, respecto a la disponibilidad en todo momento de la IOS y operación 24/7 pero no supe relacionar la importancia de la virtualización con las redes.
Los creadores de Arista Networks(Creadores de los cores de Catalyst), si que hicieron esa lectura y se adelantaron al futuro. Estos equipos permiten desde hace unos años, lo mismo que empieza a anunciar Cisco con los Nexus 9000 y la arquitectura orientada a aplicaciones: Cisco ACI.

Hth,
Robclav

SDN: El camino de networker a director de orquesta

LEONARD BERNSTEIN

Las diferentes disciplinas de la informática se reagrupan bajo el nuevo líder, la virtualización. Hoy en día ves un servidor físico y se disculpan "No tenemos las credenciales, es el servidor de fichar, pertenece a la red Scada...." y eso ha comportado un cambio sobre las expectativas del transporte. 
Los usuarios, esperan aplicaciones con buenos tiempos de respuesta de la misma manera que lo reciben de las operadoras. Si dentro de tu casa, tienes un CPD, si esta en la nube, servidores de respaldo y otras variantes no importan a nadie, y eso incluye a los financieros y a dirección.
Así que en esa linea de simplificación conceptual de las necesidades del IT interno, se dibuja el camino de la simplificación de la factura asociada. El camino trazado por otros servicios industriales, es el que creo que vamos a seguir. Hoy en día el valor de la explotación y mantenimiento de las infraestructuras de los edificios, no está en los equipos de mantenimiento sino en el diseño, el ahorro, el cumplimiento de normativo o incluso en elementos estéticos.
Por lo que cada vez más las SDN tienen más sentido. Imaginemos una empresa que con un solo técnico pueda operar toda la informática y comunicaciones de la casa. Si tiene un nuevo servicio, solo lo tiene que provisionar en una plataforma de administración y se desplegan numerosas políticas sobre los diferentes elementos. Un ejemplo lo tenemos en el abandono del lenguaje ensamblador por lenguajes orientados a objetos. Y en caso de problemas, dando acceso al SDN a los diferentes centros de soporte podemos ser asistidos. 
Entonces, cuánto nos queda para ser Directores de orquesta?
Hth,
Robclav

Vuelta al estilo anterior

Vale, vale, el nuevo formato no ha gustado. Así que vuelvo a dejar el Blog en el formato anterior ;)

Cómo sobrevivir a la arquitectura de Nexus con Enhanced vPC

La familia de Nexus está creciendo mucho en estos últimos tiempos, incorporaciones de producto pero también de funcionalidades. Y además se trata de un producto que no ha nacido en la arena de los
networkers y rompe con los estándares de facto.

Uno de los principales problemas que se nos presenta es como diseñar la arquitectura. Si no te has peleado antes con esto, te recomiendo que te armes de paciencia y busques un diseño homologado por Cisco y firmado por el Papa. Sinó, es muy probable que te encuentres con todo tipo de incompatibilidades, comportamientos erráticos y afectaciones de servicio por actuaciones de mantenimiento.

Un ejemplo claro es: Como montarías la capa de agregación y acceso de una red de Catalyst? Pues no lo hagas en Nexus, es muy probablemente incompatible. De donde nacen los problemas? De su principal virtud, el multipath en forma de Virtual Port channel, lo que en Catalyst sería un trunk contra una pareja de equipos en VSS.

Cosas que no puedes hacer:

1. No hagas vPC en el servidor dual homed y también en los uplinks de acceso a agregación.
2. No hagas vPC en el servidor dual homed y también en los uplinks de acceso a agregación si solo hay un equipo de aggregación.

Cosas que si puedes hacer:

1. Haz vPC en el servidor en teaming NICS(Una activa y otra en standby) y también en los uplinks de acceso a agregación.
2. Haz vPC en el servidor dual homed y vPC en los enlaces de un equipo de acceso que conecta a un solo equipo de agregación.

Que pasa si no sigues estas reglas. Que se bucla el tráfico de la red, que el rendimiento es pobre....

Por otra parte, si quieres conectar Nexus 2000 a dos equipos, tienes que mantener manualmente la configuración sincronizada en los dos equipos de agregación a los que se está presentando. Ya que se trata de un simple extensor de puertos y no de un switch con entidad propia. La configuración de los 2000 no se propaga entre los nexus (5k/6/k7k) en lo que se refiere a los 2000.

Fuente: Cisco Nexus 5000 Series NX-OS Operations Guide, Release 5.1(3)N1(1)
Debo agradecer a Alfonso Lopez esta entrada que me ha proporcionado el documento y también la visibilidad de los problemas.

Hth,

Robclav

Catalyst Instant Access Solution: "Nexunizando" los Catalyst

Si los clientes no van a los Nexus, los Nexus van a los clientes. Estos es lo debe haber pensado Cisco cuando ha copiado el funcionamiento de Fabric para los Catalyst.

Que los Nexus no tienen funcionalidades de pacificación y control del tráfico, pues pasamos el fabric a los Catalyst pero con Spanning tree,  y ya tenemos un big switch.
A que precio? Pues un core basado en 6500 o 6800 y acceso basado en 68xx.  
Ventajas(De Cisco directamente):

• Single point of configuration and management

• Single software image across distribution and access

• "Plug and play" provisioning of access switches

• Agile infrastructure at the access layer, with feature and hardware consistency

• Automatic uplink configuration at the access layer

• Automatic image provisioning of access switches

• Rich and consistent Catalyst 6500/6800 Series feature set across distribution and access layers

Resumen, un VSS(un único switch virtual distribuído) que agrupa toda tu red (Hasta 1008 puertos de acceso), en un solo switch, multipath, un solo upgrade en caliente para todos los switches sin disrupción, seguridad, QoS,  y visibilidad centralizada.

Además de este cambio, Cisco ha introducido las familias 3650, 3850, 4800, 6800 con controladora wifi integrada en algunos casos, enlaces a 10 y 40 G, non stopping...

hth

Robclav

NetExtender VPNSSL: Problema con el bloquear los PopUps

Hola,
el otro día estuve reinstalando el cliente VPNSSL de un Dell sonicwall. El cliente ligero que

descargas cuando accedes al portal, con cada nueva actualización de sistema operativo, deja de funcionar.
Al principio, no sabía porque fallaba la conexión, cuando el cliente continuaba instalado. Después de muchas vueltas, active el modo debug del cliente VPNSSL de Sonicwall. 
El resultado fue inmediato, deja de funcionar porque debe aparecer una alerta que no se confía en el emisor del certificado del concentrador.
En otras palabras, aparece un pop-up con una advertencia de sitio no confiable, la aceptas y funciona. Pero en el log convencional, únicamente aparece un mensaje de que no se puede conectar.
hth,
RobClav

The fence sitters: La moda anti vacunación en la seguridad

Me resultaba curioso, hablar responsables de infraestructura que te dicen que a ellos no les preocupa

la seguridad, y que nunca se han visto comprometidos. Durante un tiempo, he pensado que quizás tenían razón porque si no utilizaban casi medidas de seguridad, o eran completamente inoperantes como podía ser, que no se hubiesen visto comprometidos.
Al final he llegado a dos conclusiones, muy importantes:

• Las mismas operadoras y en algunos casos la redes públicas de comunicaciones están "limpiando" el tráfico para muchos clientes, infundiendo una falsa sensación de seguridad. 
• Muchos se han visto comprometidos y no lo saben, o simplemente no aceptan su parte de culpa o echan pelotas fuera.

Este fenómeno social de negación de la realidad tanto por falta de información(formación), como por exceso de la misma, ha sido documentada por Julie Leask y publicada en la revista NATURE.

http://www.nature.com/nature/journal/v473/n7348/abs/473443a.html

Artículo completo publicado en Nature

Este artículo no habla, de la seguridad, sino de los grupos anti vacunaciones. En los países desarrollados suelen ser personas con desconfianza hacia los oscuros intereses de algunas farmacéuticas, como se pudo confirmar con la gripe A. 

En los países subdesarrollados, suele ser debido a rumores(falta de formación) o por casos reales de abusos y ensayos no autorizados sobre población sana de tratamientos experimentales.

Sin embargo, cuando algunos de estos profesionales argumentan el motivo por el cual, no quieren ciertas protecciones o porque no lo necesitan, suelen poner el mismo ejemplo que los grupos anti vacunaciones de los países desarrollados. Con una salvedad, en el caso de la no vacunación, la ausencia de las enfermedades en las poblaciones nativas de los países, hacen una falsa validación de estas pseudo-teórias, y en la seguridad, el trabajo de muchas empresas que no comunican sus incidentes de seguridad, hacen lo propio en este campo.

hth,

RobClav

Darknet: Facebook venderá más información privada comprando WhatsApp.

Cuantas veces has buscado cosas en google y has visto que no están indexadas? Buscan en otros

buscadores menos populares y en la cuarta o quinta página aparece el contenido?
Back to basics, Internet ya no es "la red de redes" que muchos de nosotros ayudamos a construir. 
La respuesta es clara, NO.
En España, pecamos de cómodos y conformistas, y nos estamos creyendo que lo que vemos es lo que hay, cuando lo que no vemos es lo que realmente ha construido lo que hay.
La noticia de la compra de Whatsapp por parte de Facebook, desde luego es otro ladrillo en el muro (another brick on the wall). En el muro entre los estados, organizaciones y los ciudadanos. Es otro paso en la venta de la información privada, hábitos, tendencias, esperanzas, orientación sexual, políticas y credos. 

Es todo aquello que la red creada por y para el pueblo, no debería permitir ni ser usada. Y esto es solo el principio. 
Así que os dejo unas cuantas herramientas para no dejar rastro, para ver sin ser vistos y para encontrar aquello que no quieren que sea encontrado.
-Telegram. Bajate esta App, es como whatsapp, cifrada y en principio sin vender tus datos.
-Tor project (Onion project) como navegador en capas, para navegar sin dejar trazas.
-Safe-mail, correo anónimo cifrado. No comercia con tus datos.

Banda sonora de este post. Pink Floyd. Another brick in the wall.

hth
Robclav

DLP Full live circle: Control de los ficheros fuera del perímetro

Parece mentira pero el talento, la innovación y los buenos productos no entienden de fronteras. Y en

estos últimos meses, me he llevado sorpresas muy agradables con productos que complementan los proyectos de DLP.
En concreto, Protección-Online (Prot-on) y SealPath. Ambos aplicando cifrado o DRMs de Microsoft consiguen audidar en todo momento y en cualquier sitio. Quién hace que y dónde con los ficheros protegidos.
Claro que estamos hablando de ficheros, que previamente tienen que haber sido tratados para asignarles permisos, y las propiedades de compartición. Estos dos productos pueden funcionar en la nube o on-premise, con diferentes grados de integración con la empresa. Prot-on está más orientado a los usuarios, con versiones gratuitas y una interfaz más propia de una red social que de una aplicación de seguridad.
Seal-Path, nace del empuje de dos ex-Pandas software, que tiene muy claro la relevancia de garantizar el control de todo a los administradores y tiene una aproximación más empresarial. En el caso de SealPath no require de agentes para los datos, pero si para las imágenes y en el caso de Prot-on, el mismo cliente sirve para todos los ficheros. Por otra parte, cabe destacar que al compartir un fichero con alguien, se puede decidir aspectos como que no pueda imprimir, copiar y pegar, o que solo pueda acceder una horas. Los dos productos son compatibles con las principales plataformas como PCS, tablets móviles...etc.
Estos productos se instalan en cinco minutos, y son muy efectivos dentro o fuera de la organización. A diferencia de los proyectos de DLP, que son una cara, larga, inútil y frustrante elección.

VSS Monitoring: Mete un Traffic Redirector en tu vida

Vuelvo y vuelvo con algo que puede revolucionar la forma te diseñar las redes :VSS monitoring.Hacia bastantes meses que nada me parecía suficientemente rompedor como para explicarlo en el blog. Y ha
llegado mi musa. Un fabricante que hace algo no muy glamuroso, pero muy útil. Es uno de esos equipos que puedes prejuzgar como un simple TAP, sniffer o balanceador, pero es como comparar un router con un pisapapeles.
Si bien es cierto que la mayoría de los clientes sufren la limitación de los switches de número de sesiones de port-mirroring(SPAN o TAP), es fácil superarlo gracias a elementos externos que dupliquen el tráfico en dos puerto, los TAP. Pero los vProtector van mucho más allá, además de contar con otros hermanos como los vInspectors que abren el tráfico SSL...etc

Pero que hace? Intercepta el tráfico que nos interesa, de tantas fuentes como queramos y lo envía a uno o más destinos. Esto se traduce en una arquitectura limpia, escalable, carrier class y simple. Arquitectura limpia, al no necesitar meter cien mil equipos en linea.  Escalable, ya que no puedes añadir tantos equipos de estos como quieras, y con ellos reenviar el tráfico a muchos otros equipos. Carrier class, porque se comprueba que todos los servicios a los que reenvías el tráfico estén vivos y trabaja a nivel 1 en caso de fallo. Y finalmente simple, el tráfico de esta red, de esta otra y el de navegación, solo, de la otra, la reenvías al servicio del puerto x en el servidor y. Sino pasa sin tocar el tráfico.
Estos equipos, al final minimizan los cortes del tráfico de la red, las intervenciones nocturnas, el tiempo para introducir un nuevo equipo de análisis en la red.
Nota para Newbes: Carnivore es la infraestructura de interceptación legal de nuestro amigos del NSA, antes de que las propias CDN, proveedores de servicios y redes de servicio lo hicieran directamente.
No estoy afirmando que este sea el producto que hayan utilizado con este propósito, solo que es la misma base.
Hth,
Robclav

Tendencias Globales: DataCenter-In-A-Chassis

Wild New Design: Data Center in A Silo

Hola, antes de hablar de nuevos "juguetes" o locuras varias, me gustaría preguntar por los productos/tecnologías emergentes en vuestro entorno. Sí, seguro que pensáis que en todos sitios es igual, pero si hay soluciones/productos "on-fire" en vuestro entorno. Haz un comentario en este post o envíame un correo.
A parte de eso, después de leer las tendencias de Gartner del 2009. Veo que ha nosotros nos están llegando en 2012/3/4, de forma que leer el informe del 2013 es ver el futuro ;)
Una de esas tendencias es la consolidación de lo que llama Cisco bloques funcionales autosuficientes. O dicho de otra forma servidores, switching y almacenamiento en una unidad lógica.  En el esquema que adjunto se puede ver una locura que me suena a 2001 Odisea en el Espacio. Pero se trata de un CPD que ha diseñado la gente de SUN, y se trata de CPDs en forma de silos (Sitges, es una curiosidad de la traducción local). 
http://www.datacenterknowledge.com/archives/2009/12/10/wild-new-design-data-center-in-a-silo/
Evidentemente, parece energéticamente muy eficiente y a nivel de operación susceptible de una automaticación completa. De la misma forma que tenemos almacenes completamente robotizados, por que no los CPDs con SDN??
Imaginando, a los operadores humanos en el CPD en atmósfera cero, podría ser que Kubrick supiera algo que nosotros no?
Un día de estos os hablaré de otro hobby que tengo, la robótica.
Hth,
Robclav

Software Defined Networks: Recuerda este nombre

La virtualización o abstracción de la parte hardware es consustancial a la informática. Desde los primeros ordenadores, se buscó la independencia de la arquitectura y organización hardware de los modelos de Von Neumann y Harvard. Y este proceso sigue su camino en forma de virtualización de escritorios, aplicaciones, servidores, almacenamiento, balanceadores, firewalls y todo aquello que está por encima de capa 3. 

http://enterprise.alcatel-lucent.com/?dept=Editorials&page=2013GartnerDataCenterMQ

¿Cómo acaba la película? Con la parte de switching y routing desnaturalizada en forma de silicio de conmutación anodino. En todo esto, los servicios ofrecidos en la nube han empujado con fuerza, la necesidad de sistemas de provisión que no solo levantasen máquinas virtuales, más cpus o memoria, sino también mayor número de puertos físicos, seguridad y QoS asociado a diferentes flujos.

Lo curioso de todo es que ya existen frameworks como NOX y plataformas para SDN de Cloud como Meridian que dan forma al concepto. Y fabricantes de multilayer switches que tienen separada la parte de dataplane y controlplane, y que mediante una controladora se toman las decisiones. Es el caso de Xsigo que ha sido comprada por Oracle. 

Por otra parte, la SDN además de separar la capa de "data plane" de la parte de toma de decisiones, comporta otro salto evolutivo muy importante, que apoya los pasos hacia las reglas reputacionales. Se trata de automatizar las acciones de provisión y remediación en función del comportamiento del tráfico extraído con OpenFlow. Esto es trasladar a la parte de transporte, el comportamiento de profiler/auditor del NAC.
Mi opinión es que de la misma forma que ya no se programa en ensamblador, y se utiliza un lenguaje de alto nivel, en networking, ya no se programará en CLI, sinó en un lenguaje de alto nivel de redes. 
Este post es mi resumen  de una serie de artículos de la revista de Communications IEEE de Febrero 2013. Así que si supongo que en la web, también podéis encontrar mas info, respecto a las empresas que trabajan con SDN habían muchas en el MWC
como Tellabs.  
Hth,
Robclav