fn-knock を開発した理由
NAS を購入する人の多くは、写真やファイル、自分のサービスを自分の手元に置いておきたいと考えています。セットアップが終わると、すぐに 1 つの疑問に直面します。外出先から自宅の NAS へアクセスするには、どうすればよいのでしょうか。
最も直接的な方法は、ポートフォワーディングです。写真アプリ用に 1 つ、ダウンローダー用に 1 つ、管理画面用にもう 1 つポートを開けば、確かに便利です。しかし、これらのポートをインターネットへ公開した瞬間、利用するのは自分や家族だけではなくなります。インターネット上のアドレスを 24 時間スキャンし続けるスクリプトもアクセスしてきます。こちらに見えているのは自宅のサービスでも、相手から見れば繰り返し試せる入口の集まりです。
私たちが fn-knock を開発したのは、インターネット経由のアクセスをもっとシンプルにしたかったからです。サービスは今までどおり使いつつ、入口は fn-knock が一元的に引き受けます。アクセスする人は最初にログインし、権限があると確認されてから、ゲートウェイがリクエストを NAS へ転送します。
サービスの前に、もう 1 つ扉を設ける理由
2026 年初頭、飛牛 fnOS で重大なセキュリティインシデントが発生しました。飛牛チームは、その後公開したインシデントの説明で、権限を越えたアクセス、パストラバーサル、認証バイパスの 3 件の脆弱性を発見して修正したと報告しています。攻撃手法の一部が公開されると、まだ更新していないデバイスに対する大規模な探索と攻撃が始まりました。
奇安信 XLab による悪意あるサンプルの分析では、感染したデバイスの一部が Netdragon ボットネットへ組み込まれ、DDoS 攻撃やリモートコマンドの実行に利用されていたことが示されています。マルウェアはファイアウォールルールや hosts ファイルも書き換え、デバイスによるアップデートの取得を妨害します。
このインシデントから得られる現実的な教訓があります。ログイン画面や多要素認証が守れるのは、正常なログインフローだけです。脆弱性がログインより前の処理に存在する場合や、攻撃者が元の認証を回避できる場合、ログイン要素をいくつ追加しても、そのリクエストは止められません。
これは飛牛だけの問題ではありません。NAS OS、サードパーティーアプリ、Docker コンテナはいずれもコードが更新され、新しい脆弱性が見つかる可能性があります。迅速なアップデートはもちろん必要ですが、「最新版だから大丈夫」と考えて、すべてをそこへ委ねることはできません。公開する入口が 1 つ減れば、攻撃者がサービスへ直接触れられる場所も 1 つ減ります。
Basic Auth を 1 層追加すれば十分か
Lucky や Nginx などのツールでは、ページへ簡単に Basic Auth を追加できます。一時的にページを保護したり、無差別なスキャンの一部を防いだりする用途には便利です。
しかし Basic Auth で使用するのは、通常、長期間使い続ける 1 組のユーザー名とパスワードです。ネットワーク上で送信される認証情報は Base64 でエンコードされるだけで、暗号化はされません。そのため HTTPS との併用が必須であり、MDN も明確に注意を促しています。認証情報が漏えいすれば、入手した人はその後も使い続けられます。
実際の利用では、互換性の問題もあります。ブラウザー、WebDAV、メディアプレーヤー、モバイルアプリによって認証ヘッダーの扱いが完全には一致せず、ログインダイアログが繰り返し表示されたり、特定のクライアントがまったく使えなかったりします。最終的には、パスやクライアントごとに例外を追加し続けることになります。
Basic Auth は補助的な保護として使い続けられますが、NAS をインターネットへ公開するときの唯一の認証情報にはしたくありません。fn-knock は独立したログイン認証情報とセッションを使用し、TOTP、パスキー、外部アカウントを追加できます。セッションの確認や取り消し、1 組の認証情報からアクセスできるサービス範囲の制限にも対応しています。
WAF があっても fn-knock は必要か
雷池（SafeLine）のような WAF は、公開 Web サイトの保護に適しています。Web サイトはもともとすべての訪問者を受け入れる必要があり、WAF はリクエストから SQL インジェクション、XSS、パストラバーサル、悪意あるボットを検出します。
一方、NAS の管理画面、ダウンローダー、個人用フォトアルバムは、通常、知らない人を受け入れる必要がありません。すべてのリクエストを一度サービスへ近づけてから攻撃らしいか判断するより、ログインしていない人がサービスへ到達できないようにする方が望ましいと考えています。
両方を併用することもできます。fn-knock 自体も WAF、スキャナーのブロック、ブラックリスト、レート制限を提供します。ログインは訪問者に権限があるかを確認し、WAF はゲートウェイへ入った後の異常なリクエストを引き続き検査します。それぞれの役割が異なります。
Tailscale や ZeroTier を使えばよいのでは
Tailscale、ZeroTier、EasyTier、WireGuard は、いずれも成熟した仮想ネットワークのソリューションです。利用する端末がある程度固定され、すべての端末へクライアントをインストールできるなら、より徹底したネットワーク分離が可能です。
ただし、スマートフォン、タブレット、パソコンをそれぞれ先に仮想ネットワークへ参加させる必要があります。一時的に別の端末を使う場合や、家族へ 1 つのサービスを共有する場合にも、クライアントの設定が必要です。端末ですでに別の VPN やプロキシを使用していると、ルーティング、DNS、OS の VPN 権限が競合することもあります。
fn-knock が想定する使い方は異なります。ブラウザーを開いて自分のドメインを入力し、ログインしてすぐに利用します。各端末へ仮想ネットワークのクライアントをインストールする必要はなく、端末全体のネットワーク出口を引き受けることもありません。
どちらが常に優れているということではありません。インターネットへ入口を一切公開したくなければ、仮想ネットワークを選べます。家族も写真やメディアライブラリなどの Web サービスを手軽に使えるようにしたければ、fn-knock をインターネット側の入口に配置できます。
fn-knock が行うこと
Web サービスを例にすると、サービスごとにサブドメインを割り当てられます。
auth.example.com ログイン用入口
nas.example.com NAS
media.example.com メディアライブラリ
download.example.com ダウンローダーこれらのドメインは、すべて最初に fn-knock ゲートウェイへ到達します。未ログインの場合、ゲートウェイは訪問者を認証ページへ案内します。ログインに成功すると、対応する内部ネットワークのサービスへリクエストを転送します。外部からは一元化された入口を 1 つ用意するだけで、アプリケーションごとの元のポートを公開する必要はありません。
自宅にグローバル IP がない場合は、FRP や Cloudflared でNAT 越えを構成できます。ログインとサービスマッピングの使い方は変わりません。TCP／UDP の元のポートをどうしても残す必要がある一部のサービスでは、ホストのファイアウォール制御に対応したプラットフォームで直接接続による許可を使用できます。
1 回のアクセスは、おおむね次の処理を通過します。
- ゲートウェイがスキャン動作、ブラックリストとホワイトリスト、送信元を確認します。
- ログインが必要なサービスでは、現在のセッションを確認します。
- 利用者が TOTP、パスキー、ユーザー名とパスワード、外部アカウントのいずれかでログインします。
- ゲートウェイが、この認証情報に対象サービスへのアクセス権限があるかを確認します。
- WAF などの検査を通過したリクエストを、内部ネットワークのアプリケーションへ転送します。
- アクセス結果をリクエストログへ記録し、異常があれば通知できます。
マッピングでログイン保護が有効になっている場合、有効なセッションがなければ、リクエストはアップストリームへ渡されません。この保護を機能させるには、インターネットからのトラフィックがすべて fn-knock を経由し、元のサービスポートが個別に公開されたままになっていないことが必要です。
リクエストの経路
訪問者
↓
DNS / ルーター / CDN / トンネル
↓
fn-knock ゲートウェイ
├─ ログイン、セッション、ホワイトリスト、WAF、リクエストログ
└─ ドメイン、パス、プロトコルに基づいて内部サービスを選択
↓
NAS、ファイルサービス、メディアサービス、その他のアプリケーション管理画面は管理者が fn-knock を設定するためのものであり、一般の訪問者がサービスを利用する入口ではありません。実際の動作は、次の 3 つの要素によって構成されます。
| 構成要素 | 担当する処理 |
|---|---|
| Rust サービス | 管理画面、ログイン認証、セキュリティポリシー、証明書、DDNS、トンネル、運用タスク |
| Go ゲートウェイ | 外部リクエストの受信、ログイン確認、サービスルーティング、リバースプロキシ |
| SQLite | 設定と実行データの保存。Redis の追加インストールは不要 |
管理画面はインストールパッケージとイメージへ組み込まれており、通常の実行に Node.js をインストールする必要はありません。管理ポート、ゲートウェイポート、待受範囲はプラットフォームによって異なります。デプロイ時はポート、入口、アクセス経路を確認してください。
fn-knock で保護できるもの、できないもの
fn-knock が保護できるのは、ゲートウェイを通過するリクエストだけです。ルーターが元の管理ポートを転送したままの場合や、クラウドプラットフォームに別のオリジン経路が残っている場合、攻撃者は fn-knock を迂回できます。
インストール後も、次の対策が必要です。
- NAS OS、Docker イメージ、アプリケーションを速やかに更新する。
- 使用しなくなった公開ポートやオリジンアドレスを閉じる。
- ルーター、CDN、リバースプロキシから訪問者の IP が正しく伝わるよう設定する。
- アカウントごとに必要なサービスだけを割り当て、高権限の認証情報を共有しない。
- 設定、証明書、重要なデータを定期的にバックアップする。
- モバイル回線を使い、インターネットからのログインフロー全体を一度テストする。
fn-knock は、自宅で直接利用しやすいよう、ローカルネットワーク、ループバック、プライベートネットワークの一部をデフォルトで許可します。そのため、自宅の LAN からページを開けても、インターネットからのログインが正しく設定できている証拠にはなりません。必ず実際の外部ネットワークへ切り替えてテストしてください。
扉を通ってからアクセスする
セキュリティツールには、よくある 2 つの難しさがあります。簡単な機能だけでは足りず、専門的なツールは設定が難しいことです。多くの利用者は、スマートフォンから自宅の写真やファイルを安全に開きたいだけで、リバースプロキシ、ファイアウォール、証明書、さまざまな認証プロトコルを一から学びたいわけではありません。
fn-knock は、これらを 1 か所へまとめ、スマートフォンからでもインストール、ログイン、サービスマッピング、基本的な保護を完了できることを目指しています。サービスに脆弱性が生まれる可能性はなくなりませんが、ログインしていない人が最初からサービスへ触れられなければ、リスクの大きな部分を減らせます。
fn-knock をインストールすれば絶対に安全だとは約束しませんし、それを理由に OS の更新をやめることも推奨しません。この製品が行うのは、ただ 1 つの現実的なことです。最初にアクセスする人を確認し、その後で扉を開くかどうかを決めます。
まずは 1 つのサービスから試せます。