複数のソースからERSPANトラフィックを受信するUbunutu 18.04 LTSサーバーがあります。
ERSPANに慣れていない人のために説明すると、GREトンネルを使用して元のL3パケットを別のL3パケットにラップし、元のパケットソース/宛先IP、ペイロード、L2詳細などを保存します。
サーバーはプライベートインターフェイス（この場合ens192）からトラフィックを受信しますが、IDSがトラフィックを処理するときにトラフィックをカプセル化解除（GREヘッダーを削除）せず、送信元（ERSPAN送信元）と宛先（Ubuntuサーバー）のみが表示されます。 ...ソース/ターゲットIPが見つかると、IDSはその情報処理を停止するためです。
この問題を解決するためにRCDCAPを使用してみましたが、メモリ破損の問題が原因で短時間で競合が発生しました。この問題をRCDCAP開発者に伝え、彼らはこの問題を解決しようとしましたが、まだ成功していません。
私は現在、これを行うカーネルの能力を調べています。カーネルモジュール ip_gre には、ERSPAN Type I、Type II、Type III のサポートが含まれています。
Ubuntuサーバーで次のことを行いました。
#load ip_gre module into kernel
modprobe ip_gre
#create tunnel in gre mode set local and remote ends of tunnel and turn link up
ip tunnel add tun0 mode gre local 10.10.1.20 remote 10.10.1.143 ttl 255
ip link set tun0 up
#assign IP address to tunnel interface
ip addr add 10.10.1.20/24 dev tun0
これによりトンネルは正常に生成されますが、GREトラフィックを処理せずに接続されたGREヘッダーを維持します。
GREトンネルを作成するときに予想される種類を示すスイッチまたは何かがありませんか？ GREタイプごとに少しずつ違いがありますが、タイプIを期待すれば余裕がないでしょう…
答え1
解決策を見つけました！私はERSPAN処理機能を備えたSuricata 5.0.3を使用していますが、デフォルトでは無効になっています。 suricata.yml（/etc/suricata/suricata.yml）に移動し、次の行を「true」に更新しました。
erspan:
typeI:
enabled: true
次に suricata を起動して fast.log をチェックして、これが解決策であることを確認します。