This post will help you write effective Snort Rules to materially improve your security posture.
Snortは、リアルタイムのパケット分析を提供するオープンソースのネットワーク侵入検知システム（NIDS）であり、Coralogix STAソリューションの一部を構成しています。 Coralogix STAのユーザーであれば、STAでSnortルールを編集する方法に関する以前の記事もぜひご覧ください。
Snort Rulesの解剖
最適なSnortルールを作成するためのさまざまな戦略を学ぶ前に、まずはSnortルール例を分解してみましょう：
alert: Snortに対してこの動作を警告として報告させます（STA向けに作成したルールには必ず必要）。
tcp: このルールがTCPのトラフィックにのみ適用されることを意味します。
any: このコンテキストでは、「任意のソースポートから」を意味し、次に「接続先」を意味する矢印「->」があります（「<-」オペレータはありませんが、単にオペレータ周りの引数を反転することが可能です。 <>’ 演算子を使えば、このルールでは接続方向は関係ないことを示すことができます）、次に宛先IPアドレスを示すIP範囲、そしてポートがあります。 ポート範囲は、0:1024 のようにコロンで区切って指定することができます。
msg: は、一致するトラフィックが検出された場合に送信されるメッセージ（STAの場合はCoralogixに）を設定するディレクティブです。
flow: は、これから署名として定義するコンテンツがサーバーへの通信（「to_server」）またはクライアントへの通信（「to_client」）に現れる必要があるかを示すディレクティブです。
established: は、Snortがこのシグネチャに一致するパケットの検索を、確立された接続の一部であるパケットのみに制限するようにするディレクティブです。 これは、Snortの負荷を最小限に抑えるのに有効です。
uricontent: 正規化されたHTTP URIコンテンツで特定のテキストを検索するようSnortに指示するディレクティブです。 この例では、まさに “/root.exe” というテキストであるURLを探しています。
nocase: Snortに大文字小文字を区別しない検索を行うことを示す指示文です。
classtype: この規則がどのタイプの活動を検出するかを示すメタデータ属性となる指示文で、
reference: 詳細な情報について他のシステムへリンクしているメタデータ属性となる指示文で、この規則はこのメタデータ属性によって検出された活動を示します。 この例では、url,<https://….>という値がインターネット上のURLにリンクしています。
sid: は、署名IDを示すメタデータ属性である指示文です。
rev: は、ルールのバージョンを示す指示子です。
RegEx 解析、プロトコル固有の解析 (HTTP の uricontent と同様)、byte hex 値によるバイナリ (テキストではない) データの検索など、まだまだ Snort ルールについて学ぶべきことはたくさんあります。 より詳しく知りたい場合は、ここから始めることができます。
Best Practices to Writing Effective Snort Rules
- Target the vulnerability, not the exploit – 特定の悪用キットを検出するルールを書かないようにすることです。 例えば、バッファオーバーラン攻撃を検出するための初期のシグネチャの多くは、次のようなものでした。 このようなシグネチャが登場した後、多くの攻撃ツールキットは、単にバッファを埋めるために別の文字を使用し、この種のシグネチャの検出を完全に回避しています。
- Your peculiarity is your best asset, so use it – すべての組織には、その組織をユニークにしているものがあります。 その多くは、組織内の悪意ある活動（外部と内部の両方）を捕らえようとするときに、非常に役に立つことがあります。 このような内部の深い知識を活用することで、本質的に問題を技術的なものから、昔ながらの純粋なインテリジェンスの問題に変換することができます。 このようなことは、技術的なものであっても、組織特有の作業習慣や内部ガイドラインに基づくものであってもかまいません。 以下はその例です：
- 典型的な勤務時間。 私が働いていた組織の中には、従業員が自宅で仕事をすることをまったく許可していないところもあり、従業員の大半は19:00にはすでにオフィスを出ているようなところもありました。 同様の組織では、ある時間以降にオフィスからの接続を通知するアラートを設定することは理にかなっていると思います。 あなたの組織に悪意のあるソフトウェアをインストールする攻撃者は、その動作を知っていて、そのような通信が気づかれないように正確に同じ時間にコマンド & 制御サーバーと通信するようにマルウェアを調整する必要があります。 あなたの組織がメイン ブラウザとして Brave ブラウザを使用することを決定し、それがすべての新しい企業ラップトップに自動的にインストールされ、すべての企業ラップトップから IE/Edge ブラウザのデスクトップ ショートカットが削除されたとします。 このような場合、組織から IE/Edge などの異なるブラウザーを使用する内部および外部アドレスへの接続は、警告を発するように設定されなければなりません。 たとえば、すべての DB サーバーを 192.168.0.0/24 に、Web サーバーを 192.168.1.0/24 に配置するなど、役割に応じて異なる IP 範囲をサーバーに割り当てることが可能であれば、役割に基づくサーバーの予想動作に基づいた巧妙なルールを設定することも可能で、容易なことでしょう。 たとえば、データベース サーバーは通常単独で他のサーバーに接続しない、プリンターはドメイン コントローラーに接続しようとしない、などです。
- 異常な接続試行。 多くの組織では、ユーザー間でファイルを共有するためにファイル サーバー上のパブリック シェアを使用し、ユーザーが自分のコンピューターから直接印刷できるようにネットワーク対応プリンターを使用します。 つまり、クライアント コンピュータは互いに接続してはいけません。たとえ (賢明にも) ファイアウォールやスイッチでそのようなアクセスをブロックしていたとしても、あるクライアントから別のクライアント コンピュータに接続しようとすると、警告が出され、徹底的に調査されるべきです。 一部の組織では、サービス間の通信最適化のために特別なライブラリを使用し、サーバー間のすべての HTTP 通信が一般的なポート (80、443、8080 など) とは異なるポートを使用するようにしています。
- ハニートークン – インターネットのように誰もが誰にでもなれる戦場では、欺瞞は攻撃者と同じように、いやそれ以上に防御側にも有効です。 例えば、内蔵されている管理者アカウントを別の魅力的でない名前に変更し、決して使用しないAdministratorという新しいアカウントを作成し、このユーザー名、電子メール、パスワードがネットワーク上で使用された場合に検出するためのSnortルールを作成するなどのトリックがあります。 攻撃者は、Snortが偽の管理者ユーザーを使用しようとする試みを検出したことに気づくことはほとんど不可能でしょう。 もう1つの例として、データベースに偽の製品、顧客、ユーザー、クレジットカードのレコードを作成し、ネットワークトラフィックでそれらを検出するためのSnortルールをマッチングさせることができます。 Coralogix STAの詳細については、最近リリースした最新の機能をご覧ください。