Ubuntu 24.04にWebminをインストールしてセキュリティを強化する方法

構築内容

Webminは、Linuxサーバー全体をブラウザから操作可能にするWebコントロールパネルです。ユーザー、パッケージ、cronジョブ、firewall、Apache、BIND、ディスクなど、100種類以上のモジュールを管理できます。ポート10000のHTTPS経由でアクセス可能です。インストールは3つのコマンドで完了し、約1分で終わります。

このガイドの後半に多くの時間を割いている理由は、Webminがrootとしてログインし、rootと同等の操作権限を持つためです。認証なしで公開されたWebminは、単なる「管理すべきリスク」ではありません。ログイン画面の向こう側で、サーバーが完全に乗っ取られることを意味します。そのため、10分でインストールを済ませた後、残りの時間を使って自分だけがアクセスできるように設定を徹底してください。

前提条件と重要な警告

root権限またはsudoユーザーを持つ、新規の Ubuntu 24.04 KVM VPSが必要です。WebminはPerlベースで軽量です。1 GBのRAMがあれば十分であり、アイドル時は0.25 GB未満で動作します。WebminはApacheやnginxではなく、内蔵のWeb server (miniserv.pl) を使用してTCP 10000で待機するため、事前に他のソフトウェアをインストールする必要はありません。

開始前に、2つの事項を決定してください。1つ目は、ログインに使用するアカウントです。WebminはPAMを介してUnixアカウントで認証を行います。そのため、root または sudo グループのユーザーとして、そのアカウントの Unix password を使用してログインします。Cloud imageでは、デフォルトユーザーにパスワードが設定されておらず、鍵認証のみとなっていることが一般的です。Webminはパスワードのないアカウントではログインできません。まず sudo passwd youruser でパスワードを設定してください。そうしないと、何を入力してもログインに失敗します。

2つ目は、警告事項です。ポート10000をインターネットに公開したまま放置しないでください。SSH tunnelを使用してWebminにアクセスするか（推奨：外部に公開されません）、あるいは自身の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 repository? (y/N) を求めます。y と回答してください。完了したら、パッケージをインストールします。--install-recommends フラグを使用すると、共通の Perl および SSL モジュール依存関係が取得されるため、後で個別のモジュールでライブラリ不足のエラーが発生するのを防げます。

sudo apt-get install --install-recommends webmin

Webmin は以前このスクリプトの名前を変更しています（古いガイドでは setup-repos.sh と記載されています）。そのため、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 に変わります。もし ss で 10000 ポートに何も表示されない場合は、Webmin が起動していません。先に journalctl -u webmin -n 50 を確認してください。

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

ブラウザで https://YOUR_SERVER_IP:10000 にアクセスしてください。新規構築直後の状態では、2つの事象が発生します。

ufw が有効な場合（Ubuntu の標準イメージでは無効ですが、多くのプロバイダーでは事前に有効化されています）は、ページが全く読み込まれません。これについては、後述のトラブルシューティングで説明します。ポートが開いている場合、ブラウザは画面全体に警告を表示します。Chrome では NET::ERR_CERT_AUTHORITY_INVALID、Firefox では SEC_ERROR_UNKNOWN_ISSUER または "Warning: Potential Security Risk Ahead" と表示されます。これは想定された動作であり、不正アクセスではありません。Webmin はインストール時に自己署名証明書を生成します (/etc/webmin/miniserv.pem)。証明書発行局による認証がないため、ブラウザは信頼できないとして警告を出します。通信自体は暗号化されていますが、認証されていないだけです。一旦は「詳細設定」から「進む」をクリックして進めてください。後ほど、この証明書を適切に更新します。

root または sudo 権限を持つユーザー名と Unix パスワードでログインすると、System Information ダッシュボードが表示されます。よくある間違いとして、https:// と入力すべきところを http:// と入力してしまうことがあります。そのポートで miniserv がプレーンな HTTP を返すと、"This web server is running in SSL mode. Try the URL https://..." と表示されます。アドレスバーの http を https に変更することで解決します。

セキュリティ上の決定：どのように Webmin にアクセスするか

最も重要な部分です。root 権限を持つパネルを、世界中のスキャナーからのログイン試行にさらすために、公開インターネット上に置いてはいけません。推奨される順に、2つの選択肢があります。

Option B の SSH tunnel は、何も公開しないため、より優れた方法です。Option A の IP allowlist は、IP アドレスが固定されている場合に有効です。どちらも行わないことは、このガイドが防ごうとしている典型的なミスです。もし、これらよりもプライベートネットワーク経由でのアクセスを優先する場合は、サーバーを self-hosted WireGuard VPN の背後に配置し、Webmin をパブリック IP ではなく tunnel アドレスに bind してください。

Option A: Webminのアクセスを特定のIPに制限する

コントロールパネルで Webmin > Webmin Configuration > IP Access Control を開きます。"Only allow from listed addresses" を選択し、公開IPアドレスを入力してください。公開IPは、ノートPCで curl ifconfig.me を実行することで確認できます。設定を保存します。Webminは、この設定を /etc/webmin/miniserv.conf 内の allow= 行に書き込み、サービスを再起動します。

注意点：自宅のIPアドレスが動的で変更された場合や、入力ミスをした場合、アクセス不能になります。ブラウザにはログインフォームが表示されず、"Access denied for <your IP>" と表示されます。この状態から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= 行を削除すると、すべてのIPからのアクセスが許可されます。これは復旧時のみ実行し、完了後はすぐに正しい値を再設定してください。

Option B: localhostへのバインドとSSHトンネルの使用 (推奨)

許可リストを作成するよりも、パブリックインターフェースで待機しない設定にする方が安全です。miniservをloopbackのみにバインドするように設定し、信頼済みであるSSHトンネル経介してアクセスします。

/etc/webmin/miniserv.conf を編集し、以下の行を追加または変更してください。

bind=127.0.0.1

sudo systemctl restart webmin で再起動します。Webminはインターネットからアクセス不能になります。ポート10000のスキャンでは何も検出されず、以前の ss による確認では 127.0.0.1:10000 にバインドされていることが示されます。ローカルPCから、以下のコマンドでトンネルを開きます。

ssh -L 10000:localhost:10000 youruser@YOUR_SERVER_IP

セッションを開いたまま、https://localhost:10000 にアクセスしてください。通信はSSH内部で行われます。SSHはすでに鍵によって認証され、暗号化されているため、ここで自己署名証明書を安全に受け入れることができます。実際の保護はSSHレイヤーが行っています。SSHセッションを閉じると、Webminへのアクセスも遮断されます。許可リストの管理や、公開インターフェースへの露出、追加のセキュリティ強化は不要です。

bind=127.0.0.1 を設定した状態でトンネルを閉じると、リモートアクセスは停止します。これは不具合ではなく、意図した動作です。復旧するには、Option A と同様の手順を行ってください。コンソールから bind の行を削除するか、bind=0.0.0.0 を設定して再起動します。これは、tmuxでClaude Codeを実行しているリモート開発マシン にアクセスする際と同じトンネル接続の手法です。1つのSSHセッションですべてがプライベートに保たれ、パブリックインターフェースで余計なサービスが待機することはありません。

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

Option A のようにホスト名で Webmin を公開する場合、Let's Encrypt の正式な証明書を使用してブラウザの警告を解消してください。DNS名（例：panel.example.com）が必要です。その DNS名にはサーバーを指す A record が設定されている必要があり、検証中に port-80 (HTTP) で応答できる仕組みが必要です。

Webmin にはこの機能が組み込まれています。Webmin > Webmin Configuration > SSL Encryption > Let's Encrypt タブ の順に開きます。hostname を入力し、"website root directory" にそのドメインの port 80 で公開されているパスを指定して、リクエストを実行してください。Webmin が証明書を取得し、miniserv.conf 内の certfile= と keyfile= の行を自動的に更新します。また、有効期限が切れる前に自動更新も行われます。ページを再読み込みすれば、鍵マークの警告が消えます。

注意点があります。Webmin 自身のサーバーは port 10000 で動作しており、port 80 ではありません。そのため、http-01 チャレンジを完了するには、panel.example.com に対して port 80 で応答できる Apache や nginx などの実在する Web サーバーが必要です。あるいは、DNS ベースの検証を使用してください。port 80 で何も動作していない Webmin 単体のサーバーでは、Let's Encrypt がチャレンジファイルにアクセスできないため、検証エラーでリクエストが失敗します。仕組み（DNS record、port-80 チャレンジ、更新プロセス）は、通常の Webサイトの証明書発行と同じです。詳細な検証フローと DNS 設定については、Let's Encrypt TLS certificates with Certbot and nginx guide を参照してください。SSHトンネルを使用している場合は、このセクションは不要です。SSH 経由であれば自己署名証明書のままで問題ありません。また、panel.example.com 用に発行された証明書を使用しても、https://localhost:10000 にアクセスする際に名前の不一致（name-mismatch）警告が出るだけです。

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コードが表示されます。アプリでQRコードをスキャンし、生成されたコードを1つ入力して確定します。以降、ログイン時にはパスワードの後に6桁のトークンが要求されます。ログアウトする前に登録を完了させてください。2FAが要求されている状態でコードのスキャンが行われていない場合、コンソールから要求を解除できますが、先に登録を済ませておく方がはるかにスムーズです。

ブルートフォース攻撃を防ぐために Fail2ban を追加する

制限されたログインエンドポイントであっても、ログイン失敗の繰り返しに対して制限をかけるべきです。Webmin は、ログイン失敗を webmin[12345]: Invalid login as root from 10.0.0.9 の形式で syslog に記録します。Unix アカウントではないユーザー名の場合は Non-existent login as ... となります。Ubuntu 24.04 の標準イメージには /var/log/auth.log が含まれていないため、これらの行は systemd journal に記録されます。Fail2ban には、これら 2 つの行に一致する標準の webmin-auth フィルタが同梱されています。以下の jail は backend = systemd を自動的に設定するため、カスタムの regex やログパスを指定する必要はありません。

/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: 行は存在しません）。設定が正しく動作しているか確認するために、別のネットワークから意図的にログインに数回失敗させてください。その後、status コマンドを再実行し、Currently banned が増加することを確認します。数値が増えない場合は、テスト元の IP アドレスが Fail2ban の ignoreip に含まれていないか確認してください。また、サーバー上で journalctl SYSLOG_IDENTIFIER=webmin を実行し、Invalid login 行が実際に書き込まれているか確認してください。このサーバーにまだ Fail2ban がインストールされていない場合は、Ubuntu 24.04 での SSH 用 Fail2ban ガイド にインストール方法と、この設定と併用すべき SSH jail について記載されています。

Webmin ユーザーの権限を制限する

すべてのユーザーに root 権限は必要ありません。Webmin > Webmin Users から追加のログインを作成し、必要なモジュールのみを割り当てます。例えば、バックアップ担当者には cron と filesystem モジュールのみを許可します。ユーザー編集画面には全モジュールのチェックリストが表示されます。チェックを外すと、そのユーザーのメニューからモジュールが削除され、対応する URL へのアクセスもブロックされます。これは多層防御の一環です。権限の低い Webmin セッションが盗まれても、Users モジュールがリストにない限り、/etc/shadow を書き換えることはできません。

Webmin のアップデートを維持する

apt リポジトリからインストールしているため、sudo apt update && sudo apt upgrade はシステム全体と一緒に新しい Webmin リリースを取得します。コントロールパネルは攻撃の標的になりやすいため、速やかにパッチを適用してください。Webmin は Webmin > Webmin Configuration > Upgrade Webmin から自身をアップデートすることも可能ですが、Ubuntu では apt を使用する方が他のパッケージ管理との整合性が保たれるため、より適切です。これは必須事項です。過去の Webmin の CVE のいくつかは、リモートコード実行のバグでした。「修正済み」か「侵害済み」かの違いは、管理者がどれだけ速くアップグレードを実行したかのみです。

失敗パターンと表示される文字列

"Your connection is not private" / NET::ERR_CERT_AUTHORITY_INVALID。初回ロード時に表示されます。原因：インストール時に Webmin が生成した自己署名証明書には、信頼できる発行元がありません。これは攻撃ではありません。通信は暗号化されていますが、正当性が確認できない状態です。解決策：一旦警告を無視して進めてください。その後、Let's Encrypt で正規の証明書を取得するか、SSH tunnel を使用して Webmin にアクセスしている場合はそのまま使用してください。

"This web server is running in SSL mode. Try the URL https://..."。http://server:10000 と入力しました。このポートでは miniserv は TLS のみを使用するため、その旨をプレーンテキストで通知しています。解決策：アドレスバーの http を https に変更してください。

Page times out — ERR_CONNECTION_TIMED_OUT / "This site can't be reached"。リクエストが Webmin に到達していません。Ubuntu の場合、ほとんどのケースで ufw が port 10000 をドロップしています。sudo ufw status で確認してください。10000 がリストにない場合は、sudo ufw allow 10000/tcp で開放するか、Option B の SSH tunnel を使用してください。違いに注意してください：timeout はファイアウォールがパケットを静かに破棄していることを意味し、ERR_CONNECTION_REFUSED はポートには到達できるが Webmin が動作していないことを意味します。sudo systemctl status webmin を確認してください。

"Access denied for <your IP>."。Option A で IP Access Control を設定しており、現在の IP アドレスが許可リストに含まれていません。原因は、動的 IP の変更または入力ミスです。ブラウザからは復旧できません。コンソールからの解決策：/etc/webmin/miniserv.conf 内の allow= 行を編集して、修正または削除し、sudo systemctl restart webmin を実行してください。

正しい資格情報を入力しても "Login failed. Please try again." と表示される場合。そのアカウントに Unix パスワードが設定されていません。これは、key-only のクラウドイメージでは標準的な仕様です。Webmin は PAM を介して Unix パスワードで認証を行いますが、該当ユーザーにパスワードが存在しないため失敗します。解決策：サーバーで sudo passwd youruser を実行してからログインしてください。もし /var/webmin/miniserv.log が Non-existent login as ... を示す場合、入力したユーザー名は Unix アカウントではありません。

複数のサーバーを管理する場合は、各サーバーにコントロールパネルを入れるよりも自動化の方が効率的です。最初の Ansible playbook から始めてください。

FAQ

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

インターネットに公開されたWebminは、ログイン画面付きのroot shellと同等と考えてください。安全性を確保するには、多層防御が必要です。有効な証明書、2要素認証、Fail2ban、そして厳格なIP許可リスト、あるいはパブリック公開を一切行わない設定が推奨されます。最もリスクの低い設定は、Webminを127.0.0.1にバインドし、SSHトンネル経由でアクセスすることです。この方法では、オープンなインターネット上のポート10000は応答しません。

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

警告（NET::ERR_CERT_AUTHORITY_INVALID）は、Webminが自己署名証明書を使用しているために表示されます。Webminの [Webmin Configuration] > [SSL Encryption] > [Let's Encrypt] から、有効な証明書を取得してください。その際、ポート80での検証に対応したDNS名を使用する必要があります。もしlocalhostへのSSHトンネル経由でのみWebminにアクセスする場合、警告は無害です。SSHが接続の暗号化と認証を行うため、自己署名証明書をそのまま受け入れても問題ありません。

Webminのアクセスを自分のIPアドレスのみに制限するには？

Webminの [Webmin Configuration] > [IP Access Control] に移動し、"Only allow from listed addresses" を選択して、curl ifconfig.meから取得したパブリックIPを入力してください。Webminはこれを/etc/webmin/miniserv.confのallow=行に保存します。動的なホームIPには注意してください。IPが変わるとアクセス不能になり、サーバーコンソールからallow=行を修正する必要があります。実用面では、固定IPまたはSSHトンネル方式の方が信頼性が高いです。

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

WebminはPAMを介してUnixパスワードで認証を行います。クラウドイメージでは、デフォルトのアカウントにパスワードが設定されず、鍵認証のみになっていることが一般的です。その場合、PAMが照合するパスワードが存在しないため、ログインは拒否されます。サーバー上でsudo passwd youruserを実行してパスワードを設定してください。また、/var/webmin/miniserv.logにNon-existent login as ...行がある場合は、ユーザー名自体が実在するUnixアカウントではないことを意味します。

SSHと比較してWebminにはどのような利点がありますか？

Webminは、操作の発見性と利便性を高めるためのレイヤーです。ログファイルの閲覧、ユーザーやcronの管理、ファイアウォールルールの編集、ディスクやサービスのステータス確認などを、コマンドを覚えなくても実行できるため、時折管理を行う管理者や、多様なスキルを持つチームにとって非常に有用です。一方、通常のSSHは高速でスクリプト化が可能であり、日常業務における攻撃対象領域（attack surface）も大幅に少なくなります。多くの管理者は、日常業務にはSSHを使い、時折行うGUI操作のためにトンネル経由でlocalhostにバインドしたWebminを使用するという、両方の運用を行っています。