Debian11で侵入防止システム(IPS)としてSuricataを設定する方法
序章
このチュートリアルでは、Debian 11でSuricataの組み込みの侵入防止システム(IPS)モードを構成する方法を学習します。 デフォルトでは、Suricataは侵入検知システム(IDS)として実行するように構成されています。このシステムは、アラートを生成し、疑わしいトラフィックのみをログに記録します。 IPSモードを有効にすると、Suricataは、さらに分析するためのアラートを生成するだけでなく、疑わしいネットワークトラフィックを積極的にドロップできます。
IPSモードを有効にする前に、有効にしたシグニチャとそのデフォルトのアクションを確認することが重要です。 誤って構成された署名、または過度に広い署名は、ネットワークへの正当なトラフィックをドロップしたり、SSHやその他の管理プロトコルを介してサーバーにアクセスすることをブロックしたりする可能性があります。
このチュートリアルの最初の部分では、インストールして有効にした署名を確認します。 また、独自の署名を含める方法についても学習します。 IPSモードで使用するシグニチャが決まったら、デフォルトのアクションを変換してトラフィックをドロップまたは拒否します。 署名を設定したら、 netfilter NFQUEUE iptablesターゲットを使用してSuricataを介してネットワークトラフィックを送信し、無効なネットワークトラフィックを生成して、Suricataが期待どおりにドロップするようにする方法を学習します。
前提条件
このチュートリアルシリーズをフォローしている場合は、すでにサーバー上でSuricataを実行しているはずです。 それでも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 2604:a880:cad:d0::dc8:4001/64 fe80::94ad:d4ff:fef9:cee0/64 eth1 UP 10.137.0.2/16 fe80::44a2:ebff:fe91:5187/64
パブリックIPアドレスは、出力で強調表示されている203.0.113.5
および2604:a880:cad:d0::dc8:4001/64
IPと同様になります。
次に、次のカスタム署名を作成して、非SSHポートへのSSHトラフィックをスキャンし、/etc/suricata/rules/local.rules
というファイルに含めます。 nano
またはお好みのエディターでファイルを開きます。
sudo nano /etc/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 -> 2604:a880:cad:d0::dc8:4001/64 !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
および2604:a880:cad:d0::dc8:4001/64
アドレスの代わりに、サーバーのパブリック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 -> 2604:a880:cad:d0::dc8:4001/64 !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 -> 2604:a880:cad:d0::dc8:4001/64 !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-update
ツールを使用して作成または含めた署名に満足したら、次の手順に進むことができます。この手順では、署名のデフォルトのアクションをアラートまたはログからアクティブにドロップするトラフィックに切り替えます。 。
ステップ2—シグニチャアクションの設定
カスタム署名をテストしてSuricataを操作したので、アクションをdrop
またはreject
に変更できます。 SuricataがIPSモードで動作している場合、これらのアクションは、一致するシグニチャの無効なトラフィックをアクティブにブロックします。
これらの2つのアクションは、このシリーズの前のチュートリアルSuricataSignaturesの理解で説明されています。 使用するアクションの選択はあなた次第です。 drop
アクションは、ネットワークフローに属するパケットと後続のパケットを即座に破棄します。 reject
アクションは、トラフィックがTCPベースの場合はクライアントとサーバーの両方にリセットパケットを送信し、その他のプロトコルの場合はICMPエラーパケットを送信します。
前のセクションのカスタムルールを使用して、drop
アクションを使用するように変換してみましょう。これらが一致するトラフィックは、ネットワークスキャンまたはその他の無効な接続である可能性が高いためです。
nano
またはお好みのエディターを使用して/etc/suricata/rules/local.rules
ファイルを開き、ファイルの各行の先頭にあるalert
アクションをdrop
に変更します。
/etc/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 -> 2604:a880:cad:d0::dc8:4001/64 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000001;) . . .
drop
またはreject
モードに変換する/etc/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のデフォルト設定を変更する必要があります。
systemctl edit
コマンドを使用して、新しいsystemdオーバーライドファイルを作成します。
sudo systemctl edit suricata.service
ファイルの先頭のコメントの間に、次の強調表示された行を追加します。
systemctl edit suricata.service
### Editing /etc/systemd/system/suricata.service.d/override.conf ### Anything between here and the comment below will become the new contents of the file [Service] ExecStart= ExecStart=/usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /run/suricata.pid -q 0 -vvv Type=simple ### Lines below this comment will be discarded . . .
ExecStart=
行は、サービスを開始するデフォルトのsystemdコマンドをクリアします。 次の行は、使用する新しいExecStart
コマンドを定義します。Type=simple
行は、systemdがIPSモードで実行されているときにSuricataプロセスを管理できるようにします。
ファイルを保存して閉じます。 nano
を使用している場合は、CTRL+X
、Y
、ENTER
の順に使用して確認できます。 vi
を使用している場合は、ESC
、:x
、ENTER
の順に押して保存して終了します。
次に、systemdをリロードして、新しいSuricata設定を検出します。
sudo systemctl daemon-reload
これで、systemctl
を使用してSuricataを再起動できます。
sudo systemctl restart suricata.service
systemctl
を使用してSuricataのステータスを確認します。
sudo systemctl status suricata.service
次のような出力を受け取るはずです。
Output● suricata.service - Suricata IDS/IDP daemon Loaded: loaded (/lib/systemd/system/suricata.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/suricata.service.d └─override.conf Active: active (running) since Wed 2021-12-15 14:35:21 UTC; 38s ago Docs: man:suricata(8) man:suricatasc(8) https://suricata-ids.org/docs/ Main PID: 29890 (Suricata-Main) Tasks: 10 (limit: 2340) Memory: 54.9M CPU: 3.957s CGroup: /system.slice/suricata.service └─29890 /usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /run/suricata.pid -q 0 -vvv . . . Dec 15 14:35:21 suricata suricata[29890]: 15/12/2021 -- 14:35:21 - <Notice> - all 4 packet processing threads, 4 management threads initialized, engine started
Suricataが正常に再起動したことを示す強調表示されたactive (running)
行に注意してください。
この変更により、次のステップでUFWファイアウォールを使用してSuricataにトラフィックを送信する準備が整いました。
ステップ4—トラフィックをSuricataに送信するようにUFWを構成する
IPSモードでトラフィックを処理するようにSuricataを構成したので、次のステップは着信パケットをSuricataに転送することです。 このシリーズの前提条件のチュートリアルに従い、Ubuntu 20.04システムを使用している場合は、Uncomplicated Firewall(UFW)がインストールされ、デフォルトで有効になっている必要があります。
Suricataに必要なルールをUFWに追加するには、/etc/ufw/before.rules
および/etc/ufw/before6.rules
のファイアウォールファイルを直接編集する必要があります。
nano
またはお好みのエディターを使用して、最初のファイルを開きます。
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
ファイルの同じセクションに同じ行を追加します。
最初の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に転送します。
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -j NFQUEUE sudo firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass sudo firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 1 -j NFQUEUE sudo firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -j NFQUEUE sudo firewall-cmd --permanent --direct --add-rule ipv6 filter FORWARD 0 -j NFQUEUE sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -j NFQUEUE sudo firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass sudo firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 1 -j NFQUEUE sudo firewall-cmd --reload
チュートリアルのこの時点で、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;)
/etc/suricata/rules/suricata.rules
ファイルでルールを見つけて編集し、署名が含まれている場合はdrop
アクションを使用します。 それ以外の場合は、ルールを/etc/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:Z+RcUB32putNzIZ38V/kEzZbWmQ=", "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)システムにログを送信する方法について説明します。 。