Syslog seguro remoto de Unisphere para PowerMax 9.2

Historial del registro del sistema

Syslog fue desarrollado en la década de 1980 por Eric Paul Allman (nacido el 2 de septiembre de 1955).
Eric es un programador informático estadounidense que desarrolló Sendmail y su precursor Delivermail a finales de la década de 1970 y principios de la de 1980 en la Universidad de California en Berkeley. En 1998, Allman y Greg Olson cofundaron la empresa Sendmail, Inc. El formato de registro utilizado por el agente de transferencia de mensajes del MTA, conocido como registro del sistema. Al principio, Syslog fue utilizado únicamente por Sendmail, pero finalmente se convirtió en un formato estándar no oficial utilizado por otros programas no relacionados para el registro. Más tarde, este formato se oficializó con la Rfc 3164 en 2001; Sin embargo, el formato original se ha vuelto obsoleto por la revisión más reciente, Rfc 5424.

Grupo de trabajo de ingeniería de Internet

El Grupo de Trabajo de Ingeniería de Internet (IETF) es una organización de estándares abiertos, que desarrolla y promueve estándares voluntarios de Internet, en particular los estándares que consisten en el conjunto de protocolos de Internet (TCP/IP). 
No tiene una lista formal de miembros ni requisitos de membresía. Todos los participantes y gerentes son voluntarios, aunque su trabajo es financiado por sus empleadores o patrocinadores.

El Consejo de Arquitectura de Internet (IAB, por sus siglas en inglés) supervisa las relaciones externas del IETF y las relaciones con el Editor de RFC. El IAB proporciona una dirección técnica a largo plazo para el desarrollo de Internet. El IAB también es responsable conjunto del Comité de Supervisión Administrativa (IAOC) del IETF, que supervisa la Actividad de Apoyo Administrativo (IASA) del IETF, que proporciona apoyo logístico, etc. al IETF. 
El IAB también gestiona el Grupo de Trabajo de Investigación de Internet (IRTF, por sus siglas en inglés), con el que el IETF tiene varias relaciones intergrupales.

Grupo Directivo

El Grupo Directivo de Ingeniería de Internet (IESG, por sus siglas en inglés) es un organismo compuesto por el presidente del Grupo de Trabajo de Ingeniería de Internet (IETF, por sus siglas en inglés) y directores de área. Proporciona la revisión técnica final de los estándares de Internet y es responsable de la administración diaria del IETF. Recibe las apelaciones de las decisiones de los grupos de trabajo, y el IESG toma la decisión de avanzar en los documentos en la vía de estándares.

El protocolo Syslog

Syslog utilizes three layers
  o "syslog content" is the management information contained in a syslog message.
  o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages.
  o The "syslog transport" layer puts messages on the wire and takes them off the wire.
  o An "originator" generates syslog content to be carried in a message.
  o A "collector" gathers syslog content for further analysis.
  o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays.
  o A "transport sender" passes syslog messages to a specific transport protocol.
  o A "transport receiver" takes syslog messages from a specific transport protocol.

Diagram 1 shows the different entities separated by layer.

+-------------------------+  +----------------------+
 | content                |  | content              |
 |------------------------|  |----------------------|
 | syslog application     |  | syslog application   |
 |                        |  |                      | (originator,
 |                        |  |                      | (collector, relay)
 |------------------------|  |----------------------|
 | syslog transport       |  | syslog transport     | (transport sender,
 |                        |  |                      | (transport receiver)
 +------------------------+  +----------------------+
      ^                                     ^
      |                                     |
          -----------------------------

¿Cómo se transporta el registro del sistema?

Hay dos maneras comunes de enviar mensajes de registro del sistema. A pesar de que RFC 5424 requiere que todas las implementaciones de syslog sean compatibles con un transporte de red TLS cifrado a través de TCP, la mayoría de los mensajes de syslog aún se entregan mediante el método UDP más antiguo. En la versión UDP, los mensajes simplemente se colocan en la parte de datos de un paquete UDP y se envían al servidor a través del puerto UDP 514. Por lo general, cada mensaje cabrá en un solo paquete. UDP no tiene estado ni sesión, por lo que no hay confirmación. Los paquetes se envían a la red. Esto tiene el problema obvio de que cualquier tipo de problema de red podría impedir la entrega del paquete, en cuyo caso es posible que no sepa que la red está inactiva porque no puede decírselo. También significa que, a veces, los paquetes importantes pueden perderse o dañarse durante el transporte.

Principios básicos

 Los siguientes principios se aplican a la comunicación del registro del sistema:
o El protocolo del registro del sistema no proporciona confirmación de la entrega de mensajes. Aunque algunos transportes pueden proporcionar información de estado, conceptualmente, syslog es un protocolo de comunicaciones simple puro.
 o Los originadores y relés pueden configurarse para enviar el mismo mensaje a varios colectores y relés.
 o La funcionalidad del originador, el relé y el colector pueden residir en el mismo sistema.

Asignación de transporte mínima requerida

 Todas las implementaciones de esta especificación DEBEN admitir un transporte basado en TLS, como se describe en [RFC5425].
 Todas las implementaciones de esta especificación también DEBEN admitir un transporte basado en UDP, como se describe en [RFC5426]. Se RECOMIENDA que las implementaciones de esta especificación utilicen el transporte basado en TLS.
La naturaleza de forma libre de los mensajes de syslog es la mayor fortaleza de syslog, pero también es el mayor problema de syslog. Es muy difícil analizar un registro que incluye eventos de docenas de sistemas diferentes de diferentes proveedores y darles sentido simultáneamente. ¿Qué mensajes representan qué funciones? ¿Y cuáles representan eventos críticos frente a meros mensajes informativos?
Para hacer frente a estas preguntas, el protocolo syslog (que se define en RFC 5424) proporciona estos mensajes de forma libre con campos especiales llamados "instalación" y "gravedad".
(Tenga en cuenta que RFC 5424 es el estándar para syslog, pero no todas las implementaciones de syslog son compatibles con RFC 5424. El protocolo syslog existe desde hace mucho tiempo y todavía hay algunas implementaciones preestándar en uso).

Requisitos de seguridad para el registro del sistema

Los mensajes de syslog pueden transitar varios saltos para llegar al recopilador deseado. Es posible que el originador, el repetidor o el receptor no confíen en algunas redes intermediarias porque la red se encuentra en un dominio de seguridad diferente o en un nivel de seguridad diferente al del originador, el repetidor o el recopilador. Otro problema de seguridad es que el originador, el repetidor o el receptor se encuentran en una red insegura.
Hay varias amenazas que se deben abordar para la seguridad del registro del sistema.

Las amenazas principales son las siguientes:

  o Mascarada. Un remitente de transporte no autorizado puede enviar mensajes a un receptor de transporte legítimo, o un receptor de transporte no autorizado puede intentar engañar a un remitente de transporte legítimo para que le envíe mensajes de syslog. 
 
  o Modificación. Un atacante entre el remitente de transporte y el receptor de transporte puede modificar un mensaje de registro del sistema en tránsito y, a continuación, reenviar el mensaje al receptor de transporte. Esta modificación puede hacer que el receptor de transporte malinterprete el mensaje o que se comporte de forma no deseada.

  o Divulgación. Una entidad no autorizada puede examinar el contenido de los mensajes de registro del sistema y obtener acceso no autorizado a la información. Algunos datos en los mensajes de registro del sistema son confidenciales y pueden ser útiles para un atacante, como la contraseña de un administrador o usuario autorizado.

La amenaza secundaria es

o Modificación del flujo de mensajes. Un atacante puede eliminar uno o más mensajes de registro del sistema de una serie de mensajes, reproducir un mensaje o alterar la secuencia de entrega. El protocolo de registro del sistema en sí no se basa en el orden de los mensajes. Sin embargo, un evento en un mensaje de registro del sistema puede relacionarse semánticamente con eventos en otros mensajes, por lo que el orden de los mensajes puede ser importante para comprender una secuencia de eventos.

Las siguientes amenazas se consideran de menor importancia para syslog y no se abordan en este documento:
  o Denegación de Servicio

o Análisis de Tráfico

Uso de TLS para proteger el registro del sistema

TLS se puede utilizar como un transporte seguro para contrarrestar todas las amenazas principales para el registro del sistema descritas anteriormente

  o Confidencialidad para contrarrestar la divulgación del contenido del mensaje.

  o Comprobación de integridad para contrarrestar las modificaciones de un mensaje salto a salto.

  o Servidor o autenticación mutua para contrarrestar la mascarada.

Nota: Este transporte seguro (es decir, TLS) solo protege el transporte del registro del sistema de manera salto por salto y no se preocupa por el contenido de los mensajes de registro del sistema. En particular, la identidad autenticada del remitente de transporte (p. ej., el nombre del sujeto en el certificado) no está necesariamente relacionada con el campo HOSTNAME del mensaje de registro del sistema. Cuando se requiere la autenticación del origen del mensaje del registro del sistema, se puede utilizar [SYS-SIGN].

Cifrado del tráfico del registro del sistema con TLS (SSL https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Guía de SIEM
y registro del sistema de Dell Security Management Serverhttps://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide

Registro
de Rsyshttps://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

 Guía del usuario de eventos y alertas para PowerMax y VMAX 9.2

Guía de referencia de la CLI de Solutions Enabler 9.2

Ayuda en línea de Unisphere para PowerMax 9.2.0