背景

還記得之前，我正在處理公司的 WAF 日誌時，遇到了一個讓人頭痛的問題。那時候我們的資安設備每天都在勤奮地防禦各種網路攻擊，產生了大量的日誌，這些日誌就像是第一線戰士的戰報一樣重要。為了方便分析這些「戰報」，我們使用了 Elasticsearch 這個強大的搜尋引擎來儲存和分析這些日誌。

但是，就在某一天，系統突然向我發出了警報！原來是駭客，他們不只是進行簡單的攻擊，還會在他們的攻擊payload中塞入各種奇奇怪怪的符號。這些特殊符號就像是給我們的日誌分析系統下了一個難題 —— 我們用來處理日誌的 Logstash 在解析這些內容時，開始瘋狂地產生大量的欄位，就像是一個不受控制的複製機器，最後導致 Elasticsearch 不堪負荷，直接舉白旗投降了，近期幫客戶導入Elasticsearch 也遇到類似問題，就先把它記錄起來。

問題描述

在 Elasticsearch 中，當查詢擴展匹配的欄位數超過預設限制（1024個欄位）時，會出現以下錯誤：

field expansion matches too many fields, limit: 1024, got: 1238

這個問題主要源於以下幾個原因：

  • 攻擊者注入的特殊字符導致 Parser 產生意外的欄位名稱
  • Logstash 的解析規則過於寬鬆
  • Elasticsearch 的動態映射機制自動為新欄位創建映射

相關 Elasticsearch 欄位說明

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html

痛點分析

這個問題會帶來以下影響：

  • 系統性能下降
  • 儲存空間浪費
  • 查詢效率降低
  • 系統穩定性受影響
  • 安全事件分析效果不佳

解決方案

1. 優化 Logstash 配置

a. 實作嚴格的欄位白名單

filter {
  prune {
    whitelist_names => [ 
      "timestamp", 
      "client_ip", 
      "request_uri", 
      "attack_type"
    ]
  }
}

b. 特殊字符處理

filter {
  mutate {
    gsub => [
      "field_name", "[^a-zA-Z0-9_-]", "_"
    ]
  }
}

2. Elasticsearch 配置優化

a. 調整欄位限制

{
  "persistent": {
    "indices.query.bool.max_clause_count": 2048
  }
}

b. 設置嚴格的映射規則

{
  "mappings": {
    "dynamic": "strict",
    "properties": {
      "timestamp": { "type": "date" },
      "client_ip": { "type": "ip" },
      "request_uri": { "type": "keyword" },
      "attack_type": { "type": "keyword" }
    }
  }
}

實際操作步驟

  1. 分析現有日誌
    • 收集樣本日誌
    • 識別必要欄位
    • 分析異常模式
  2. 實作 Parser 優化 
    filter {
  grok {
    break_on_match => true
    match => {
      "message" => "%{TIMESTAMP_ISO8601:timestamp} %{IPV4:client_ip} %{GREEDYDATA:request_uri}"
    }
    tag_on_failure => ["_grokparsefailure"]
  }
  
  # 欄位驗證
  ruby {
    code => '
      event.to_hash.keys.each do |key|
        if key =~ /[^a-zA-Z0-9_-]/
          event.remove(key)
        end
      end
    '
  }
  
  # 保留白名單欄位
  prune {
    whitelist_names => [ "timestamp", "client_ip", "request_uri", "attack_type" ]
  }
}
  3. 配置 Elasticsearch
    • 應用嚴格映射
    • 設置適當的欄位限制
    • 監控系統性能

效益

實施上述優化後，可以獲得以下好處：

  • 系統穩定性提升
  • 查詢性能改善
  • 儲存空間節省
  • 分析效率提高
  • 維護成本降低

實際案例

某金融機構在實施以上優化後，達到以下效果：

  • 欄位數量從原本的 1200+ 降至 50 以下
  • 查詢響應時間提升 60%
  • 儲存空間減少 40%
  • 系統穩定性明顯改善

結論

在處理 WAF 日誌時，欄位爆炸是一個常見但可以解決的問題。通過適當的配置和優化，我們可以建立一個更穩定、高效的日誌分析系統。關鍵在於：

  • 實作嚴格的欄位控制
  • 處理特殊字符
  • 使用適當的映射設置
  • 持續監控和優化

通過這些措施，我們不僅可以解決欄位數量過多的問題，還能提升整體系統的效能和可維護性。這對於需要處理大量 WAF 日誌的組織來說尤為重要。