Skip to content
KitploitKITPLOIT
ツールエクスプロイトブログ
Log in
提出
ツールエクスプロイトブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
Spip-Go — Goで書かれたSpipネットワークセンサー | Kitploit
ツール/GitHubGitHub/honeylabshq/spip-go
防御ツール侵害指標 (IOC) 管理パケットスニッフィングと分析偵察情報収集ネットワークセキュリティ脅威インテリジェンス侵入検知インシデントレスポンスログ分析
GitHubhoneylabshq/spip-go

Spip-Go

71238日前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

Goで書かれたSpipネットワークセンサー

リポジトリを見る

Spip - ネットワークハニーポットセンサー

Spip は、軽量で低対話型のネットワークハニーポットセンサーです。任意の受信 TCP トラフィック (平文および TLS) をリッスンし、スキャナーやボットが送信する内容をキャプチャし、各接続を構造化 JSON (ECS 準拠) としてログに記録します。これにより、SIEM やデータレイクに容易に取り込めます。

Spip センサーは、キャプチャしたデータを基に構築された無料の検索可能な脅威インテリジェンスプラットフォーム HoneyLabs を支えています。Spip が実際に何を収集するか確認するには、そこのライブの IP ごとのレポート、またはセンサーネットワークから生成された週間脅威レポートを参照してください。

ezgif-476608ae440271e4

クイックスタート

前提条件

  • Go 1.24.0 以降
  • iptables が利用可能な Linux
  • root アクセス (例示の iptables ルールを適用するために必要)
  1. エージェントをビルドする
git clone https://github.com/honeylabshq/Spip-Go.git
cd Spip-Go
go build -o spip-agent ./cmd/spip-agent
  1. (オプション) 対話型セットアップヘルパーを使用する
sudo ./scripts/initial_setup.sh

このヘルパーは config.toml を書き込みます (ログで使用する短い name を求めるプロンプトが表示されます)。また、自己署名 TLS キーを生成したり、オプションで Loom (URL、sensor_id、token など) を設定したり、以下の例で使用する PREROUTING iptables リダイレクトをオプションで適用したりできます。

  1. config.toml を作成または編集する 最小限の config.toml:
name = "spip-agent"
ip = "127.0.0.1"
port = 8080

オプションの設定キー:

  • cert_path / key_path — 両方が設定されている場合 TLS を有効にします。パスは設定ファイルからの相対パスでも構いません (セットアップスクリプトは相対パスを書き込むため、どの作業ディレクトリからでも設定が機能します)。
  • ログ出力: log_file (ローカル) および/または [loom] (リモート)。下記のログ出力を参照してください。
  • read_timeout_seconds / write_timeout_seconds — 接続タイムアウト
  • rate_limit_per_second / rate_limit_burst — 接続レート制限
  • community_id_seed — Community ID v1 フローハッシュ用のオプションの 16 ビットシード (省略または 0 でデフォルト)

これらの実行時チューニングフィールドが省略されるか 0 に設定された場合、Spip は以下のデフォルトを適用します:

  • read_timeout_seconds: 30
  • write_timeout_seconds: 10
  • rate_limit_per_second: 20
  • rate_limit_burst: 50000
  1. 受信 TCP をエージェントにリダイレクトする (例、SSH は除外)
sudo iptables -t nat -F
sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j RETURN
sudo iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-port 8080
  1. エージェントを実行する
./spip-agent -config config.toml

ログ出力

Spip は ECS ログを単一のローカル宛先に書き込み、オプションで同じログを Loom サーバーに送信できます:

宛先設定動作
ローカルlog_fileデフォルト: 省略するか空のままにする → stdout。パスを設定する → そのファイル。いずれか一つ、常に有効。
Loom[loom] で enabled = trueオプション。同じイベントがバッチ処理され、ローカルに加えて Loom インジェスト URL に POST されます。

つまり: ローカルはデフォルトで stdout です。ファイルにするには log_file で上書きします。オプションで Loom を追加できます。両方とも同じ ECS 形式を使用します。

  • ローカルのみ: log_file をコメントアウト/空のままにする (stdout) か、パスを設定します。
  • ローカル + Loom: 上記のようにローカルを設定し、url、sensor_id、token を含む [loom] セクションを追加します (下記のLoomを参照)。

ログ形式

Spip は各接続を単一の JSON オブジェクトとして出力します。出力は、Spip が提供できるフィールドのみを使用して ECS 互換になるようにフォーマットされています (ASN/地理エンリッチメントは行いません)。生成される代表的なフィールドは以下の通りです:

  • @timestamp — イベントの RFC3339 タイムスタンプ
  • event.id — 接続ごとのセッション識別子
  • observer.hostname / host.name — 設定からのエージェント name
  • source.ip、source.port および destination.ip、destination.port
  • network.transport — 例: tcp
  • http.request.body / url.path — ペイロードが明らかに HTTP に類似している場合
  • user_agent.original — 利用可能な場合
  • event.summary — HTTP 以外のプローブの生のペイロード
  • event.original_payload_hex — 生のペイロードの 16 進数 (常に保存)
  • フィンガープリンティング (組み込み) は、該当する場合に network.community_id、tls.client.*、http.request.hash.ja4h、ssh.client.hash.hassh を追加します。

Spip によって生成される (ECS 準拠の) レコードの例:

{
  "@timestamp": "2025-12-01T19:35:18.123Z",
  "event": {
    "id": "bd30cdc1-95b0-49aa-b8fe-e77230b6a04f",
    "summary": "BitTorrent protocol",
    "original_payload_hex": "426974546f7272656e742070726f746f636f6c",
    "ingested_by": "spip"
  },
  "observer": {"hostname": "spip-agent"},
  "host": {"name": "spip-agent"},
  "source": {"ip": "146.70.1.1", "port": 35882},
  "destination": {"ip": "146.190.1.1", "port": 6881},
  "network": {"transport": "tcp"}
}

注意: エージェントは接続ペイロードとメタデータから導出できるフィールドのみを出力します。ダウンストリームシステムはこれらのレコードを必要に応じてエンリッチ (geo、ASN など) できます。

フィンガープリンティング

Spip は各接続レコードに受動的フィンガープリントフィールドを追加できます (ECS 互換、ペイロードキャプチャには影響しません):

  • Community ID (network.community_id) — 5 タプル (送信元/宛先 IP とポート、プロトコル) の v1 フローハッシュ。トラフィックが iptables 経由でリダイレクトされる場合、Spip は 元の宛先 (REDIRECT 前) を使用するため、ハッシュは他のツール (例: Zeek、Suricata) が同じフローに対して計算するものと一致します。
  • TLS — ClientHello から: tls.client.server_name (SNI)、tls.client.supported_protocols (ALPN リスト)、tls.client.hash.ja4 (JA4 フィンガープリント)。
  • HTTP — 最初のリクエストから: http.request.hash.ja4h (JA4H)。
  • SSH — ペイロードが SSH-2.0- で始まり KEXINIT を含む場合: ssh.client.hash.hassh (Hassh)。

これらはすべて付加的なものです。既存の動作 (ローカルログ、Loom、ペイロードの 16 進数、HTTP 解析) は変更されません。

参考文献 (検証と帰属のため):
Community ID: Corelight Community ID 仕様。
JA4 / JA4H: FoxIO JA4。
Hassh: Salesforce HASSH。
TLS フィンガープリンティングは github.com/psanford/tlsfingerprint (MIT) を使用しています。

Loom (オプションのログ送信)

ログ出力の一部: [loom] で enabled = true の場合、同じ ECS レコードがバッチ処理され、Loom インジェスト URL に POST されます。有効にする場合に必要なもの: url、sensor_id、token。オプション: batch_size (デフォルト 50)、flush_interval (例: "10s")、insecure_skip_verify (自己署名 Loom 証明書用)。エクスポーターは非同期で実行され、キャプチャループをブロックしません。失敗した POST は stderr に記録され、バッチは破棄されます (フェイルオープン)。

プロジェクト構造

.
├── cmd/                 # メインアプリケーションエントリポイント
├── internal/            # 設定、ロギング、ネットワーク、TLS、フィンガープリンティング、エクスポーター (例: Loom)
├── pkg/                 # Linux ソケットヘルパー (syscall 経由の SO_ORIGINAL_DST)
├── test/                # エンドツーエンドテストヘルパー
└── scripts/             # ユーティリティスクリプト (`initial_setup.sh` を含む)

テスト

ユニットテストを実行する:

go test ./...

エンドツーエンドテスト は iptables を操作する権限が必要です。リポジトリルートからスクリプト経由で実行します:

sudo -E ./scripts/run_e2e_tests.sh

スクリプトは環境と iptables をセットアップします。代わりにコンテナヘルパーを使用するには: ./scripts/run_e2e_in_container.sh。E2E はコア動作 (ペイロードキャプチャ、送信元/宛先、TLS 検出、Loom バッチ処理、フィンガープリンティング) を検証します。

HTTP 解析とデプロイに関する注意事項

Spip はキャプチャしたペイロードからベストエフォートで HTTP リクエストを検出します。ペイロードが明らかに HTTP リクエストに類似している場合 (有効なリクエスト行と基本的なヘッダー、または ALPN)、エージェントは http.*、url.path、user_agent.original フィールドを出力します。そうでない場合、Spip はペイロードを event.summary に格納し、生のペイロードの 16 進数を event.original_payload_hex に常に保存します。

Spip は応答に送信元 IP を反映し、任意の受信 TCP トラフィックを受け入れるため、制御/監視された環境でのハニーポット型センサーまたはエッジコレクターとして使用することを意図しており、任意のユーザーエンドポイントでの使用は想定されていません。

初期セットアップヘルパー

リポジトリルートから対話型ヘルパーを実行します (iptables ルールを適用する場合 root が必要):

sudo ./scripts/initial_setup.sh

スクリプトは以下の入力を求めます: 短い name (config.toml に書き込まれ、ログで observer.hostname / host.name として使用されます)、リッスン IP とポート、オプションの自己署名 TLS 証明書の生成 (パスは設定ファイルからの相対パスで書き込まれるため、任意のディレクトリから機能します)、オプションの Loom 設定 (URL、sensor_id、token、batch_size、flush_interval、TLS 検証)、ログファイルのパス、およびオプションの iptables PREROUTING リダイレクト。

ツールをダウンロード