Posted inネットワーキング

ELKスタックによるネットワーク機器とファイアウォールのログ集中管理

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

午前2時のネットワークの悪夢

火曜日の午前2時14分、主要データセンターのコアスイッチがパケットの約15%をドロップし始めました。モニターは真っ赤なアラートで埋め尽くされていましたが、その「原因」は依然として不明なままでした。

10分以内に12個のSSHターミナルを開き、Cisco Nexusスイッチ、Juniperエッジルーター、そして一対のFortiGate 600Fファイアウォールのログを必死に追いかけました。ファイアウォールの「拒否（deny）」イベントের タイムスタンプと、スイッチのスパニングツリーの変動を関連付ける作業は、溶けていくパズルのピースを繋ぎ合わせるような感覚でした。手動で大量のテキストファイルをgrepしてようやくループ箇所を特定するまでに、2時間のダウンタイムが発生しました。

これが「分散型ロギング」の代償です。データが孤立したサイロに存在する場合、対応が遅れるだけでなく、文字通り「盲目」の状態で運用することになります。場当たり的なトラブルシューティングからプロアクティブなインフラ管理へと移行するには、ハードウェアが生成するすべてのテレメトリを集中管理するという重要な一歩が必要です。

分散型ログが機能しない理由

問題はログの保存場所だけではありません。ログが「短命」であることも大きな課題です。ネットワーク機器のストレージ用循環バッファは非常に小さいことで知られています。トラフィックの激しい10Gbpsリンクでは、スイッチのログが30分ごとに上書きされることも珍しくありません。「決定的な証拠」を即座に確認できなければ、それは永遠に失われてしまいます。

フォーマットの不一致も摩擦を生みます。Cisco IOSのログ、Palo Altoのトラフィックログ、Linuxのiptablesエントリには、共通項がほとんどありません。これらを単一の検索可能なスキーマに正規化する方法がなければ、デバイスをまたいだ相関分析は不可能です。経路上のすべてのホップにログインせずに、「過去5分間にIP 10.0.5.42がどのデバイスに接触したか」という単純な問いに答えることさえできないのです。

比較：Grep vs. Splunk vs. ELK

この問題を解決するために、3つの異なるアプローチを検討しました。

  • マニュアル手法（Grep/Rsyslog）：Syslogを介してすべてを中央のLinuxサーバーに送信します。導入は無料で迅速ですが、100GBもの生テキストファイルを検索するのは苦痛なほど時間がかかります。可視化や自動アラートも期待できません。
  • エンタープライズ手法（Splunk）：その性能と完成度からゴールドスタンダードとされています。しかし、ライセンスモデルはデータ量に基づいています。1日50GBのファイアウォールログを生成するネットワークの場合、年間のライセンス料がハードウェアの予算を簡単に超えてしまう可能性があります。
  • エンジニアリング手法（ELK Stack）：Elasticsearch、Logstash、Kibanaの組み合わせです。プロフェッショナルなSIEMのパワーとオープンソースの柔軟性を備えています。データを所有し、パース（解析）を制御し、トラフィックの増加に合わせてクラスタをスケールさせることができます。

多くのチームにとって、ELKは「スイートスポット」です。商用ツールの高額な請求に驚くことなく、ハイエンドな可視性を手に入れることができます。

ELKパイプラインの構築

優れたロギング戦略とは、単なる保存ではなく「変換」にあります。取り込み、パース、インデックス作成、そして可視化を行うパイプラインが必要です。以下に、本番環境で使用しているアーキテクチャを紹介します。

1. Elasticsearchのチューニング

Elasticsearchがエンジンとなります。中規模のネットワークなら単一ノードでも動作しますが、メモリを優先する必要があります。Linux環境では、/etc/elasticsearch/jvm.optionsでヒープサイズを設定します。システムRAMの50%を目安にしつつ、圧縮ポインタの効率を維持するために31GBを上限に設定してください。

# 8GB RAMのVMの場合、4GBをヒープに割り当てる
-Xms4g
-Xmx4g

2. Logstash：データ翻訳機

Logstashこそが「魔法」が起きる場所です。着信したSyslogトラフィック（UDP/514）をリッスンし、乱雑な文字列をsrc_ipやactionといったクリーンなフィールドに分解して、Elasticsearchに送信します。/etc/logstash/conf.d/network-logs.confを作成します。

input {
  syslog {
    port => 514
    type => "syslog"
  }
}

filter {
  if [type] == "syslog" {
    # Grokパターンを使用して特定のCiscoフォーマットをパースする
    grok {
      match => { "message" => "%{CISCOFW1}" }
    }
    # 外部IPの地理的な発信元をマッピングする
    geoip {
      source => "src_ip"
    }
  }
} 

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "network-logs-%{+YYYY.MM.dd}"
  }
}

geoipフィルタの使用を強くお勧めします。セキュリティ報告において、単なる中国やロシアのIPアドレスの羅列よりも、ブロックされた接続試行のヒートマップを見せる方がはるかに有用です。

3. ハードウェアの設定

デバイスの設定は最終ステップです。Ciscoスイッチの場合、コマンドはシンプルです。

logging host 192.168.1.100 transport udp port 514
logging trap informational

FortiGateファイアウォールの場合、CLIを使用して詳細な制御を行います。

config log syslogd setting
    set status enable
    set server "192.168.1.100"
    set mode udp
    set port 514
end

Kibanaによる可視化

データが流れ始めると、Kibanaがあなたのコックピットになります。grepを使う代わりに、重要な問いに即座に答えるダッシュボードを構築できます。

  • ブロックされた接続元のトップ：どの特定のIPがエッジを叩いているか？
  • トラフィックの急増：内部トラフィックが300%急増していないか？それはブロードキャストストームやランサムウェアの同期かもしれません。
  • 監査証跡：管理者が午後3時にコアスイッチで具体的にどのコマンドを実行したか？

本当のROI（投資対効果）は「Discover」タブに現れます。ユーザーから「接続が遅い」という報告があった際、すべてのスイッチ, ルーター、ファイアウォールをまたいでそのユーザーのIPで同時にフィルタリングできます。パケットがコアに到達し、ルーターを通過し、おそらくエッジファイアウォールでドロップされる様子が、一つの統合されたタイムライン上で確認できるのです。

最後に

ELKのセットアップには、初期段階の時間とハードウェアの投資が必要です。しかし、複雑なルーティングループを3時間ではなく3分で解決できたとき、その価値は十分に証明されます。まずはスモールスタートで始めましょう。最初にエッジファイアウォールのインデックスを作成し、次にコアスイッチを追加します。現代のエンジニアにとって、完全な可視性はもはや贅沢品ではなく、生き残るための唯一の手段です。

Share:
Tags: