어플라이언스 로그를 원격 수집기로 안전하게 보내는 방법

어플라이언스는 로그를 출력할 수 있고, 수집기는 인터넷 반대편에 있으며, 모두가 처음 던지는 질문은 어떤 터널을 만들 것인가입니다. 그 틀은 잘못된 지점에서 시작합니다. 전송 방식을 결정하는 것은 어플라이언스가 생성할 수 있는 형식, 수집기가 받아들일 인증, 그리고 링크가 끊길 때 '전달됨'이 무엇을 의미해야 하는지입니다. 이 세 가지 답을 적어 두면 전송 방식은 대개 스스로 정해집니다.

어플라이언스가 출력할 수 있는 것에서 시작하십시오

실제로는 세 가지 형태만 있습니다. UDP 또는 TCP를 통한 개별 syslog 이벤트, 제품에 내장된 인증된 HTTPS 업로드, 또는 디스크에 기록해 옮겨야 하는 완전한 파일입니다. UDP syslog만 보낼 수 있는 방화벽은 터널을 추가해도 TLS 송신자가 되지 않으며, 암호화된 봉투 안에서도 확인되지 않은 데이터그램을 계속 보냅니다.

따라서 먼저 송신자를 목록화하십시오. 프로토콜, TLS 지원과 어떤 TLS 라이브러리인지, 수집기의 인증서를 검증할 수 있는지, 클라이언트 인증서를 제시할 수 있는지, 전송 버퍼가 재부팅을 견디는지이며, 어플라이언스가 할 수 없는 일은 경로의 다른 무언가가 해야 하고, 그 다른 무언가가 설계의 일부가 됩니다.

TLS syslog: 양쪽이 모두 말할 때 가장 짧은 경로

어플라이언스가 TLS를 통한 syslog를 지원하고 수집기가 이를 종단한다면, 그것을 사용하고 멈추십시오. 애플리케이션 프로토콜이 스스로를 보호하고, 수집기가 송신자를 인증하며, 이제 가용성을 떠맡을 추가 홉이 없습니다. 함정은 'TLS syslog'가 매우 다양한 구현을 포괄한다는 점이며, 현재의 안전한 syslog 지침 은 오래된 자습서의 암호 목록을 넘어섰으며, 그래서 작동하던 포워더가 라이브러리 업그레이드 후 깨지는 것입니다.

rsyslog에서는 전송 모듈의 이름만으로 어떤 시대인지 알 수 있으며, lmnsd_gtls은 GnuTLS를 감싸고, lmnsd_ossl은 OpenSSL을 감싸며 현재 8.x 패키지가 제공하는 것이 후자입니다. 인증서 검증이 있는 전달 작업은 대략 다음과 같으며, 정확한 매개변수 이름은 설치된 버전과 대조해 확인할 가치가 있습니다:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

송신자를 디버깅하기 전에 엔드포인트를 검증하십시오. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error은 유효한 체인으로 핸드셰이크를 완료하거나 어느 검사가 실패했는지 정확히 알려줍니다. 노트북이 아니라 어플라이언스에서 시험해야 하며, 중요한 것은 어플라이언스의 트러스트 저장소입니다.

SFTP: 파일에는 적합하고 스트림에는 부적합

파일 기반 전달은 회전하는 로그만 쓰는 어플라이언스에 적합합니다. SSH 기반 전송은 호스트 키, 계정별 키, 감사할 수 있는 파일 시스템을 제공하므로 TLS를 전혀 할 수 없는 장치에 합리적인 신뢰 이야기입니다. 이벤트 스트림에는 좋지 않은 선택인데, '파일이 매시간 기록된다'는 것은 장애가 현재 시간의 꼬리를 잃게 한다는 뜻입니다.

호스트 검증을 켜 두십시오. 프롬프트를 피하려고 이를 끄는 배치 호출은 전송이 가진 유일한 인증을 무력화합니다:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

프로비저닝 중에 계정의 known_hosts에 호스트 키를 고정하고, 계정을 대상 디렉터리로 제한하며, chroot가 있는 internal-sftp 하위 시스템을 선호하고, 재전송 이야기도 계획하십시오. 부분 실패 후 파일을 다시 보낸다면 수집기는 도착 시간이 아니라 보통 이름과 체크섬으로 중복과 새 파일을 구별할 수 있어야 합니다.

로컬 게이트웨이나 터널이 정직한 답일 때

일부 어플라이언스는 아무도 노출하고 싶지 않은 형식만 말할 수 있습니다. 그 경우 어플라이언스 자체 네트워크의 권한 있는 수집기가 기본 형식을 받아 TLS로 계속 전달합니다. 합법적인 설계이지만 무엇을 사는지 정확히 말해야 하며, 게이트웨이에서 시작하는 암호화는 어플라이언스와 게이트웨이 사이 구간을 소급해 보호하지 않으므로, 그 홉에는 여전히 자체 신뢰 경계와 접근 제어가 필요합니다.

라우팅된 사이트 또는 장치 터널은 가장 무거운 선택이며, 수집기가 사설 주소를 유지해야 하고 로그뿐 아니라 여러 서비스를 실어야 할 때입니다. 주소 계획, 접근 규칙, 반환 경로, 터널 엔드포인트의 수명 주기를 수반합니다. 내부 프로토콜도 개선하지 않으며 IPsec 터널 내부의 UDP syslog는 여전히 전달 확인이 없는 데이터그램 서비스입니다.

무엇을 선택하든 수집기의 권한을 전송보다 좁게 유지하십시오. 터널 정체성은 엔드포인트에 속하며, 메시지의 특정 호스트 이름 필드를 어느 하위 어플라이언스가 생성했는지에 대해서는 아무것도 말하지 않습니다.

보내기 전에 전달 계약을 작성하십시오

암호화, 인증, 보존은 서로 다른 질문에 답하며 큐는 보존 정책이 아니며, 첫 로그가 어플라이언스를 떠나기 전에 이 수집기에서 확인이 실제로 무엇을 의미하는지 결정하십시오. 회선에서 수신되었는지, 처리 위해 수락되었는지, 아니면 저장소에 내구성 있게 기록되었는지입니다. 세 가지 다른 보증이며 수집기 재시작을 견디는 것은 마지막 하나뿐입니다.

그런 다음 운영상 질문에 서면으로 답하십시오. 보내지 않은 이벤트는 어디에서 기다리며 그 버퍼는 정전을 견디는가? 가득 차면 무슨 일이 일어나고 누가 통보받는가? 재시도는 어떻게 제한되고 중복은 어떻게 식별되는가? 전달 홉이 호스트 이름을 다시 쓸 수 있다면 어느 필드가 송신자의 신원을 증명하는가?

설계는 한 문단으로 설명할 수 있을 만큼 작게 유지하고, 필요한 이벤트를 운반하는 가장 작은 지원 전송 방식에 그것이 제공하지 않는 보증에 대한 명시적 설명을 더합니다. 답에 두 홉이 필요하면 runbook에 그렇게 쓰고 각 홉에 책임자를 두십시오.