Otros protocolos de supervisión de redes

a. Funciones iniciales de un registro de eventos

Cuando se produce un acontecimiento inesperado, como una avería, en un equipo de red, el administrador comienza por analizar los archivos de registro de eventos (bitácora o log). Estos archivos son generados por el equipo en cuestión y registran todos los eventos que se han producido, en tiempo real.

Un evento se caracteriza, por ejemplo, por un cambio en el estado de una interfaz, un incidente de tipo seguridad de puertos en un switch, un umbral elevado de utilización de recursos de hardware, una conexión a la interfaz de administración del equipo o cualquier otra actividad que se produzca en la «vida» del activo en cuestión. Cualquier proceso que se ejecute en el equipo se ha desarrollado con vistas a mantener un rastro del mismo o, al menos, mostrar su estado en la consola de administración.

Concretamente, los logs corresponden a mensajes de texto que generalmente se almacenan en una memoria RAM o de solo lectura, lo que permite al administrador ver la actividad del activo en tiempo real, pero también a lo largo de un periodo determinado, ya que estos mensajes llevan un sello de tiempo (timestamp). 

De ahí la importancia de configurar la hora y la fecha en un equipo, pero sobre todo de asegurarse de que están sincronizadas con una referencia única, utilizada por todos los otros activos de la red. Incluso se ha desarrollado un protocolo para este fin, el NTP (Network Time Protocol, Protocolo de sincronización horaria).

El mecanismo de bitácora se ajusta plenamente a los objetivos de la supervisión y se puede establecer un paralelismo con el uso de SNMP en modo de captura (trapping). De hecho, es el propio equipo el que genera y suministra los eventos, ningún proceso externo está en el origen de los mismos. Para el administrador, los registros de eventos permiten identificar un problema y, potencialmente, comprender y explicar su origen observando los eventos que lo preceden.

La ventaja de este sistema de logs es que, en su mayor parte, es propio de los activos de red, pero también de los servidores, sistemas operativos y aplicaciones. De hecho, la primera norma oficial que dio lugar al protocolo normalizado Syslog se registró en el IETF con el nombre de «BSD Syslog», una referencia directa al mecanismo de bitácora implementado en los sistemas operativos basados en el núcleo Unix de BSD.

En el proceso de desarrollo de software, y en nuestro caso para los SO de red, el programador debe prever la generación de estos eventos e integrarlos en su código fuente del mismo modo que la gestión de errores.

b. Necesidad de una gestión centralizada

A la vista de las cuestiones expuestas, es necesario poner en marcha en una red determinada un mecanismo que recoja los archivos de registro de eventos generados por los distintos equipos. Parece claro que la consulta diaria, individual y manual de las bitácoras de todos los activos de una red dada tiene inmediatamente sus límites y es impensable a largo plazo, especialmente en una red relativamente grande.

Esto llevó a la necesidad de establecer un protocolo que, en primer lugar, definiera un formato universal para estos archivos de registro de eventos y, en segundo lugar, especificara cómo se intercambian a través de una red para que se puedan centralizar en un único servidor. El administrador consulta todos estos logs en este servidor, los almacena y ejecuta los scripts de copia de seguridad. Este servidor se denomina «recolector Syslog»...

a. Orígenes del protocolo

El protocolo NetFlow fue diseñado por Cisco System en 1996 y se integró muy rápidamente en las distintas gamas de routers vendidos. El principio en el que se basa NetFlow consiste en analizar el tráfico de red que entra por una interfaz y vuelve a salir por una interfaz de salida. A partir de este análisis, el tráfico se agrupa en lo que se conoce como flujos. Esta recopilación de flujos permite al administrador elaborar estadísticas sobre el rendimiento de la interfaz en función de una serie de criterios, como la dirección IP (origen y/o destino), los puertos utilizados y las clases de QoS activadas.

El NetFlow y sus variantes son utilizados sobre todo por los operadores de telecomunicaciones para supervisar sus redes y facturar a sus clientes en función del pago por uso, es decir, según el ancho de banda consumido. Es más, algunos de los programas informáticos que interpretan los flujos recogidos son capaces de darles un valor económico.

NetFlow se estandarizó originalmente en la RFC 3954, que era más un memorando para uso público que una norma real. En 2009, Cisco publicó la versión 9 de NetFlow, que sigue siendo relativamente utilizada porque es compatible con los protocolos IPv6, MPLS y BGP. Al mismo tiempo, el protocolo IPFIX (IP Flow Information Export) fue publicado por el IETF bajo la RFC 5101, incorporando todos los conceptos de NetFlow y formalizándolos de manera oficial.

En 2013, IPFIX (que incluso se considera la versión 10 de NetFlow) se mejoró en la nueva RFC 7012. Se presentó entonces como la norma «oficial» que debían aplicar los fabricantes para el formateo, gestión y recopilación de flujos. Se trata de una mejora de NetFlow 9, que permite una mayor flexibilidad en la definición de los flujos, es decir, la posibilidad de añadir variables adicionales para un flujo determinado, como un nombre de usuario; algo que Cisco no había previsto necesariamente. No obstante, IPFIX sigue siendo compatible con NetFlow v9.

En última instancia, sin embargo, esta capacidad de permitir a los fabricantes integrar campos adicionales de su elección crea una opción de implementación del protocolo...