JUNIPER JUNOS VS CISCO IOS

JunOS vs IOS: Estos días estaba preguntándome cual de los dos sistemas operativos era mejor. No hay duda, JUNOS. Otra cosa es comparar la fuerza de las empresas o su marqueting...
Dicho esto, los primeros pasos se pueden hacer leyendo Day one Configuring JUNOS Basics en la web de Juniper. Solo haciendo una lectura de los títulos publicados, se aprecia la facilidad en operación que proporciona JUNOS en el día a día comparado con IOS. Lo siguiente es la traducción de un artículo auto explicativo, disfrutadlo!

"IOS tradicionalmente es un sistema operativo monolítico, lo que significa que se ejecuta como una sola operación y todos los procesos comparten el mismo espacio de memoria.Debido a que esta última característica, los BUGS (Corrección 28/03/2011) en una sola operación puede tener un impacto en otros procesos. Además, si un usuario desea activar opciones o funcionalidades del sistema operativo, La IOS tiene que ser reiniciada, para que la funcione correctamente la funcionalidad o el upgrade.

JUNOS, a diferencia de IOS, fue construido como un sistema operativo modular. El núcleo está basado en el código abierto del sistema operativo FreeBSD, y los procesos que se ejecutan en forma de módulos en la parte superior del núcleo son segregados en espacios de memoria, protegidos, y dedicados. Así los usuarios pueden activar opciones  y funcionalidades de la versión de JUNOS en ejecucción en el sistema, sin desactivar todo el sistema operativo - una característica conocida como el servicio de actualizaciones de software-en el que también mejora el tiempo de actividad y disponibilidad.

El objetivo de las nuevas versiones de Cisco IOS - IOS XR, XE IOS y NX OS - es superar las limitaciones monolítica de la IOS  y la necesidad creciente de máxima disponibilidad. Todos estos nuevos sistemas operativos son modulares, en los que los servicios o demonios de IOS se ejecutan en forma de módulos en la parte superior de un núcleo basado en Linux (en IOS XE y NX-OS), o en un sistema operativo de terceros fabricantes (POSIX) con kernel en tiempo real (en IOS XR).

"[Se trata] absolutamente, de el paso en la dirección correcta" para Cisco, dice Doyle. "Cualquier cosa que nos acerque a una arquitectura modular, hará que suframos menos por tener una mayor fiabilidad. Cisco es muy consciente de las responsabilidades de la IOS en términos de ser una arquitectura monolítica. La misma que creo que verás que morir". Jeff Doyle.

El objetivo de la nueva arquitectura de las nuevas versiones de IOS, es eliminar del núcleo todos los procesos que no son absolutamente necesarios para ejecutar en él. En su lugar, se ejecutan como procesos modulares, como se ejecuta aplicaciones en un ordenador o en JUNOS.

De esta manera, el Linux FreeBSD con el que ha sido desarrollado JUNOS, basado en núcleos, ayuda a facilitar la modularidad, alta disponibilidad y virtualización de servicios. 


NOTA RoblClav 28/03/2011: También hay que decir que las dos o tres primeras veces que configuras JUNOS se hace muy complicado encontrar donde esta cada cosa. Básicamente el problema estriba en la estructura de la configuración que no sigue la lógica de CISCO sino, de los procesos.
Por poner un ejemplo, configurar una agregación de enlaces, por una parte tienes que lidiar si o si, con la estructura abstracta obligatoria de las units(entes virtuales) , luego anunciar que interfícies participan de este modo y a nivel de protocolo de nivel 2 como lo hacen, y luego ir a la interficie lógica resultante para configurar los parámetros. Vaya un lío viniendo desde CISCO pero claro desde el punto de vista conceptual. 
Junos es más potente, pero más dificil. Cisco es limitado pero más simple.
HTH,

Robclav


Leer más de Junos vs IOS:Resumen-de-junos-vs-cisco-ios.html

Descubriendo los Cisco CSS(Content Services Switches)

Estos días he estado desconectado del blog intentando cerrar proyectos y con algunas tareas diferentes. En concreto he iniciado una nueva etapa como "trainer" oficial. Después de unos cuantos meses sin hacer formación específica, he vuelto con un curso de los balanceadores de carga CSS. Así que os dejo aquí, el resumen de los conceptos interesantes, que fuera de la materia habitual no se tienen en cuenta en la implantación/mantenimiento de los mismos.

Los Cisco Content Services Switches (CSS) fueron renombrados tras la adquisición de Arrowpoint technologies por parte de la empresa de San FranCISCO.  Los CSS son balanceadores avanzados de carga externos a los servidores de contenidos, y no son simplemente unos substitutos de la clusterización de los servidores. A parte de recibir la petición de conexión por un puerto específico, tomar la decisión de a que servidor reenviar la petición y comprobar que ese mismo servidor este operativo como haría un cluster puedes "conducir" las sessiones como desees.

1. Ejemplo de  keepalive, La comprobación del servidor esta basado en recuperar un string de la cabecera web una vez te has validado en la conexión https. Por lo que aunque el servidor este funcionando, si el demonio web y el contenido de la web no, este servidor no recibirá tráfico. 
2. Ejemplo de persistencia de session(Stickiness) y servidor(Persistence). Puedes asegurar que un cliente cuando establece una sesión de ecomerce en la web, no se reenvíe a un nuevo servidor hasta que se finalice la compra(Stickiness). Si nos interesa, ese cliente, para cualquier tipo de protocolo o tráfico, ftp, http, ssh..etc, siempre consultará al mismo servidor(Persistence).  Y también se puede elegir la forma de comprobar que el mismo origen, algunos ejemplos serían por ip origen, id de la sessión de SSL, cookie de los servidores de contenidos, una cookie que inserta el propio CSS(Arrowpoint-cookie), identificador de un campo de la URL único...etc. Sin olvidar, que también se puede hacer que todas las peticiones de tráfico sean rebalanceadas, para los servicios numerosos y breves como DNS o NTP. Se puede configurar la acción a realizar en caso de fallo del servidor destino: enviar hacia un (Sorryserver) servidor con un mensaje genérico, rebalancear, descartar la petición...etc
3. Otro ejemplo, que no puedes hacer con un cluster, es tomar la decisición de balanceo en función del idioma del navegador o versión del mismo,  en función de la url, de si es contenido cacheable para enviarlo a caches o no.
4. Finalmente, comentar los diferentes algoritmos para repartir el volumen de conexiones se pueden basar desde Round Robin hasta el ACA propietario que mide los tiempos de respuesta, pasando por reparto asimétrico basado en pesos, o enviar las peticiones al más libre.
5. Los CSS pueden descargar a los servidores finales de la parte de cifrado SSL con los clientes, o reenviando las conexiones hacia appliance ex profeso.

Hasta aquí podemos decir que se pueden apreciar las diferencias con un cluster convencional a la hora de garantizar la disponibilidad del servicio. Y resumiendo su comportamiento, actuan como un router con gran capacidad de Policy Based Routing, con IP SLA de comprobación de los servidores. Pero los CSS también evitan los ataques de DDOS, los barridos de puertos, ataques basados en vulnerabilidades de los protocolos...etc. Y otra funcionalidades, supuestamente auxiliares pero que pueden facilitarnos la vida.

Los CSS pueden actuar como servidores DNS autoritativos para nuestros dominios. Los dominios los podemos mover entre diferentes grupos de CSS, siendo anunciados desde los contents su existencia(A parte de el root del dominio, evidentemente). Para aquellas peticiones de dominios que no conozcan hablan con otros servidores, para resolverlas, de forma que en nuestra red ellos son los DNS. Por otra parte, con la licencia adicional, se puede configurar el network proximity. Esta funcionalidad consiste en balancear las peticiones al dominio, entre los diferentes grupos de CSS repartidos por países. Por ejemplo, estamos albergando www.paloaltonetworks.com en Barcelona. Una petición hacia este servidor nos llega desde EEUU, y disponemos de una pareja de CSS en ese país; pues por defectonuestros CSS resuelven el dominio con la ip pública del "Content" de EEUU ya que se prioriza servir el contenido con los CSS locales. Para que esto funcione, se definen "zonas" geográficas. También se puede balancear a nivel de resolución DNS para nuestros dominios, en función de los CSS que tienen menor carga o aquellos que no nos tarifiquen por las líneas.

Trucos y consejos:

• Como herramientas útiles a la hora de utilizarlos, es recomendable simplificar la configuración utilizando los objetos y grupos de objetos. EQL(Extension Qualifier list), NQL(Network Qualifier list), DQL(Domain Qualifier list) y host(para definir una traducción nombre-IP).
• Ten en cuenta que los CSS son routers, y si no configuramos ACLS tendremos todos los servidores expuestos.
• Para modificar una ACLS, hay que desactivar su uso, desaplicarla de los circuits(Vlans) y volver a activarlo en los circuits y luego a nivel global.
• Solo se puede tener un Source Group(NAT origen de los servidores de contenidos) activo, y por lo tanto se recomienda utilizar una VIP que es con la que se traduce la conexión origen dedicada.
• El nat de los clientes, se considera premium y se tiene que pagar mediante correspondiente licencia.
• Todo el tráfico es procesado, estos equipos no tienen ASICS, por lo que el debug no afecta al rendimiento. Así que se habla de "flows" y no de conexiones...
• Estos equipos están pensados para www y DNS, y junto con el motivo previo, CISCO lo ha puesto están en vía muerta. Creo que la CSM, se continua vendiendo.
• Para activar el debug, hay que estar en modo configuración de terminal, escribir "llama" o combinación "ESC"+ "x". Cambiará el prompt a DEBUG y hay que jugar con los comandos flow trace-IP x.x.x.x para seleccionar el tráfico a debugar, luego cambiar el nivel de logs a debugging mediante flow option 0x00130(Si en hexa) y logging console o VTY X para que podamos ver los logs. Desactivar el debug es cambiar el flow option.
• Soporta hace de DHCP relay y activar un Port mirror o SPAN.
• El modo experto, solo sirve para evitar que nos pida confirmación cada vez que hacemos algo y para poder pegar con comodidad la config en modo texto, desde el CLI.

Robclav

Apple: El mito ha caído

Hace unos meses compramos unos cuantos Apple MacBook buscando no solo su diseño y sus aplicaciones, sino la fiabilidad de sus sistema operativo. El precio de cada portátil triplicaba el precio de sus competidores con sistemas Microsoft, pero vamos mirando el coste a medio-largo plazo (capex-opex) salía rentable.
Con la mirada puesta en garantizar la máxima disponibilidad, todo el software instalado en el mismo, por ejemplo el paquete de microsoft Office 2010, es propietario y licenciado.
Pues toda la teoría y el marqueting detrás de la manzana mordida se desmoronó hace tres días.
Un MacBook Air de 13" dejó de arrancar. No salió un pantallazo, o un programa no funcionaba. Simplemente el portátil no pasaba del icono inicial de la manzana. PEOR que un Windows 95 SP1. Por supuesto el mantenimiento solo es hardware, por lo que mirando en internet vi que el mismo problema se lo ha encontrado la mitad de la red...
Resumen, he tenido que restaurar sistema, eso sí me ha mantenido el software instalado y los datos de usuarios. NOTA: El Macbook air, no tiene conectores de red RJ45 o unidades ópticas DVD/CD. Por lo que solo tienes puertos USB para restaurar el sistema y guardar los datos.
 Os dejo los pasos que he seguido:

1. NO conectes el disco duro externo o la memoria USB todavía.
2. Dejar pulsado a la vez las teclas "Command" (CMD o manzana) y "s". Arrancará en modo mono usuario (Single-user mode), lo que vendría a ser un run level 3 en UNIX/Linux.
3. Una vez, nos devuelve el prompt solucionamos posibles problemas del sistema de ficheros, sbin/fsck -fy.
4. Ahora ejecutamos sbin/mount -uw /

5. Si el sistema de ficheros se monta en solo lectura, sigue al punto 7, sino puedes crear un nuevo directorio para montar el disco duro externo o el pendrive. mkdir /Volumes/midisco
6. Lista las particiones de tu sistema ls /dev/disk* y apunta las que tienes.
7. Conecta el disco duro externo o la memoria USB(Formateado con FAT32).
8. Lista las particiones de tu sistema ls /dev/disk* y busca que nuevo disco y partición ha aparecido.
9. Monta el disco externo o el pendrive: 
1. Si no has podido crear un directorio /sbin/mount_msdos /dev/disk0s3 /Volumes
2. Si has podido crear el directorio /sbin/mount_msdos /dev/disk0s3 /Volumes/midisco
10. Comprueba que has podido montar correctamente el disco ls /Volumes/midisco o ls /Volumes
11. Copia tus ficheros al disco o pendrive: cp /Volumes/MacHardDrive/testfile /Volumes/
12. Apagar el sistema y desconnexión lógica del disco o pendrive: shutdown -h now
13. Haz un comentario en el blog, acordandote de Steve Jobs y su marqueting.

Para restaurar el sistema, inserta el pendrive de restauración de sistema. Arranca el portátil y mantén presionada la "c". Sigue las intrucciones.

Siempre nos quedará el discurso de Steve Jobs en Standford.

stay hungry stay foolish (Steve Jobs' 2005 Stanford Commencement Address)

Robclav

Next Generation Firewalls: Eligiendo el futuro

Hace ya un tiempo ví un artículo de Gartner haciendo referencia de los next generation firewalls y al principio pensé que era otro recurso marketiniano para denominar nuevas funcionalidades o roles de los Paloalto Networks. No obstante, el mercado ha reaccionado sacando producto al mercado confirmando la apuesta de Nir Zuk, el producto se llama Checkpoint Application Control Software Blade. Sí, podemos considerar que es la amenaza más seria de los PAN. En este sentido, y debido a la arquitectura distribuida y la política de precios de CP es caro y de momento poco madura.


 Pero, volviendo a lo que nos ocupa, podríamos establecer una ruta evolutiva de los firewalls, teniendo el primer gran salto que hubo. Sistemas multipropósito vs sistemas monopropósito Firewalls,  ¿qué es lo diferencia un firewall convencional de uno considerado de nueva generación?
Para conocer la respuesta, voy a contestar con otra pregunta: Que diferencia un linux con IPTABLES de un firewall? Las respuestas pueden ser múltiples, pero algunas serías:

1. Iptables filtra tráfico de una dirección ip o red a otras IPs o redes en función del puerto(Capa 4). 
2. Las reglas son unidireccionales, por lo que aquellas aplicaciones que aunque conocido el comportamiento, no funcionarían de no habilitar la regla que permita la respuesta del otro sistema.
3. Solo aporta filtrado de conexiones hasta capa 4 (IP y puerto), no inspecciona el tráfico en búsqueda de virus, de malformaciones de paquetes, de utilización errónea del protocolo, no permite filtrar en función de categorización de URLS.
4. Muchas veces los procesos de NAT no están soportados o están limitados en utilización.
5. No implementa servicios adicionales perimetrales, como VPNs o QoS...etc

Y habría una larga lista de otras diferencias pero el resumen sería que es IPTABLES es una solución básica, no escalable e insuficiente en funcionalidades, teniendo en cuenta la evolución de las comunicaciones. Así que hasta ahora, se consideraba aceptable que:

• Los firewalls actuales, requieren de un conocimiento previo de la red y luego se pueden personalizar para cumplir con su cometido.
• Los firewalls actuales, han simplificado las reglas haciéndolas bidireccionales con la tecnología statefull. Algunos se basan el el puerto habilitado y otros inspeccionan los primeros bytes para identificar la aplicación, por ejemplo http.
• Casi todos los firewalls actuales, incorporan algunas o todas estas funcionalidades auxiliares: firmas de IPS, control de uso de los protocolos mediante ALG, antivirus, categorización de URLs, protocolos de enrutamiento dinámico, antispam, VPNs IPSEc y SSL, QoS. En este caso se denominan Unified Thread Management.
• Los UTM que han incorporado una serie de funcionalidades que permiten inspeccionar, filtrar, modificar los paquetes pero con un rendimiento pobre y lo que es peor, con limitaciones debido a los flujos de procesos que atraviesa el paquete para poder ser tratado. 
• Si un UTM, tiene una regla que permite el tráfico http por el puerto 80 contra un servidor que tenemos en la DMZ. El flujo que tiene que seguir el paquete seria, primero entra en el proceso de ACLS, luego pasa al proceso de detección de aplicación, luego al proceso enforcement de protocolo, luego pasa al proceso de NAT con el que ha sido publicado el servidor, después se le aplica la limitación por cliente de QoS, y finalmente al de enrutado a la DMZ y switching para entregarlo al servidor.
• Todo esto, debe ser procesasado, y el paquete reserva un espacio en memoria, por lo que los recursos del firewall UTM se ven rapidamente comprometidos y la latencia de entrega del paquete suele ser alta.

Bien, ahora ya hemos repasado todas las bondades de los cortafuegos actuales, pero entonces ¿qué más necesitamos en la securización de nuestras infraestructuras?

1. Identificar las aplicaciones de forma fiable, de forma que no se puedan aplicar técnicas de ofuscación de IPs, de tunneling o enmascaramiento. Este es el principal problema de los actuales firewalls. Y por otra parte, que las reglas se creen en función de la aplicación, no en función de puertos como hasta ahora.
2. Identificación de las personas detrás de las conexiones. De forma que podamos crear reglas inteligentes para un usuario móvil,o un usuario con múltiples dispositivos.
3. Disponer de la foto en tiempo real de que tráfico tenemos en la red. Eso quiere decir disponer de un cuadro de mandos que nos diga, que aplicaciones se reparten el ancho de banda, que usuarios son los que están detrás, si mi red esta bajo ataque, que documentos están siendo intercambiados, tengo fuga de información sensible????
4. A partir de información real del comportamiento de la red, filtrar por usuarios, por aplicaciones o por partes de las mismas. No solo por IP o puertos.
5. Tener todas las respuestas, y un único punto donde mirar cuándo algo raro pasa. 
6. Poder registrar y controlar la fuga de información para cualquier aplicación que pueda extraer estos datos. No solo web y correo. Por ejemplo, post en el Facebook, un tweet o un fichero intercambiado por skype.
7. Poder tener activados todos los filtros del tráfico, sea antivirus, ALG o firmas de ataques.
8. Poder hacer cumplir la utilización de los recursos de la empresa mediante filtrado en función de categorización de contenidos.
9. Y hacer todo esto sin latencia, ni colapsos del sistema, y sin tener en cuenta las posibles incompatibilidades entre funcionalidades debidos a los flujos.

En resumen, los firewalls actuales tratan de controlar algo que no entienden. Vamos que sería como ponerse en una frontera y fiarte únicamente de los pasaportes que te entregan ya que no entiendes ni una palabra de las personas que cruzan. Por lo que los firewalls de nueva generación, primero entienden el porqué y el quien, lo analizan y después lo dejan pasar.
HTH
RobClav

OT:Buscando networkers freelance en Barcelona

Parece que últimamente hable mas de cosas prácticas que de teorías pero creo que todo puede ser de vuestro interés. Así que ahora, estamos buscando freelance para colaborar en proyectos a corto, medio y largo plazo. No es necesario tener exclusividad pero si un conocimiento equiparable al CCNP en alguno de   los siguientes ámbitos:

• Switching, routing multifabricante o Cisco.
• Seguridad, Firewalls de Paloalto, Netscreen o Junipers.
• Wifi, no importa el fabricante.
• Telefonia IP Cisco, Avaya o Asterisk.

 Podéis contactar con nosotros mediante el correo o via Linked-IN.
Robclav