ZO

0. 들어가며

ElasticStack을 구축하며 beat와 logstash를 연동하여 운영하는데, beat를 통해 데이터를 수집하는 서버에서 아래 이미지와 같은 에러가 지속적으로 발생함을 알수있었다.

해당 글은 지속적으로 발생하는 해당 에러를 조치하는 방안을 작성한 글이다.

1. 원인 파악

원인을 파악하기 위해 클라이언트(beat)에서 로그스태시로 telnet 접속시도를 했는데 정상적으로 커넥션이 되는걸 확인할 수 있었다. 즉 통신에는 문제가 없음을 확인하였고, 로그를 확인해보니 내용에 나와있는 connection reset by peer의 경우 클라이언트가 아닌 서버측에서 RST를 던져서 접속이 끊길때 발생하는 에러이기에, RST를 던진쪽이 서버(logstash)인지 

상단 또는 네트워크장비인지 확인을 하기위해 방화벽장비에서 패킷을 캡쳐하여 와이어샤크로 확인을해봤다.

 위 이미지와 서버내 tcpdump와 같은 추가적인 확인을 통해 서버(logstash)에서 RST를 던지고 있음을 확인하였고, 추가로 서버에서 통신을 끊는 이유를 확인하기 위하여 logstash에서  타임아웃관련 옵션을 공식 docs를 통해 확인해봤다.

Client_inactivity_timeout

위 공식 Docs 링크에 나와있듯이 logstash의 input plugin의 옵션중 client_inactivity_timeout이라는 옵션이 있으며,

해당 옵션은 클라이언트가 inactivity상태라면 X초후에 끊는다 라는 의미로 보인다.

* Close Idle clients after X seconds of inactivity.

기본값은 60초이므로 즉 예상하건데, beat에서 60초내에 데이터를 보내지않는다면 접속을 끊는다는 의미인거같다.

2. 해결방안

이미 위에 내용에서 예상했겠지만, 간단한 조치방법은 해당 옵션을 활성화 하여 알맞은 시간을 할당하는 방법이다. 필자는 타임아웃값을 30분(1800초)으로 줬으나, 만약 빈번하게 데이터흐름이 발생한다면 좀더시간을 줄여도 괜찮을듯하다.

vi /etc/logstash.conf


input {
  beats {
    port => 5044
    client_inactivity_timeout => 1800
  }
}
####중략######

0. 들어가며

auditbeat가 구동중인 linux 서버에서 rsyslog를 연동 할 경우 messages 로그에

설정한 auditbeat log가 남는것을 확인 할 수 있다. 이는 로그를 관리해야하는 입장에서 시스템 로그와 섞이기에 로그확인에 불편항 사항을 초래 할 수있다. 하지만 추가 설정 없이 기본 설정으로 운영 할 경우 rsyslog를 통하여 messages 로그에 남는 auditbeat 로그의 컨트롤 (ex.예외처리,파일분리 등)이 불가한데 아래는 이와같은 문제를 해결해나가는 과정이다.

1. auditbeat facility 확인

auditbeat 의 공식 docs를 찾아봐도 syslog의 facility에 대한 내용이 남겨져있는건 확인을 못했다.

(필자가 못찾은거일수도..)

서치중에 아래와 같이 libbeat내에 하드코딩된 내역을 확인 할 수 있었다. 확인된 내용으로 설정을 진행해보자.

2. 설정

위 내용을 토대로 syslog상에서 local0 퍼실리티에 대해 beat.log로 출력 및 messages에 예외처리 설정을 진행했다

[root@test ~]# vi /etc/rsyslog.conf

*.info;mail.none;authpriv.none;cron.none;local0.none                /var/log/messages
local0.*		/var/log/beat.log

그러나 여전히 messages log에 쌓이며 beat.log는 쌓이지않는 현상이 발생하였다.

관련하여 공식 문서를 좀더 확인해보던중 아래와 같은 옵션을 확인할수있었다.

messages에 자동으로 남는걸보고 syslog에 대한 설정이 기본적으로 되어있는거라 생각했는데,

해당 옵션이 있는걸 보고 auditbeat.yml에 아래와 같이 추가 설정을 진행해주었다.

[root@test ~]# vi /etc/auditbeat/auditbeat.yml

logging.to_syslog: true

위와 같이 진행 후 rsyslog에 설정된 내역대로 로그가 정상적 쌓이는걸 확인 할 수있었다. 

3. 결론

공식DOCS에 나와있는 여러 옵션 중 쓸모없는 옵션은 없다라는걸 느끼게 됐다.

messages에 남는걸보고 당연히 syslog 설정이 되어있다고 생각한점도 반성해야 될 부분중 하나인것 같다.

PCI-DSS 인증을 받게 되어, 기존에 없던 실시간 로그모니터링 시스템구축 프로젝트를 개인적으로 진행하게 되었다. 

로그모니터링 시스템은 상용툴도 있지만, 비용적인 측면을 고려하여 오픈소스 기반의 툴을 찾아보게 되었다.

여러 툴을 알아보던중 가장 유명한 ElasticSearch+Kibana+Logstash+Beats를 이용한 Elastic Stack으로 진행하게되었다.

1. 어떤방식으로 구성할것인가?

기본적으로 내부적으로 rsyslog를 통한 로그 수집 서버가 존재하여, 해당 서버에 beats를 올린뒤

로그모니터링 서버에 모니터링을 진행 할 특정 로그를 보내어,  

logstash를 통해 필요한 부분만 파싱하여 ElasticSearch에 보내고 Kibana를 통해 시각화 구성,

모니터링 룰에 따라 ElastAlert을 통해 Telegram 메시지를 발송하려고한다.

추가로 각서버에 MetricBeat를 통해 Metric 모니터링도 진행하고자한다. 로그분석서버의 경우 Docker-Compose를 통해 ELK를 같은 컨테이너 네트워크상에 구성해볼 예정이다.

2. 어떤 로그를 모니터링할것인가?

PCI-DSS 요건을 살펴보면  아래와 같이 매일 보안로그 및 보안이벤트가 검토되고있는지를 체크하는부분이 있다. 

모든 보안 장비 및 보안로그에 대한 모니터링이 이루어져야하지만,

1차적으로 운용중인 서버의 OS 보안 로그를 통해 적용해보고자 하며, 추후엔 보안 장비 로그까지 모니터링하고자한다.