Ubuntu 24.04にWebminを導入して安全に設定する方法

構築するもの

Webmin は、Linux サーバー全体の Web インターフェースを提供する Web コントロールパネルです。ブラウザーから、ユーザー、パッケージ、cron ジョブ、ファイアウォール、Apache、BIND、ディスク、その他多数のモジュールを管理できます。HTTPS の port 10000 でアクセスします。インストール自体は 3 つのコマンドで実行でき、約 1 分で完了します。

このガイドの大半を後半に割く理由は、Webmin が root としてログインし、root と同じ操作を実行できるためです。無制限に公開された Webmin や認証のない Webmin は、「管理すべきリスク」ではありません。ログインページを備えたサーバー全体の侵害です。そのため、10 分でインストールした後、残りの時間を使って、自分だけがアクセスできることを確認します。

前提条件と、正直な注意点

root または sudo ユーザーでアクセスできる、Ubuntu 24.04 の新しい KVM VPS を用意します。Webmin は Perl 製で軽量です。RAM は 1 GB あれば十分で、アイドル時の使用量は 0.25 GB を大きく下回ります。Webmin は内蔵 Web サーバー (miniserv.pl) で TCP 10000 番ポートを待ち受けます。Apache や nginx は使用しないため、事前に別のソフトウェアをインストールする必要はありません。

開始前に、2 つの点を決めます。1 つ目は、ログインに使用するアカウントです。Webmin は PAM を通じて Unix アカウントを認証します。そのため、root または sudo グループに所属するユーザーとして、そのアカウントの Unix パスワード を使用してログインします。クラウドイメージは通常、デフォルトユーザーが鍵認証のみで、パスワードが設定されていません。Webmin はパスワードのないアカウントではログインできません。先に sudo passwd youruser でパスワードを設定してください。設定しない場合、入力内容にかかわらずログインに失敗します。

2 つ目は、重要な注意点です。ポート 10000 番をインターネットに単純に公開したままにしないでください。Webmin に SSH トンネル経由で接続する方法（推奨、外部公開なし）と、自分の IP アドレスからの接続だけを許可する方法のどちらかを、ここで決めます。この判断が以下のすべての手順に影響するため、ファイアウォールを変更する前に両方の方法を確認してください。

公式リポジトリから Webmin をインストールする

Webmin は署名付きの apt リポジトリを公開しています。セットアップスクリプトはリポジトリと GPG 署名キーを追加します。そのため、今後の apt upgrade 実行時に、他のパッケージと同じように Webmin が取得されます。自動更新されないダウンロード済みの .deb に頼るのではなく、認証済みの更新を受けられます。

curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh

スクリプトは実行する内容を表示し、Setup Webmin stable repository? (y/N) を求めます。y と入力してください。完了したら、パッケージをインストールします。--install-recommends フラグを指定すると、共通で使用する Perl と SSL モジュールの依存関係も取得できます。これにより、後で個別のモジュールがライブラリ不足のエラーで失敗することを防げます。

sudo apt-get install --install-recommends webmin

Webmin では、過去にこのスクリプトの名前が変更されています。古いガイドでは setup-repos.sh が使われている場合があります。そのため、raw URL が 404 を返す場合は、名前を固定せず、webmin.com/download から現在のワンライナーを直接取得してください。正しくインストールできると、Webmin install complete. You can now login to https://your-host:10000/ as root のような行で終了します。サービスは有効化され、実行中になります。設定は /etc/webmin 以下に保存されます。リクエストは /var/webmin/miniserv.log に記録され、ログイン失敗は syslog に記録されます。Ubuntu 24.04 では、systemd journal にも記録されます。

ブラウザーを開く前に、実際に起動して待ち受けていることを確認します。

sudo systemctl status webmin --no-pager
sudo ss -tlnp | grep 10000

active (running) の状態であり、miniserv.pl が 0.0.0.0:10000 にバインドされている行が表示されることを確認します。下記のトンネル経由に切り替えると、そのアドレスは 127.0.0.1:10000 に変わります。10000 について ss に何も表示されない場合、Webmin は起動していません。先に journalctl -u webmin -n 50 を確認してください。

初回ログインと証明書の警告

ブラウザーで https://YOUR_SERVER_IP:10000 を開きます。新規インストール直後は、2 つのことが起こります。

ufw が有効な場合、ページはまったく読み込まれません。Ubuntu のサーバーイメージでは ufw は無効になっていますが、多くのプロバイダーはあらかじめ有効にしています。この問題については、後述の障害例で説明します。ポートが開いている場合、ブラウザーにはページ全体を覆うブロック画面が表示されます。Chrome では 「この接続ではプライバシーが保護されません」 とコード NET::ERR_CERT_AUTHORITY_INVALID、Firefox では SEC_ERROR_UNKNOWN_ISSUER / 「警告: セキュリティ上の潜在的なリスクがあります」 と表示されます。これは想定された動作であり、侵入されたわけではありません。Webmin はインストール時に自己署名証明書を生成します（/etc/webmin/miniserv.pem）。この証明書を認証局が保証していないため、ブラウザーは暗黙的に信頼することを拒否します。接続自体は暗号化されています。認証局による保証がないだけです。ひとまず警告を進めます（Advanced、次に Proceed）。この証明書は、後ほど適切なものに置き換えます。

root または sudo ユーザーとその Unix パスワードでログインすると、System Information ダッシュボードが表示されます。ここでよくある入力ミスは、https:// の代わりに http:// と入力することです。miniserv はそのポートでプレーン HTTP に応答し、「この Web サーバーは SSL モードで実行されています。URL https://... を試してください」 と正確に表示します。対処方法は、アドレスバーの http を https に変更するだけです。

セキュリティ上の判断: Webmin にはどのように接続しますか？

ここが重要です。root と同等の権限を持つパネルをインターネットに直接公開し、世界中のスキャナーからのログイン試行に応答させるべきではありません。十分に妥当な選択肢は2つあります。推奨順に説明します。セルフホストする管理インターフェースでは、必ずこの問題に行き着きます。そのため、Vaultwarden が安全かどうかは暗号化ではなく、管理エンドポイントとバックアップファイルによって決まります。

Option B の SSH トンネルのほうが優れています。何も公開しないためです。アドレスが固定されている場合は、Option A の IP allowlist も許容できます。どちらも実施しないことが、このガイド全体で防ごうとしているまさにその誤りです。どちらの方法よりもプライベートネットワーク経由で Webmin に接続したい場合は、サーバーを セルフホストの WireGuard VPN の背後に置き、Webmin をパブリックアドレスではなくトンネルのアドレスにバインドしてください。

オプション A: Webmin へのアクセスを自分の IP に制限する

パネルで Webmin、次に Webmin Configuration、次に IP Access Control を開きます。「一覧にあるアドレスからのみ許可」を選択し、ノートパソコンで curl ifconfig.me を実行して確認できるパブリック IP を入力します。保存します。Webmin は /etc/webmin/miniserv.conf の allow= 行にこの設定を書き込み、自動的に再起動します。

注意点は、自宅の IP が動的で変更された場合や、アドレスを入力し間違えた場合に、アクセスできなくなることです。ブラウザーには 「<your IP> のアクセスが拒否されました」 と表示され、ログインフォームも表示されません。Webmin の Web インターフェースから復旧する方法はありません。SSH またはプロバイダーの VNC でサーバーコンソールに接続し、次の操作を行います。

sudo nano /etc/webmin/miniserv.conf
# find the line that begins  allow=
# correct your IP, or delete the whole line to allow all again
sudo systemctl restart webmin

allow= 行を削除すると、すべてのアクセスが許可された状態に戻ります。これは復旧時だけ行い、直後に正しい値を設定してください。

オプション B: localhost にバインドし、SSH 経由でトンネル接続する（推奨）

どの許可リストよりも確実なのは、パブリックインターフェースで待ち受けないことです。miniserv をループバックにのみバインドし、信頼済みの暗号化された SSH トンネル経由で接続します。

/etc/webmin/miniserv.confを編集し、次の行を追加または変更します。

bind=127.0.0.1

sudo systemctl restart webminで再起動します。これで Webmin はインターネットから到達できなくなり、10000 番ポートをスキャンしても何も検出されません。前述の ss の確認結果も、127.0.0.1:10000で待ち受けていることを示します。ラップトップからトンネルを開きます。

ssh -L 10000:localhost:10000 youruser@YOUR_SERVER_IP

このセッションを開いたまま、https://localhost:10000にアクセスします。通信は SSH 内部を通過します。SSH はすでに鍵で認証され、暗号化されているため、ここでは自己署名証明書を安全に受け入れられます。実際の保護は SSH 層が担います。SSH セッションを閉じると、Webmin に接続できなくなります。許可リストも、公開されたサービスも、追加で保護するサービスもありません。

bind=127.0.0.1を設定してトンネルを忘れた場合、リモートアクセスは停止します。これは障害ではなく、この機能が正常に動作している状態です。オプション A と同じ方法で復旧できます。コンソールから bind の行を削除するか、bind=0.0.0.0に設定してから再起動します。これは、tmux で Claude Code を実行しているリモート開発ボックスに接続するときにも使う、同じトンネル接続の方法です。1 つの SSH セッションですべてを非公開にし、パブリックインターフェースでは何も待ち受けさせません。

自己署名証明書を正式な証明書に置き換える

Option A で Webmin を公開する場合は、正式な Let's Encrypt 証明書を使用してブラウザーの警告をなくします。証明書に使用する名前と、検証時に Let's Encrypt が port 80 へ到達できる方法が必要です。通常、この名前には DNS 名を使用します。たとえば panel.example.com を指定し、サーバーを指す A レコードを設定します。Webmin 2.650（2026 年 6 月 25 日リリース）以降は、Certbot 5.3 以降がインストールされていれば、サーバーの公開 IP アドレスも指定できます。Let's Encrypt が IP 証明書を発行するのは短期有効プロファイルのみです。有効期間は約 6 日なので、Webmin の自動更新間隔を日数で設定してください。Webmin は、IP 証明書に対してこれより長い間隔を受け付けません。

Webmin にはこの機能が組み込まれています。Webmin、次に Webmin Configuration、次に SSL Encryption、次に Let's Encrypt タブの順に開きます。ホスト名または IP アドレスを入力し、検証方法を選択して、リクエストを送信します。Webmin が証明書を取得し、miniserv.conf 内の certfile= 行と keyfile= 行を更新して、自動的に有効期限前に更新します。ページを再読み込みすると、ブラウザーに警告のない鍵アイコンが表示されます。

注意点が 1 つあります。Webmin 自体のサーバーは 10000 番ポートで動作し、80 番ポートでは動作しません。そのため、port 80 で http-01 challenge に応答する仕組みが必要です。方法は 3 つあります。Apache または nginx がすでに port 80 でその名前のサイトを提供している場合は、そのサイトのドキュメントディレクトリを検証先に指定します（IP アドレスの場合は Certbot 5.4 以降が必要です）。port 80 が空いている場合は、Certbot に組み込まれた Web サーバーを選択します。これは Webmin が version 2.110 で追加した standalone mode です。Certbot が port 80 で一時的に独自の Web サーバーを実行するため、Certbot をインストールし、ファイアウォールで port 80 を許可して空けておく必要があります。もう 1 つは DNS validation です。これはホスト名では機能しますが、IP アドレスでは機能しません。Ubuntu 24.04 に付属する certbot package は version 2.9 です。ホスト名の standalone validation には十分ですが、IP 証明書には古すぎます。IP 証明書には、2026 年 10 月時点で version 5.8 だった snap など、現行の Certbot をインストールしてください。これらの方法をどれも使用しない場合、リクエストは validation error で失敗します。仕組み、DNS レコード、port-80 challenge、更新方法は、通常の Web サイト用証明書を発行する場合と同じです。詳しい背景を確認したい場合は、Certbot と nginx を使用した Let's Encrypt TLS 証明書ガイドで、検証の流れと DNS 設定を詳しく説明しています。SSH トンネル方式を使用した場合は、このセクション全体を省略できます。SSH 経由で使用する場合は自己署名証明書で問題ありません。また、panel.example.com 用に発行した正式な証明書を https://localhost:10000 で使用しても、名前が一致しないため警告が表示されます。

2 要素認証を有効にする

root パネルをパスワードだけで保護するのは不十分なため、2 つ目の要素を追加します。Webmin、次に Webmin Configuration、次に Two-Factor Authentication を開きます。Google Authenticator プロバイダーを選択します。これは標準の TOTP であるため、Authy、1Password、その他の認証アプリで使用できます。保存します。Webmin は必要な Perl モジュール（Authen::OATH と QR コード生成機能）をインストールして、この機能を有効にします。この操作だけでは、どのアカウントもまだ保護されません。

次に、各アカウントで使用するデバイスを登録します。2FA を有効にした状態で、Webmin、次に Webmin Users を開き、対象のアカウントを選択して Enable Two-Factor For User を選びます。Webmin に QR コードが表示されるため、認証アプリでスキャンし、生成されたコードを 1 つ入力して確認します。それ以降、ログイン時にはパスワードの後に 6 桁のトークンが求められます。ログアウトする前に登録してください。2FA が必須なのにアカウントでコードを一度もスキャンしていない場合でも、コンソールから要件を解除できますが、先に登録しておく方がはるかに簡単です。

ブルートフォースログインを禁止するために Fail2ban を追加する

制限されたログインエンドポイントでも、失敗を繰り返す接続元は拒否するべきです。Webmin は失敗したログインを syslog に webmin[12345]: Invalid login as root from 10.0.0.9 の形式で記録します。Unix アカウントとして存在しないユーザー名の場合は Non-existent login as ... になります。Ubuntu 24.04 では、標準イメージに /var/log/auth.log がないため、これらの行は systemd journal に記録されます。Fail2ban には、この2種類の行に正確に一致する標準の webmin-auth フィルターが含まれています。以下の jail では backend = systemd 自体を設定するため、カスタム正規表現やログパスは不要です。

/etc/fail2ban/jail.d/webmin.local を作成します。

[webmin-auth]
enabled  = true
port     = 10000
filter   = webmin-auth
backend  = systemd
maxretry = 4
bantime  = 1h

sudo systemctl restart fail2ban で再読み込みし、jail が稼働していることを確認します。

sudo fail2ban-client status webmin-auth

最初は ban カウンターが 0 の状態で jail が表示されます。journal バックエンドでは File list: 行はありません。設定が最後まで機能することを確認するには、別のネットワークから意図的に数回ログインを失敗させます。その後、ステータスコマンドを再実行し、Currently banned が増えることを確認します。増えない場合は、テスト元のアドレスが Fail2ban の ignoreip に含まれていないことを確認してください。また、サーバー上で journalctl SYSLOG_IDENTIFIER=webmin を実行し、Invalid login 行が実際に書き込まれていることを確認します。このサーバーに Fail2ban がまだインストールされていない場合は、Ubuntu 24.04 で SSH 用に Fail2ban を設定するガイドで、インストール手順と、この jail と併用すべき SSH jail を説明しています。

各 Webmin ユーザーが操作できる範囲を制限する

パネルを必要とするすべてのユーザーに、すべての操作に対する root 権限を与える必要はありません。Webmin、次に Webmin Users を開き、追加の Webmin ログインを作成して、それぞれに必要なモジュールだけを許可します。たとえば、バックアップ担当者には cron とファイルシステムのモジュールだけを表示します。ユーザーを編集すると、すべてのモジュールのチェックリストが表示されます。チェックを外すと、そのユーザーのメニューからモジュールが削除され、対応する URL へのアクセスもブロックされます。これは多層防御の一環です。Users モジュールが一覧にない場合、権限の低い Webmin セッションを盗まれても /etc/shadow を書き換えることはできません。

Webmin を最新の状態に保つ

apt リポジトリからインストールしたため、sudo apt update && sudo apt upgrade はシステムの他の更新と同時に Webmin の新しいリリースを取得します。コントロールパネルは攻撃対象になりやすいため、速やかにパッチを適用してください。Webmin は Webmin、Webmin Configuration、Upgrade Webmin の順に選択して自身を更新することもできますが、Ubuntu では apt を使う方法のほうが適しています。他のパッケージ管理対象とバージョンを一貫させられるためです。これは任意の作業ではありません。過去には Webmin の複数の CVE がリモートコード実行の脆弱性でした。「パッチ適用済み」と「侵害済み」を分けたのは、管理者がどれだけ速くアップグレードを実行したかだけでした。

障害のパターンと表示される文字列

「接続はプライベートではありません」 / NET::ERR_CERT_AUTHORITY_INVALID。 最初の読み込み時に表示されます。原因は、インストール時に Webmin が生成した自己署名証明書に、信頼された発行者がないことです。攻撃ではありません。通信経路は暗号化されていますが、証明書による保証がありません。対処方法は、ひとまず警告を進んで表示し、後で正式な Let's Encrypt 証明書を発行することです。SSH トンネル経由で Webmin にアクセスする場合は、証明書を恒久的に受け入れても構いません。

「この Web サーバーは SSL モードで動作しています。URL https://... を試してください」 http://server:10000 と入力しました。miniserv はそのポートで TLS のみを使用しており、そのことをプレーンテキストで通知しています。アドレスバーで http を https に変更してください。

ページがタイムアウトする、ERR_CONNECTION_TIMED_OUT / 「このサイトにアクセスできません」。 リクエストが Webmin に到達していません。Ubuntu では ufw がポート 10000 を破棄していることがよくありますが、決めつける前に確認してください。sudo ufw status を実行します。Status: inactive と表示された場合、ufw は何もブロックしていません（Ubuntu では ufw は無効な状態で提供され、許可ルールを追加しても有効にはなりません）。その場合は、プロバイダーのコントロールパネルにあるファイアウォールなど、さらに上流を確認します。Status: active と表示された場合は、sudo ufw status verbose を実行して、デフォルトの受信ポリシーと、より広い範囲に適用されるルールを確認します。受信トラフィックが拒否され、10000 が一覧にない場合は、sudo ufw allow 10000/tcp で開放できます。ただし、より適切なのは閉じたままにして、Option B の SSH トンネルを使用することです。違いに注意してください。タイムアウトは、ファイアウォールがパケットを黙って破棄していることを意味します。一方、ERR_CONNECTION_REFUSED はポートには到達できるものの、Webmin が実行されていないことを意味します。sudo systemctl status webmin を確認してください。

「<your IP> のアクセスが拒否されました。」 Option A で IP Access Control を設定したため、現在のアドレスが許可リストにない可能性があります。動的 IP が変更されたか、入力ミスの可能性もあります。ブラウザーから元に戻す方法はありません。コンソールから対処します。/etc/webmin/miniserv.conf の allow= 行を編集して、内容を修正または削除し、sudo systemctl restart webmin を実行してください。

正しいことが分かっている認証情報で「ログインに失敗しました。もう一度お試しください。」と表示される。 そのアカウントに Unix パスワードがありません。鍵のみを使用するクラウドイメージでは一般的な状態です。Webmin は PAM を通じて Unix パスワードで認証しますが、そのユーザーにはパスワードが設定されていません。サーバーで sudo passwd youruser を実行してからログインしてください。/var/webmin/miniserv.log に Non-existent login as ... と表示される場合は、Unix アカウントではないユーザー名を入力しています。

数台を超えるサーバーでは、各サーバーにコントロールパネルを配置するよりも自動化のほうが適しています。最初の Ansible playbook から始められます。

FAQ

Webmin をパブリックインターネットに公開しても安全ですか？

インターネットに公開された Webmin は、ログイン画面付きの root shell と考えてください。実際にそのものだからです。安全性を確保するには、実際の証明書、二要素認証、Fail2ban、厳格な IP allowlist のいずれか、できれば公開しない構成を組み合わせる必要があります。最もリスクが低い構成は、Webmin を 127.0.0.1 に bind し、SSH tunnel 経由でアクセスする方法です。この場合、port 10000 はオープンなインターネットからの接続を受け付けません。

Webmin の証明書警告を消すにはどうすればよいですか？

Webmin は self-signed certificate を使用するため、警告（NET::ERR_CERT_AUTHORITY_INVALID）が表示されます。Webmin の Webmin Configuration、SSL Encryption、Let's Encrypt から実際の証明書を発行してください。サーバーを指す DNS name を使用するか、Certbot 5.3 以降がインストールされている場合はサーバーの public IP address を使用します。challenge のために port 80 へ到達できる必要があります。既存の web server または Certbot 自身の standalone server が応答します。Webmin へ常に localhost への SSH tunnel 経由でアクセスする場合、警告は無害です。SSH が接続を暗号化して認証するため、self-signed certificate を安全に受け入れられます。

Webmin へのアクセスを自分の IP address だけに制限するにはどうすればよいですか？

Webmin、Webmin Configuration、IP Access Control の順に開き、「Only allow from listed addresses」を選択して、curl ifconfig.me に表示される public IP を入力します。Webmin はこの設定を /etc/webmin/miniserv.conf の allow= 行に保存します。動的な自宅 IP には注意してください。IP が変わると接続できなくなり、サーバーの console から allow= 行を修正する必要があります。そのため、実際の運用では static address または SSH-tunnel 方式のほうが信頼性が高くなります。

正しいパスワードを入力してもログインに失敗するのはなぜですか？

Webmin は PAM を通じて Unix password で認証します。一方、cloud image は通常 key-only で、default account に password が設定されていません。そのため PAM が照合できる情報がなく、ログインは拒否されます。サーバーで sudo passwd youruser を実行して password を設定してから、ログインしてください。/var/webmin/miniserv.log に Non-existent login as ... 行がある場合は、username 自体が実在する Unix account ではありません。

通常の SSH と比べて、Webmin は何に適していますか？

Webmin は、システムを見つけやすく操作しやすくするためのレイヤーです。すべての command を覚えなくても、log file の参照、user と cron の管理、firewall rule の編集、disk と service の状態確認を行えるため、臨時の管理者やスキルが混在するチームに役立ちます。通常の作業では、通常の SSH のほうが高速で script 化しやすく、攻撃対象領域も大幅に小さくなります。多くの管理者は両方を使用します。日常の作業には SSH を使い、必要なときだけ point-and-click 操作を行えるよう、Webmin を localhost に bind して tunnel の背後で動かします。知りたいことが panel と shell の比較ではなく、どの panel を選ぶべきかであれば、まず Cockpit と Webmin の比較を検討してください。2 つは、変更できるシステム範囲と認証方法が異なります。