요약

  • RFC 3164에 기록된 동작에 따라, PRI는 인식하지만 TIMESTAMP는 인식하지 못한 릴레이는 자신의 현재 현지 시간을 삽입하고 가능하면 릴레이가 파악한 장치 식별 정보도 삽입했습니다.
  • 확장된 패킷은 여전히 1,024바이트 안에 들어가야 했습니다. 새 필드가 한도를 넘기면 릴레이는 꼬리 부분을 잘라야 했고, 그곳에 원래 메시지의 가장 중요한 내용이 있었을 수 있습니다.
  • 이후의 syslog 표준은 발신 장치, 릴레이, 수집기, 전송 역할을 더 정확하게 구분했습니다. 그러나 이 표준들은 깔끔한 구문, 정확한 프레이밍, TLS 피어 신원을 변경되지 않은 종단 간 발신의 증거로 만들지는 않았습니다.

복구 비용은 페이로드로 지불해야 했다

2001년에RFC 3164가 발표될 때 이미 syslog에는 역사가 있었습니다. 이 문서는 관측된 BSD 관행을 기술했습니다. 문서는 메시지를 생성하는 기기를 device, 메시지를 받아 전달하는 기기를 relay, 전달 없이 받기만 하는 기기를 collector라고 불렀습니다. 발신 측은 다음 홉에서 어떤 역할이 기다리는지 알 필요가 없었습니다.

릴레이는 먼저 꺾쇠 괄호로 묶인 우선순위인 PRI를 검사한 다음 TIMESTAMP의 형식을 검사했습니다. 두 값이 모두 유효하고 자신의 설정이 해당 우선순위를 전달 대상으로 선택했다면, 릴레이는 패킷을 변경하지 않고 전송해야 했습니다. 기록된 시간이 정확한지 판단할 필요는 없었습니다. HOSTNAME이 네트워크 발신지와 일치하는지 확인할 필요도 없었습니다.

따라서 이 분기에서 '유효'란 변경 없이 라우팅할 수 있을 만큼 인식 가능하다는 뜻이었습니다. 헤더가 사실을 말하고 있다는 판정이 아니었습니다.

더 중대한 분기는 PRI는 유효하지만 TIMESTAMP가 없거나 형식이 잘못된 경우에 시작되었습니다. 릴레이는 PRI 바로 뒤에 타임스탬프와 공백을 삽입해야 했습니다. 그 값은 릴레이의 현재 현지 시간이었습니다. 발신 장치의 시계를 복원한 값이나 응용 프로그램 이벤트가 발생한 시점의 추정치가 아니었습니다.

릴레이는 HOSTNAME도 삽입해야 했습니다. 릴레이가 알고 있던 장치 이름을 사용했고, 이름을 확인할 수 없으면 장치의 IP 주소를 사용했습니다. 이후 도착한 나머지 내용은 모두 CONTENT가 되어 이 새 필드들 뒤에 이어졌습니다. 릴레이는 발신 프로세스를 복원할 수 없었기 때문에 TAG를 만들지는 않았습니다.

결과에는 더 많은 좌표가 담겼습니다. 이 릴레이가 패킷을 관측한 시각과, 이 릴레이가 바로 앞 장치와 연관 지은 식별 정보입니다. 그러나 RFC 3164는 여전히 전체 패킷이 1,024바이트를 넘지 않도록 요구했습니다. 타임스탬프, 또는 타임스탬프와 호스트명을 삽입한 뒤 릴레이는 다시 크기를 세야 했습니다. 패킷이 한도를 초과해 늘어났다면 1,024바이트로 잘라야 했습니다.

사양은 그 결과를 단순하게 말합니다. 원래 패킷의 끝에서 중요한 정보가 사라질 수 있습니다. 맥락은 추가 저장 공간과 함께 오지 않았습니다. 맥락은 자신이 설명하려던 내용과 경쟁했습니다.

어떤 경보는 정상적인 우선순위, 그럴듯한 날짜, 인식 가능한 호스트를 유지하면서도 대상 이름, 오류 코드, 결과 또는 최종 한정 정보를 잃을 수 있었습니다. 수집기는 분류하기는 더 쉬워졌지만 올바르게 해석하기는 더 어려워진 기록을 확보한 것입니다.

우선순위 없는 패킷은 정규화에 더 많이 지불했다

RFC 3164는 식별 가능한 PRI가 없는 패킷을 위한 세 번째 경로도 마련했습니다. 릴레이는 기본 우선순위 13을 삽입하고 자신의 타임스탬프를 추가하고, 가능하면 호스트명도 추가하며, 받은 패킷 전체를 CONTENT로 취급했습니다. 그런 다음 같은 1,024바이트 검사와 필수 잘라내기를 적용했습니다.

입력 구조가 나쁠수록 정규화가 소모하는 바이트는 늘어났습니다. 그런데 뒤쪽 릴레이는 복구된 PRI와 TIMESTAMP를 유효한 값으로 보고 결과를 그대로 전달할 수 있었습니다. 최종 사본만 보존하는 수집기는 어떤 헤더 필드가 장치에서 왔고 어떤 필드가 첫 릴레이에서 왔는지 알려주지 못할 수도 있습니다. 사라진 꼬리 부분이 한때 존재했다는 표시도 없습니다.

구식 타임스탬프는 별도의 불확실성을 더했습니다. 여기에는 월, 일, 현지 시간이 담기지만 연도와 시간대는 없었습니다. 수집기는 보관 기간으로부터 연도를 추론할 수 있었지만, 지연된 패킷과 연도 경계는 그 추론을 흐렸습니다. 릴레이가 삽입한 타임스탬프는 가장 직접적으로는 릴레이의 관측 시점을 나타내며, 발신 장치의 이벤트를 나타내지 않습니다.

정확한 프레이밍은 이미 불완전한 메시지를 보존할 수도 있다

2009년에 발표된RFC 5424는 originator, relay, collector, transport sender, transport receiver라는 용어를 공식화했습니다. 그 헤더에는 VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, MSGID가 들어가고, 그 뒤에 구조화된 데이터와 선택적 메시지가 옵니다. 더 명확한 역할 어휘는 각 필드가 누구의 주장인지 묻기 쉽게 만들었습니다.

이 표준은 메시지 크기 지원을 전송 매핑 쪽으로 옮겼습니다. 모든 전송 수신기는 480옥텟까지는 반드시 받아야 하고 2,048옥텟까지는 받는 것이 권장되었습니다. 지원 범위를 넘는 메시지를 만난 수신기는 페이로드를 잘라내거나 메시지를 폐기할 수 있었습니다.

잘라낸다면 그 절단은 끝부분에서 이루어져야 했습니다. 이것은 접두부는 보존하지만 나머지가 유효하다는 보장은 주지 않았습니다. UTF-8이나 구조화된 데이터는 인코딩 중간에서 끊길 수 있습니다. 보안 논의는 잘라내기가 중요한 로그 정보를 숨기는 데 사용될 수 있다고 경고하고, 중요한 정보는 가능한 한 앞쪽에 배치하도록 권고했습니다.

접두부의 생존은 명시적인 설계 고려 사항이 되었습니다. 완전성에 대한 보장은 아니었습니다.

RFC 5425의 TLS 매핑은 각 syslog 메시지를 십진 옥텟 수와 공백으로 감쌉니다. 메시지가 TLS 레코드에 걸쳐 있거나 하나의 레코드에 여러 메시지가 들어 있어도 수신기는 정확한 메시지 경계를 알 수 있습니다. 수신기는 최소 2,048옥텟을 처리해야 하고 8,192옥텟까지 처리하는 것이 권장됩니다.

그럼에도 TLS는 syslog를 홉 단위로 보호합니다. RFC 5425는 인증된 전송 발신자 신원이 syslog 메시지 내부의 HOSTNAME과 일치할 필요가 없음을 명시적으로 언급합니다. 완전한 TLS 프레임은 한 피어가 그 보호된 연결을 통해 전달한 내용을 증명할 뿐입니다. 이전 릴레이가 내용을 전혀 변경하거나 줄이지 않았다는 것은 증명하지 않습니다.

RFC 5426의 UDP 매핑은 각 데이터그램에 정확히 하나의 syslog 메시지를 담으며, 그 메시지는 완전할 수도 잘려 있을 수도 있습니다.RFC 6587에 기록된 TCP 관행에는 옥텟 카운팅과 구분자 기반 비투명 프레이밍이 있습니다. 둘 다 메시지 단위를 구분하지만, 단위가 도착하기 전에 잘려나간 꼬리를 복원하지는 못합니다.

IANA Syslog Parameters 레지스트리는 facility, severity, 버전, 구조화 데이터 식별자를 할당합니다. 이것은 값을 해독하기 위한 근거입니다. 특정 구현이 그 값을 지원한다는 근거, 메시지가 전달되었다는 근거, HOSTNAME이 진짜라는 근거, 보존된 기록이 완전하다는 근거는 아닙니다.

출처