Ubuntu 20.04で侵入防止システム（IPS）としてSuricataを構成する方法

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

序章

このチュートリアルでは、Ubuntu 20.04でSuricataの組み込みの侵入防止システム（IPS）モードを構成する方法を学習します。デフォルトでは、Suricataは侵入検知システム（IDS）として実行するように構成されています。このシステムは、アラートを生成し、疑わしいトラフィックのみをログに記録します。 IPSモードを有効にすると、Suricataは、さらに分析するためのアラートを生成するだけでなく、疑わしいネットワークトラフィックを積極的にドロップできます。

IPSモードを有効にする前に、有効にしたシグニチャとそのデフォルトのアクションを確認することが重要です。誤って構成された署名、または過度に広い署名は、ネットワークへの正当なトラフィックをドロップしたり、SSHやその他の管理プロトコルを介してサーバーにアクセスすることをブロックしたりする可能性があります。

このチュートリアルの最初の部分では、インストールして有効にした署名を確認します。また、独自の署名を含める方法についても学習します。 IPSモードで使用するシグニチャが決まったら、デフォルトのアクションを変換してトラフィックをドロップまたは拒否します。署名を設定したら、 netfilter NFQUEUE iptablesターゲットを使用してSuricataを介してネットワークトラフィックを送信し、無効なネットワークトラフィックを生成して、Suricataが期待どおりにドロップするようにする方法を学習します。

前提条件

このチュートリアルシリーズをフォローしている場合は、Ubuntu20.04サーバーでSuricataを実行しているはずです。

それでもSuricataをインストールする必要がある場合は、Ubuntu20.04にSuricataをインストールする方法に従ってください。
また、 ET Open Ruleset をsuricata-updateコマンドを使用してダウンロードし、Suricata署名に含める必要があります。
jqコマンドラインJSON処理ツール。前のチュートリアルでインストールしていない場合は、aptコマンドを使用してインストールできます。
```
sudo apt update
sudo apt install jq
```

前のSuricata署名についてチュートリアルで使用したいカスタム署名がある場合もあります。

ステップ1—カスタム署名を含める

このシリーズのこれまでのチュートリアルでは、Suricataをインストールして構成する方法と、署名を理解する方法について説明しました。独自のルールを作成して含める場合は、Suricataの/etc/suricata/suricata.yamlファイルを編集して、署名へのカスタムパスを含める必要があります。

まず、サーバーのパブリックIPを見つけて、カスタム署名で使用できるようにします。 IPを見つけるには、ipコマンドを使用できます。

ip -brief address show

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

Outputlo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.5/20 10.20.0.5/16 2001:DB8::1/32 fe80::94ad:d4ff:fef9:cee0/64
eth1             UP             10.137.0.2/16 fe80::44a2:ebff:fe91:5187/64

パブリックIPアドレスは、出力で強調表示されている203.0.113.5および2001:DB8::1/32IPと同様になります。

次に、次のカスタム署名を作成して、非SSHポートへのSSHトラフィックをスキャンし、/var/lib/suricata/rules/local.rulesというファイルに含めます。 nanoまたはお好みのエディターでファイルを開きます。

sudo nano /var/lib/suricata/rules/local.rules

次の署名をコピーして貼り付けます。

無効なSSHトラフィック署名

alert ssh any any -> 203.0.113.5 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000000;)
alert ssh any any -> 2001:DB8::1/32 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000001;)

ルールの203.0.113.5および2001:DB8::1/32アドレスの代わりに、サーバーのパブリックIPアドレスを使用してください。 IPv6を使用していない場合は、このルールと次のルールでその署名を追加することをスキップできます。

ネットワークとアプリケーションに応じて、このlocal.rulesファイルにカスタム署名を追加し続けることができます。たとえば、非標準ポートへのHTTPトラフィックについてアラートを送信する場合は、次のシグニチャを使用できます。

非標準のポート署名のHTTPトラフィック

alert http any any -> 203.0.113.5 !80 (msg:"HTTP REQUEST on non-HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000002;)
alert http any any -> 2001:DB8::1/32 !80 (msg:"HTTP REQUEST on non-HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000003;)

Webサーバーのデフォルトの443以外のポートへのTLSトラフィックをチェックする署名を追加するには、次を追加します。

非標準のポート署名でのTLSトラフィック

alert tls any any -> 203.0.113.5 !443 (msg:"TLS TRAFFIC on non-TLS HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000004;)
alert tls any any -> 2001:DB8::1/32 !443 (msg:"TLS TRAFFIC on non-TLS HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000005;)

署名の追加が完了したら、ファイルを保存して閉じます。 nanoを使用している場合は、CTRL+X、Y、ENTERの順に使用して確認できます。 viを使用している場合は、ESC、:x、ENTERの順に押して保存して終了します。

いくつかのカスタム署名を定義したので、nanoまたはお好みのエディターを使用してSuricataの/etc/suricata/suricata.yaml構成ファイルを編集してそれらを含めます。

sudo nano /etc/suricata/suricata.yaml

構成のrule-files:部分を見つけます。 nanoを使用している場合は、CTRL+_を使用して、行番号1879を入力します。 viを使用している場合は、1879ggと入力して行に移動します。ファイル内の正確な場所は異なる場合がありますが、ファイルの正しい一般的な領域にいる必要があります。

セクションを編集し、次の強調表示された- local.rules行を追加します。

/etc/suricata/suricata.yaml

. . .
rule-files:
  - suricata.rules
  - local.rules
. . .

ファイルを保存して終了します。ルールを追加した後は、必ずSuricataの構成を検証してください。これを行うには、次のコマンドを実行します。

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

デフォルトのsuricata.rulesファイルにロードしたルールの数によっては、テストに時間がかかる場合があります。テストに時間がかかりすぎる場合は、行の先頭に#を追加して、構成の- suricata.rules行をコメントアウトしてから、構成テストを再実行できます。最終的な実行構成でsuricata.rules署名を使用する場合は、必ず#コメントを削除してください。

suricata-updateツールを使用して作成または含めた署名に満足したら、次の手順に進むことができます。次の手順では、署名のデフォルトのアクションをalertまたはlogトラフィックを積極的にドロップします。

ステップ2—シグニチャアクションの設定

カスタム署名をテストしてSuricataを操作したので、アクションをdropまたはrejectに変更できます。 SuricataがIPSモードで動作している場合、これらのアクションは、一致するシグニチャの無効なトラフィックをアクティブにブロックします。

これらの2つのアクションは、このシリーズの前のチュートリアルSuricataSignaturesの理解で説明されています。使用するアクションの選択はあなた次第です。 dropアクションは、ネットワークフローに属するパケットと後続のパケットを即座に破棄します。 rejectアクションは、トラフィックがTCPベースの場合はクライアントとサーバーの両方にリセットパケットを送信し、その他のプロトコルの場合はICMPエラーパケットを送信します。

前のセクションのカスタムルールを使用して、dropアクションを使用するように変換してみましょう。これらが一致するトラフィックは、ネットワークスキャンまたはその他の無効な接続である可能性が高いためです。

nanoまたはお好みのエディターを使用して/var/lib/suricata/rules/local.rulesファイルを開き、ファイルの各行の先頭にあるalertアクションをdropに変更します。

sudo nano /var/lib/suricata/rules/local.rules

/var/lib/suricata/rules/local.rules

drop ssh any any -> 203.0.113.5 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000000;)
drop ssh any any -> 2001:DB8::1/32 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000001;)
. . .

dropまたはrejectモードに変換する/var/lib/suricata/rules/suricata.rulesの署名について、上記の手順を繰り返します。

注：前提条件のチュートリアルでsuricata-updateを実行した場合、suricata.rules fileに30,000を超える署名が含まれている可能性があります。

すべての署名をdropまたはrejectに変換すると、ネットワークまたはサーバーへの正当なアクセスがブロックされるリスクがあります。代わりに、当面はsuricata.rulesにルールを残し、local.rulesにカスタム署名を追加してください。 Suricataは、IPSモードで実行されている間、suricata.rulesのシグニチャによって記述される疑わしいトラフィックのアラートを生成し続けます。

アラートを数日または数週間収集した後、アラートを分析し、sidに基づいてdropまたはrejectに変換する関連するシグニチャを選択できます。

実行するアクションですべてのシグニチャを構成したら、次のステップは、再構成してから、IPSモードでSuricataを再起動することです。

ステップ3—`nfqueue`モードを有効にする

SuricataはデフォルトでIDSモードで実行されます。つまり、ネットワークトラフィックをアクティブにブロックしません。 IPSモードに切り替えるには、Suricataの/etc/default/suricata構成ファイルを編集する必要があります。

nanoまたはお好みのエディターでファイルを開きます。

sudo nano /etc/default/suricata

LISTENMODE=af-packet行を見つけて、行の先頭に#を追加してコメントアウトします。次に、SuricataにIPSモードで実行するように指示する新しい行LISTENMODE=nfqueue行を追加します。

編集が完了すると、ファイルには次の強調表示された行が含まれているはずです。

/ etc / default / suricata

. . .
# LISTENMODE=af-packet
LISTENMODE=nfqueue
. . .

ファイルを保存して閉じます。これで、systemctlを使用してSuricataを再起動できます。

sudo systemctl restart suricata.service

systemctlを使用してSuricataのステータスを確認します。

sudo systemctl status suricata.service

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

Output● suricata.service - LSB: Next Generation IDS/IPS
     Loaded: loaded (/etc/init.d/suricata; generated)
     Active: active (running) since Wed 2021-12-01 15:54:28 UTC; 2s ago
       Docs: man:systemd-sysv-generator(8)
    Process: 1452 ExecStart=/etc/init.d/suricata start (code=exited, status=0/SUCCESS)
      Tasks: 12 (limit: 9513)
     Memory: 63.6M
     CGroup: /system.slice/suricata.service
             └─1472 /usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid -q 0 -D -vvv

Dec 01 15:54:28 suricata systemd[1]: Starting LSB: Next Generation IDS/IPS...
Dec 01 15:54:28 suricata suricata[1452]: Starting suricata in IPS (nfqueue) mode... done.
Dec 01 15:54:28 suricata systemd[1]: Started LSB: Next Generation IDS/IPS.

Suricataが正常に再起動したことを示す強調表示されたactive (running)行に注意してください。また、Starting suricata in IPS (nfqueue) mode... done.行に注意してください。これは、SuricataがIPSモードで実行されていることを確認します。

この変更により、次のステップでUFWファイアウォールを使用してSuricataにトラフィックを送信する準備が整いました。

ステップ4—トラフィックをSuricataに送信するようにUFWを構成する

IPSモードでトラフィックを処理するようにSuricataを構成したので、次のステップは着信パケットをSuricataに転送することです。このシリーズの前提条件のチュートリアルに従い、Ubuntu 20.04システムを使用している場合は、Uncomplicated Firewall（UFW）をインストールして有効にする必要があります。

Suricataに必要なルールをUFWに追加するには、/etc/ufw/before.rules（IPv4ルール）および/etc/ufw/before6.rules（IPv6）のファイアウォールファイルを直接編集する必要があります。

nanoまたはお好みのエディターを使用して、IPv4ルールの最初のファイルを開きます。

sudo nano /etc/ufw/before.rules

ファイルの先頭近くに、次の強調表示された行を挿入します。

/etc/ufw/before.rules

. . .
# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines

## Start Suricata NFQUEUE rules
-I INPUT 1 -p tcp --dport 22 -j NFQUEUE --queue-bypass
-I OUTPUT 1 -p tcp --sport 22 -j NFQUEUE --queue-bypass
-I FORWARD -j NFQUEUE
-I INPUT 2 -j NFQUEUE
-I OUTPUT 2 -j NFQUEUE
## End Suricata NFQUEUE rules

# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT
. . .

編集が完了したら、ファイルを保存して終了します。次に、/etc/ufw/before6.rulesファイルの同じセクションに同じ強調表示された行を追加します。

sudo nano /etc/ufw/before.rules

両方のファイルの内容が同じであることを確認してください。編集が完了したら、ファイルを保存して終了します。

最初の2つのINPUTおよびOUTPUTルールは、Suricataをバイパスするために使用されるため、Suricataが実行されていない場合でも、SSHを使用してサーバーに接続できます。これらのルールがないと、署名が正しくないか、広すぎると、SSHアクセスがブロックされる可能性があります。さらに、Suricataが停止している場合、すべてのトラフィックはNFQUEUEターゲットに送信され、Suricataが実行されていないためにドロップされます。

次のFORWARDルールは、サーバーが他のシステムのゲートウェイとして機能している場合、そのすべてのトラフィックが処理のためにSuricataにも送られることを保証します。

最後の2つのINPUTおよびOUTPUTルールは、SSHトラフィックではないall残りのトラフィックを処理のためにSuricataに送信します。

UFWを再起動して、新しいルールをロードします。

sudo systemctl restart ufw.service

注：別のファイアウォールを使用している場合は、ファイアウォールが期待する形式に一致するようにこれらのルールを変更する必要があります。

iptablesを使用している場合は、iptablesおよびip6tablesコマンドを使用してこれらのルールを直接挿入できます。ただし、iptables-persistentなどのツールを使用して、再起動後もルールが永続的であることを確認する必要があります。

firewalldを使用している場合、次のルールがトラフィックをSuricataに転送します。

firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -j NFQUEUE
firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 1 -j NFQUEUE

firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -j NFQUEUE
firewall-cmd --permanent --direct --add-rule ipv6 filter FORWARD 0 -j NFQUEUE

firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -j NFQUEUE
firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 1 -j NFQUEUE

チュートリアルのこの時点で、SuricataはIPSモードで実行するように構成されており、ネットワークトラフィックはデフォルトでSuricataに送信されています。サーバーはいつでも再起動でき、Suricataとファイアウォールのルールは永続的です。

このチュートリアルの最後のステップは、Suricataがトラフィックを正しくドロップしていることを確認することです。

ステップ5—無効なトラフィックをテストする

Suricataとファイアウォールがネットワークトラフィックを処理するように構成されたので、Suricataがカスタムおよびその他の含まれている署名に一致するパケットをドロップするかどうかをテストできます。

前のチュートリアルの署名sid:2100498を思い出してください。この例では、dropに一致するパケットに変更されています。

sid：2100498

drop ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)

/var/lib/suricata/rules/suricata.rulesファイルでルールを見つけて編集し、署名が含まれている場合はdropアクションを使用します。それ以外の場合は、ルールを/var/lib/suricata/rules/local.rulesファイルに追加します。

SuricataにSIGUSR2シグナルを送信して、署名をリロードさせます。

sudo kill -usr2 $(pidof suricata)

次に、curlを使用してルールをテストします。

curl --max-time 5 http://testmynids.org/uid/index.html

リクエストがタイムアウトしたことを示すエラーが表示されます。これは、SuricataがHTTP応答をブロックしたことを示しています。

Outputcurl: (28) Operation timed out after 5000 milliseconds with 0 out of 39 bytes received

jqを使用してeve.logファイルを調べることで、SuricataがHTTP応答をドロップしたことを確認できます。

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

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

Output
{
. . .
  "community_id": "1:tw19kjR2LeWacglA094gRfEEuDU=",
  "alert": {
    "action": "blocked",
    "gid": 1,
    "signature_id": 2100498,
    "rev": 7,
    "signature": "GPL ATTACK_RESPONSE id check returned root",
    "category": "Potentially Bad Traffic",
    "severity": 2,
    "metadata": {
      "created_at": [
        "2010_09_23"
      ],
      "updated_at": [
        "2010_09_23"
      ]
    }
  },
  "http": {
    "hostname": "testmynids.org",
    "url": "/uid/index.html",
    "http_user_agent": "curl/7.68.0",
    "http_content_type": "text/html",
    "http_method": "GET",
    "protocol": "HTTP/1.1",
    "status": 200,
    "length": 39
  },
. . .

強調表示された"action": "blocked"行は、署名が一致したことを確認し、SuricataはテストHTTPリクエストをドロップまたは拒否しました。

結論

このチュートリアルでは、組み込みのIPSモードを使用して疑わしいネットワークトラフィックをブロックするようにSuricataを構成しました。また、非標準ポートでのSSH、HTTP、およびTLSトラフィックを調べてブロックするためのカスタムシグニチャを追加しました。すべてを結び付けるために、ファイアウォールルールを追加して、トラフィックをSuricataに転送して処理します。

SuricataをインストールしてIPSモードで構成し、疑わしいトラフィックを警告またはドロップする独自の署名を作成できるようになったので、サーバーとネットワークの監視を継続し、署名を調整できます。

Suricataの署名と構成に満足したら、このシリーズの最後のチュートリアルに進むことができます。このチュートリアルでは、Suricataから Elastic Stackを使用して構築されたセキュリティおよび情報イベント管理（SIEM）システムにログを送信する方法について説明します。。

getdocs

13036

序章

前提条件

ステップ1—カスタム署名を含める

ステップ2—シグニチャアクションの設定

ステップ3—nfqueueモードを有効にする

ステップ4—トラフィックをSuricataに送信するようにUFWを構成する

ステップ5—無効なトラフィックをテストする

結論

getdocs

ステップ3—`nfqueue`モードを有効にする