요약

  • RFC 3164는 구형 syslog 패킷 전체를 1,024바이트로 제한하면서, 누락된 타임스탬프와 선택적으로 호스트 이름을 릴레이가 추가하도록 지시합니다.
  • 이 보강 작업이 패킷을 한도를 초과하게 만들면 릴레이는 잘라내야 하며, RFC는 잃어버린 바이트에 원본 메시지 끝부분의 중요한 정보가 포함될 수 있다고 경고합니다.

헤더는 어딘가에 들어가야 했다

거의 가득 찬 syslog 패킷을 사용 가능한 타임스탬프 없이 보내는 라우터를 상상해 보세요. 릴레이는 이를 받아 우선순위 필드를 확인하고 전달을 준비합니다. RFC 3164의 §4.3.2에 따라 릴레이는 PRI 필드 뒤에 자신의 현재 현지 타임스탬프를 삽입해야 합니다. 판별 가능한 경우 호스트 이름도 추가해야 합니다. 나머지 원본 내용이 메시지의 CONTENT가 됩니다.

이 작업에는 대가가 있습니다. RFC 3164 §4.1은 이벤트 텍스트만이 아니라 전체 패킷을 1,024바이트로 제한합니다. PRI, 헤더, 메시지가 모두 하나의 예산을 공유합니다. 타임스탬프, 호스트 이름, 구분 공백이 재구성된 패킷을 너무 길게 만들면, §4.3.2는 릴레이가 새 길이를 확인하고 패킷을 다시 1,024바이트로 잘라내도록 요구합니다. 이 문서는 그 결과를 단순명료하게 밝힙니다. 원본 패킷 끝부분의 정보, 어쩌면 생명처럼 중요한 정보가 손실될 수 있습니다.

미묘한 점은 손실이 어디서 발생하느냐입니다. 수집기는 구문상 인식 가능한 syslog 메시지를 받을 수 있습니다. PRI와 새로 삽입된 헤더는 질서 정연해 보일 수 있습니다. 그러나 이벤트의 마지막 바이트들—"because" 뒤의 절, 명령 실행 결과, 기기 식별자, 체크섬, 진단 메시지의 두 번째 값—은 더 이상 존재하지 않을 수 있습니다. 이 예들은 가능성일 뿐이며, 이 글이 주장하는 실제 사건이 아닙니다. 이 프로토콜은 보강 작업이 이미 긴 입력을 공유 한도 너머로 밀어붙일 때 끝부분을 취약하게 만듭니다.

표준 지시 사항이지 구현 실태 조사가 아니다

이것은 BSD syslog 프로토콜을 기술하는 2001년 8월의 Informational 문서에 담긴 규칙이지, 모든 배포된 릴레이가 이를 따랐다는 증거가 아닙니다. RFC의 4.2절은 기기의 원본 UDP/514 페이로드가 유효한 syslog 메시지라면 무엇이든 될 수 있다고 말하며, 가독성을 높이고 릴레이 수정의 필요를 없애기 때문에 PRI, HEADER, MSG 구조를 포함할 것을 권장합니다. 6.1절은 별도로, 수신자는 1,024바이트를 초과하는 메시지에서 오작동해서는 안 되며 수신자마다 다른 동작이 있음을 경고합니다. 어느 구절도 실제 기기가 긴 메시지를 얼마나 자주 보냈는지, 어느 릴레이가 잘라냈는지, 어떤 수집기가 무엇을 보존했는지를 확인해 주지 않습니다.

또한 1,024바이트 메시지 한도는 경로 MTU와 혼용될 수 없습니다. 전자는 RFC 3164의 syslog 패킷/메시지 규칙이고, 후자는 경로를 따라 네트워크 계층 패킷 크기를 다룹니다. IP 단편화, UDP 데이터그램 처리, 애플리케이션 수준 잘라내기는 서로 다른 메커니즘입니다. 메시지는 프로토콜의 상한 안에 들면서 더 작은 경로 MTU와 상호작용할 수도 있고, 경로와 무관하게 구형 애플리케이션 상한을 초과할 수도 있습니다.

추가된 값들도 증거로서 한계가 있습니다. 타임스탬프는 릴레이의 현재 현지 시간이며, 반드시 이벤트의 원래 시각은 아닙니다. 호스트 이름은 그 릴레이가 아는 기기의 이름이며, 이름을 판별할 수 없으면 IP 주소입니다. RFC 3164는 수신자에게 그 호스트 이름을 발신자와 대조하여 검증하도록 요구하지 않습니다. 따라서 보강 작업은 기록을 더 읽기 쉽게 만들 수 있지만, 원본 이벤트 시각이나 암호학적 출처 신원을 증명하지는 못합니다.

이후 형식이 중요하지만—배포 실태를 정리하지는 않는 이유

RFC 5424는 이후 더 명시적인 syslog 헤더와 구조화된 데이터로 RFC 3164를 대체했습니다. RFC 6587은 TCP 프레이밍을 기술하며, 표준화된 syslog에서는 구형 1,024옥텟 상한이 확장되었음을 언급합니다. RFC 3195는 또 다른 경로를 택했습니다. 이 문서의 RAW 프로필은 BEEP 프레이밍 오버헤드를 제외한 채 각 이벤트 본문을 1,024바이트로 제한합니다. 이 비교는 "1,024바이트"가 계층에 따라 서로 다른 것을 측정할 수 있음을 보여주기 때문에 유용합니다. 그러나 새로운 RFC가 발표되었다고 해서 구형 발신기나 릴레이가 사라졌다는 것은 보여주지 않습니다.

역사적 교훈은 더 좁습니다. 릴레이가 맥락을 개선하려는 시도가 자신이 운반하는 콘텐츠와 동일한 유한한 예산을 소모할 수 있다는 것입니다. 결과 패킷은 여전히 도착하고, 구문 분석되고, 저장될 수 있습니다. 어느 상태도 원본 메시지 전체가 살아남았다는 증명이 아닙니다. 실제 시스템에서 그것을 입증하려면 발신 측 바이트, 각 릴레이의 입력과 출력, 수집기의 구문 분석, 그리고 이후의 재독회까지 짝지어진 증거가 필요합니다. 성공적인 전송이나 형식이 맞는 헤더만으로는 부족합니다.

출처