Syslog seguro remoto do Unisphere for PowerMax 9.2

Histórico do Syslog

Syslog foi desenvolvido na década de 1980 por Eric Paul Allman (nascido em 2 de setembro de 1955).
Eric é um programador de computador americano que desenvolveu o Sendmail e seu precursor Delivermail no final dos anos 1970 e início dos anos 1980 na Uc Berkeley. Em 1998, Allman e Greg Olson co-fundaram a empresa Sendmail, Inc. O formato de log usado pelo agente de transferência de mensagens mta, conhecido como syslog. O Syslog foi inicialmente usado apenas pelo Sendmail, mas eventualmente se tornou um formato padrão não oficial usado por outros programas não relacionados para registro. Mais tarde, este formato foi oficializado pelo Rfc 3164 em 2001; No entanto, o formato original tornou-se obsoleto pela revisão mais recente, Rfc 5424.

Força-tarefa de engenharia da Internet

A Internet Engineering Task Force (IETF) é uma organização de padrões abertos, que desenvolve e promove padrões voluntários da Internet, em particular os padrões que consistem no conjunto de protocolos da Internet (TCP/IP). 
Não tem lista formal de membros ou requisitos de associação. Todos os participantes e gestores são voluntários, embora seu trabalho seja financiado por seus empregadores ou patrocinadores.

O Internet Architecture Board (IAB) supervisiona os relacionamentos externos do IETF e as relações com o Editor RFC. O IAB fornece direção técnica de longo alcance para o desenvolvimento da Internet. O IAB também é co-responsável pelo Comitê de Supervisão Administrativa do IETF (IAOC), que supervisiona a Atividade de Apoio Administrativo do IETF (IASA), que fornece apoio logístico para o IETF. 
O IAB também gerencia o Internet Research Task Force (IRTF), com o qual o IETF tem várias relações entre grupos.

Grupo diretivo

O Internet Engineering Steering Group (IESG) é um órgão composto pelo presidente da Internet Engineering Task Force (IETF) e diretores de área. Ele fornece a revisão técnica final dos padrões da Internet e é responsável pelo gerenciamento diário do IETF. Recebe recursos das decisões dos grupos de trabalho, e o IESG toma a decisão de avançar os documentos na trilha de normas.

O 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)
 +------------------------+  +----------------------+
      ^                                     ^
      |                                     |
          -----------------------------

Como o syslog é transportado?

Há duas maneiras comuns de enviar mensagens syslog. Embora a RFC 5424 exija que todas as implementações de syslog devam suportar um transporte de rede TLS criptografado por TCP, a maioria das mensagens de syslog ainda é entregue usando o método UDP mais antigo. Na versão UDP, as mensagens são simplesmente colocadas na parte de dados de um pacote UDP e enviadas ao servidor pela porta UDP 514. Cada mensagem geralmente caberá em um único pacote. O UDP é stateless e session less, portanto, não há confirmação. Os pacotes são enviados para a rede. Isso tem o problema óbvio de que qualquer tipo de problema de rede pode impedir a entrega do pacote, caso em que você pode não saber que a rede está inativa porque não pode dizer. Isso também significa que, às vezes, pacotes importantes podem ser perdidos ou danificados em trânsito.

Princípios Básicos

 Os seguintes princípios se aplicam à comunicação syslog:
o O protocolo syslog não fornece confirmação de entrega de mensagem. Embora alguns transportes possam fornecer informações de status, conceitualmente, o syslog é um protocolo de comunicação simplex puro.
 o Originadores e relés podem ser configurados para enviar a mesma mensagem para vários coletores e relés.
 o As funcionalidades do originador, relé e coletor podem residir no mesmo sistema.

Mapeamento mínimo de transporte necessário

 Todas as implementações desta especificação DEVEM dar suporte a um transporte baseado em TLS, conforme descrito em [RFC5425].
 Todas as implementações desta especificação também DEVEM suportar um transporte baseado em UDP, conforme descrito em [RFC5426]. É RECOMENDÁVEL que implementações dessa especificação usem o transporte baseado em TLS.
A natureza de forma livre das mensagens do syslog é a maior força do syslog, mas também é o maior problema do syslog. É muito difícil analisar um log que inclui eventos de dezenas de sistemas diferentes de diferentes fornecedores e dar sentido a eles simultaneamente. Quais mensagens representam quais funções? E quais representam eventos críticos versus meras mensagens informativas?
Para lidar com essas questões, o protocolo syslog (que é definido na RFC 5424) fornece essas mensagens de forma livre com campos especiais chamados "facilidade" e "gravidade".
(Observe que o RFC 5424 é o padrão para syslog, mas nem todas as implementações de syslog são compatíveis com RFC 5424. O protocolo syslog existe há muito tempo e há algumas implementações pré-padrão ainda em uso.)

Requisitos de segurança para syslog

As mensagens do Syslog podem transitar vários saltos para chegar ao collector pretendido. Algumas redes intermediárias podem não ser confiáveis para o originador, retransmissão ou receptor porque a rede está em um domínio de segurança diferente ou em um nível de segurança diferente do originador, relé ou coletor. Outra preocupação de segurança é que o próprio originador, relé ou receptor está em uma rede insegura.
Há várias ameaças a serem abordadas para a segurança do syslog.

As principais ameaças são

  o Máscara. Um remetente de transporte não autorizado pode enviar mensagens para um destinatário de transporte legítimo, ou um receptor de transporte não autorizado pode tentar enganar um remetente de transporte legítimo para enviar mensagens syslog para ele. 
 
  o Modificação. Um invasor entre o remetente de transporte e o destinatário de transporte pode modificar uma mensagem syslog em trânsito e, em seguida, encaminhar a mensagem para o receptor de transporte. Tal modificação pode fazer com que o receptor de transporte entenda mal a mensagem ou fazer com que ela se comporte de maneiras indesejáveis.

  o Divulgação. Uma entidade não autorizada pode examinar o conteúdo das mensagens syslog, obtendo acesso não autorizado às informações. Alguns dados nas mensagens do syslog são confidenciais e podem ser úteis para um invasor, como a senha de um administrador ou usuário autorizado.

A ameaça secundária é

o Modificação do fluxo de mensagens. Um invasor pode excluir uma ou mais mensagens syslog de uma série de mensagens, reproduzir uma mensagem ou alterar a sequência de entrega. O protocolo syslog em si não é baseado na ordem das mensagens. No entanto, um evento em uma mensagem syslog pode se relacionar semanticamente a eventos em outras mensagens, portanto, a ordenação de mensagens pode ser importante para entender uma sequência de eventos.

As seguintes ameaças são consideradas de menor importância para o syslog e não são abordadas neste documento:
  o Negação de Serviço

o Análise de Tráfego

Como usar o TLS para proteger o Syslog

O TLS pode ser usado como um transporte seguro para combater todas as principais ameaças ao syslog descritas acima

  o Confidencialidade para combater a divulgação do conteúdo da mensagem.

  o Verificação de integridade para combater modificações em uma mensagem em uma base hop-by-hop.

  o Servidor ou autenticação mútua para combater mascarados.

Nota: Esse transporte seguro (ou seja, TLS) protege apenas o transporte de syslog de maneira hop-by-hop e não está relacionado ao conteúdo de mensagens de syslog. Em particular, a identidade autenticada do remetente do transporte (por exemplo, nome do assunto no certificado) não está necessariamente relacionada ao campo HOSTNAME da mensagem do syslog. Quando a autenticação da origem da mensagem syslog é necessária, [SYS-SIGN] pode ser usado.

Criptografando o tráfego do Syslog com TLS (SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Guia
de Syslog e SIEM do Dell Security Management Serverhttps://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide

https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html de log
Rsys

 Guia do usuário de eventos e alertas do PowerMax e do VMAX 9.2

Guia de referência da CLI do Solutions Enabler 9.2

Ajuda on-line do Unisphere for PowerMax 9.2.0