Unisphere for PowerMax 9.2 원격 보안 Syslog

Syslog 기록

Syslog는 Eric Paul Allman(1955년 9월 2일 출생)이 1980년대에 개발했습니다.
Eric은 Uc Berkeley에서 1970년대 후반과 1980년대 초반에 Sendmail과 그 선구자인 Delivermail을 개발한 미국 컴퓨터 프로그래머입니다. 1998년 Allman과 Greg Olson은 Sendmail, Inc.를 공동 설립했습니다. Syslog라고 하는 MTA 메시지 전송 에이전트에서 사용하는 로깅 형식입니다. Syslog는 처음에는 Sendmail에서만 사용되었지만 결국 로깅을 위해 관련 없는 다른 프로그램에서 사용하는 비공식 표준 형식이 되었습니다. 나중에 이 형식은 2001년 Rfc 3164에 의해 공식화되었습니다. 그러나 원래 형식은 최신 버전인 rfc 5424에 의해 더 이상 사용되지 않습니다.

인터넷 엔지니어링 태스크 포스

IETF(Internet Engineering Task Force)는 자발적인 인터넷 표준, 특히 TCP/IP(Internet Protocol Suite)로 구성된 표준을 개발하고 장려하는 개방형 표준 조직입니다. 
공식적인 회원 명부나 회원 자격 요건은 없습니다. 모든 참가자와 관리자는 고용주 또는 스폰서가 자금을 지원하지만 자원 봉사자입니다.

IAB(Internet Architecture Board)는 IETF의 외부 관계 및 RFC 편집기와의 관계를 감독합니다. IAB는 인터넷 개발을 위한 장기적인 기술 방향을 제공합니다. IAB는 또한 IETF에 대한 물류 지원을 제공하는 IETF 행정 지원 활동(IASA)을 감독하는 IETF 행정 감독 위원회(IAOC)를 공동으로 담당합니다. 
IAB는 또한 IETF와 여러 그룹 간 관계를 맺고 있는 IRTF(Internet Research Task Force)를 관리합니다.

운영 그룹

IESG(Internet Engineering Steering Group)는 IETF(Internet Engineering Task Force) 의장과 지역 책임자로 구성된 기관입니다. 인터넷 표준에 대한 최종 기술 검토를 제공하고 IETF의 일상적인 관리를 담당합니다. 실무 그룹의 결정에 대한 이의 제기를 받고 IESG는 표준 트랙에서 문서를 진행하기로 결정합니다.

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

syslog는 어떻게 전송됩니까?

syslog 메시지를 보내는 두 가지 일반적인 방법이 있습니다. RFC 5424에서는 모든 syslog 구현이 TCP를 통한 암호화된 TLS 네트워크 전송을 지원해야 하지만 대부분의 syslog 메시지는 여전히 이전 UDP 방법을 사용하여 전달됩니다. UDP 버전에서 메시지는 단순히 UDP 패킷의 데이터 부분에 배치되고 UDP 포트 514를 통해 서버로 전송됩니다. 각 메시지는 일반적으로 단일 패킷에 맞습니다. UDP는 상태 비저장 및 세션이 없으므로 승인이 없습니다. 패킷은 네트워크로 전송됩니다. 여기에는 모든 종류의 네트워크 문제가 패킷 전달을 방해할 수 있다는 명백한 문제가 있으며, 이 경우 사용자에게 알려줄 수 없기 때문에 네트워크가 다운되었는지 모를 수 있습니다. 또한 때때로 중요한 패킷이 전송 중에 손실되거나 손상될 수 있음을 의미합니다.

기본 원칙

 syslog 통신에는 다음 원칙이 적용됩니다.
o syslog 프로토콜은 메시지 전달에 대한 승인을 제공하지 않습니다. 일부 전송은 상태 정보를 제공할 수 있지만 개념적으로 syslog는 순수한 단방향 통신 프로토콜입니다.
 o 발신자와 릴레이는 여러 컬렉터 및 릴레이에 동일한 메시지를 보내도록 구성할 수 있습니다.
 o 발신자, 릴레이 및 수집기 기능은 동일한 시스템에 상주할 수 있습니다.

필요한 최소 전송 매핑

 이 사양의 모든 구현은 [RFC5425]에 설명된 것처럼 TLS 기반 전송을 지원해야 합니다(MUST).
 이 사양의 모든 구현은 [RFC5426]에 설명된 것처럼 UDP 기반 전송도 지원해야 합니다(SHOULD). 이 사양의 배포는 TLS 기반 전송을 사용하는 것이 좋습니다.
syslog 메시지의 자유 형식 특성은 syslog의 가장 큰 장점이지만 syslog의 가장 큰 문제이기도 합니다. 서로 다른 공급업체의 수십 가지 시스템에서 온 이벤트를 포함하여 로그를 구문 분석하고 동시에 이해하는 것은 매우 어렵습니다. 어떤 메시지가 어떤 기능을 나타냅니까? 그리고 중요한 이벤트를 나타내는 메시지와 단순한 정보 메시지를 나타내는 것은 무엇입니까?
이러한 질문을 처리하기 위해 syslog 프로토콜(RFC 5424에 정의됨)은 이러한 자유 형식 메시지에 "facility" 및 "severity"라는 특수 필드를 제공합니다.
RFC 5424는 syslog의 표준이지만 모든 syslog 구현이 RFC 5424와 호환되는 것은 아닙니다. syslog 프로토콜은 매우 오랫동안 사용되어 왔으며 여전히 사용 중인 몇 가지 사전 표준 구현이 있습니다.)

Syslog의 보안 요구 사항

Syslog 메시지는 의도한 Collector에 도착하기 위해 여러 홉을 전송할 수 있습니다. 일부 중개 네트워크는 발신자, 릴레이 또는 컬렉터와 다른 보안 도메인 또는 다른 보안 수준에 있기 때문에 발신자, 릴레이 또는 수신자가 신뢰하지 않을 수 있습니다. 또 다른 보안 문제는 발신자, 릴레이 또는 수신자 자체가 안전하지 않은 네트워크에 있다는 것입니다.
syslog 보안을 위해 해결해야 할 몇 가지 위협이 있습니다.

주요 위협은 다음과 같습니다.

  o 가장무도회. 권한이 없는 전송 발신자가 합법적인 전송 수신자에게 메시지를 보내거나 권한이 없는 전송 수신자가 합법적인 전송 발신자를 속여 syslog 메시지를 보내도록 할 수 있습니다. 
 
  o 수정. 전송 발신자와 전송 수신자 사이의 공격자는 전송 중인 syslog 메시지를 수정한 다음 메시지를 전송 수신자에게 전달할 수 있습니다. 이러한 수정은 전송 수신자로 하여금 메시지를 오해하게 하거나 바람직하지 않은 방식으로 동작하게 할 수 있다.

  o 공개. 권한이 없는 엔터티가 syslog 메시지의 내용을 검사하여 정보에 대한 권한 없는 액세스 권한을 얻을 수 있습니다. syslog 메시지의 일부 데이터는 권한이 부여된 관리자 또는 사용자의 암호와 같이 기밀이며 공격자에게 유용할 수 있습니다.

두 번째 위협은

o 메시지 스트림 수정. 공격자는 일련의 메시지에서 하나 이상의 syslog 메시지를 삭제하거나, 메시지를 재생하거나, 배달 시퀀스를 변경할 수 있습니다. syslog 프로토콜 자체는 메시지 순서를 기반으로 하지 않습니다. 그러나 syslog 메시지의 이벤트는 다른 메시지의 이벤트와 의미상 관련될 수 있으므로 메시지 순서는 일련의 이벤트를 이해하는 데 중요할 수 있습니다.

다음 위협은 syslog의 중요성이 낮은 것으로 간주되며 이 문서에서 다루지 않습니다.
  o 서비스

거부 o 트래픽 분석

TLS를 사용하여 Syslog 보호

TLS는 위에서 설명한 syslog에 대한 모든 주요 위협에 대응하기 위한 보안 전송으로 사용할 수 있습니다

  o 메시지 내용의 공개에 대응하기 위한 기밀 유지.

  o 홉 단위로 메시지 수정에 대응하기 위한 무결성 검사.

  o 서버 또는 상호 인증으로 가장무도회에 대응합니다.

참고: 이 보안 전송(즉, TLS)은 hop-by-hop 방식으로만 syslog 전송을 보호하며 syslog 메시지의 내용에는 관여하지 않습니다. 특히, 전송 발신자의 인증된 ID(예: 인증서의 주체 이름)가 반드시 syslog 메시지의 HOSTNAME 필드와 관련되는 것은 아닙니다. syslog 메시지 출처의 인증이 필요한 경우 [SYS-SIGN]을 사용할 수 있습니다.

TLS로 Syslog 트래픽 암호화(SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Dell Security Management Server Syslog 및 SIEM 가이드
https://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide

Rsys 로깅
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

 PowerMax 및 VMAX 9.2용 이벤트 및 알림 사용자 가이드

Solutions Enabler 9.2 CLI 참조 가이드

Unisphere for PowerMax 9.2.0 온라인 도움말