はじめに
SNORTについては多くのことが言われていますが、ほとんどの記事では、ネットワークインターフェースからすべてのデータを収集するネットワークを完全に監視する手段として、SNORTについて説明しています。 この記事では、IPSモードのSNORTがインターフェイス上のすべてのトラフィックを監視せず、iptablesのルールを使用して記述できるトラフィックのみを監視する設計を組み立てる方法を説明します。 ルール設定については触れません。SNORTをアセンブルする方法と、ベアシステムでIPSモードで動作する方法、およびそれによって抽象サービス保護にアプローチする方法についてのみ説明します。 SNORTの組み立てと起動についても説明します。
どのように機能しますか?
SNORTに入ると、パケットはデコーダー、プリプロセッサを順番に通過し、それからのみルールを適用し始める検出器に入ります。 デコーダーのタスクは、ネットワークとトランスポートレイヤーデータ(IP、TCP、UDP)をデータリンクレイヤープロトコル(イーサネット、802.11、トークンリングなど)から「引き出す」ことです。

プリプロセッサのタスクは、ルールを適用するプロセスのためにトランスポート層とネットワーク層のプロトコルからデータを準備することです。 このケースでは、プリプロセッサを使用してTCPを処理します。一般に解決するタスクのリストは次のとおりです。
- 状態監視(プロトコルコンプライアンス監視)
- セッションアセンブリ(複数のセッションパケットからのデータを結合する)
- プロトコルの正規化(その場でパケットヘッダーを編集する、かなり滑りやすい機能)
プリプロセッサを適切にセットアップすると、システムのパフォーマンスが大幅に向上し、検出器に入るガベージデータの量を減らすことができます。 また、アーキテクチャにより、自己記述型プリプロセッサをSNORTに接続するのは比較的簡単です。
その結果、検出器に送信される前に「スーパーパケット」が形成され、そこにルールが適用され始めます。 ルールを適用するプロセスは、ルールで定義された署名の「スーパーパケット」を検索することになります。 ルール自体は、トラフィックの説明、目的の署名、脅威の説明、および発見に対する反応の説明で構成されます。
SNORTのコンパイル。
最新のUbuntu 11.04をダウンロードします。 32ビットシステムのインストールについて説明します。 必要なものをすべてダウンロードします。
daq-0.5.tar.gz
libdnet-1.11.tar.gz
libnetfilter_queue-1.0.0.tar
libnfnetlink-1.0.0.tar
libpcap-1.1.1.tar.gz
pcre-8.12.zip
snort-2.9.0.5.tar.gz
snortrules-snapshot-2903.tar.gz
必要なバッグをインストールします。
apt-get install bison flex gcc g++ zlib1g-dev
ソースからダウンロードしたソフトウェアを次の順序で構成およびインストールします。
pcre-8.12.zip
libpcap-1.1.1.tar.gz
libdnet-1.11.tar.gz
libnfnetlink-1.0.0.tar
libnetfilter_queue-1.0.0.tar
daq-0.5.tar.gz
構成スクリプトの場合、不快な驚きを避けるためにインストールディレクトリを強制することをお勧めします
./configure --libdir=/usr/lib --includedir=/usr/include
daqを設定するときに、
「Build NFQ DAQ module ...:yes」という行が表示され、すべてが問題なくコンパイルされた場合、正しい軌道に乗っています。 全体の鍵は、SNORTビルドです。
./configure --libdir=/usr/lib --includedir=/usr/include --enable-ipv6 --enable-gre --enable-targetbased --enable-decoder-preprocessor-rules --enable-active-response --enable-normalizer --enable-reload --enable-react --enable-zlib
--enable-ipv6 -IP v6のサポート(突然のキャプテン!)
--enable-gre -GREカプセル化のサポート。
--enable-targetbased-断片化されたパケットの収集のサポート。
--enable-decoder-preprocessor-rules-プリプロセッサーとデコーダーが機能するときにトラフィックで検出された異常に対応するためのルールのサポート。
--enable-active-response-ルールがトリガーされたときにセッションにパッケージを導入するためのサポート。
--enable-normalizer-プロトコルノーマライザーのサポート。
--enable-reload -SNORTを再起動せずにルールをロード/アンロードする機能。
--enable-react-ルールがトリガーされたときの即時セッション終了(RST)のサポート。
--enable-zlib-圧縮されたトラフィックの処理のサポート。
次の
メイク; インストールする SNORTがインストールされています。
戦闘発射のセットアップ。
新たにダウンロードされたsnort構成は、経験の浅いユーザーには大きな印象を与えますが、その構造を理解していれば、それを理解するのは簡単です。 一般に問題を解決する最小構成の簡略版は次のようになります。
# 1:
#
var HOME_NET any
var RULE_PATH ../rules
# 2:
config disable_decode_alerts
……
# 3:
#
config pcre_match_limit: 3500
……
# 5:
#
# , ,,
preprocessor normalize_ip4
….
#
preprocessor frag3_global: max_frags 65536
…
#
preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp ….
…
# 6:
include classification.config
…..
# 7:
include $RULE_PATH/test.rules
簡単にするために、test.rulesファイルにはルールが1つだけあります。
reject tcp any any -> any any (msg:"Test pattern for snort abc123"; content:"abc123"; classtype:shellcode-detect; sid:310; rev:1;)
このルールは、着信tcpパケットに
abc123部分文字列が見つかった場合、RSTがすぐにソースに送信され、セッションが中断されることを示しています。 危険なパケットは、IPSを超えてシステムに侵入することはありません。 SNORTを実行します。
snort -Q --daq nfq --daq-var queue=2 -c /home/ubuntu/Downloads/snort/etc/snort.conf -l /var/log/snort -A full
-Q -IPSモードで動作します
--daq-パッケージソース
--daq-var-パッケージソースオプション
-c-構成へのパス
-l-ログへのパス
-完全な詳細ログ(攻撃およびトラフィックダンプの説明)
-D-デーモンモードで動作します(すべてのデバッグ時に使用)
起動がエラーで途切れる場合は、悲しいことではありません-ほとんどの場合、設定内のファイルパスを修正する必要があります。
キューを作成します。
システムのパケットフィルターは、受信したパケットをカーネルレベルからユーザーレベルに転送するように設定できます。ユーザーレベルのプログラムはそれを処理し、カーネルレベルに戻します。この場合、このプログラムはSNORTです。 番号付きキュー(NFQUEUE)で動作するようにSNORTを開始したため、このキューにフィルタリングされたトラフィックを配置する必要があります。
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j NFQUEUE --queue-num 2PREROUTINGチェーンが選ばれたのはなぜですか?
Iptablesモデルでは、ルーティングルールが適用される前に、パケットが
PREROUTINGベースキューに入ります。 この段階でパケットをSNORTに送信すると、ローカルで処理することも、たとえばNATを使用してさらに転送することもできるので便利です。 番号付きキューを使用する利点は、複数のキューを作成し、フィルタリングされたトラフィック用に調整された一連のルールで開始されたSnortを介して各キューのトラフィックを渡すことができることです。 このアプローチの重大な欠点は、SNORTクラッシュが発生した場合、ユーザーモードからカーネルにデータを転送する人がいないため、保護されたサービスが利用できなくなることです。 SNORTを開始してキューを作成したら、netcatを介して、ルールからの署名
abc123をキューに送信するなどして、すぐに操作を確認する必要
があります。 すべてが正しく行われた場合、接続はすぐに切断されます。
モニタリング
SNORTは、記述されたパラメーターを使用して実行し、検出された脅威ごとにファイルを書き込みます(データベースへの書き込みやsyslogの送信と同じ方法で):
[**] [1:310:1] Test pattern for snort abc123 [**]
[Classification: Executable Code was Detected] [Priority: 1]
01/19-12:03:12.155213136 172.16.249.1:56473 -> 172.16.249.130:8080
TCP TTL:64 TOS:0x0 ID:1241 IpLen:20 DgmLen:59 DF
***AP*** Seq: 0x9510F391 Ack: 0xC40C0E14 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 125531844 9470333
また、署名が検出されたセッションの一部をログファイルに書き込むと、検出エラーの検出に役立ちます。 これで、SNORTの作業は終了し、「SNORTログ分析システム」が働き始めます。 実際、これらはさまざまな程度の悲惨さのスクリプトのセットであり、場合によっては、悲痛な「Webインターフェース」(BASE、ACID ...)が添付されます。 その主な欠点は、柔軟なデータ分析を実行できないことと、DBMSでの非効率な作業です。その結果、大量のデータを処理できなくなります。 私の経験では、Snortログの使用を許容できる唯一のソリューションはSplunkです。 一般に、Splunkはログ管理システムであり、それらを保存し、インデックスを作成し、結果のデータベースを操作するための便利なインターフェイスを保護します。 これはプロプライエタリなソフトウェアであり、シェアウェアです(1日あたりのインデックスデータの量は500 MB以下であり、Snortには十分です)。 このシステムは、管理の利便性と大量のデータを処理する機能を兼ね備えています。最も重要なことは、このシステムには、SNORTログを処理するために特別に調整されたプラグインがあります。 Splunkを
ここからダウンロード
splunkをインストールします。
dpkg -i splunk-4.2.1-98164-linux-2.6-intel.deb
以下を開始します。
/opt/splunk/bin/splunk start
Webフェイスに移動して、プラグインを見つけてインストールします。

次に、データソース(ファイル)を追加します。 ここではすべてが直感的であり、唯一の微妙な点は、ソースタイプを手動で設定する必要があることです:
snort_alert_full 。 すべての準備が整ったら、アラートを生成します(netcatを介してabc123を保護ポートに送信します)。 そして、splunkで見る:

左側の列には、パーサーが認識したデータと、着信データのインデックスが構築されるデータが表示されます。 これらのデータに基づいて、組み込みのクエリ言語を使用して分析したり、グラフを作成したり、マップ上にソースを表示したりできます。

さらに、独自のプラグインを作成するプロセスはメーカーのWebサイトに記載されており、特定のタスク用にシャープ化される独自のプラグインを作成できます。
おわりに
生産的にsnortを開始する前に、苦痛にならないように、次のことを行う必要があります。
- ルールのバージョン管理システムを構築し、サードパーティのホストにルールを保存します(SVNで問題ありません)。
- 緊急時の運用計画を作成します(鼻水が落ち、交通が通らない場合)。
- Snortのあるハードウェアがデータ損失で破損した場合の復旧計画。
- 上記のタイプのテストルールabc123を作成します。これは、変更を行うたびにsnortの動作を確認する必要があります。
ご質問にお答えします。