Ubuntu20.04にSuricataをインストールする方法

投稿日: 2022-04-20 2022-04-20
タグ: Networking, Security, Suricata, ubuntu, Ubuntu 20.04

序章

Suricata は、コミュニティで作成およびユーザー定義された署名（ルールとも呼ばれる）のセットを使用してネットワークトラフィックを検査および処理するネットワークセキュリティ監視（NSM）ツールです。 Suricataは、サーバー上で実行されている任意の数の異なるサービスへの疑わしいパケットまたは要求を検出すると、ログイベントを生成し、アラートをトリガーし、トラフィックをドロップできます。

デフォルトでは、Suricataはパッシブ侵入検知システム（IDS）として機能し、サーバーまたはネットワーク上の疑わしいトラフィックをスキャンします。さらに調査するためにアラートを生成してログに記録します。また、特定のルールに一致するネットワークトラフィックをログに記録し、警告し、完全にブロックするアクティブな侵入防止システム（IPS）として構成することもできます。

Suricataをネットワーク内のゲートウェイホストに展開して、他のシステムからのすべての着信および発信ネットワークトラフィックをスキャンするか、いずれかのモードの個々のマシンでローカルに実行することができます。

このチュートリアルでは、Suricataをインストールする方法と、Ubuntu20.04でのデフォルト設定の一部をニーズに合わせてカスタマイズする方法を学習します。また、Suricataがネットワークトラフィックをスキャンするために使用する既存の署名セット（通常はルールセットと呼ばれる）をダウンロードする方法についても学習します。最後に、Suricataが応答で疑わしい要求とデータを検出したときに正しく機能しているかどうかをテストする方法を学習します。

前提条件

ネットワーク構成とSuricataの使用方法に応じて、サーバーに必要なCPUとRAMが増減する場合があります。一般に、検査する予定のトラフィックが多いほど、Suricataに割り当てる必要のあるリソースが多くなります。実稼働環境では、最初に少なくとも2つのCPUと4または8GBのRAMを使用することを計画します。そこから、Suricataのパフォーマンスと処理する必要のあるトラフィックの量に応じてリソースをスケールアップできます。

Suricataを使用して、実行されているサーバーを保護する場合は、次のものが必要になります。

2つ以上のCPU、sudo非rootユーザー、およびファイアウォールが有効になっている1つのUbuntu20.04サーバー。これを設定するには、 Ubuntu20.04を使用したサーバーの初期設定チュートリアルに従うことができます。

それ以外の場合、ゲートウェイホストでSuricataを使用して複数のサーバーを監視および保護する場合は、ホストのネットワークが正しく構成されていることを確認する必要があります。

DigitalOceanを使用している場合は、ドロップレットをVPCゲートウェイとして構成する方法に関するこのガイドに従うことができます。これらの手順は、ほとんどのUbuntuサーバーでも機能するはずです。

ステップ1—Suricataをインストールする

Suricataのインストールを開始するには、Open Information Security Foundation（OISF）のソフトウェアリポジトリ情報をUbuntuシステムに追加する必要があります。 add-apt-repositoryコマンドを使用してこれを行うことができます。

次のコマンドを実行して、リポジトリをシステムに追加し、使用可能なパッケージのリストを更新します。

sudo add-apt-repository ppa:oisf/suricata-stable

リポジトリを追加することを確認するメッセージが表示されたら、ENTERを押します。このコマンドは、新しいリポジトリを追加した後、使用可能なパッケージのリストを更新します。

これで、aptコマンドを使用してsuricataパッケージをインストールできます。

sudo apt install suricata

パッケージがインストールされたので、suricata.serviceを有効にして、システムの再起動時にパッケージが実行されるようにします。 systemctlコマンドを使用して有効にします。

sudo systemctl enable suricata.service

サービスが有効になっていることを示す次のような出力が表示されます。

Outputsuricata.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable suricata

Suricataの構成方法を説明するこのチュートリアルの次のセクションに進む前に、systemctlを使用してサービスを停止してください。

sudo systemctl stop suricata.service

Suricataを停止すると、構成ファイルを編集およびテストするときに、Suricataが再起動したときに、行った変更が検証およびロードされます。

ステップ2—初めてSuricataを設定する

OISFリポジトリのSuricataパッケージには、さまざまなユースケースをカバーする構成ファイルが付属しています。 SuricataのデフォルトモードはIDSモードであるため、トラフィックはドロップされず、ログに記録されるだけです。 Suricataを学ぶときは、このモードをデフォルトに設定したままにしておくことをお勧めします。 Suricataを構成して環境に統合し、アラートが表示されるトラフィックの種類を把握したら、IPSモードをオンにすることを選択できます。

ただし、デフォルトの構成には、環境やニーズに応じて変更する必要のある設定がいくつかあります。

（オプション）コミュニティフローIDの有効化

Suricataは、JSON出力に Community ID フィールドを含めることができるため、個々のイベントレコードを他のツールによって生成されたデータセットのレコードと簡単に照合できます。

ZeekやElasticsearchなどの他のツールでSuricataを使用する場合は、コミュニティIDを今すぐ追加することをお勧めします。

このオプションを有効にするには、nanoまたはお好みのエディターを使用して/etc/suricata/suricata.yamlを開きます。

sudo nano /etc/suricata/suricata.yaml

# Community Flow IDと書かれている120行目を見つけます。 nanoを使用している場合は、CTRL+_と入力し、行番号の入力を求められたら120と入力します。その線の下にはcommunity-idキーがあります。 trueに設定すると、次の設定が有効になります。

/etc/suricata/suricata.yaml

. . .
      # Community Flow ID
      # Adds a 'community_id' field to EVE records. These are meant to give
      # records a predictable flow ID that can be used to match records to
      # output of other tools such as Zeek (Bro).
      #
      # Takes a 'seed' that needs to be same across sensors and tools
      # to make the id less predictable.

      # enable/disable the community id feature.
      community-id: true
. . .

これで、イベントを調べるときに、1:S+3BA2UmrHK0Pk+u3XH78GAFTtQ=のようなIDが付けられ、さまざまなNMSツール間でレコードを相互に関連付けることができます。

/etc/suricata/suricata.yamlファイルを保存して閉じます。 nanoを使用している場合は、CTRL+X、Y、ENTERの順に使用して確認できます。

使用するネットワークインターフェイスの決定

Suricataがトラフィックを検査するデフォルトのネットワークインターフェースをオーバーライドする必要がある場合があります。 OISF Suricataパッケージに付属する構成ファイルは、デフォルトでeth0と呼ばれるデバイスのトラフィックを検査します。システムが異なるデフォルトのネットワークインターフェースを使用している場合、または複数のインターフェースでトラフィックを検査する場合は、この値を変更する必要があります。

デフォルトのネットワークインターフェイスのデバイス名を確認するには、次のようにipコマンドを使用できます。

ip -p -j route show default

-pフラグは出力を読みやすくフォーマットし、-jフラグは出力をJSONとして出力します。

次のような出力を受け取るはずです。

Output[ {
        "dst": "default",
        "gateway": "203.0.113.254",
        "dev": "eth0",
        "protocol": "static",
        "flags": [ ]
    } ]

dev行は、デフォルトのデバイスを示します。この出力例では、デバイスは強調表示されたeth0インターフェースです。出力には、ens...やeno...などのデバイス名が表示される場合があります。名前が何であれ、それを書き留めてください。

これで、Suricataの構成を編集し、インターフェース名を確認または変更できます。 nanoまたはお好みのエディターを使用して、/etc/suricata/suricata.yaml構成ファイルを開きます。

sudo nano /etc/suricata/suricata.yaml

580行目あたりにaf-packet:と表示されている行が表示されるまで、ファイルをスクロールします。 nanoを使用している場合は、CTRL+_と入力して行番号を入力することにより、その行に直接移動することもできます。その線の下には、Suricataがトラフィックを検査するために使用するデフォルトのインターフェースがあります。次の強調表示された例のように、インターフェイスに一致するように行を編集します。

/etc/suriata/suricata.yaml

# Linux high speed capture support
af-packet:
  - interface: eth0
    # Number of receive threads. "auto" uses the number of cores
    #threads: auto
    # Default clusterid. AF_PACKET will load balance packets based on flow.
    cluster-id: 99
. . .

追加のインターフェースでトラフィックを検査する場合は、- interface: eth...YAMLオブジェクトをさらに追加できます。たとえば、enp0s1という名前のデバイスを追加するには、af-packetセクションの一番下までスクロールして650行目あたりまで移動します。新しいインターフェースを追加するには、次の強調表示された例のように、-interface: defaultセクションの前にインターフェースを挿入します。

/ec/suricata/suricata.yaml

    #  For eBPF and XDP setup including bypass, filter and load balancing, please
    #  see doc/userguide/capture-hardware/ebpf-xdp.rst for more info.

  - interface: enp0s1
    cluster-id: 98

  - interface: default
    #threads: auto
    #use-mmap: no
    #tpacket-v3: yes

- interfaceオブジェクトごとに一意のcluster-id値を選択してください。

エディターを開いたままにして、ライブルールの再読み込みを構成する次のセクションに進みます。その設定を有効にしたくない場合は、/etc/suricata/suricata.yamlファイルを保存して閉じることができます。 nanoを使用している場合は、CTRL+X、Y、ENTERの順に使用して確認できます。

ライブルールの再読み込みの構成

Suricataは、ライブルールの再読み込みをサポートしています。つまり、実行中のSuricataプロセスを再起動しなくても、ルールを追加、削除、および編集できます。ライブリロードオプションを有効にするには、構成ファイルの一番下までスクロールして、次の行を追加します。

/etc/suricata/suricata.yaml

. . .

detect-engine:
  - rule-reload: true

この設定を行うと、SIGUSR2システムシグナルを実行中のプロセスに送信できるようになり、Suricataは変更されたルールをメモリにリロードします。

次のようなコマンドは、プロセスを再起動せずに、ルールセットをリロードするようにSuricataプロセスに通知します。

sudo kill -usr2 $(pidof suricata)

コマンドの$(pidof suricata)部分は、 subshell を呼び出し、実行中のSuricataデーモンのプロセスIDを見つけます。コマンドの最初のsudo kill -usr2部分は、killユーティリティを使用して、サブシェルによって報告されるプロセスIDにSIGUSR2シグナルを送信します。

このコマンドは、suricata-updateを実行するとき、または独自のカスタムルールを追加または編集するときにいつでも使用できます。

/etc/suricata/suricata.yamlファイルを保存して閉じます。 nanoを使用している場合は、CTRL+X、Y、ENTERの順に使用して確認できます。

ステップ3—Suricataルールセットを更新する

チュートリアルのこの時点で、Suricataを起動すると、ロードされたルールがないことを示す次のような警告メッセージがログに表示されます。

Output<Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules

デフォルトでは、Suricataパッケージには（/etc/suricata/rulesディレクトリ内の）限定された検出ルールのセットが含まれているため、この時点でSuricataをオンにすると、限られた量の不良トラフィックのみが検出されます。

Suricataには、外部プロバイダーからルールセットをフェッチできるsuricata-updateというツールが含まれています。次のように実行して、Suricataサーバーの最新のルールセットをダウンロードします。

sudo suricata-update

次のような出力を受け取るはずです。

Output19/10/2021 -- 19:31:03 - <Info> -- Using data-directory /var/lib/suricata.
19/10/2021 -- 19:31:03 - <Info> -- Using Suricata configuration /etc/suricata/suricata.yaml
19/10/2021 -- 19:31:03 - <Info> -- Using /etc/suricata/rules for Suricata provided rules.
. . .
19/10/2021 -- 19:31:03 - <Info> -- No sources configured, will use Emerging Threats Open
19/10/2021 -- 19:31:03 - <Info> -- Fetching https://rules.emergingthreats.net/open/suricata-6.0.3/emerging.rules.tar.gz.
 100% - 3044855/3044855               
. . .
19/10/2021 -- 19:31:06 - <Info> -- Writing rules to /var/lib/suricata/rules/suricata.rules: total: 31011; enabled: 23649; added: 31011; removed 0; modified: 0
19/10/2021 -- 19:31:07 - <Info> -- Writing /var/lib/suricata/rules/classification.config
19/10/2021 -- 19:31:07 - <Info> -- Testing with suricata -T.
19/10/2021 -- 19:31:32 - <Info> -- Done.

強調表示された行は、suricata-updateが無料のEmergingThreats ET Open Rules をフェッチし、それらをSuricataの/var/lib/suricata/rules/suricata.rulesファイルに保存したことを示しています。また、処理されたルールの数も示します。この例では、31011が追加され、そのうち23649が有効になっています。

ルールセットプロバイダーの追加

suricata-updateツールは、さまざまな無料および商用のルールセットプロバイダーからルールをフェッチできます。すでに追加したETOpenセットのような一部のルールセットは無料で利用できますが、その他のルールセットには有料のサブスクリプションが必要です。

次のように、list-sourcesフラグをsuricata-updateに使用して、ルールプロバイダーのデフォルトセットを一覧表示できます。

sudo suricata-update list-sources

次のようなソースのリストを受け取ります。

Output. . .
19/10/2021 -- 19:27:34 - <Info> -- Adding all sources
19/10/2021 -- 19:27:34 - <Info> -- Saved /var/lib/suricata/update/cache/index.yaml
Name: et/open
  Vendor: Proofpoint
  Summary: Emerging Threats Open Ruleset
  License: MIT
. . .

たとえば、tgreen/huntingルールセットを含める場合は、次のコマンドを使用して有効にすることができます。

sudo suricata-update enable-source tgreen/hunting

次に、suricata-updateを再度実行すると、既存のET Openルールやダウンロードしたその他のルールに加えて、新しいルールのセットが追加されます。

ステップ4—Suricataの構成を検証する

Suricataの構成ファイルを編集してオプションのコミュニティIDを含め、デフォルトのネットワークインターフェイスを指定し、ライブルールの再読み込みを有効にしたので、構成をテストすることをお勧めします。

Suricataには、構成ファイルと含まれているルールの有効性をチェックするテストモードが組み込まれています。 -Tフラグを使用して前のセクションからの変更を検証し、Suricataをテストモードで実行します。 -vフラグはいくつかの追加情報を出力し、-cフラグはSuricataに構成ファイルの場所を通知します。

sudo suricata -T -c /etc/suricata/suricata.yaml -v

Suricataに割り当てたCPUの量と追加したルールの数によっては、テストに時間がかかる場合があるため、テストが完了するまで1〜2分待つ準備をしてください。

デフォルトのETOpenルールセットを使用すると、次のような出力を受け取るはずです。

Output21/10/2021 -- 15:00:40 - <Info> - Running suricata under test mode
21/10/2021 -- 15:00:40 - <Notice> - This is Suricata version 6.0.3 RELEASE running in SYSTEM mode
21/10/2021 -- 15:00:40 - <Info> - CPUs/cores online: 2
21/10/2021 -- 15:00:40 - <Info> - fast output device (regular) initialized: fast.log
21/10/2021 -- 15:00:40 - <Info> - eve-log output device (regular) initialized: eve.json
21/10/2021 -- 15:00:40 - <Info> - stats output device (regular) initialized: stats.log
21/10/2021 -- 15:00:46 - <Info> - 1 rule files processed. 23879 rules successfully loaded, 0 rules failed
21/10/2021 -- 15:00:46 - <Info> - Threshold config parsed: 0 rule(s) found
21/10/2021 -- 15:00:47 - <Info> - 23882 signatures processed. 1183 are IP-only rules, 4043 are inspecting packet payload, 18453 inspect application layer, 107 are decoder event only
21/10/2021 -- 15:01:13 - <Notice> - Configuration provided was successfully loaded. Exiting.
21/10/2021 -- 15:01:13 - <Info> - cleaning up signature grouping structure... complete

構成ファイルにエラーがある場合、テストモードは、トラブルシューティングに役立つ特定のエラーコードとメッセージを生成します。たとえば、test.rulesという名前の存在しないルールファイルを含めると、次のようなエラーが生成されます。

Output21/10/2021 -- 15:10:15 - <Info> - Running suricata under test mode
21/10/2021 -- 15:10:15 - <Notice> - This is Suricata version 6.0.3 RELEASE running in SYSTEM mode
21/10/2021 -- 15:10:15 - <Info> - CPUs/cores online: 2
21/10/2021 -- 15:10:15 - <Info> - eve-log output device (regular) initialized: eve.json
21/10/2021 -- 15:10:15 - <Info> - stats output device (regular) initialized: stats.log
21/10/2021 -- 15:10:21 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/test.rules

このエラーが発生した場合は、構成ファイルを編集して正しいパスを含めるか、無効な変数と構成オプションを修正することができます。

Suricataテストモードの実行が正常に完了すると、次のステップに進むことができます。これは、デーモンモードでSuricataを起動することです。

ステップ5—Suricataを実行する

有効なSuricata構成とルールセットができたので、Suricataサーバーを起動できます。次のsystemctlコマンドを実行します。

sudo systemctl start suricata.service

systemctl statusコマンドを使用して、サービスのステータスを調べることができます。

sudo systemctl status suricata.service

次のような出力を受け取るはずです。

Output● suricata.service - LSB: Next Generation IDS/IPS
     Loaded: loaded (/etc/init.d/suricata; generated)
     Active: active (running) since Thu 2021-10-21 18:22:56 UTC; 1min 57s ago
       Docs: man:systemd-sysv-generator(8)
    Process: 22636 ExecStart=/etc/init.d/suricata start (code=exited, status=0/SUCCESS)
      Tasks: 8 (limit: 2344)
     Memory: 359.2M
     CGroup: /system.slice/suricata.service
             └─22656 /usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid --af-packet -D -vvv

Oct 21 18:22:56 suricata systemd[1]: Starting LSB: Next Generation IDS/IPS...
Oct 21 18:22:56 suricata suricata[22636]: Starting suricata in IDS (af-packet) mode... done.
Oct 21 18:22:56 suricata systemd[1]: Started LSB: Next Generation IDS/IPS.

テストモードコマンドと同様に、Suricataがすべてのルールをロードして解析するのに1〜2分かかります。 tailコマンドを使用して、開始が終了したことを示すSuricataのログ内の特定のメッセージを監視できます。

sudo tail -f /var/log/suricata/suricata.log

多数の出力行が表示され、Suricataのロード中に端末がスタックしているように見える場合があります。次のような行が表示されるまで、出力を待ち続けます。

Output19/10/2021 -- 19:22:39 - <Info> - All AFP capture threads are running.

この行は、Suricataが実行中であり、トラフィックを検査する準備ができていることを示しています。 CTRL+Cを使用して、tailコマンドを終了できます。

Suricataが実行されていることを確認したので、このチュートリアルの次のステップは、アラートを生成するように設計されたテストURLへの要求をSuricataが検出するかどうかを確認することです。

ステップ6—Suricataルールのテスト

ダウンロードしたETOpenルールセットには、30000を超えるルールが含まれています。 Suricataルールがどのように機能するか、およびそれらを構築する方法の完全な説明は、この入門チュートリアルの範囲を超えています。このシリーズの後続のチュートリアルでは、ルールの仕組みと独自のルールの作成方法について説明します。

このチュートリアルでは、生成した構成でSuricataが疑わしいトラフィックを検出しているかどうかをテストするだけで十分です。 Suricata Quickstart は、curlコマンドを使用して、番号2100498でETOpenルールをテストすることをお勧めします。

次のコマンドを実行してHTTPリクエストを生成します。これにより、Suricataのアラートルールに一致するレスポンスが返されます。

curl http://testmynids.org/uid/index.html

curlコマンドは、次のような応答を出力します。

Outputuid=0(root) gid=0(root) groups=0(root)

この応答データの例は、Webシェルを介して侵害されたリモートシステムで実行される可能性のあるidのようなコマンドの出力を返すふりをして、アラートをトリガーするように設計されています。

これで、Suricataのログで対応するアラートを確認できます。デフォルトのSuricata構成で有効になっている2つのログがあります。 1つ目は/var/log/suricata/fast.logにあり、2つ目は/var/log/suricata/eve.logの機械可読ログです。

`/var/log/suricata/fast.log`を調べる

curlリクエストに対応する/var/log/suricata/fast.logのログエントリを確認するには、grepコマンドを使用します。クイックスタートドキュメントの2100498ルール識別子を使用して、次のコマンドを使用してそれに一致するエントリを検索します。

grep 2100498 /var/log/suricata/fast.log

リクエストでIPv6が使用されている場合は、次のような出力を受け取る必要があります。ここで、2001:DB8::1はシステムのパブリックIPv6アドレスです。

Output
10/21/2021-18:35:54.950106  [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 2600:9000:2000:4400:0018:30b3:e400:93a1:80 -> 2001:DB8::1:34628

リクエストでIPv4が使用されている場合、ログには次のようなメッセージが表示されます。ここで、203.0.113.1はシステムのパブリックIPv4アドレスです。

Output
10/21/2021-18:35:57.247239  [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 204.246.178.81:80 -> 203.0.113.1:36364

出力で強調表示されている2100498値に注意してください。これは、Suricataがルールを識別するために使用する署名ID（sid）です。

`/var/log/suricata/eve.log`を調べる

Suricataは、 JSON を使用してエントリをフォーマットし、イベントを/var/log/suricata/eve.log（EVEログと呼ばれる）にも記録します。

Suricataのドキュメントでは、jqユーティリティを使用して、このファイルのエントリを読み取り、フィルタリングすることを推奨しています。次のaptコマンドを使用して、システムにjqがない場合は、インストールします。

sudo apt install jq

jqをインストールしたら、次のコマンドで2100498シグニチャを検索することにより、EVEログのイベントをフィルタリングできます。

jq 'select(.alert .signature_id==2100498)' /var/log/suricata/eve.json

このコマンドは、各JSONエントリを調べ、検索している2100498値と一致するsignature_idキーを使用して、alertオブジェクトを持つすべてのエントリを出力します。出力は次のようになります。

Output{
  "timestamp": "2021-10-21T19:42:47.368856+0000",
  "flow_id": 775889108832281,
  "in_iface": "eth0",
  "event_type": "alert",
  "src_ip": "203.0.113.1",
  "src_port": 80,
  "dest_ip": "147.182.148.159",
  "dest_port": 38920,
  "proto": "TCP",
  "community_id": "1:XLNse90QNVTgyXCWN9JDovC0XF4=",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 2100498,
    "rev": 7,
    "signature": "GPL ATTACK_RESPONSE id check returned root",
    "category": "Potentially Bad Traffic",
. . .
}

強調表示された"signature_id": 2100498,行に注意してください。これは、jqが検索しているキーです。 JSON出力で強調表示された"community_id": "1:XLNse90QNVTgyXCWN9JDovC0XF4=",行にも注意してください。このキーは、Suricataの構成ファイルで有効にした生成されたコミュニティフロー識別子です。

各アラートは、一意のコミュニティフロー識別子を生成します。他のNMSツールも同じ識別子を生成して、Suricataアラートを他のツールからの出力と相互参照できるようにすることができます。

いずれかのログファイルのログエントリが一致するということは、Suricataがネットワークトラフィックを正常に検査し、検出ルールと照合し、その後の分析またはログ記録のためにアラートを生成したことを意味します。このシリーズの今後のチュートリアルでは、Suricataアラートをセキュリティ情報イベント管理（SIEM）システムに送信してさらに処理する方法について説明します。

ステップ7—Suricataアラートの処理

アラートを設定してテストしたら、アラートの処理方法を選択できます。一部のユースケースでは、監査目的でアラートをログに記録するだけで十分な場合があります。または、繰り返しアラートを生成するシステムからのトラフィックをブロックするために、より積極的なアプローチを取ることをお勧めします。

Suricataが生成するアラートに基づいてトラフィックをブロックする場合、1つのアプローチは、EVEログのエントリを使用してから、ファイアウォールルールを追加して1つまたは複数のシステムへのアクセスを制限することです。 jqツールを使用してアラートから特定のフィールドを抽出し、UFWまたはIPtablesルールを追加してリクエストをブロックできます。

繰り返しになりますが、この例は、意図的に作成された要求および応答データを使用した架空のシナリオです。どのトラフィックが正当で、どのトラフィックをブロックできるかを判断するには、環境がアクセスできる必要のあるシステムとプロトコルに関する知識が不可欠です。

結論

このチュートリアルでは、OISFソフトウェアリポジトリからSuricataをインストールしました。この方法でSuricataをインストールすると、Suricataの新しいバージョンがリリースされるたびに更新を受け取ることができます。 Suricataをインストールした後、デフォルト構成を編集して、他のセキュリティツールで使用するコミュニティフローIDを追加しました。また、ライブルールの再読み込みを有効にし、ルールの初期セットをダウンロードしました。

Suricataの構成を検証したら、プロセスを開始し、テストHTTPトラフィックを生成しました。両方のデフォルトログを調べて、テストしているルールに対応するアラートが含まれていることを確認することで、Suricataが疑わしいトラフィックを検出できることを確認しました。

Suricataの詳細については、公式Suricataサイトをご覧ください。このチュートリアルで構成した構成オプションの詳細については、Suricataユーザーガイドを参照してください。

Suricataをインストールして構成したので、このシリーズの次のチュートリアル Suricataシグネチャについてに進み、独自のカスタムSuricataルールを作成する方法を探ります。無効なTCP/IPパケット、DNSクエリの内容、HTTP要求と応答、さらにはTLSハンドシェイクなどの基準に基づいて、アラートを作成するさまざまな方法、またはトラフィックを完全にドロップする方法について学習します。

getdocs

13036

序章

前提条件

ステップ1—Suricataをインストールする

ステップ2—初めてSuricataを設定する

（オプション）コミュニティフローIDの有効化

使用するネットワークインターフェイスの決定

ライブルールの再読み込みの構成

ステップ3—Suricataルールセットを更新する

ルールセットプロバイダーの追加

ステップ4—Suricataの構成を検証する

ステップ5—Suricataを実行する

ステップ6—Suricataルールのテスト

/var/log/suricata/fast.logを調べる

/var/log/suricata/eve.logを調べる

ステップ7—Suricataアラートの処理

結論

getdocs

`/var/log/suricata/fast.log`を調べる

`/var/log/suricata/eve.log`を調べる