Suricata についてのほぼすべての手引きは、Elasticsearch と Logstash と Kibana を入れるところで終わります。一台の VPS にとってそれは悪い助言です。この一式はメモリを四ギガバイトと絶え間ない世話を要求しますが、あなたが欲しかったのは過去一日で IDS が何を捕まえたかを見ることだけでした。Suricata はそれらが無くても十分に動きます——ただし、人々がそれを入れて一週間後に外してしまう、ある性質を持っています。

既定設定に埋まった地雷

箱から出したままの Suricata は eve.json に三十を超える種類のイベントを書きます。alert だけでなく、あらゆる DNS 問い合わせ、あらゆる TLS ハンドシェイク、あらゆる HTTP トランザクション、ARP、DHCP、flow また flow。加えて八秒ごとに別の stats.log。そしてその間 Suricata はログのローテーションを設定しません——それは管理者の仕事であり、どこにも大きな字では書かれていません。

実際のサーバーからの数字：二日で 15 ギガバイト——うち九つが eve.json、六つ近くが 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 で識別子を指定して切ります——遠慮なく使ってください。このセットは企業ネットワーク向けであり、普通の Web サーバーでは十数個のルールが理由もなく発火し続けます。

モード。既定では 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 を分類と発信元で分けて一つのページに置くとどう見えるかは、下のデモで。