Posted inセキュリティ

ステルス化：OpenZitiを使ってLinuxサーバーの全公開ポートを閉鎖した方法

Security tutorial - IT technology blog
Security tutorial - IT technology blog

公開ポートが抱える問題

以前、私のSSHログは悲惨な状態でした。毎朝、一度も訪れたことのない地域のボットネットによる何百ものログイン失敗の記録をスクロールしていました。標準的なルーチンは、ポートを開け、Nginxを設定し、Fail2Banが悪意のあるアクターを捕まえてくれるよう祈ることでした。OpenZitiを導入して半年、それらのログようやく静かになりました。半年間ファイアウォールルールに触れていませんが、サービスへのアクセス性は以前よりも向上しています。

従来のセキュリティは「城と堀」モデルに依存しています。厚い壁（ファイアウォール）を築きますが、443番や22番ポートのために門を開けたままにします。問題は単純です。自分に対してポートが開いているなら、誰に対しても開いているということです。OpenZitiはこの常識を覆します。パブリックIPで一切リスン（待機）しない「ダーク（不可視）」なサービスを作成します。代わりに、サービスは安全なファブリックへ自ら接続しに行きます。ShodanやNmapでIPをスキャンしても、そこにはデジタルのレンガの壁しか見えません。

手法の比較：従来のVPN vs. OpenZiti

移行前はWireGuardを利用していました。高速ですが、トンネルの片側がパブリックに公開された到達可能なUDPポートを持っている必要があります。そのポートが見つかれば、依然としてDDoS攻撃の標的になります。OpenZitiはその「リスン」の要件を完全に排除します。

機能 従来のVPN (WireGuard) OpenZiti (ゼロトラスト)
インバウンドポート 必須 (UDP/TCP) ゼロ (アウトバウンドのみ)
アクセス制御 ネットワーク全体 (IPベース) きめ細やか (アイデンティティベース)
攻撃対象領域 削減 排除 (不可視)
リソース使用量 非常に低い 低い (タネラー用に約50MBのRAM)

本番環境で半年運用して得た教訓

メリット

  • ログスパムの解消: 認証ログがようやく読めるようになりました。パブリックに公開された22番ポートが存在しないため、ブルートフォース攻撃が100%減少しました。
  • 真の最小権限: サーバー上の他のものには一切触れさせず、特定のPostgreSQLインスタンス（ポート5432）のみへのアクセス権を外部の請負業者に与えることができます。
  • ネットワークの柔軟性: 自宅の光回線でも、カフェの不安定なWi-Fiでも、ノートPCは同じ方法で接続されます。接続は一時的なIPアドレスではなく、暗号化されたアイデンティティに紐付けられています。

課題

  • 考え方の転換: IPアドレスで考えるのをやめ、サービスとアイデンティティで考える必要があります。反射的にiptablesを操作しようとする癖が抜けるのに約4日かかりました。
  • PKI管理: 証明書とキーの管理がシステムのバックボーンです。コントローラーのルートCAを紛失すると、再構築に長い午後を費やすことになります。

推奨されるセットアップ構成

信頼性の高い「ステルス」ネットワークのために、3層のアプローチを提案します。

  1. コントローラー (Controller): ネットワークの管制塔として機能します。アイデンティティを管理し、ポリシーを適用します。私は月額5ドルのVPSで運用しています。
  2. エッジルーター (Edge Router): ファブリックへの入り口です。小規模な構成では、コントローラーと同じVPSにホストできます。
  3. タネラー (Tunneler): サーバーとクライアントデバイスで動作する軽量エージェント（ziti-edge-tunnel）です。

Zitiコントローラーをプロビジョニングする際、私は toolcraft.app/ja/tools/security/password-generator のパスワード生成ツールを使用して、高エントロピーな管理キーを作成しました。ブラウザ内でローカルに文字列を生成するため、ネットワークへの露出リスクを冒さずに、データベースや管理者アカウントに必要な複雑な認証情報を安全に処理できます。

実装：ステルスネットワークの構築

「Express Install（エクスプレスインストール）」メソッドを使用します。これはUbuntu 22.04または24.04 LTSユーザーにとって最も簡単な道です。

ステップ 1: OpenZiti CLIのインストール

まず管理ツールを入手します。コントローラーにするサーバーで以下を実行してください。

curl -sS https://get.openziti.io/install.sh | sudo bash
export PATH=$PATH:$HOME/.ziti/bin

ステップ 2: ファブリックの起動

クイックスタートスクリプトは、面倒な証明書生成やルーティング設定を自動化してくれます。大幅な時間の節約になります。

# サーバーのパブリックDNSまたはIPを使用
export ZITI_CTRL_ADVERTISED_ADDRESS=ziti.yourdomain.com
source /dev/stdin <<< "$(curl -sS https://get.openziti.io/quickstart/express-install.sh)"

スクリプトが出力する管理者認証情報を保存してください。後でネットワークを管理するために必要になります。このコマンドにより、コントローラーとエッジルーターの両方が自動的に起動します。

ステップ 3: アイデンティティの作成

次に、2つのデジタルパスポートが必要です。1つはアプリケーションサーバー用、もう1つはノートPC用です。

# コントローラーで認証
ziti edge login $ZITI_CTRL_ADVERTISED_ADDRESS:1280 -u $ZITI_USER -p $ZITI_PWD

# アイデンティティを作成
ziti edge create identity device app-server-node -o app-server.jwt
ziti edge create identity user my-laptop -o laptop.jwt

.jwt ファイルは使い捨ての登録トークンです。app-server.jwt をサーバーに、laptop.jwt をワークステーションに安全に移動してください。

ステップ 4: アプリサーバーの隠蔽

保護したいサーバーにタネラーをインストールします。このエージェントはファブリックへのアウトバウンド専用接続を作成します。インバウンドのファイアウォールルールは不要です。

sudo apt update && sudo apt install ziti-edge-tunnel

# デバイスを登録（エンロール）
sudo ziti-edge-tunnel enroll --jwt app-server.jwt --identity /var/lib/ziti/app-server.json

ステップ 5: サービスの定義

ここで接続の紐付けを行います。OpenZitiに対して、サービスが「app-server-node」上に存在する（ローカルのポート8080）こと、そしてノートPCからは internal.dashboard.ziti として見せたいことを伝えます。

# サービスエントリを作成
ziti edge create service my-private-app

# アプリの場所を定義 (Bind)
ziti edge create config app-host.v1 host.v1 '{"protocol":"tcp", "address":"localhost", "port":8080}'

# クライアントのアクセス方法を定義 (Intercept)
ziti edge create config app-client.v1 intercept.v1 '{"protocols":["tcp"], "addresses":["internal.dashboard.ziti"], "portRanges":[{"low":80, "high":80}]}'

# アクセスポリシーを適用
ziti edge create service-policy app-bind Bind --identity-roles "#app-server-node" --service-roles "#my-private-app"
ziti edge create service-policy app-dial Dial --identity-roles "#my-laptop" --service-roles "#my-private-app"

ステルス接続のテスト

ノートPCに OpenZiti Desktop Edge をインストールし、laptop.jwt をインポートします。次に、ブラウザを開いて http://internal.dashboard.ziti にアクセスしてください。

まるで魔法のように感じますが、これはスマートなルーティングによるものです。サーバーのファイアウォールは依然としてすべてのインバウンド接続をブロックしています。サーバーのパブリックIPをスキャンしようとしても、サーバーがオンラインですらないように見えます。それなのに、ブラウザは即座にダッシュボードを読み込みます。

OpenZitiへの切り替えは、私のセキュリティ体制を根本から変えました。サーバーへの「表玄関」を取り払うことで、自動化された攻撃のカテゴリーそのものを排除できました。基本的なSSHトンネルよりも手間はかかりますが、15分のセットアップで得られる安心感にはそれだけの価値があります。

Share:
Tags: