gopassivedns

네트워크 기반 DNS 로깅 (Go)

요약

네트워크 캡처 기반 DNS 로거로, https://github.com/gamelinux/passivedns에서 영감을 받았습니다. gopacket을 사용하여 libpcap 및 패킷 처리를 다룹니다. JSON 로그를 출력합니다. 하나에서 수백 개의 DNS 리졸버가 있는 환경에서 높은 볼륨의 쿼리 캡처를 처리하기 위한 것입니다.

gamelinux의 PassiveDNS를 사용하지 않는 이유는?

좋은 선택입니다. 저는 이 도구를 만든 이유는 문서화되지 않은 많은 에지 케이스가 있는 대량의 신뢰할 수 없는 데이터를 처리하는 작업은 메모리 손상 공격을 방지하기 위해 관리형 런타임으로 처리되어야 한다고 믿기 때문입니다. 저는 여러 조직에서 PassiveDNS를 배포했으며, 관찰된 몇 가지 특정 문제점을 해결하기 위해 gopassivedns를 만들었습니다: 많은 위치에 계측이 필요했고, 많은 조회를 처리할 수 있도록 스토리지 계층을 확장해야 했으며, 모든 DNS 에지 케이스에 대해 좋은 테스트 커버리지를 가진 테스트 스위트를 원했습니다.

Bro (또는 다른 DNS 로깅 IDS)를 사용하지 않는 이유는?

또한 좋은 선택입니다. Bro와 같은 시스템은 일반적으로 네트워크 이그레스(egress)에 배포되며, 이는 조회의 실제 출처가 재귀 리졸버 뒤에 숨겨지는 결과를 초래합니다. 즉, 일반적으로 Bro를 배포하고 리졸버 쿼리 로깅(가능한 경우)을 수행한 다음, 두 로그를 중앙 로깅 시스템에 통합하여 클라이언트까지 조회를 추적해야 합니다. gopassivedns는 리졸버 설정 변경 없이 리졸버에 배포하거나 네트워크 이그레스에 배포하고, 신뢰할 수 있는 프로토콜을 통해 중앙에 로깅하며, 모든 로그 시스템에 간단히 파싱되도록 설계되었습니다.

그냥 리졸버 쿼리 로깅을 사용하지 않는 이유는?

리졸버의 쿼리 로깅 지원(질문과 응답 모두 포함)은 기껏해야 부실합니다. 가장 많이 배포된 DNS 서버 중 하나인 BIND는 전혀 지원하지 않습니다. Windows DNS와 같은 다른 서버는 매우 형편없는 로그 형식을 가지고 있습니다. 또한 네트워크 기반 로깅은 클라이언트에서 원격 서버(예: Google DNS)로 직접 전송된 쿼리를 포착합니다.

사용법

구성 옵션은 환경 변수, .env 파일 또는 명령줄에서 지정할 수 있습니다. 우선순위는 명령줄 플래그, .env 파일, 마지막으로 환경에 이미 정의된 변수입니다. 구성 옵션은 다음과 같습니다.

• -dev [device] 캡처용 네트워크 장치 (ENV: PDNS_DEV)
• -fluentd_socket [socket] 메시지팩 형식으로 로깅하는 데 사용되는 Fluentd 유닉스 소켓 경로 (ENV: PDNS_FLUENTD_SOCKET)
• -bpf [bpf filter] 캡처용 BPF 필터 (기본값: port 53) (ENV: PDNS_BPF)
• -pcap [file] 처리할 pcap 파일 (ENV: PDNS_PCAP_FILE)
• -logfile [file] DNS 조회 로그 파일 (소규모 배포 또는 디버깅에만 권장) (ENV: PDNS_LOG_FILE)
• -logMaxAge 로그 파일 회전 전 최대 보관 일수 (기본값: 28) (ENV: PDNS_LOG_AGE)
• -logMaxBackups 회전 후 보관되는 최대 파일 수 (기본값: 3) (ENV: PDNS_LOG_BACKUP)
• -logMaxSize 회전 전 로그 파일 최대 크기 (MB) (기본값: 100) (ENV: PDNS_LOG_SIZE)
• -quiet DNS 조회를 STDOUT에 기록하지 않음 (ENV: PDNS_QUIET)
• -debug STDOUT에 디버그 로깅 활성화 (ENV: PDNS_DEBUG)
• -gc_age [num] 불완전한 연결을 가비지 컬렉션할 기준 시간 (기본값: -1m) (ENV: PDNS_GC_AGE)
• -gc_interval [num] 연결 테이블에서 GC가 실행되는 간격 (기본값: 3m) (ENV: PDNS_GC_INTERVAL)
• -kafka_brokers [brokers] 쉼표로 구분된 Kafka 브로커 목록 (ENV: PDNS_KAFKA_PEERS)
• -kafka_topic [topic] 로깅용 Kafka 토픽 (ENV: PDNS_KAFKA_TOPIC)
• -cpuprofile [file] CPU 프로파일링 활성화 (ENV: PDNS_PROFILE_FILE)
• -numprocs [num] 패킷 데이터 파싱에 사용할 고루틴 수 (기본값: 8) (ENV: PDNS_THREADS)
• -pfring PF_RING을 사용한 패킷 캡처 (ENV: PDNS_PFRING)
• -statsd_host statsd 서버의 호스트 및 포트 (예: localhost:8125) (ENV: PDNS_STATSD_HOST)
• -statsd_interval statsd 전송 간격 (초) (ENV: PDNS_STATSD_INTERVAL)
• -statsd_prefix 사용할 메트릭 이름 접두사 (기본값: gopassivedns) (ENV: PDNS_STATSD_PREFIX)
• -snaplen [int] pcap 버퍼에 사용되는 snaplen
• -name 통계 및 로그 메시지에 사용할 센서 이름 (기본값: 호스트 이름) (ENV: PDNS_NAME)
• -syslog_facility syslog 시설 (ENV: PDNS_SYSLOG_FACILITY)
• -syslog_priority syslog 우선순위 (ENV: PDNS_SYSLOG_PRIORITY)

-dev 또는 -pcap 중 하나를 제공해야 합니다.

고루틴과 표준 데몬화 프로세스 사이에 알려진 문제가 있습니다(https://github.com/golang/go/issues/227). 따라서 시스템 도구를 사용하여 이 프로세스를 데몬으로 실행하려면 여기에 설명된 방법 중 하나를 사용하는 것을 강력히 권장합니다: http://stackoverflow.com/questions/10067295/how-to-start-a-go-program-as-a-daemon-in-ubuntu

syslog 로깅을 사용하기로 선택한 경우, golang의 "log/syslog"를 사용합니다. 이는 syslog와 통신하는 데 사용되는 유닉스 소켓이 /dev/log, /var/run/log 또는 /var/run/syslog 중 하나에 있어야 합니다.

배포 가이드

이 도구를 어디에 배포해야 하나요?

세 가지 선택이 있습니다: 리졸버에 배포하거나 게이트웨이에 배포하거나 둘 다 배포하는 것입니다. 리졸버에 배포하면 원래 요청을 보낸 클라이언트의 IP 주소를 얻을 수 있기 때문에 좋습니다. 또한 요청의 업스트림 경로(리졸버에서 체인의 다음 리졸버로)도 볼 수 있습니다. 단, BPF 필터를 조정하여 해당 경로를 무시하지 않는 경우입니다. 게이트웨이에 배포하면 클라이언트 -> 내부 리졸버 경로를 볼 수 없으므로 요청을 특정 클라이언트에 연결하기 어려울 수 있습니다. 반면에 내부 리졸버를 우회하는 요청을 볼 수 있습니다. 또한 리졸버가 사용하는 모든 업스트림 리졸버로부터 오는 쿼리도 볼 수 있습니다. 이상적인 세계에서는 이 도구를 각 내부 리졸버와 게이트웨이의 탭(tap)에 배포할 것입니다. 내부 리졸버는 쿼리의 업스트림 경로를 무시하는 BPF 필터를 가지게 하고, 게이트웨이는 아무것도 무시하지 않게 할 것입니다.

결과로 무엇을 해야 하나요?

현재로서는 logstash를 사용하여 로그를 elasticsearch 클러스터로 전송하는 것을 권장합니다. 모든 로그는 JSON이므로 매우 쉬울 것입니다. 또한 장기 저장 및 대량 분석을 위해 HDFS와 같은 것을 사용하는 것이 좋습니다. DNS 쿼리는 내부 데이터의 놀라운 소스입니다!

빌드 및 설치

• 이 저장소를 클론하세요
• libpcap, libpcap-dev를 설치하세요
• 'go get'
• 'go build -o gopassivedns' (-o는 정말 주의를 위한 것이며, 저장소를 클론했다면 필요하지 않을 것입니다)
• 'cp gopassivedns /some/path/to/gopassivedns'