Synology Threat Prevention：検知できるものと検知できないもの
更新日 2026年10月25日
Threat Prevention は、Synology NAS でウェブサイトをホストしようと決めたときに、多くの人が最初に手を伸ばすパッケージです。ルーター上で動作し、シールドアイコンがあり、ダッシュボードには何百もの攻撃がカウントされるため、公開サイトを安全に保つ存在のように見えます。私たちは保有するすべてのマシンの手前にある RT6600ax で運用しており、導入する価値は十分にありました。しかし同時に、セルフホスト型のウェブサイトにとっては、ほとんど意味をなさないものでもあります。
この NAS ホスティング 101 の記事では、自社のルーターを開き、実際の 1 週間のイベントを読み解き、 Threat Prevention が対処できなくなる限界を正確に示します。その際、 Threat Prevention では検知できるはずのない攻撃の例として PHP2Shell を取り上げます。
SynoPower Clubポイント： 私はSynologyのサポート側に長年携わってきましたが、「この攻撃を止めるにはどのオプションをオンにすればよいか」という質問が常に寄せられました。それは正しい直感ですが、対象とする機器（ボックス）が間違っています。私が最終的に納得できたのは、機能の紹介ページではなく、当社自身のイベントリストを読み込んだ時でした。今月当社のルーターが記録したすべてのアラートは、悪意のあるペイロードを持つリクエストではなく、評判（レピュテーション）の悪いアドレスでした。それを確認すれば、封印された封筒の中に入っているトラフィックを検査するようThreat Preventionに求めることはなくなるでしょう。
Synology ルーター上で Threat Prevention が実際に何を行うか #
Threat Prevention は、Snort および Suricata の系譜を受け継ぐ侵入検知・防止システムです。ルーターがパケットを転送する際にパケットを読み取り、シグネチャセットと照合して、アラートを記録するかパケットを破棄します。当社の RT6600ax では、シグネチャフィードとして Emerging Threats ルールセットの無料層である ET Open を使用しており、毎日 09:00 に更新スケジュールが実行されます。
その設計から 3 つの特性が生じますが、そのすべてがインターフェース内のどのチェックボックスよりも重要です。
- It can only examine packets the router forwards. Traffic that never crosses the routing engine is not slow to inspect, it is invisible.
- It can only match on bytes it can read。Threat PreventionにはTLSインターセプト機能が一切ないため、暗号化されたペイロードの内容は読み取れません。
- It can only match signatures somebody else wrote. The interface exposes vendor classes to switch on and off, and nothing that accepts a rule you author yourself.
これらはどれも欠陥ではありません。ネットワーク境界に IPS を配置することは合理的で役立つことです。間違いは、境界部分こそがウェブサイトが攻撃を受ける場所であると思い込んでしまうことにあります。
Threat Prevention と Web アプリケーションファイアウォールの違い #
その違いを最も明確に理解する方法は、 Threat Prevention と Web アプリケーションファイアウォール（WAF）を並べ、それぞれの判定時に保持している情報が何かを考えることです。 Threat Prevention が保持しているのはパケットです。一方、WAF が保持しているのは復号化された HTTP リクエストです。
| Question | Router IPS | Reverse-proxy WAF |
|---|---|---|
| 走る場所 | On the routing path, before TLS ends | At the edge, after TLS ends |
| What it inspects | Packet headers and any cleartext bytes | Method, path, headers, cookies, body |
| HTTPS traffic | Opaque | Fully readable |
| Rules you can add | Vendor classes on or off | Your own expressions, plus managed rulesets |
| Same-subnet traffic | Never seen | Not applicable, it is upstream of everything |
| Typical catch | Reputation hits, scans, cleartext exploits, outbound command and control | Injection, traversal, known CVE request shapes, credential stuffing, bots |
これらは競合する製品ではありません。同じ通信経路の異なるセグメントをカバーしており、セルフホスト型サイトに必要なのは後者（WAF）です。当社では両方を運用しており、それぞれから全く異なる役割を期待しています。
自社ルーターでの 1 週間・595 件のイベントを解読する #
2026 年 10 月 25 日時点における、当社本番ルーターの Threat Prevention 概要画面です。7 日間で 595 件の悪意のあるイベントが発生し、そのうち 75 件が「高」重要度でした。まるで洪水を防ぐ壁のように見えます。
その画面にある 2 つの詳細な情報は、見出しの数値以上の価値があります。1 つ目は、潜在的な脅威の下に表示されているデバイスが 1 台のみであり、それが TLS を終端して MailPlus を実行しているマシン「REVERSE_MAIL」である点です。2 つ目は、緑色のチェックマークの横にあるシグネチャの日付です。では、1 つのイベントを開いて、実際に何が検出されたのかを確認してみましょう。
分類 Misc Attack、重要度「中」、ステータス Alert、シグネチャ名 ET CINS Active Threat Intelligence Poor Reputation IP group 24。ルール本体を開くと、alert ip とそれに続く長いアドレスリストから始まります。これは単なるブロックリストの照合です。HTTP リクエストのどの部分も読み取られていません。構造上読み取ることができないからです。2 つ目の宛先である当社の Virtual DSM ホストに対するイベントもサンプル抽出したところ、グループ番号が異なるだけで同じ種類のルールが見つかりました。
したがって、1 週間の正直なまとめは次のようになります。ルーターは、すでに評判の悪いアドレスからの数百件の接続を認識しただけです。これは実に有用な機能です。しかし、ウェブ攻撃の検知ではなく、595 という数値をウェブ攻撃の防御数として解釈すべきではありません。
Threat Prevention を 4 つのステップで監査する方法 #
Threat Prevention を全面的に信頼する前に、自身のネットワークで実際に何を行っているかを調べるために 10 分ほど時間を取ってください。以下のステップはすべて読み取り専用であり、設定を変更することはありません。
Open one event and read the signature body #
Threat Preventionから「イベント」に移動し、いずれかのエントリーをクリックします。色付きの深刻度バッジの先にある「シグネチャルール」ボックスを確認してください。alert ipで始まるルールは、アドレスの評判（レピュテーション）のみでマッチングしています。contentやpcreを含むルールは、ペイロードでマッチングしています。Threat Preventionが何を保護しているかを判断する前に、ご自身のリストでそれぞれがいくつ見つかるか数えてみてください。
監視されているインターフェースを確認する #
[設定] を開き、[監視対象のインターフェース] テーブルを確認します。チェックが入っているインターフェースのみが検査され、通常の運用環境ではインターネットに面したインターフェースがそれに該当します。同一 LAN サブネット内の 2 つのデバイス間のトラフィックは、ルーティングではなくスイッチングされるため、検査エンジンに到達することはなく、このページのどの設定を変更してもそれを変えることはできません。
ルーターが混雑しているときに何が起こるかを確認する #
同じパネル内で、デフォルトモードを確認してください。「ネットワーク安定性を優先」は、トラフィックがエンジンで処理できる容量を超えた場合、超過分がフィルタリングされずにそのまま通過することを意味します。「セキュリティを優先」は、代わりに超過分が破棄されることを意味します。前者の選択肢はフェイルオープンとなり回線を維持し、後者の選択肢はフェイルクローズとなり回線をダウンさせます。どちらが実際に必要かを判断してください。
Try to add a rule of your own #
Open Self-Defined Policy. You can change the action for a signature the vendor already ships, and you can scope it by source or destination address. There is no field anywhere that accepts a signature you wrote. If your threat is newer than your signature feed, this screen is where you discover you have no way to respond.
Threat Prevention が真の価値を発揮する場面 #
当社では Threat Prevention をオンにし続けていますが、それは気休めではありません。当社の環境にある他のどのツールも代用できない 4 つの役割を果たしているからです。
- Outbound command and control. This is the strongest case by far. A compromised device has to call home, that call has to leave through the router, and a good share of it is still either cleartext or aimed at a known address. Our router ships the Malware Command and Control Activity class with 3,450 of 3,498 rules enabled, and the Domain Observed Used for C2 class with 7,157 of 7,202.
- Cleartext protocols from the internet. Our mail server answers on port 25, and SMTP is cleartext until STARTTLS. That is real inspectable traffic, and it is no accident that the mail host is the one device our events list keeps naming.
- Scanning and reconnaissance. Port sweeps and fingerprinting are recognised by connection behaviour rather than by payload, so encryption does not hide them.
- Visibility. A searchable log of who knocked and with what reputation is worth having, even when every entry is only a reputation hit. It is monitoring value, and it should be counted as monitoring value rather than as protection.
これら 4 つに共通しているのは、いずれも「ウェブサイトに対する攻撃ではない」という点です。
サイト所有者が Threat Prevention に誤った期待を寄せてしまう理由 #
NAS でサイトをホストする場合、リクエストの経路には通常リバースプロキシが含まれます。当社の構成は以下のようになっており、この構造自体がすべてを決定づけています。
- The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
- What is left crosses the router、そこでThreat Preventionに見えるのは暗号化されたTLSストリームだけであり、それ以上のものではありません。
- その reverse proxy NAS terminates TLS and forwards plain HTTP to the machine that runs the site.
- That last hop is on the same subnet, so the frame goes through a switch and the router is not in the path.
これら4行を合わせて読むと、落とし穴は明白です。リクエストが読み取り可能な形式で存在する唯一のセグメントは最後のホップであり、それこそがルーターが監視できない唯一のセグメントです。ルーターが監視できるすべての場所において、リクエストは暗号化されています。このような矛盾を解決するチェックボックスは存在せず、Threat Prevention が沈黙しているからといって失敗しているわけではありません。構造的に読み取ることができないトラフィックについて正確に報告しているのです。
これが、Threat Prevention を特定のサイトに向けさせても機能しない理由でもあります。このパッケージはホスト名ではなく、ルーターのインターフェイスにバインドされています。Host ヘッダーを一切参照しないため、接続がどのサイトに属しているかという概念がありません。
PHP2Shell がルーターで検知できなかった3つの理由 #
CVE-2026-109618 および CVE-2026-109619 として追跡された認証前のリモートコード実行の脆弱性のペアである PHP2Shell は、2026年10月20日に流出し、翌日にアップストリームでパッチが適用されました。これはまさにルーターの IPS が吸収してくれることを人々が期待する種類の攻撃ですが、なぜそれが不可能だったのかを具体的に説明する価値があります。
第一に、ルーターが監視するすべてのセグメントでトラフィックが暗号化されていたことです。 The exploit lives in the HTTP request, and the HTTP request only exists in the clear after TLS has been terminated, which happens downstream of the router on a hop the router never carries.
第二に、有効化すべきThreat Preventionのシグネチャが存在しません。 We checked again on 25 October 2026 and found no published Snort or Emerging Threats rule for either CVE. Our feed is ET Open, the free tier, which lags the commercial set, and the Self-Defined Policy screen accepts no rule of your own. So even an operator who knew precisely what to match for had nowhere to put it.
第三に、そして最も根本的な理由として、この攻撃には一致させるべきペイロードの形状が存在しないことです。 The chain takes two requests. The first has to push PHP into exhausting its memory limit, which makes the engine abandon a request through a path that skips cleanup and leaves some global state behind. The second request is ordinary, and it is the one that reaches a stale pointer and turns into code execution.
The first request is defined by how much memory it consumes, not by any sequence of bytes, and a large upload, a huge JSON body, a deep array and a long string in a regular expression all qualify. The second carries no malicious bytes at all. An IPS decides per packet and per flow. It has no model of a worker process carrying contaminated state from one request into the next, which is precisely where this bug lives.
これはまた、当時普及していた回避策の限界も示しています。その回避策とは、PHP 設定で session.upload_progress をオフにすることでした。確かに2つ目の CVE に到達するための文書化された1つの方法を取り除くことができ、どうしてもパッチを適用できないマシンにおいては、何もしないよりはマシです。しかし、これは根本的な修正ではありません。メモリ枯渇はその1つの機能経由だけで到達できるものではなく、この設定は CVE-2026-109618 にはまったく影響しません。当社ではこれを正確に1台のホストでの場当たり的な応急処置として使用し、解決策ではなく猶予期間として扱いました。パッチ適用の詳細な経緯は、当社の PHP2Shell write-up.
設計上のフェイルオープン、そしてメールが被害を受けた日 #
Threat Prevention を信頼できる制御機構として扱う前に、知っておくべきプロパティがもう1つあります。推奨されるデフォルトはネットワークの安定性を優先モードであり、インターフェイスにはその意味が遠曲表現なしに明記されています。トラフィックが処理能力を超えた場合、保留中のパケットはフィルタリングなしでバイパスされます。もう1つの選択肢であるセキュリティを優先モードでは、代わりにパケットをドロップし、問題が解決されるまで接続が不安定になることを警告します。
これは家庭用ルーターとしては賢明なデフォルトです。しかし、フィルタリングしたいフラッド攻撃そのものが処理能力を超える原因となるため、Threat Prevention が最も強力であってほしいまさにその瞬間に最も弱くなることを意味します。
当社にはもう1つの失敗モードの記録もあります。2026年8月2日、何者かが Linux に対しては全く機能しない Windows PHP-CGI の脆弱性を突くエクスプロイトで、当社のリバースプロキシを 116 回攻撃しました。Threat Prevention は自身の状態を固定化してしまうほど多くのパケットをドロップし、防衛していたはずの自マシンからのアウトバウンドトラフィックまでも拒否し始めました。当社のメールキューは停止し、その症状はまさに DNS エラーのように見えました。ルーターを再起動することで解決しました。プロキシには何も届かなかったため、プロキシのアクセスログには何も表示されませんでした。構造的に成功するはずのない攻撃が、それを阻止するはずだったものを介して、結果的に当社の障害を引き起こしたのです。
そのリストの有効化カウントに目を通してみてください。Web Application Attack では 6,010 ルール中 5,928 ルールがアクティブになっており、関心のあるクラス全体で同様の割合を示しています。クラスをオンにしても、その中のすべてのルールがオンになるわけではなく、インターフェイスには残りのどのルールが不足しているかを確認する方法が提供されていません。
前面にプロキシを配置し、オリジンをそこにロックする #
NASからウェブサイトを配信する場合、ルーターでは不可能な役割を果たすコントロールがリバースプロキシWAFです。当社ではCloudflareを使用していますが、その理由はブランドではなく配置位置にあります。TLSはエッジで終了するため、判断が下される瞬間にリクエスト全体を読み取ることができます。メソッド、パス、クエリ、ヘッダー、クッキー、ボディのすべてがルールで利用可能です。
そのため、PHP2Shellの保護はルーターではなくそちらに適用されました。CVEが公開された際、マネージドルールセットは2日以内にこのペアに対して7つのルールを追加し、当社が自社のコンテナの再構築を終える前に、運用している4つすべてのゾーンで有効化されました。Threat Preventionのフィードには同等のルールが一切登場せず、5日経った時点でもインストール可能なパブリックのSnortやEmerging Threatsのルールは存在しません。
プロバイダーの選択以上に重要な注意事項が1つあります。前面のプロキシは、それを迂回できない場合にのみ効果を発揮します。オリジンアドレスがパブリックインターネットに直接応答する場合、それを発見した人は設定したすべてのエッジルールをスキップできてしまいます。オリジンのポート443をプロキシのネットワーク範囲に制限し、その範囲をハードコーディングするのではなくプロバイダーのエンドポイントから取得し、アドレスから直接サイトにリクエストを送信して制限が機能しているか検証してください。当社のより広範な構成、およびこの層の後ろにある4つの層については、以下で説明されています。 the five layers we run.
Threat Preventionの制限事項とセキュリティ上の注意点 #
Threat Preventionはルーター上に外部ストレージを必要とし、すべてのモデルで利用できるわけではないため、導入を計画する前にご使用のハードウェアのサポート状況をご確認ください。また、このエンジンはルーターで最も負荷のかかる処理であり、コンシューマー向け製品ではスループットのボトルネックに最もなりやすいコンポーネントです。マーケティング上の数値を鵜呑みにせず、導入前後で測定を行ってください。
概要画面のすべての数値は、阻止された攻撃の回数ではなく、シグネチャの一致回数として扱ってください。この2つは双方の意味で異なります。成果を上げることのないスキャナーに対するレピュテーションのヒットは合計を増大させ、ログが静かな1週間であっても、エンジンが読み取れないHTTPSトラフィックについては何も証明しません。
Threat Preventionでは、重要度と同じくらいステータスが重要です。「高リスクパケットを自動的にドロップ」は高ランクの範囲にのみ作用するため、中程度の重要度のエントリーは記録されて転送されます。「警告」と表示されているインターフェースは、パケットが配信されたことを伝えています。
シグネチャフィードはサプライチェーンです。ET Openはスケジュールに従って更新され、商用ルールセットより遅れて提供されるため、公開から数日経った脆弱性に対しても何も配信されないことがあります。データベースが最新であると報告するダッシュボードは、それがフィードと一致していることを報告しているのであり、現在悪用されている内容をフィードがカバーしていることを報告しているわけではありません。
これらはどれもパッチ適用に代わるものではありません。ここで取り上げた各レイヤーは、脆弱性を実際に修正する作業（影響を受けるソフトウェアの更新）までの時間を稼ぐものに過ぎません。PHP2Shellの場合、それは新しいPHPパッケージと再構築されたコンテナを意味し、それに代わるネットワーク制御は存在しませんでした。
最後に、セキュリティ勧告を読んだ後にすべてのクラスを有効にしたくなる衝動を抑えてください。「Misc activity（その他のアクティビティ）」のようなクラスには価値の低いルールが何千個も含まれており、そのほとんどがノイズを発生させ、役立つクラスが必要とする処理能力を消費します。無視することを覚えてしまうような騒がしいイベントリストよりも、実際に目を通す静かで調整されたイベントリストの方がはるかに優れています。
よくある質問 #
Threat Preventionは私のNASでホストされているWebサイトを保護しますか？ #
ほとんど保護しません。また名前から連想されるような方法ではありません。WebサイトはHTTPS経由で提供され、Threat PreventionはTLSインターセプトを行わないため、ルーターから見える範囲ではリクエストの内容は不透明（暗号化されたまま）です。一般的な構成では、リクエストはリバースプロキシがTLSを終端した後に初めて読み取り可能になります。そのホップは通常同じサブネット上にあるため、ルーティングではなくスイッチングされ、ルーターを通過することはありません。WebサイトにはリバースプロキシWAFを使用し、Threat Preventionはが得意とする用途に利用してください。
Which option should I switch on to stop a specific CVE? #
Usually none, because the answer depends on whether the vendor shipped a signature for it at all. Open Self-Defined Policy and you will find you can change the action on an existing signature but cannot add one of your own. If no rule exists in the feed, there is nothing to enable, and for a vulnerability a few days old that is the normal case.
Why does my event list only name one or two devices? #
Because those are the devices receiving traffic the engine can actually read. On our network it is consistently the mail server, which answers cleartext SMTP on port 25. A web host behind a reverse proxy produces few entries not because it is attacked less, but because its traffic is encrypted at every point the router inspects.
Threat PreventionはLAN上のデバイス間のトラフィックを検査しますか？ #
No. Two devices in the same subnet reach each other through a switch, and the router is not in that path, so the packets are never offered to the inspection engine. The Monitored Interfaces table in Settings shows the real scope, and no option there extends it to same-subnet traffic.
Threat Preventionを有効のままにしておいても安全ですか？ #
Yes, with one caveat worth knowing. The recommended default passes traffic through unfiltered when the engine is saturated, which keeps your line up at the cost of inspection. The opposite mode drops that traffic instead. We have also had the engine wedge under a flood of harmless exploit attempts and start refusing a server’s outbound traffic, which cost us a mail outage, so include the router in your list of suspects when a machine goes quiet.
Threat PreventionはPHP2Shellに対して少しは役に立ちましたか？ #
No, and three separate reasons each would have been enough on their own. The traffic was encrypted everywhere the router looks, no Snort or Emerging Threats signature was published for either CVE, and the exploit has no payload shape to match because the first request is defined by the memory it consumes and the second looks completely ordinary. The fix was new PHP packages, with a reverse-proxy WAF covering the gap in the meantime.
Is disabling session.upload_progress enough on an unpatchable host? #
It helps and it is not enough. Switching it off removes one documented route to CVE-2026-109619, which is worth doing on a host you truly cannot update, but memory exhaustion is reachable by other means and the setting does nothing for CVE-2026-109618. Treat it as borrowed time and plan the package update.
What should I buy or configure first for a NAS-hosted site? #
サイトの前にマネージドルールセットを備えたリバースプロキシを配置し、ポート443がそのプロキシネットワークにのみ応答するようにオリジンを制限します。これら2つのステップを組み合わせることで、検査ポイントがリクエストを読み取れる場所に移動し、それを無効化してしまうバイパスが排除されます。その後も、アウトバウンドのコマンド＆コントロール（C2）や平文サービスなど、実際に効果を発揮する場面のためにThreat Preventionを有効にしておきます。
参考資料とビデオチュートリアル #
上記で述べたすべての一次情報源と、時間を割く価値のある3つのウォークスルー。
- Synologyナレッジセンター：Threat Prevention covers requirements, modes and model support.
- Synology-SA-26:14 lists the fixed PHP package versions for DSM, including the 7.4 build.
- Synology Statement on PHP2Shell names the affected packages and the one that needs a manual update.
- Cloudflare WAF managed rules explains how managed rulesets are versioned and deployed.
- CloudflareのIPアドレス範囲 is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.