Suricata에 관한 거의 모든 안내서는 Elasticsearch와 Logstash와 Kibana를 설치하는 것으로 끝납니다. VPS 한 대에는 나쁜 조언입니다. 이 묶음은 메모리 4기가바이트와 끊임없는 관리를 요구하는데, 당신이 원했던 것은 지난 하루 동안 IDS가 무엇을 잡았는지 보는 것뿐이었으니까요. Suricata는 그것들 없이도 잘 작동합니다 — 다만 사람들이 설치했다가 일주일 뒤 지워 버리게 만드는 성질이 하나 있습니다.

기본 설정에 묻힌 지뢰

설치 직후의 Suricata는 eve.json에 서른 종류가 넘는 이벤트를 씁니다. alert만이 아니라 모든 DNS 질의, 모든 TLS 핸드셰이크, 모든 HTTP 트랜잭션, ARP, DHCP, flow에 또 flow. 여기에 8초마다 별도의 stats.log까지. 그러면서 Suricata는 로그 회전을 설정해 주지 않습니다 — 그건 관리자의 몫이고, 어디에도 큰 글씨로 적혀 있지 않습니다.

실제 서버의 수치: 이틀에 15기가바이트 — 그중 9기가는 eve.json에, 6기가 가까이는 stats.log에. 디스크가 차기까지 닷새쯤 남아 있었습니다. 그 서버의 트래픽도 많지 않았고, 바쁜 노드였다면 몇 시간의 문제였을 것입니다.

지금 당신 것을 확인해 보세요.

sudo du -sh /var/log/suricata/*

읽는 것만 남기기

네트워크 포렌식이 아니라 alert를 본다면 eve-log에서 필요한 것은 정확히 한 종류의 이벤트뿐입니다. /etc/suricata/suricata.yaml에서 outputs 블록을 찾아 eve-log의 types에 alert만 남기고 나머지는 주석 처리하세요. 같은 자리에서 통계 출력도 끕니다.

  - stats:
      enabled: no

수정 후 설정 확인은 필수입니다 — 서비스를 다시 시작하기 전에.

sudo suricata -T -c /etc/suricata/suricata.yaml -v

순서가 중요합니다. 규칙이 아직 로드되지 않았다면 이 확인은 통과하지 못합니다. 먼저 suricata-update, 그다음 설정 확인, 그러고 나서 시작.

실제로 작동하는 회전

파일 /etc/logrotate.d/suricata:

/var/log/suricata/*.log /var/log/suricata/*.json {
    daily
    rotate 7
    maxsize 200M
    missingok
    compress
    delaycompress
    create 0664 suricata suricata
    su suricata suricata
    postrotate
        systemctl kill -s HUP suricata
    endscript
}

여기에는 눈에 띄지 않는 두 줄이 있고 둘 다 결정적입니다.

su suricata suricata — 이것이 없으면 logrotate는 모든 파일을 조용히 건너뜁니다. 디렉터리 /var/log/suricata는 root가 아니라 suricata 그룹의 것이고, logrotate는 그런 구성을 안전하지 않다고 봅니다. 메일에도 로그에도 오류는 없습니다. 디스크가 다 찰 때까지 회전이 있다고 믿고 있게 될 뿐입니다. 미리 잡아내는 유일한 방법은 빈 실행입니다.

sudo logrotate -d /etc/logrotate.d/suricata

create 0664 suricata suricata — 새 파일의 권한입니다. 기본값(0640)이면 root가 아닌 사용자로 로그를 읽는 어떤 패널이나 스크립트도 첫 회전 이후에는 아무것도 보지 못합니다.

로그 말고 또 무엇을 설정할까

HOME_NET. 이것은 Suricata가 무엇을 자기 편으로 보는지를 기술합니다. 기본값은 사설 대역을 전부 나열하지만 VPS가 가진 것은 공인 주소입니다 — 그래서 일부 규칙이 발동하지 않거나 거꾸로 발동합니다. 자신의 네트워크를 명시하세요.

규칙. Emerging Threats Open 묶음은 suricata-update가 가져오며, 그 자리는 하루 한 번의 cron입니다. 개별적으로 시끄러운 시그니처는 /etc/suricata/disable.conf에서 식별자로 끕니다 — 겁내지 말고 쓰세요. 이 묶음은 기업 네트워크를 위한 것이고, 평범한 웹 서버에서는 열 개 남짓한 규칙이 이유 없이 계속 발동합니다.

모드. 기본적으로 Suricata는 트래픽의 사본을 듣고 경고만 합니다(IDS). 서버 한 대에서 차단 모드(IPS, nfqueue 경유)를 쓰는 것은 주로 자신에게 위험합니다. 오탐 한 번이면 스스로를 밖에 가둡니다. 관찰부터 시작해 한 달 동안 무엇이 잡히는지 보세요.

Kibana 없이 읽는 법

짧은 alert는 /var/log/suricata/fast.log에 있습니다. 이벤트 하나당 한 줄, 눈으로 읽을 수 있습니다.

sudo tail -50 /var/log/suricata/fast.log

세부는 eve.json에, 한 줄당 JSON 객체 하나로 들어 있습니다. 보통 Kibana를 설치하는 목적의 전부가 명령 하나로 줄어듭니다.

sudo jq -r 'select(.event_type=="alert") | .alert.signature' \
    /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head -20

이것이 가장 자주 나타나는 스무 개의 시그니처입니다. 일주일치의 이런 목록은 서버에 무슨 일이 벌어지는지 정직하게 답해 주고, 어떤 규칙을 끌 때가 됐는지도 보여 줍니다.

Fail2ban이 있는데 왜 필요한가

둘은 성질이 다릅니다. Fail2ban은 애플리케이션의 로그를 읽고 실패한 로그인에 반응합니다 — 즉 이미 어떤 서비스에 닿은 것에 반응합니다. Suricata는 트래픽 자체를 보고, 어떤 로그에도 결코 남지 않을 것을 봅니다. 포트 스캔, 알려진 시그니처와 일치하는 취약점 공격 시도, 당신 서버 내부에서 명령 서버로 나가는 연결. 마지막 것은 특히 값집니다. 남의 명령 서버로 나가는 연결은, 당신이 실행하지 않은 무언가가 서버에서 이미 돌고 있다는 가장 이른 징후입니다.

둘 다 두어도 됩니다. 충돌하지 않습니다. 유일한 문제는 그 출력을 분기에 한 번보다 자주 읽는 사람이 있느냐는 것입니다. 같은 alert를 분류와 출처로 나눠 한 페이지에 두면 어떤 모습인지는 아래 데모에서.