Monday, February 06, 2012

Manual de seguridad de la información

Los siguientes conceptos han sido obtenidos de los manuales de de la Oficina federal alemana para la seguridad y las tecnologías de la información, abreviada como BSI (Bundesamt für Sicherheit in der Informationstechnik)

Definición y tareas de gestión de seguridad



  • Seguridad IT: Es el estado de un sistema de información donde es posible limitar los riesgos y amenazas un nivel controlable. Esto es gracias a la implementación de medidas adecuadas que se han tomado para proteger la infraestructura tecnológica y de información. 
  • Seguridad TIC: Seguridad para los sistemas IT y de comunicación
  • Seguridad de la Información: Protege la información contra pérdida, alteración y acceso no autorizado. Incluye los activos de información que se ha procesado y almacenado electrónicamente, además de la información verbal o escrita en documentos (SIHB).
  • Privacidad: Protección de datos personales (DSG)
  • Seguridad de datos: (GDG) depende del tipo de datos utilizados, el alcance y el propósito de uso de estos. Es necesario tener en cuenta la capacidad técnica y la viabilidad económica para garantizar  el uso correcto de los datos y su  protección en contra de perdida, ya sea por destrucción accidental o ilegal, por ejemplo que no sean accesibles a personas no autorizadas. 
  • Gestión de Seguridad: Es el proceso continuo para garantizar el cumplimiento de los objetivos de seguridad (Confidencialidad, integridad, disponibilidad) de los sistemas IT. Los posibles requisitos adicionales son poder determinar la traceabilidad, responsabilidad, autenticidad y anonimato. 
Las nuevas tecnologías traen grandes ventajas pero también generan nuevos riesgos y nuevas amenazas.

¿Como está la situación hoy en día? 

  • Demasiadas medidas
  • Responsabilidades poco claras
  • Normas que se contradicen
  • Medidas poco prácticas
la seguridad de la información es siempre una tareas de administración y persigue los siguientes objetivos y funciones:
  • Definir los objetivos y las políticas de seguridad de la información que debe seguir una Organización
  • Identificación y análisis de riesgos
  • Establecimiento de medidas de seguridad adecuadas
  • Control de la ejecución y la operación continua
  • Fomentar la concientización sobre la importancia de las aplicación de las medidas de seguridad dentro de la empresa.
  • Generar respuestas adecuadas a los posibles incidentes de seguridad

Manual de seguridad de información SIHB

Recopila las medidas de seguridad estandarizadas para cumplir necesidades normales de protección, partiendo de diferentes fuentes como: el  Manual de Protección de Línea Base del  BSI  y de las normas ISO/IEC 27002, ISO/IEC 27001 e ISO/IEC TR 13335. Sus requisitos son:

• Compatibilidad con otros sistemas de gestión de seguridad
•
Acomodación al Marco legal y jurídico con las Normas y leyes del país dende se implemente
• Las medidas genéricas sin detalles específicos para un sistema en particular
• El sistema y la información poseen un Ciclo de vida el cual debe realimentarse, ajustarse y actualizarse, según la dinámica en que se mueva la organización.

Estructura del Manual

Capítulo 1: Introducción
Capítulo 2: Sistema de Gestión de Seguridad de la Información
Capítulo 3: Responsabilidad de Gestión
Capítulo 4: Análisis de Riesgos

Medidas SIHB conforme a ISO/IEC 27001 e ISO/IEC 27002

Capítulo 5: Política de Seguridad de la Información
Capítulo 6: Organización
Capítulo 7: los activos y la clasificación de la información
Capítulo 8: Seguridad del personal
Capítulo 9: La seguridad física y ambiental
Capítulo 10: Gestión de la seguridad en las comunicaciones y operaciones
Capítulo 11: Control de acceso, sistemas de autenticación
Capítulo 12: Seguridad en el desarrollo, operación y mantenimiento
Capítulo 13: Manejo de Incidentes
Capítulo 14: Recuperación de Desastres y de Continuidad del Negocio
Capítulo 15: Cumplimiento de Seguridad

Anexos incluidos en el SIHB
  • Escenarios de seguridad
    • Seguridad Industrial
    • Seguridad y la doctrina de defensa
    • Gobierno electrónico
  • Tecnologías de Seguridad
    • Medidas criptográficas
    • Tunelamiento
    • Virtualización
  • Patrones de contratos, compromisos, documentación
  • Normas
  • Documentos de referencia
  •  Tablas de referencia
  • Decisiones de la Junta Directiva TIC y leyes
  • Direcciones
Mas información detallada sobre SIHB aqui
 
Si tienes información adicional sobre este tema, tus comentarios o links de referencia son bienvenidos. 

Saturday, February 04, 2012

¿Como saber si un producto IT o Software es seguro?

Existen tres manera de responder esta pregunta
  • Confiar ciegamente en las declaraciones de los fabricantes del sistema IT o software.
  • Hacer pruebas personalmente, esto generaría un gran esfuerzo si se hace manualmente, debido al tiempo requerido en recopilación de documentación técnica sobre las diferentes versiones del sistema, sus pautas de desarrollo  y posibles vulnerabilidades que se generan en cada una de las actualizaciones del sistema. Adicionalmente conocimiento avanzado en codificación,  debugging y seguridad.
  • Recurrir a una auditoría neutral encargada de evaluar y certificar el cumplimiento de los requisitos de seguridad que se han especificado previamente en normas internacionalmente estandarizadas. Los criterios de evaluación son objetivos, confiables  y de validez general.  
Criterio de Evaluación de Sistemas de computación confiables

En ingles: Trusted Computer System Evaluation Criteria(TCSEC 1983) es un estándar creado por el departamento de defensa de los  EE.UU. También es  conocido como el Libro Naranja de Seguridad.

Base de computación Confiable (Trusted Computing Base TCB): Comprende las partes relevantes relacionadas con la seguridad del sistema, contiene todos los elementos del sistema encargados de soportar las política de seguridad y el aislamiento de objetos (código y datos) en que se basa la protección.

Monitor de referencia: Refuerza las relaciones de acceso autorizado entre los sujetos y objetos de un sistema [Informe Anderson, 1972]
El monitor de referencia debe estar siempre activo, ser lo suficientemente liviano para permitir el uso de métodos formales para sus comprobaciones y por supuesto, estar lo suficientemente protegido en contra de interferencias externas, manipulaciones y falsificaciones.

Modelos Formales de Seguridad
El modelo más conocido se llama Bell-LaPadula (1976), el cual especifica dos tipos de actores. primero los Sujetos o entidades activas como los  usuarios, administradores, aplicaciones o procesos y segundo los Objetos que son entidades pasivas como datos, archivos,etc.Cada sujeto y objeto tiene asignado diferentes atributos de seguridad.
  • No-Read-Up: Propiedad de seguridad simple, implica que sujetos con bajo nivel de confianza no deben leer los objetos con clasificaciones superiores  (clasificación de objetos ≤  Autorización de Sujeto)
  • No-Write-down: Sujetos con clasificación alta no deben escribir sobre  archivos con niveles de confianza inferiores.

Clases funcionales en TCSEC


D: Protección mínima (No cumple los requisitos de evaluación)

C: Protección discrecional (Protección definida por el usuario DAC)

  • C1: Protección de Seguridad Discrecional
    • Identificación y autenticación de los usuarios
    • Concesión y verificación de los derechos de acceso individuales
    • Protege contra la lectura o  destrucción accidental de información
  • C2: Protección de acceso controlado
    • Control detallado de acceso discrecional
    • Procedimientos de inicio de sesión, pruebas y reprocesamiento
    • Ofrece protección contra ataques dirigidos
    • Permite el rastreo de actividades ilicitas
B: Protección Mandatoria (Protección basada en reglas MAC)
  • B1:Protección de Seguridad Etiquetada
    • Descripción informal del modelo de seguridad baasada en normas de control de acceso
    • Todos los sujetos y objetos deben ser controlados por una Base de Computación Confiable (TCB) proporcionada por medio de atributos, los cuales pueden ser de forma jerárquica.
    • Los axiomas Bell-LaPadula deben cumplirse.
  • B2: Protección Estructurada
    • TCB basado en modelos formales  de seguridad
    • Diferencia entre elementos de seguridad críticos y no críticos
    • Todos los sujetos y los objetos poseen atributos
    • Hace frente a problemas como el de canales encubiertos o  definición de  Ancho de banda máximo.
     
  • B3: Dominios de Seguridad
    • Monitor de referencia
    • Supervisión de los eventos críticos para la seguridad
    • Implementación de mecanismos de reinicio
A: Protección Verificada
  •  Técnicas formales  de las especificación de diseño y su verificación

Continuación> Criterios Comunes para la evaluación de la seguridad en tecnologías de la información CC 

Fuente: TCSE
https://www.bsi.bund.de/cln_156/DE/Themen/ZertifizierungundAnerkennung/zertifizierungundanerkennung_node.html

Si tienes información adicional sobre este tema, tus comentarios o enlaces de referencia son bienvenidos. 

Monday, October 17, 2011

Protocolo de redundancia en routers virtuales (VRRP Virtual Router Redundancy Protocol)



AcrónimoSignificadoFabricante
VRRPVirtual Router Redundancy ProtocolRFC 3768
XRRP Router Redundancy ProtocolHewlet Packard
HSRPHost Standby Router ProtocolRFC 2281 3/1998 CISCO

Algunas de las principales características en entornos distribuidos y redes LAN son La tolerancia a fallos y la redundancia, por lo tanto el desarrollo de nuevas  tecnologías LAN va dirigido a garantizar una alta disponibilidad de interconexión de los dispositivos de red. Por ejemplo: la capacidad de soportar fallos de una tarjetas de interfaz en un servidor de balanceo de carga, o la configuración redundante de las fuentes de alimentación de los switches en un backbone.
Gracias a VRRP estas mismas características pueden ser aplicadas a los switches y routers de capa 3 que han sido configurados estáticamente como puertas de entrada predeterminadas, evitando así cualquier punto de fallo que se pueda generar, especialmente por redundancia en la asignación manual de las direcciones IP fijas de la puerta de enlace predeterminada.

Funcionamiento 
El primer paso a seguir para enrutar datos entre dominios de red es determinar una puerta de enlace. Algunos sistemas utilizan protocolos dinámicos de descubrimiento de ruteo, tales como OSPF (Open shortest path first - Primero la ruta libre mas corta) o RIP (Routing Information Protocol - Protocolo de Enrutamiento de Información), para determinar su puerta de enlace predeterminada. Los protocolos OSPF y RIP han sido diseñados para evitar cualquier fallo que se pueda presentar al obtener un puerta de enlace óptima.
Sin embargo, muchos administradores de red prefieren configurar las puertas de enlace de forma estática, para así reducir la sobrecarga de procesamiento en los hosts. El riesgo de dicho procedimiento es que el router que sirve de puerta de enlace predeterminada se puede convertir en un punto único de fallo, lo cual puede significar una catástrofe para los hosts que basan sus conexiones en una sola puerta de enlace predeterminada para acceder a una WAN o a otros dominios LAN.
Diseñar una arquitectura eficiente de VRRP es la manera relativamente simple de evitar los fallos ya mencionados, aunque los protocolos dinámicos de descubrimiento de rutas son capaces de localizar una nueva puerta de enlace predeterminada, VRRP proporciona un sistema de tolerancia a fallos mas rápida y eficientemente.

Componentes
La asignación de puertas de enlace predeterminadas se consigue mediante la creación de los routers virtuales, un maestro y un router de reserva (backup), actuando como un grupo. VRRP combina conjuntos de routers en grupos lógicos  llamados routers virtuales(VR), los VR redundantes son identificados para cada grupo, los cuales comparten una sola puerta de enlace predeterminada para aumentar la disponibilidad y fiabilidad de los caminos enrutados, así es posible asignar los VR como puertas de entrada a los hosts clientes que solicitan una conexión a la red.
El router VRRP responsable de controlar las direcciones IP asociadas con un router virtual se llama Maestro, este es único en el grupo y se encarga de dirigir los paquetes entrantes a las direcciones IP internas requeridas.
A la puerta de enlace predeterminada del host participante se le asigna un router virtual en lugar de un router físico. El router físico que reenvía los paquetes en un momento dado se llama el router principal, en caso de que este falle, otro router físico de reserva es seleccionado automáticamente para reemplazarlo. Uno o más routers pueden ser reserva en una misma LAN o VPN.
El maestro comunica su estado a los dispositivos de reserva, Si el maestro no puede comunicar su estado, VRRP toma un router de reserva en orden de precedencia, así el router backup responde asumiendo el papel de maestro para  garantiza la comunicación entre todos los routers que tengan aplicaciones VRRP, que estén asociados con una ID de Router Virtual y que soporten redundancia de routers a través de un proceso de elección prioritaria entre ellos.


Características Adicionales
El envió de mensajes internos entre routers se hace por medio de paquetes multicast IPv4 e IPv6, ya que está diseñado para LANs multiacceso y multicast/broadcast (como ethernet), así la dirección de origen del paquete enviado es siempre la dirección IP de la interfaz de envío.
VRRP funciona ademas en aplicaciones de balanceo de carga ya que permite que un router actúe como un maestro para una subred IP y como router de reserva (backup) para otra subred que tiene su propio router maestro. Dos routers configurados de esta manera pueden compartir carga, ya que cada router actúa como una reserva redundante del otro.
VRRP proporciona información sobre el estado de un router, no las rutas procesadas e intercambiadas por ese router. por lo tanto no reemplaza a ningún protocolo de routing.
Cada instancia VRRP tiene alcance limitado, a una única subred. No anunciar las rutas más allá de la subred IP o ni afectan a la tabla de enrutamiento de ninguna manera, debido a que los paquetes son enviados con TTL = 255, en el caso que el router reciba un paquete con TTL mas pequeño, el paquete es descartado.

Si tienes información adicional sobre este tema, tus comentarios o links de referencia son bienvenidos. 

Modelo TCP/IP de Internet


Internet ofrece una gran cantidad de servicios a los cuales los usuarios de computadores personales se suelen conectar, los propósitos son diferentes y variados, ya sea consultar una página web alojada en un servidor remoto, visitar una cuenta de correo electrónico, descargar o compartir archivos, etc. Estos procesos que aparentemente parecen triviales e inmediatos en realidad requieren de protocolos específico y de una infraestructura que responde a las peticiones que los usuarios finales han solicitado.

Capas

La siguiente figura muestra el camino lógico de algunos de los protocolos que intervienen en las comunicaciones host a host o host a servidor. El proceso de descarga de una página web comienza en el cuadro de busqueda del Navegador o browser. Antes de que una petición para ver la información de una página web llegue al servidor web donde está se encuentra alojada, el host de origen debe encapsular la petición a través de diversos procesos, niveles y protocolos, así a su vez enviarla a través de la red. Cada capa representa un tramo en el camino lógico entre el computador que origina la petición hasta al servidor que aloja la página web y que recibirá el paquete encapsulado.
 
Después de que el host emisor empaqueta los de datos por medio de las diferentes capas, los datos son entregados al host receptor a través de Internet. El equipo receptor desenvuelve las capas de datos, una por una. Una capa individual obtiene los datos destinados para a ella y pasa el resto del mensaje a las capas superiores. Las siguientes cuatro capas componen el modelo TCP/IP de Internet:
  • Capa de aplicación. Es la capa superior (la solicitud de una página web en el ejemplo anterior). Contiene el Software de envío y recepción que soporta las aplicaciones implementadas como por ejemplo el navegador y el servidor web.
  • Capa de transporte. Debajo de la capa de aplicación está la capa de transporte. Esta capa abarca muchos aspectos de la forma en que dos hosts se comunican. Esta capa de transporte proporciona fiabilidad a otras capas inherentemente poco fiables.
    Los dos tipos de protocolos de transporte normalmente son: TCP, que asegura una entrega fiable de datos debido a sus mecanismos para garantizar la entrega de estos, mientras que el User Datagram Protocol (UDP), es un protcolo no orientado a la conexión lo que lo hace poco confiable por la perdida de datos que presenta. En este ejemplo de aplicación con el servidor web , TCP es necesaria debido a que no se admite la pérdida de datos.
  • Capa de red. Debajo de la capa de Transporte está la capa de red,la cual es responsable de mover los datos desde el equipo de origen hasta el equipo de destino (el servidor web, en este caso), a menudo hay saltos sobre algún tramo de la ruta de red. Este salto pude estar entre un host y un router, o entre dos routers, sin embargo en última instancia, se toman los datos del camino de enrutamiento mas cercanos para alcanzar su destino.
  • La capa de enlace. La capa inferior es la capa de enlace, esta capa se encarga de las comunicaciones desde un host al medio físico en el que reside. Puede ser ethernet, wireless o fibra óptica. Esta capa se ocupa de recibir y enviar datos desde el host a través de una interfaz específica a la red.

Flujo de Datos

Teniendo en cuenta la figura anterior, la actividad del flujo de datos sería la siguiente: La solicitud de una página web desde un host remitente, desciende las capas de la pila TCP/IP. Se dirige al equipo de destino por medio de la capa inferior o capa de enlace y sube nuevamente la pila TCP/IP del servidor. 
Las flechas horizontales entre los hosts representa la comunicación entre capas del mismo nivel. Los dos equipos no interactúan directamente entre sí, por sí mismos. Cuando la solicitud desciende la pila TCP/IP del computador que envía, los datos son  empaquetados de manera que cada capa tiene un mensaje para su capa contraparte, por lo que parecen estar hablando directamente.

los concepto mas importantes para comprender es el modelo de pila TCP/IP el cual se  se utiliza para describir la estructura en capas del procesamiento de solicitudes o respuestas TCP/IP. Esto significa que los datos en el host remitente se envuelven con las etiquetas de identificación de cada capa, para guiar al equipo receptor en el análisis del mensaje recibido, capa por capa. 
Cada capa del dispositivo que envía añade su propia cabecera, y el host receptor invierte el proceso para desempacar el mensaje, eliminando la cabecera, y dirigiendo el resto de datos a la capa correspondiente. Este proceso se repite desde la capas mas altas del servidor hasta que los datos llegan a la capa superior del host receptor, el cual finalmente procesa las solicitudes de la página web. Cuando la respuesta se envía de nuevo, todo el proceso se repite, ahora el equipo donde se aloja el servidor web empaqueta los datos a enviar, los cuales son entregados y recibidos, el equipo cliente que aloja el navegador desempaca el mensaje recibido para hacerlo llegar a la capa de aplicación que soporta el navegador web.
Escrito por: Sujel Melina Murillo Polanía

Si tienes información adicional sobre este tema, tus comentarios o links de referencia son bienvenidos. 

¿Para que se Utiliza la interfaz Loopback en protocolos de ruteo dinámico como OSPF?

OSPF utiliza la mayor dirección IP configurada en las interfaces como el identificador (ID) del router. Si alguna vez la interfaz asociada a esta dirección IP se cae, hay una intermitencia o si la dirección es eliminada, el protocolo OSPF debe recalcular un nuevo ID del router y reenviar toda la información de enrutamiento de sus interfaces.

El interfaz loopback es un interfaz virtual creada por software que representa al propio dispositivo independiente de la dirección IP que se la haya asignado, no existe físicamente en el equipo, pero realiza todas las funciones de un interfaz física. Se pueden crear tantos interfaces loopback como sean requeridas. 


Si la interfaz loopback está configurada con una dirección IP, el sistema operativo del router utilizará esta dirección IP como su ID de router, incluso si otras interfaces tienen direcciones IP mayores.  Así se logra una mayor estabilidad en la tabla de enrutamiento, debido a que las interfaces loopback nunca se caen y por lo tanto los protocolos de enrutamiento se mantienen latentes.

OSPF automáticamente prefiere una interfaz loopback sobre cualquier otro tipo de interfaz física, eligiendo así la mayor dirección IP entre todas las interfaces loopback. Si no hay presencia de interfaces loopback configuradas, elige como segunda opción a la mayor dirección IP del router. OSPF utiliza el algoritmo de
Dijkstra para seleccionar sus caminos de enrutamiento, por lo tanto no puede ser configurado para usar una interfaz específica.

Agradecimientos: Alfonso David Diaz Torres por su oportuna explicación

Si tienes información adicional sobre este tema, tus comentarios o links de referencia son bienvenidos. 

Friday, October 14, 2011

Linux MailServer con Exim: Comandos y directorios importantes

El archivo de configuración de Exim se puede modificar, a través de la consola de comandos:
gedit /etc/exim/exim4.conf

Los servicios de cualquier servidor Linux pueden activarse o desactivarse manualmente por medio de secuencias de comandos (scripts) en el archivo
/etc/init.d/Nombre_del_Servicio

Iniciar Servidor de Email

  • /etc/init.d/exim4 start
  • /etc/init.d/courier-all start
  • Detener Servidor de Email

  • /etc/init.d/exim4 stop
  • /etc/init.d/courier-all stop
  • Reiniciar Servidor de Email

  • /etc/init.d/exim4 restart
  • /etc/init.d/courier-all restart

  • El registro de mensajes salientes en la cola de correos que no han sido entregados se encuentra en
    /var/spool/exim4/msglog

    La información detallada sobre el contenido de los correos salientes (*- H = información del sobre, *- D = información del cuerpo)
     / var/spool/exim4/input

    Registro principal del Daemon Exim
    /var/log/exim4/mainlog

    Ver los emails en la cola que Exim trata de entregar
    exim4-qf

    Ver los emails en la cola de salida
    exim4-BP

    Número de emails en la cola de salida
    exim4-bpc

    Si tienes información adicional sobre este tema, tus comentarios o links de referencia son bienvenidos. 

    Herramientas SNMP, MIBs y funciones de la estación de Monitoreo

    Standard MIBs
    Define las características propias de SNMP como MIBs, traps , la interoperatividad entre las diferentes versiones. Además declara la estructura e identificación de la información administrada para diferentes protocolos de red como TCP/IP, UDP, IPv6 , IPv4, MLPS, LLDP, Link Aggregation, OSPF, RIP, DNS,  VRRP, entre otros. Así mismo para diferentes interfaces como ADSL, Ethernet, E1, E2, E3,DS1, DS2, DS3/E3, T1 , ATM and  Frame Relay.

    MIBs Activas:
    • Accesibilidad de Ping
    • Servicio de Prueba de puertos 
    • Servicio de verificación de contenido (HTTP, Telnet-Login inicio de sesión, POP3, IMAP, DNS, ...) y de Información interna, por ejemplo, SNMP, WMI, DMI, ...  
    MIBs Pasivas

    • Recopilación de registros (por ejemplo, Syslog,RADIUS)
    •  SNMP Traps 
    MIBs Análisis de eventos
    • Traps especiales
    • Texto en los registros (logs)
    • dependencias
    MIBs de Reacción
    • Recopilación de registros
    • Descripción del Estado
    • Notificaciones de alerta por SMS, e-mail, solicitudes al helpdesk...
    • reacciones automáticas ...

    Dependencias
    Muchas pruebas dependen de las condiciones de error que se generen en un entorno de red. Por ejemplo, si una estación de administración no puede alcanzar su propia puerta de enlace predeterminada, entonces cualquier dispositivo externo a la red local que intente conectarse a esta, generaría mensajes de error, como solución es necesario analizar la combinación entre los mensajes de error y el dispositivo comprometido. Si la estación de administración no puede alcanzar ni siquiera sus propios recursos fuera de la red local, entonces es realmente necesario analizar pruebas de  operación de la puerta de enlace predeterminada.
     
    Enterprise-Specific MIBs
    MIBs hechas por iniciativa privada tales como:
    • Objetos AAA que proveen soporte para monitorear autenticación, autorización y contabilidad (Accounting = todos los eventos puedan ser rastreados) a través de RADIUS, LDAP, SecurID, Firewalls y servidores de autenticación local.
    • Monitereo de Firewall, alarmas, analizadores, Políticas de seguridad
    • Chassis MIB Provee soporte para el monitoreo del entorno operativo de la carcasa (rack o chasis) donde se ubican los dispositivos de red (Fuente de poder, Voltajes del board, ventildaores, temperatura, flujo de aire, ...)
    • Monitoreo y estadísticas por interfaz
    • Bitácoras con el historial de cambios en los traps, la configuración de administración notifica el momento en el que se generó el cambio de configuración en cada trap, la identificación del usuario, el dispositivo de donde se generó la orden y el método utilizado.
    • Soporte para monitorear proxys DNS, solicitudes, peticiones, respuestas y fallas.
    • Ethernet MAC monitorea las estadísticas del media access control (MAC).
    • Flow Collection Services: Provee estadísticas de utilización de archivos, almacenamiento, memoria, FTP, estados de errores y monitoreo de interfaces, tambien provee traps  para destinos no disponibles, o transferencia de archivos no exitosa, desbordamiento de flujo o de memoria.
    • Multiple Instance Multiple Spanning Tree protocol MIMSTP
    • RMON Events and Alarms
    • Soporte Nat SUport 
    Software útil para usar en procedimientos de administración de redes, monitoreo y SNMP 

    ..Y muchos, muchos mas..., también es posible buscar por MIBs por ejemplo en


    Si tienes información adicional sobre este tema, tus comentarios o links de referencia son bienvenidos. 

    Monday, September 12, 2011

    SNMP (Protocolo Simple de Administración de Red - Simple Network Management Protocol)

    Como una araña en su red, una estación de administración de red SNMP tiene la tarea de monitorear un grupo de dispositivos en una red, dichos dispositivos administrados son servidores, enrutadores, hubs, switches, estaciones de trabajo, impresoras, etc; los cuales poseen un software llamado Agente de gestión (Managment Agent) que proporciona información de su estado y ademas permite su configuración.
      

    SNMP hace parte de la suite de protocolos de Internet (TCP/IP) y está compuesto por un conjunto de normas de gestión de redes, incluyendo un protocolo de capa de aplicación, un esquema de base de datos, y un conjunto de objetos de datos. SNMP expone la gestión de datos en forma de variables que describen la configuración del sistema administrado. Estas variables pueden ser consultadas y configuradas por  medio de sus aplicaciones de gestión. 

    Algunos de los objetivos SNMP
    • Gestión, configuración y monitoreo remoto de los dispositivos de red
    • Detección, localización y corrección de errores
    • Registro y estadísticas de utilización
    • Inventario y Topología de red
    • Planificación del crecimiento de la red.
    Componentes SNMP
    Una red con aplicaciones SNMP posee al menos uno o varias estaciones de Administración, cuya función es supervisar y administrar un grupo de dispositivos de red por medio de un software denominado NMS (Network Management System- Sistema de gestión de redes), este se encarga de proporciona los recursos de procesamiento y memoria requeridos para la gestión de la red administrada, la cual a su vez puede tener una o más instancias NMS.
    El dispositivo administrado es un nodo de red que implementa la interfaz SNMP, este tambien intercambia datos con el NMS y permite el acceso (bidireccional o unidimensional -solo lectura) a la información específica del nodo. Cada dispositivo administrado ejecuta permanentemente un componente de software llamado agente, el cual reporta y traduce información a través de SNMP con la estación de administración.
    En esencia, los agentes SNMP exponen los datos de gestión a las estaciones de administración en forma de variables organizadas en jerarquías, dichas jerarquías junto con  otros metadatos (como el tipo y la descripción de las variables), son descritos en una Base de Gestión de Información (MIB Managment Information Base).El protocolo también permite ejecutar tareas de gestión activa, como la modificación y la aplicación de una nueva configuración de forma remota, a través de la modificación de dichas variables. 

    OID Object Identifier
    Es el identificador único para cada objeto en SNMP, que proviene de una raíz común en un namespace jerárquicamente asignado por la IANA, Los OIDs están organizados sucesivamente para identificar cada nodo del árbol MIB desde la raíz hasta los nodos hojas.

    MIB Management  Information Base

    Base de datos con información jerárquicamente organizada en forma de arbol con los datos de todos los dispositivos que conforman una red. Sus principales funciones son: la asignación de nombres simbólicos, tipo de datos, descripción y parámetros de accesibilidad de los nodos OID.

    PDU (Protocol Data Unit - Unidad de datos del Protocolo)
    SNMP utiliza un servicio no orientado a conexión como UDP (User Datagram Protocol) para realizar las operaciones básicas de administración de la red, especialmente el envío de pequeños grupos de mensajes (denominados PDUs) entre las estaciones de administración y los agentes. Este tipo de mecanismo asegura que las tareas de gestión no afectan el rendimiento global de la red.  SNMP utiliza comúnmente los puertos 161 UDP para obtener y establecer mensajes y 162 UDP para capturar mensajes y traps.

     =============================================================
    | Tipo de  | ID de     | ... | ... |  ... Variables  ...      |
    | PDU      |Petición   | ... | ... |        MIB               |
     =============================================================
    

    Petición y Respuesta GET (SNMPv1)
    La estación de administración hace UNA petición al agente para obtener el valor de una o muchas variables del MIB, las cuales se especifican mediante asignaciones (los valores no se utilizan). el agente recupera los valores de las variables con operaciones aisladas y envía una respuesta indicando el éxito o fracaso de la petición. Si la petición fue correcta, el mensaje resultante contendrá el valor de la variable solicitada.

    Petición  GETNext


    La estación de administración hace una petición al agente para obtener los valores de las variables disponibles. El agente retorna una respuesta con la siguiente variable según el orden alfabético del MIB. Con la aplicación de una petición GetNextRequest es posible recorrer completamente la tabla MIB si se empieza con el ID del Objeto 0. Las columnas de la tabla pueden ser leídas al especificar las columnas OIDs en los enlaces de las variables de las peticiones.

    Petición  GETBulk (SNMPv2)

    La estación de administración hace una petición al agente para obtener  múltiples iteraciones de GetNextRequest. El agente retorna una respuesta con múltiples variables MIB enlazadas. Los campos non-repeaters y max-repetitions se usan para controlar el comportamiento de las respuesta.





    Set-Request & -Response
    La estación de administración hace una petición al agente para cambiar el valor de una variable, una lista de variables MIB o para la configuración de los agentes. El acceso a las variables se especifica dentro de la petición para que el agente cambie las variables especificadas por medio de operaciones atómicas., despues se retorna una respuesta con los valores actualizados de las variables preestablecidas y  con los valores de las nuevas variables creadas. Así mismo existen conjunto de parámetros de configuración (por ejemplo, direcciones IP, switches, ...)

    Notificaciones y Trampas(Traps)
    Son mensaje SNMP generados por el agente que opera en un dispositivo monitoreado, estos mensajes no son solicitados por la consola y están clasificados según su prioridad  (Muy importante, urgente,... ) . Estas notificaciones se producen cuando el agente SNMP detecta un cambio de parámetros en las variables MIB. Estos mensajes son utilizados por los sistemas de alerta sin confirmación. Los tipos estándar de trampas indican los siguientes eventos:
    • (0) Coldstart:  El agente se ha reiniciado
    • (1) Warmstart: La configuración del agente ha cambiado.
    • (2) Linkdown: Alguna interfaz de comunicación está fuera de servicio (inactiva)
    • (3) Linkup: Alguna interfaz de comunicación está en servicio (activa).
    • (4) Authenticationfailure: El agente ha recibido una solicitud de un NMS no autorizado
    • (5) EGPNeighborLoss: Un equipo, junto a un sistema donde los routers están utilizando el protocolo EGP, está fuera de servicio;
    • (6) Enterprise:  Incluye nuevas traps configuradas manualmente por el administrador de red.
    Versiones SMNP
    Las versiones más utilizadas son la versión SNMPv1 y SNMPv2. El SNMPv3 última versión tiene cambios importantes con relación a sus predecesores, sobre todo en temas de seguridad, sin embargo, no ha sido ampliamente aceptada en la industria.
     
    SNMPv1 
    Esta es la versión inicial y la mas utilizada, principalmente debido a la simplicidad del esquema de autenticación y a las políticas de acceso que utiliza el agente SNMP para determinar cuales estaciones de administración pueden acceder a las variables MIB. Una política de acceso SNMP es una relación administrativa, que supone asociaciones entre una comunidad SNMP, un modo de acceso, y una vista MIB.
    • Una comunidad SNMP es un grupo de uno o más dispositivos y el nombre de comunidad (cadena de octetos que una estación de administración debe agregar en un paquete de solicitud SNMP con fines de autenticación).
    • El modo de acceso especifica como se accede a los dispositivos de la comunidad se les permite con respecto a la recuperación y modificación de las variables MIB de un agente SNMP específico. El modo de acceso: ninguno, sólo lectura, lectura-escritura o sólo escritura. 
    •  Una vista MIB define uno o más sub-árboles MIB a los cuales una comunidad SNMP específica puede tener acceso. La vista MIB puede ser el árbol MIB o un subconjunto limitado de todo el árbol MIB.
    Cuando el agente SNMP recibe una solicitud de una estación de administración, este verifica el nombre de la comunidad a la que pertenece y la dirección IP para determinar si el host solicitante en realidad  es miembro de la comunidad que dice pertenecer. El agente SNMP determina si concede el acceso hasta las variables MIB según lo defina la política de acceso asociada a esa comunidad. Si todos los criterios son verificados y se cumplen. De lo contrario, el agente SNMP genera una captura authenticationFailure o devuelve el mensaje de error correspondiente a la máquina solicitante.  
    Formato del mensaje SNMP
     ======================================================================
    | Versión    | Nombre de Comunidad | ...           PDU   ...           |
    | (Integer)  | (Octet Str.)        |             (Sequence)            |
     ======================================================================
      El diseño de esta versión fue realizado en los años 80, cuando la prioridad era atender la  demanda de protocolos generado por el rápido crecimiento de las redes, así que es de esperarse que nadie se haya preocupado por los problemas de autenticación y de seguridad, siendo estas sus principales falencias. La autenticación de los clientes se realiza sólo por la cadena de octetos de Comunidad, en efecto tenemos un tipo de contraseña, que se transmite en texto plano.

    SNMPv2
    Incluye mejoras en rendimiento, seguridad, confidencialidad y comunicación entre estaciones de administración. Introduce GetBulkRequest, una alternativa a GetNextRequests iterativo para la recuperación de grandes cantidades de datos de administración en una sola solicitud. Sin embargo, no fue ampliamente aceptado debido a su complejidad y a la poca compatibilidad con los  NMSs de la versión anterior; sin embargo este inconveniente se soluciono utilizando agentes proxy y NMS bilingües para ambas versiones de NMS; adicionalmente se desarrolló la versión SNMPv2c un poco mas simple, pero sin embargo mas segura que la primera versión.

    SNMPv3
    Proporciona importantes características de seguridad y configuración remota:
    • Autenticación: Firmas digitales MD5 y SHA1 basadas en usuarios garantiza que el mensaje proviene de una fuente segura.
    • Confidencialidad: Cifrado de paquetes DES y AES para garantizar mayor privacidad
    • Integridad: Asegurar que el paquete no ha sido alterado en tránsito, incluye un mecanismo opcional de protección de paquetes reenviados. 
     Mas Información sobre herramientas SNMP aqui
    References
    http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol
    http://h18000.www1.hp.com/products/quickspecs/10757_div/10757_div.HTML
    Class Slides: N_Netzwerk-Management SNMP.pdf

    Si tienes información adicional sobre este tema, tus comentarios son bienvenidos.

    Thursday, September 08, 2011

    Agregar un Archivo JAR a Eclipse

    En el caso de querer desarrollar aplicaciones usando una IDE como es el caso de Eclipse, es necesario agregar los archivos libvirt-0.4.7.jar and jna.jar al class path. A continuación describo paso a paso como hacerlo:

  • Creamos un nuevo proyecto en File>New>Project, Aparece un asistente, seleccionamos Java Project y click en el boton Next>
  • Asignamos un nombre al nuevo proyecto y y click en el boton Next>, se genera una carpeta con el nombre que hemos asignado
  • Sobre esta nueva carpeta con el nombre del proyecto abrimos el menú desplegable con el click derecho del mouse y elegimos "propiedades"
  • En la ventana que se abre, hay un menú a la izquierda elegimos "Java Build Path".
  • En el lado derecho de la ventana, elegimos la pestaña "Libraries"
  • Click al botón "Add External JARs"
  • Vamos a la carpeta que previamente hemos descomprimido en el post anterior: libvirt-java-0.4.7_compiled/target/jars 
  • buscamos libvirt-0.4.7.jar y jna.jar las seleccionamos una por una. click en OK y listo ya forma parte de nuestro proyecto Eclipse y podemos usarlo en nuestro programa 
  • Si tienes información adicional sobre este tema, tus comentarios o links de referencia son bienvenidos. 

    Wednesday, September 07, 2011

    Como vincular la librería Libvirt con Java

    Ya que este es el punto de partida para empezar a desarrollar aplicaciones con herramientas de virtualización, me parece importante describir el proceso paso a paso para instalar la librería Libvirt y vincularla con Java. Estas instrucciones van dirigidas a sistemas operativos como debian o Ubuntu.
    1. Verificar si el procesador del equipo en el que trabajamos tiene hardware de soporte para virtualización. El hecho de no obtener salida alguna, indica que no hay soporte para esta característica, sin embargo, es posible trabajar con algunas aplicaciones pero con bajo rendimiento, se recomienda usar con propósitos de investigación pero nunca para correr servidores reales.
      sudo egrep '(vmx|svm)' /proc/cpuin
    2. Libvirt está escrita en C y se instala con el siguiente comando:
      sudo apt-get install libvirt-dev
    3. Para editar las características del paquete escribimos:
      apt-get source -d libvirt
      sudo apt-get build-dep libvirt
      dpkg-source -x libvirt*dsc
    4. Es necesario instalar Los siguientes paquetes adicionales:
      sudo apt-get install sun-java6-jdk libjna-java junit ant
      sudo update-alternatives --config java
    5. Para confirmar la versión de Java y apache Ant
      javac -version
      ant -version 
    6. Crear una carperta llamada source para guardar el paquete a descargar
      mkdir -p ~/source
      cd ~/source 
    7. Ahora es necesario indexar la librería livbirt para utilizarla en Java. El paquete de archivos para vincular dicha librería se pueden descargar aqui.
    8. Guárdelo en la carpeta source y extráigalo con la siguiente línea de comandos:
      tar xvfz libvirt-java-0.4.7_compiled.tar.gz 
    9. La carpeta "libvirt-java-0.4.7_compiled.tar.gz" provee un archivo precompilado .jar. A continuación ingresamos a la carpeta y construimos el archivo .jar
      cd libvirt-java-0.4.7_compiled.tar.gz
      ant build
    10. El archivo construido se copia en el directorio que contiene las librerías de Java
      sudo cp libvirt-java-0.4.7_compiled.jar /usr/share/java/
      sudo ln -s /usr/share/java/libvirt-java-0.4.7_compiled.jar /usr/share/java/libvirt.jar
      
    11. El CLASSPATH debe apuntar al directorio actual y el directorio que contiene los archivos jna.jar y libvirt.jar.
      export CLASSPATH=.:/usr/share/java/*

    12. La variable LD_LIBRARY_PATH debe apuntar al archivo libjnidispatch.so.
      export LD_LIBRARY_PATH=/usr/lib/jni/
    13. El test descrito a continuación debe trabajar en cualquier maquina sin que se haya instalado previamente algún hipervisor ya que Libvirt provee un hypervisor de prueba.
    14. En la carpeta libvirt-java-0.4.7_compiled vaya al directorio target/testclasses para correr el siguiente shell script:
      cd
      cd ~/libvirt-java-0.4.7_compiled/target/testclasses
      ./run_test.sh

    Si libvirt está correctamente instalada, obtendremos una larga lista de salidas, si no, Java mostrará un mensaje de error.



    Si tienes información adicional sobre este tema, tus comentarios o links de referencia son bienvenidos.