Ubuntu 26.04にMySQLを導入。

概要

Webアプリのお供であるDBを入れます。

環境

  • Ubuntu 26.04

※ローカル運用で実施。いわゆるLAMP環境のため、他のサーバがDBを見に行くことはないという想定です。

さっくりとした手順

  1. パッケージのアップデートを行います。
  2. MySQLをインストールします。
  3. MySQLのrootパスワードを設定します。
  4. mysql_secure_installationにより安全性を高めます。

パッケージのアップデート

sudo aptitude update

筆者の好みでaptitudeを用いています。必要に応じてaptを使ってください。

MySQLインストール

  • パッケージでインストール
sudo aptitude install mysql-server
  • インストール確認
systemctl status mysql

active(running)を確認します。

MySQL設定変更について

MySQL 8.4以降では、長年使われてきた古い認証方式(mysql_native_password)がデフォルトで無効化され、よりセキュアな caching_sha2_password が標準となっています。そのため、設定ファイル(mysqld.cnf)を書き換えて旧プラグインを強制する手順は不要となり、標準の認証方式のまま初期設定を進めます。

また、近年のバージョンではインストール直後の初期セキュリティが強化されていますが、mysql_secure_installation は以下の重要な役割を持つため実行します。

  • パスワード検証コンポーネント(VALIDATE PASSWORD)の導入
  • 匿名ユーザーアカウントを削除
  • リモートからのrootユーザーのログインを無効化
  • testデータベースを削除し、testデータベースへのアクセス権限を持つユーザーを削除

mysql rootパスワード設定

sudo mysql

初期状態ではローカルソケット認証(auth_socket)のため、sudo経由でパスワードなしでログインできます。

ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'password';

''のpasswordは任意の、強固なものを入力ください。

標準推奨の caching_sha2_password を用いて強固なパスワードを設定します。

flush privileges;
exit

mysql_secure_installation

sudo mysql_secure_installation

質問事項

Enter password for user root: 
# 上記で設定したパスワードを入力します
​
VALIDATE PASSWORD COMPONENT can be used to test passwords
and improve security. It checks the strength of password
and allows the users to set only those passwords which are
secure enough. Would you like to setup VALIDATE PASSWORD component?
​
Press y|Y for Yes, any other key for No:
# パスワード強度チェックを有効にするためYを入力してEnter
​
There are three levels of password validation policy:
​
LOW   Length >= 8
MEDIUM Length >= 8, numeric, mixed case, and special characters
STRONG Length >= 8, numeric, mixed case, special characters and dictionary file
​
Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG:
# ポリシーに合わせて0/1/2を入力(ローカル開発環境なら0または1を推奨)
​
Estimated strength of the password: 50
Change the password for root ? ((Press y|Y for Yes, any other key for No) :
# 既に直前の手順でパスワードを設定済みのため、ここではnを選択します。
​
By default, a MySQL installation has an anonymous user,
allowing anyone to log into MySQL without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother.
You should remove them before moving into a production
environment.
​
Remove anonymous users? (Press y|Y for Yes, any other key for No) :
# anonymousユーザーを削除するためY
​
Normally, root should only be allowed to connect from
'localhost'. This ensures that someone cannot guess at
the root password from the network.
​
Disallow root login remotely? (Press y|Y for Yes, any other key for No) :
# rootユーザのリモートログインを禁止するためY
​
Remove test database and access to it? (Press y|Y for Yes, any other key for No) :
# テストDBを削除するためY
​
Reload privilege tables now? (Press y|Y for Yes, any other key for No) :
# 設定を反映するためY

以上でMySQLの初期設定は完了です。

ピボット旅行2026-20『ゴリラルームの強制指示』

はじめに

山陽線からマリンライナーを乗り継ぎ、高松駅へと帰宿した筆者。

そこで、筆者自身の行動パターンを咎め、ある指示を出す存在がありました。

脳内ゴリラルーム。その、もう一つの役割です。

ゴリラルームのもう一つの役割

以前の記事でも触れた、プロレスにおけるゴリラポジション。

試合を組み立てるだけでなく、アクシデントへの対応も重要な役割です。

いくら精鋭揃いのスーパースターとはいえ、事故や怪我はつきものです。当然、人命が最優先されるものの、彼らの「時間を売る商売」にとっては、何をおいても守らなければならないものがあります。

  • 試合時間
  • それに伴うCMの入れ方
  • CMを挟んでも途切れさせない番組の進行とインターバル

もっと有り体に言えば、『The Show Must Go On』を地で行く商売です。

予期せぬ事態が起きても、興行を成立させる。そのために、状況を見極め、必要な指示を出す。

そして、この考え方は旅行にも応用できるのではないか。

今回、ゴリラルームには、もう一つの役割を担ってもらうことになりました。

旅行者本人が疲労に負けてサボろうとしたとき、必要な行動を強制すること。

何が言いたいかというと

絶対に、宿に直行するとサボる。

高松駅から宿までは歩いてすぐです。雨の中を移動し、千光寺公園までの垂直移動もこなした身としては、もう十分に働いたという気持ちもあります。

「いいや、今日は、真下のコンビニでも行こう」

そう考えることは容易に想像できました。

もちろん、それはそれで旅の思い出にはなるでしょう。しかし、こういうところで手を抜いた後悔は、ずっと引きずるのが筆者の性分です。

そもそも、今回のピボット旅行は、2024年の消化不良だった旅行へのリベンジも兼ねています。

せっかくの旅行で、疲れたからという理由だけで必要な行動を省略し、後になって「あのとき、やっておけばよかった」となる。それだけは避けたい。

そこで、脳内ゴリラルームから指示が出ました。

「宿に帰ってゆっくりしたい。だから外食はしたくない。その気持ちは分かる。だが、最低限の夕飯の買い物は済ませろ」

……はい。

反論の余地はありませんでした。

結果的に、これが正解

前述したとおり、この日はかなりの買い物をしています。しかも雨の中、千光寺公園までの垂直移動までこなしています。

体力の消耗は相当なものでした。

しかし、買い物をして正解でした。

またしてもスーパーマルナカへと向かい、(そして、やっぱりスルーしてしまったレクサスショールームを横目に)手慣れた手つきと足取りで、2日目の夕飯を確保します。

ここまで来れば、あとは宿に戻って食べるだけ。

さらに、食べ終わったら宿の大浴場で汗を流します。

これも、放っておけばサボるという自信しかありませんでした。

疲れているから、今日はいいや。

その「今日はいいや」が積み重なると、せっかくの旅行が少しずつ消化不良になっていく。だからこそ、疲れた自分に判断を委ねず、元気なうちに決めた方針を実行させる必要があったわけです。

この日の買い物

今回、スーパーマルナカで確保したのは以下の品々。

  • バラちらし
  • 貝のにぎり
  • 鶏皮ポン酢和え
  • ノンアル2種
  • カップ味噌汁

正直なところ、高松に戻ってきても胃の容量は相当なものです。

あの餅入りの尾道焼きが、まだ胃袋の記憶に控えている。それでも、これくらい食べないと体力的にキツいという実感はありました。

旅先での食事は、単なる楽しみであると同時に、翌日以降の行動を支えるための補給でもあります。

そして、買い物を済ませ、食事を取り、大浴場で汗を流す。

これでようやく、2日目の行動を締めくくることができました。

脳内に臨時指揮権を与えるという行為

本当に、この試みは最高でした。

先に述べた脳内シャアが、お気楽なレビューをしている。その一方で、こちらの言葉や行動の行間を読み取り、必要な指示を出してくれる存在がいる。

  • プロに見えて、割とアドリブで生きる赤い人
  • エンターテインメントをプロとして成立させる達人

このタッグが、思いのほかうまく機能しているのです。

自分一人で考えていると、疲労を理由に判断を先送りしたり、その場の楽さを優先したりする。しかし、別の視点から「それは本当に必要な省略なのか」と指摘されることで、後悔しないための行動を選べるようになる。

もちろん、何もかもを厳格に管理する必要はありません。旅にはアドリブも必要です。

ただし、アドリブで済ませていいことと、後回しにすると後悔することは違う。

その線引きをしてくれる存在が、脳内にいる。

そして、旅行は残すところ、あと一泊。

脳内シャアがレビューを続ける傍ら、ゴリラルームは必要な指示を出す。

どうやら、この旅行の指揮系統は、思っていた以上に優秀なようです。

壁をどう補強するか──ログと決断、そして未来への備え

はじめに

Linuxサーバーを運用していると、セキュリティ対策について考える機会が少なくありません。

  • ファイアウォールを設定する
  • アクセス制御を行う
  • WAFを導入する
  • OSやソフトウェアを更新する
  • 必要に応じて設定を見直す。

こうした作業を続けていると、一つの疑問に行き着きます。

次に、何をすればよいのでしょうか。

防御を強化しようと思えば、できることはいくらでもあります。壁を高くすることも、厚くすることも、別の材料を追加することもできます。

しかし、すべてを実施するには時間も手間もかかります。設定を増やせば、その分だけ管理する対象も増えていきます。だからこそ、必要になるのは判断です。

何を守るべきなのか。現在の防御には何が足りないのか。そして、次に何をするべきなのか。

今回は、サーバーのログを手がかりに、セキュリティ対策における決断と未来への備えについて考えてみます。

壁の補強には、判断が必要です

前回の記事では、セキュリティを「壁を作り、手入れを続けること」として考えました。

壁一枚でも、そこにあることで防げるものがあります。壁が万能ではないからといって、その価値がなくなるわけではありません。

しかし、壁を作り、維持しているだけで十分なのかといえば、そうとも限りません。

時間が経過すれば、周囲の環境が変わります。以前は問題にならなかった経路から侵入を試みる者が現れることもあれば、利用するソフトウェアが変わり、新たな対策が必要になることもあります。

そのとき、壁を補強する必要があるのかを考えなければなりません。

例えば、ファイアウォールで許可する通信を見直す。SSHの接続元を制限する。ModSecurityのルールセットを更新する。認証ログに現れる不審な試行を調査する。

どれも防御を維持するための選択肢です。

しかし、ある場所で問題が発生したからといって、すべての壁を一律に高くすればよいわけではありません。必要なのは、どこが弱く、何を補強すれば、守りたいものをより確実に守れるのかを見極めることです。

防御を増やすことよりも、何を補強するべきかを判断することのほうが重要になる場面があります。

ログは、補強する場所を考えるための材料です

では、その判断を何に基づいて行えばよいのでしょうか。

ここで役立つのが、日々蓄積されていくログです。

アクセスログには、どのようなリクエストが届いたのかが記録されます。認証ログには、ログインの成功や失敗などが残ります。システムログには、サービスの起動や停止、エラーなどが記録されます。

それぞれの記録を確認することで、普段どのような通信が発生しているのか、どのような問題が繰り返されているのかを調べられます。

例えば、特定のURLに対して不審なリクエストが繰り返されているとします。その記録から、WAFのルールで検知できているのか、遮断できているのか、アプリケーションに到達しているのかを確認できます。

また、SSHへの認証失敗が繰り返されている場合には、現在のアクセス制御や認証方式が適切かどうかを見直すきっかけになります。

一件の記録だけでは分からないことも、長期間の記録を比較することで見えてくる場合があります。

ログは、単に過去の出来事を保存するためのものではありません。次にどこを補強するべきかを考えるための材料でもあるのです。

すべての問題に、すぐ対応する必要はありません

ログを確認していると、さまざまな問題や不審な動きが目に入ります。

対処できるものもあれば、調査が必要なものもあります。現在の設定で十分に防げているものもあるでしょう。

ここで重要になるのが、決断の順序です。

見つけた問題に片っ端から対応していけば、一見すると積極的に防御を強化しているように見えます。しかし、変更のたびに検証や影響確認が必要になり、管理する対象も増えていきます。

場合によっては、対策を追加したことで正規の通信まで遮断してしまうこともあります。

だからこそ、問題を発見したときには、まず現状を把握する必要があります。

  • 何が起きているのか
  • 現在の仕組みで防げているのか
  • 放置した場合、どのような影響が考えられるのか
  • 対策を変更した場合、既存のサービスにどのような影響があるのか
  • 変更したことを、後から検証できるのか

こうした点を整理してから、対応する順序を決めます。

すぐに対処するべきものは対処し、継続して観察するものは記録を追い、現状で十分に防げているものはその状態を維持する。

この区別ができれば、目に入った問題すべてに同じだけの時間を費やす必要はなくなります。

判断を先送りすることと、状況を把握したうえで経過を観察することも違います。

何もしないという選択にも、状況を確認したうえで維持するという判断があり得ます。

未来への備えは、未来を完全に予測することではありません

サーバーの運用では、これから何が起きるかを完全に予測することはできません。

新たな脆弱性が発見されるかもしれません。攻撃の傾向が変わるかもしれません。ソフトウェアの更新によって、これまで問題のなかった設定を見直す必要が生じるかもしれません。

そのすべてを事前に予測し、対策を完成させておくことは困難です。

では、未来に備えるとは、どういうことなのでしょうか。

それは、未来に起きることをすべて当てることではなく、変化が起きたときに対応できる状態を維持することだと考えています。

ログを残しておく。設定変更の内容を記録する。変更前の状態に戻せるようにしておく。定期的に更新情報を確認する。必要なときに調査できるよう、基本的な運用手順を整えておく。

こうした準備があれば、問題が発生したときにも、手がかりを探し、影響を確認し、対応を選ぶことができます。

未来への備えとは、すべての問題に対する答えを先に用意することではありません。

問題が起きたときに、考え、判断し、行動できる余地を残しておくことです。

決断コストを減らすために、決断の仕組みを作る

ここで、日々のサーバー運用と決断コストの関係についても考えてみます。

運用を続けていれば、何らかの判断を求められる場面は必ず発生します。

  • どのログを調べるのか。
  • どの設定を変更するのか。
  • どの脆弱性に優先して対応するのか。
  • どこまで対策を追加するのか。

そのたびに、すべてをゼロから考えていては、時間も注意力も消費してしまいます。だからこそ、あらかじめ判断の基準を持っておくことが役立ちます。

例えば、設定を変更するときには、変更の目的、影響範囲、確認方法、切り戻し方法を整理しておく。問題を発見したときには、実際の影響と現在の防御状況を確認する。定期的な更新や点検は、可能な範囲で手順化する。

そうすれば、毎回すべてを考え直す必要がなくなります。

一方で、手順化したからといって、状況を確認せずに機械的に実行すればよいわけでもありません。前提条件が変わっていれば、以前の判断基準が適切でなくなることもあります。

重要なのは、考えることを放棄するのではなく、繰り返し発生する判断を整理し、本当に検討が必要な部分に時間を使えるようにすることです。

壁を作り、点検し、必要に応じて補強する。その一連の仕事に、一定の基準と手順を設けておく。これによって、日々の判断に必要なコストを抑えながら、状況の変化にも対応しやすくなります。

心構えを維持するということ

こうした運用を続けるうえで、もう一つ大切なのが、管理者自身の心構えです。

セキュリティ対策は、一度実施すれば終わる仕事ではありません。ログは日々増え、ソフトウェアは更新され、環境は少しずつ変化していきます。

毎日すべてを完璧に確認することは難しくても、必要な点検を続け、問題があれば調べ、必要な変更を行うことはできます。そのためには、運用を一時的な気合いや緊張感だけに頼らないことも重要です。

  • 作業を手順化する。
  • 変更内容を記録する。
  • 定期的に確認する項目を決める。
  • 問題が発生したときに、どこから調べればよいかを整理しておく。

こうした仕組みがあれば、日々の気分や忙しさだけに左右されず、必要な作業を継続しやすくなります。

すべてを一度に解決しようとしないことも大切です。今日できる点検を行い、必要な修正を加え、次に確認するべきことを残しておく。状況が変われば、そのときに改めて判断する。

これもまた、壁を長持ちさせるための手入れの一つです。

おわりに

サーバーを守るための仕組みは、一度作れば完成するものではありません。

環境の変化に応じて点検し、必要な部分を補強し、役割を果たし続けられるように維持していく必要があります。

そのために、ログがあります。過去の出来事を確認し、現在の状態を理解し、次に何をするべきかを考えるための材料です。

そして、その材料を使って判断するのは、運用者自身です。

すべての問題を予測することはできません。すべての対策を一度に実施することもできません。それでも、状況を記録し、判断の基準を持ち、必要なときに対応できる状態を維持することはできます。

壁を作る。壁を手入れする。ログを読み、必要な場所を補強する。そして、変化に備えて次の判断ができるようにしておく。

その繰り返しが、長く使い続けられるサーバーを支えます。

未来を完全に予測することはできなくても、未来に向けて判断できる状態を維持することはできます。

そういう意味で、筆者が心に留めている言葉があります。『未来戦隊タイムレンジャー』

未来は変えられなくたって自分達の明日ぐらい変えようぜ。
出来るって! だってさ、次の瞬間、何するか決めるの
どう考えたって自分だろ?

このログ(言葉)があるからこそ、筆者は少なくとも未来をちょっとはマシにできると考えています。

さておき、日々の運用とは、そうした小さな決断を積み重ねながら、必要な安全性と安心を保ち続ける仕事なのだと思います。

ピボット旅行2026-19『あるのがいけない!! Part 1』

はじめに

旅行というやつ、買い物のリミットが割と外れます。

みつけたもの

尾道紅茶。2024年も買ってはいましたが、あくまでもお土産として。普段使いという意味では足りませんでした。(これは完全な言い訳ですが、旅行中に体力を大幅に削っていたのでいちいち覚えていなかったというのも大きいです)

さて、尾道は隠れた名産としてお茶があります。特に尾道紅茶は先の2025年大阪万博のスリランカ館で、この尾道の茶舗の商品が展示されたほど。

なぜ尾道に紅茶がここまで流通しているのか? それを軽くシミュレートして、買うことにしました……。

  1. 北前船の寄港地としての『天然の良港』と経済の要所

尾道は天然の良港。また、風待ちとしても嵐除けとしても中継地として非常にちょうど良く、古くから瀬戸内海航路の要所・北前船の寄港地として、各地の銘茶や物資が集まる交易の街だった

また、住友財閥の極めて重要な「尾道会議」にて、住友銀行ヲ興ス事が諮られた非常に重要な土地。

  1. 坂道と猫の街に根づく『サロン文化・カフェ文化』
    文豪や志賀直哉たちが愛した尾道は、時間を忘れて思索に耽る喫茶文化が古くから育まれてきた土地。細い坂道を巡り、ふと立ち寄った洋館やカフェで丁寧に淹れられた紅茶をいただく……そんな風土と、全国の紅茶通を唸らせる名産へと育った

なるほど。では、紅茶があるのは自然です。

↑建前↑

↓本音↓

「あるのがいけない!! あるのがいけない!!」

に尽きます。そう、あの『ドカ食い』を求める方のごとく、ポイポイとカゴに入れて会計していたことは覚えています。

帰り道に思ったこと

さて、今回の旅の拠点は高松です。山陽線の電車の待ち時間に抹茶のブリオッシュをいただいて「うお、なんだこのとろける舌触りは、本当に小麦粉なの? これがブリオッシュ(お菓子)ならマリー・アントワネットはヘイトを勝って当然では(言ってない)」を思い出しました。

それはさておき、電車の中で会計を思い出します。

「9,208円になります」

と言われたことも覚えています。

「え? そんなに買った? そんなに入れてないはずなんだけど……」

思いつつ、夕飯を仕入れ、帰宿。食後に買ったものを整理していると

「……いや、よく1万円で収まったな」

と結論。

  • 缶入りティーバッグ3種
  • アソート1袋
  • 八朔ティーバッグ
  • レモンティーバッグ
  • エコバッグ

なるほど。商品があったことは覚えていたがその途中経過がすぽっと抜けていました。これに関しては筆者が「お茶を買うときにいちいち値札を見ない」という買い方がある種災いをしています。

高級茶でそんな買い方をしたら一瞬で資産が溶けますが、生憎とフレーバーティーを主体としていたので「そのノリで買えば大丈夫だろう」という最後の理性は働いていたのは、ある種の幸いでした。

さて、この尾道紅茶。休み明けにそれぞれ楽しみましたが「……よかった、通販があって」でした。これから足りないときは注文できるので。

しかし、「現地で買う→次の旅行“いつにする”か」という動機が減ったのはやや残念な点です。

セキュリティとは、壁を作り、手入れを続けることである

はじめに

Linuxサーバーを運用していると、セキュリティという言葉を目にする機会は少なくありません。

  • ファイアウォール
  • WAF
  • 侵入検知
  • アクセス制御
  • ログ監視

等。攻撃を防ぐための仕組みはいくつもあり、調べれば調べるほど、対策すべき項目は増えていきます。

しかし、そもそもセキュリティとは何のためにあるのでしょうか。

攻撃者を撃退するためでしょうか。脆弱性をゼロにするためでしょうか。それとも、最新の防御技術を導入すること自体が目的なのでしょうか。

私は、セキュリティの本質的な価値は、安心して使えること、そして安全に使い続けられることにあると考えています。

そのために必要なのは、必ずしも巨大な要塞ではありません。壁一枚だって、立派なセキュリティです。

壁一枚にも、意味があります

例えば、外からの侵入を防ぐために壁を設けたとします。

もちろん、その壁だけですべての侵入を防げるわけではありません。壁を越える者もいれば、壁の隙間から入り込む者もいるでしょう。壁そのものが壊される可能性だってあります。

だからといって、壁を設ける意味がないわけではありません。

壁がなければ自由に通り抜けられる場所でも、壁があることで侵入には手間がかかるようになります。壁があることで防げるものがあり、壁があることで守られる範囲があります。

セキュリティ対策も同じだと筆者は考えています。ファイアウォールで通信を制限する。SSHへのアクセスを必要な接続元に限定する。不要なサービスを停止する。WebサーバーにWAFを導入する。

それぞれ単独で、あらゆる脅威を防ぐことは不可能です。しかし、何も設けていない状態と比べれば、そこには確かな違いがあります。

万能ではないことと、役に立たないことは違います。

防げるものを防ぎ、影響を小さくし、必要なときに気づけるようにする。その積み重ねが、システムを守ることにつながるというのが筆者が4年ほどvpsを「育てた」知見です。

壁を作るだけでは、終わりません

ただし、壁は作れば永遠に機能するわけではありません。

時間が経てば劣化します。ひびが入ることもあれば、周囲の環境が変わり、以前は問題のなかった場所が弱点になることもあります。

だからこそ、壁には手入れが必要です。

Linuxサーバーでいえば、OSやソフトウェアの更新、設定の見直し、ログの確認、不要なアカウントやサービスの整理などが該当します。

一度ファイアウォールを設定したからといって、その設定が将来にわたって適切であるとは限りません。導入したWAFも、ルールセットが古くなれば、現在の脅威やアプリケーションの状態に合わなくなる可能性があります。

そして、手入れとは、必ずしも壁を補強することだけではありません。

安全を確保できないと判断したときには、門を閉じることも必要です。

例えば、稼働中のソフトウェアに重大な脆弱性が発見され、既存の防御策や暫定的な設定変更だけでは十分な安全性を確保できない場合。サービスを一時停止すれば、利用者への影響は避けられません。それでも、稼働を続けることによるリスクが大きいのであれば、停止は合理的な選択肢になります。

もちろん、停止すればすべての問題が解決するわけではありません。停止によって何が防げるのか、ほかに残る攻撃経路はないか、どのような条件で再開できるのかを確認する必要があります。

それでも、無理に動かし続けることだけが正解ではありません。

逆に、手入れを続けていれば、問題が大きくなる前に気づけることがあります。

これはセキュリティに限った話ではありません。定期的な点検や保守が必要なのは、システムが動き続ける以上、環境も前提条件も変化するからです。

防御を作ることと、防御を維持することは、表裏一体のお仕事です。

そして、実際の運用では、作った防御を維持する仕事のほうが長く続きます。

ModSecurityは、要塞というより箒とハタキです

以前、Web Application Firewall(WAF)であるModSecurityについて考えていたとき、興味深い説明に出会いました。しかも、その話をしたのがAIというのもまた哲学を感じます。

WAFの本質は、軍事要塞のようにミサイルを撃ち返すことではない。Webサーバーの玄関先に溜まる有害なゴミや、SQLインジェクションの蜘蛛の巣、XSSの不正な泥を、ルールセットという箒とハタキで払い落とすことだ、という説明です。

ModSecurityは、HTTPリクエストをルールに照らして検査し、設定に応じて記録や遮断などを行います。OWASP Core Rule Set(CRS)などのルールセットを組み合わせることで、Webアプリケーションへの攻撃を検知し、防御を補助します。

あくまでも防御の補助ではありますが、それでも、意味があります。

Webサーバーに到達するリクエストを検査し、既知の攻撃パターンに合致する通信を処理する。ルールに任せられるものはルールに任せ、人間は検知内容の確認や誤検知の調査、必要な設定変更に集中する。

毎回、すべての通信を人間が判断する必要はありません。

そして、箒とハタキは一度使えば永久に不要になる道具でもありません。日々の通信がある以上、検査も続きます。ルールセットの更新や設定の見直しも必要になります。

派手な反撃を見せるわけではありませんが、こうした地道な処理によって、Webアプリケーションを安全に運用できる状態を維持するのです。

セキュリティの目的は、対策を増やすことではありません

セキュリティについて調べていると、新しい脅威や新しい防御技術が次々と見つかります。

それらを知ることには意味があります。しかし、対策を増やすこと自体が目的になってしまうと、本来守るべきものを見失いかねません。

設定を複雑にしすぎれば、管理する側の負担が増えます。防御を強化したつもりが、正規の利用者を遮断してしまうこともあります。変更によってサービスが停止すれば、それ自体が運用上の問題になります。

一方で、サービスを動かし続けること自体が目的になってもいけません。

2026年10月、PHPの重大な脆弱性が報じられた際、筆者は当初、設定変更による暫定的な対策を検討しました。しかし、事態を踏まえ、最終的には自分のVPSでPHP-FPMを一時停止する判断をしました。

サービスを止めれば、当然ながら利用者への影響が生じます。それでも、十分な安全性を確保できない状態で稼働を続けるより、いったん停止して状況を見極めるほうが適切だと判断したためです。

セキュリティは、単に攻撃を防げばよいという話ではありません。

必要なサービスが正常に動作し、正規の利用者が安心して使え、管理者が異常を把握して対処できること。そうした状態を継続して維持することが重要です。

ただし、それは、どのような状況でもサービスを動かし続けるという意味ではありません。安全を確保するために停止が必要なら、停止したうえで、再び安全に動かせる状態を目指すことも運用の一部です。

ここで、冒頭の話に戻ります。

セキュリティの本質的な価値は、安心と安全にあります。

利用者が毎回、攻撃を心配しながらサービスを使う必要がないこと。運用者が毎回、同じ種類の通信を手作業で判断しなくてもよいこと。そして、問題が発生したときには、状況を把握して適切に対応できること。

防御の仕組みは、そのために存在します。

決断コストを減らすということ

ここで、もう一つ考えておきたいことがあります。それは、判断にはコストがかかるということです。

  • ログを確認する
  • 通信を調査する
  • ルールを追加する
  • 例外を設定する
  • 設定変更が既存のサービスに与える影響を検討する。

どれも必要な仕事ですが、すべてを毎回、人間がゼロから判断していたら、運用は成り立ちません。だからこそ、機械に任せられる仕事は機械に任せます。

ファイアウォールで不要な通信を遮断する。SSHへの接続元を制限する。WAFでリクエストを検査する。ログを記録し、異常の調査に必要な情報を残す。

これらは、人間の仕事を奪うための仕組みではありません。人間が判断しなければならない場面に、時間と注意力を残すための仕組みです。

人間が判断すべきことと、あらかじめ仕組みに任せられることを分ける。

これもまた、セキュリティ運用の重要な仕事だと考えています。

  • 壁を作る
  • 壁を点検する
  • 壁に任せられることは壁に任せる
  • そして、壁だけでは防げないことに、人間の注意を向ける

この繰り返しによって、日々の運用に必要な判断を減らしながら、必要な安全性を維持していきたいです。

壁を作り替えるために壊すことも必要です

先般、筆者が直面した「php2shell」(CVE-2026-109618、CVE-2026-109619)。

これのために筆者が選んだ方法は「アップデートが確定するまで、php-fpmを止め、アップデートを確認してから再開させる」でした。

これは筆者にとっては矛盾ではなく、「嵐に出航し、難破するよりは安全な港に停泊して嵐が過ぎるのを待つ」方がサーバを守るからです。

言うなれば、古い壁が風雨に耐えられそうにない。なので一度真新しくするため壊すというのもメンテナンスの一つです。

おわりに

セキュリティ対策というと、最新の防御技術や、攻撃者との攻防に目が向きがちです。しかし、セキュリティの価値は、必ずしも派手な出来事の中にあるわけではありません。

何事もなくサービスが動き続けること。利用者が安心して使えること。運用者が異常に気づき、必要な対応を取れること。

それらが維持されているなら、そこにはセキュリティ対策の価値があります。

壁一枚でも、壁があることで防げるものがあります。そして、その壁を長持ちさせるために手入れをすることは、何もしないよりもずっと有用です。

ファイアウォールも、WAFも、アクセス制御も、ログ監視も、それぞれが万能の解決策ではありません。それでも、それぞれが役割を果たし、適切に維持されていれば、システムの安全性を支えるものになります。

セキュリティとは、何があっても破られない壁を夢見ることではなく、必要な壁を作り、その壁が役割を果たし続けるように手入れをすることです。

そして、その先にあるのは、防御そのものを誇ることではありません。

利用者が安心してサービスを使い、運用者が必要な仕事に集中できる、「なんてことないサーバの、なんてことない管理者の」当たり前の日常です。

ピボット旅行2026-断章『氷面師たち』

はじめに

『パン屋航路』での食事をご紹介しました。この時に食べたものは、

  • グリーンカレーパン
  • ずんだ入りクリームチーズベーグル

の2つ。しかし、パッケージには3つめのものがあったはずです。

実はこれ、道中のおやつに食べようと思っていた「抹茶ブリオッシュ」。しかし、「お昼に尾道焼きが控えているため」に取っておいたものです。

本来、これを聖地巡礼の後に食べる予定だったのですが……。

脳内ハリソン山中の提案

商店街を歩いていると、脳内のハリソン山中(『地面師たち』)が語りかけてきました。

もっと大きなヤマを狙いませんか?

そうですね……白玉がゴロゴロ転がるようなヤマです。つまらないじゃないですか、宿に帰れば食べられるものをチマチマ食べても。小さなヤマよりは大きなヤマ、容易いヤマよりは困難なヤマ。胃袋が怖気づいて二の足を踏むような――難攻不落のヤマを落としてこそ、この旅をしているんじゃないですか?

それに一も二も無く飛びつきました。

向かった先の「ととあん」

ここで向かったのが、甘味処「ととあん」です。

筆者がこのお店を知ったのは2011年。それ以来訪れている、最高に好きな甘味屋です。もちろん、今回のような「ヤマ」が待ち構えていることも知っていました。

選んだのは、白玉はっさく練乳かき氷。(正式な商品名は忘れました)

そして、運ばれてきたのがこちら。

……大きい。

写真のとおり、かき氷の頂上にはっさくが鎮座しています。白玉とはっさく、練乳は別添え。つまり、目の前にあるのは、文字どおりの「大きな山」です。

もちろん、注文時に描かれていたものしか乗っていません。そこに偽りはありません。

ただし、実物を前にしたときのインパクトまでは、メニューから読み取れませんでした。

予定していたおやつを食べる代わりに、思いがけず大きなヤマに挑むことになりました。

「このヤマ、どうやって攻略するか……」

の前に既に食べ終わっていました。

  • サクサクとした味を楽しむ
  • 白玉と練乳を別添えでやる
  • シロップを足す
  • 最後に全てを混ぜ合わせて飲むようにして食べる

はやっていたはずです。

余談

筆者がこのお店を知って以来、訪れるたびに思うことがあります。

「自宅とこの店のポータル、開けられないかな?」

それくらい好きなお店なのです。

なお、先のWWEの例で言うなら、今回の出来事はハリソン山中がキャッシュインしたようなものです。

こちらは抹茶ブリオッシュを温存していたつもりでした。しかし、目の前に現れたのは、それを後回しにするだけの価値がある大物でした。(なお、このブリオッシュは電車待ちの間に美味しくいただきました)

BOSGAME E5 初期セットアップ記録 ――Ubuntu 26.04 LTS、four-mations出発準備

はじめに

シェイクスピアの悲劇を経て購入した、自宅サーバ用の小型PC、BOSGAME E5。

手元に届いた以上、いつまでも箱の中に置いておくわけにはいきません。

今回の目的地は、自室のローカルサーバ環境です。これまでLet's note CF-XZで運用していたNextcloudとAdGuard Homeを、より余裕のある環境へ移す。そのための第一歩として、まずはOSを入れ替え、SSHで管理できるところまで整えます。

導入するOSはUbuntu 26.04 LTS Desktop。

ホスト名は four-mations としました。

ここから先の作業は、まだ本番サービスの移行ではありません。まずは土台を作り、ネットワークを整え、手元の自宅NWから遠隔操作できる状態にします。

環境

項目設定内容
対象機器BOSGAME E5
CPUAMD Ryzen 3 5300U
メモリ16GB DDR4
ストレージ512GB NVMe SSD
導入OSUbuntu 26.04 LTS Desktop
ホスト名four-mations
有線インターフェースenp2s0
固定IPアドレス192.168.11.21/24
デフォルトゲートウェイ192.168.11.1
DNSサーバー192.168.11.1

さっくりとした手順

  1. Ubuntu 26.04 LTS Desktopをクリーンインストールします。
  2. システムパッケージを最新化します。
  3. OpenSSH Serverを導入し、リモート接続を確認します。
  4. 有線LANのIPアドレスを固定化します。
  5. IPアドレス、ルーティング、外部ネットワークへの疎通を検証します。

1. Windows 11 ProからUbuntuへ

1.1 ブートメディアから起動します

購入時のBOSGAME E5にはWindows 11 Proが導入されていました。

しかし、今回の用途は自室のローカルサーバです。Windows環境をそのまま使うのではなく、Ubuntuをクリーンインストールします。

Ubuntu 26.04 LTS DesktopのインストーラUSBを用意し、本体に接続します。

電源投入時に DEL を押してブートメニューを開き、USBメモリから起動します。キーは機器のファームウェア設定によって異なる場合があります。

1.2 既存のストレージを初期化します

インストーラの画面に従ってインストールを進め、インストールタイプでは「ディスクを削除してUbuntuをインストール」を選択します。

インストール先は、内蔵NVMe SSDの nvme0n1 です。

注意:この操作では既存のWindows環境と、対象ディスク上のデータが消去されます。 必要なデータが残っていないことを確認してから実行します。

1.3 ホスト名を設定します

初期アカウントの設定では、コンピュータ名を次のように指定しました。(本ブログのアイキャッチの顔になっている4パターン、5人のお姉さんたちのユニット名です)

four-mations

ユーザー名とパスワードを設定し、インストール完了後に再起動します。こうして、新しい自室サーバの土台ができました。

2. システムを最新化します

2.0 aptitudeを入れます。

これは完全に筆者の好みの問題。

sudo apt install aptitude

2.1 パッケージリストを更新します

初期起動後、ターミナルを開きます。

sudo aptitude update

2.2 インストール済みパッケージを更新します

sudo aptitude upgrade -y

OSを入れたら、まずはシステムを最新の状態に整えます。この先、SSHやネットワークの設定を行うにしても、最初に基本部分を整えておくのが順序というものです。

3. SSHで遠隔操作できるようにします

3.1 OpenSSH Serverを導入します

自室サーバとして運用する以上、毎回ディスプレイとキーボードを接続して操作するのは避けたいところです。

そこで、OpenSSH Serverを導入します。

sudo apt install -y openssh-server

3.2 SSHサービスを有効化します

sudo systemctl enable --now ssh

これで、システム起動時の自動起動と、現在のサービス起動を設定できます。

3.3 サービスの稼働状態を確認します

systemctl status ssh --no-pager

出力に Active: active (running) と表示されていれば、SSHサービスは稼働しています。

3.4 現在のIPアドレスを確認します

ip -br a

有線インターフェース enp2s0 に割り当てられているIPアドレスを確認します。

この段階ではDHCPによる自動割り当てです。実際に割り当てられたアドレスを確認し、クライアント端末から接続できる状態にします。

3.5 ローカルネットワークからSSH接続します

手元のPCなど、同じLANに接続したクライアント端末から実行します。

ssh <ユーザー名>@<現在のIPアドレス>

Windowsの場合はお好みのターミナルソフトを使ってください。

初回接続時にはホスト鍵の確認が表示される場合があります。接続先が正しいことを確認してから受け入れます。

ログインできれば、ひとまず本体にディスプレイやキーボードをつながなくても操作できるようになりました。

ここから先は、遠隔操作を基本に進められます。

4. 有線LANのIPアドレスを固定化します

4.1 固定IPを設定する前に

多くの企業や組織では、固定IPの競合や管理問題から、最初から固定IPを導入するパターンでしょうが、筆者は違います。「DHCPがリースしたIPは他のNW機器とIPが被りようがない」です。

なので、省力化を果たします。(省力化とは)ただし、ここは作業上の注意点があります。

SSH接続中にネットワーク設定を変更すると、接続が切れる可能性があります。 固定IPへの切り替え前に、現在の接続情報を控え、可能なら本体のローカルコンソールから復旧できる状態を確保しておきます。

4.2 アクティブな接続名を取得します

Ubuntu Desktopでは、NetworkManagerを利用してネットワーク接続を管理できます。

まず、有線インターフェース enp2s0 に対応するアクティブな接続名を取得します。

CON_NAME=$(nmcli -t -f DEVICE,NAME connection show --active | awk -F: '$1=="enp2s0"{print $2}')

取得した値を確認します。

echo "$CON_NAME"

Wired connection 1 や 有線接続 1 など、実際の接続名が表示されることを確認します。

何も表示されない場合は、設定を変更せず、インターフェースと接続状態を確認します。

4.3 固定IPアドレスを設定します

まず、IPアドレスを指定します。

sudo nmcli connection modify "$CON_NAME" ipv4.addresses 192.168.11.21/24

デフォルトゲートウェイを指定します。

sudo nmcli connection modify "$CON_NAME" ipv4.gateway 192.168.11.1

DNSサーバーを指定します。

sudo nmcli connection modify "$CON_NAME" ipv4.dns 192.168.11.1

IPアドレスの取得方式をDHCPから手動設定へ変更します。

sudo nmcli connection modify "$CON_NAME" ipv4.method manual

4.4 設定を反映します

接続設定を再適用します。

sudo nmcli connection up "$CON_NAME"

正常に反映されれば、Connection successfully activated などのメッセージが表示されます。

接続が切れた場合は、固定IPアドレスで再接続します。

ssh <ユーザー名>@192.168.11.21

接続できない場合は、本体のローカルコンソールからネットワーク設定を確認します。DHCPへ戻す場合は、対象の接続名を確認したうえで次の設定を適用します。

sudo nmcli connection modify "$CON_NAME" ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns ""
sudo nmcli connection up "$CON_NAME"

なお、これは対象接続のIPv4設定をDHCPへ戻す操作です。実行前に接続名が正しいことを確認します。

5. ネットワーク設定を検証します

5.1 IPアドレスとインターフェース状態を確認します

ip -br a

enp2s0 が UP となり、192.168.11.21/24 が割り当てられていることを確認します。

5.2 ルーティングテーブルを確認します

ip route

出力例は次のとおりです。

default via 192.168.11.1 dev enp2s0 proto static metric 100
192.168.11.0/24 dev enp2s0 proto kernel scope link src 192.168.11.21 metric 100

デフォルトルートが 192.168.11.1 を向き、送信元アドレスとして 192.168.11.21 が使われていることを確認します。

5.3 IPアドレスを指定して疎通を確認します

ping -c 3 1.1.1.1

応答が返れば、少なくとも指定した外部IPアドレスへの通信ができています。

ネットワーク環境によってはICMPが制限される場合もあるため、応答がない場合は、この結果だけでネットワーク全体の障害と判断しないようにします。

5.4 DNSによる名前解決を確認します

getent hosts google.com

IPアドレスが返れば、名前解決ができています。

続けて、必要に応じて次のコマンドでも確認します。

ping -c 3 google.com

こちらは名前解決に加え、相手からICMP応答が返ることも確認するものです。名前解決が成功しても、ICMPが制限されていれば応答が返らない場合があります。

おわりに

これで、BOSGAME E5の初期セットアップはひとまず完了です。

Ubuntu 26.04 LTS Desktopを導入し、ホスト名を four-mations に設定。SSHで遠隔操作できるようにし、有線LANのIPアドレスを固定化しました。

まだNextcloudもAdGuard Homeも移行していません。今回整えたのは、あくまでそのための土台です。

しかし、これで自室の新しいサーバを構築する準備が整いました。

次は、既存環境の設定やデータを確認しながら、サービスの移行と動作検証を進めていきます。

ピボット旅行2026-18『神様お願い!』

この言葉にピンと来た方は、グループ・サウンズの大御所、ザ・テンプターズの曲、あるいはそれをカバーした桃姫BAND(尾崎亜美)のタイトルを思い出すかもしれません。

しかし、筆者にとってこの言葉は、アニメ『かみちゅ!』のサブタイトルになります。

はじめに

筆者がこの旅を決めてから、プレイリストにぶち込んだ曲があります。

このタイトルにある『神様お願い!』を筆頭として、

  • 青春のいじわる
  • 野性時代
  • 時の河を越えて
  • 君に決定

そう、アニメ『かみちゅ!』のサブタイトルに使われていた曲です。

これらのサブタイトルは、1980年代のアイドルソングなどから取られています。タイトルだけを並べれば、当時の音楽に詳しい方なら別の景色が浮かぶかもしれません。

筆者の場合は、これらをAmazon Musicのプレイリストに放り込むところから、今回の旅が始まりました。

尾道を歩き、作品の舞台となった場所を訪れる。そのための準備として、まずは音楽から作品の世界に入っていくわけです。

……我ながら、ずいぶんと回りくどい準備運動です。

筆者にとっての『かみちゅ!』

以前の断章でも触れたとおり、筆者にとって尾道は、単にアニメの舞台だから訪れたい町ではありません。

そもそも、筆者が尾道という町を知り、実際にその空気を感じた後で『かみちゅ!』に出会っています。

作中では、中学生の一橋ゆりえが突然神様になってしまいます。けれども、物語の中心にあるのは、神様になったことによる壮大な冒険ばかりではありません。学校に通い、友人と過ごし、町を歩く。そんな日常の中に、神様や不思議な出来事が自然に溶け込んでいます。

この世界観が、実際に歩いた尾道の町と重なりました。

筆者にとって『かみちゅ!』は、作品を見てから舞台を訪ねたというよりも、先に五感で記憶していた町が、作品を通じてもう一度つながったような存在です。

だからこそ、今回の旅行で自転車を置いていく判断をしたのは、断腸の思いでした。自転車で尾道を走ることも、もちろんやりたかったことです。

しかし、今回あらためて確かめたかったのは、自転車で走ることそのものではありません。尾道という町を歩き、以前訪れた場所にもう一度立つことでした。

そして、せっかく尾道に来たのですから、『かみちゅ!』の聖地も巡りたい。

今回の行程では、そんな筆者にとって外せない場所を3か所回ることにしました。

尾道で確実に行ける3つの聖地

福本渡船「神様御用達」のフェリー

まずは、福本渡船です。

『かみちゅ!』に登場する来福神社は、神様がいる神社として描かれています。その神様にゆかりのある場所を巡る旅で、渡船という存在を外すわけにはいきません。

尾道の町と向島を結ぶ渡船は、単に対岸へ移動するための交通手段ではありません。海を挟んで向かい合う町の景色と、そこを日常的に行き来する人々の暮らしをつなぐ存在です。

そして福本渡船は、多くの人々に惜しまれながら、その長い運航の歴史に幕を下ろしました。

今となっては、かつてのように船に乗ることはできません。それでも、尾道の風景と暮らしを形作ってきた渡船の記憶までなくなったわけではありません。

今回の聖地巡礼では、作品に描かれた世界と、現実の尾道の町が重なる場所として、この渡船を記録に残しておきたいと思いました。

御袖天満宮

続いて、御袖天満宮です。

『かみちゅ!』に登場する来福神社。その境内のモデルとなった場所です。

作中では、主人公の一橋ゆりえが神様となり、三枝祀(みこ)の実家でもある来福神社を中心に、さまざまな出来事が展開します。

その来福神社の境内に対応するのが、ここ御袖天満宮です。

そして、この場所にはもうひとつ、映画ファンにとってもおなじみの景色があります。映画『転校生』で、人格が入れ替わる場面に登場する石段です。

ひとつの場所に、異なる作品の記憶が重なっています。

『かみちゅ!』の舞台として見るなら、神様が暮らす神社の境内。『転校生』の舞台として見るなら、物語が大きく動く石段。

実際にその場に立つことで、作品の中で見ていた景色が、現実の町の中に存在していることを確かめられます。

艮神社

そして、艮神社です。

こちらは、来福神社の拝殿に対応する聖地です。

御袖天満宮が境内のモデルであるのに対し、艮神社は拝殿のモデル。この2か所を巡ることで、作中の来福神社が、現実の尾道にある複数の場所から形作られていることが分かります。

特に印象的なのは、『かみちゅ!』のオープニングです。艮神社の社殿は、タイトルロゴと重なる場所としても知られています。

作品を見ていたときには、ひとつの神社として目に入っていた景色。しかし、実際の場所を訪ねると、境内と拝殿という異なる要素が、それぞれ別の場所に対応していることに気づきます。

御袖天満宮と艮神社。どちらか一方だけではなく、両方を訪れることで、来福神社という架空の場所を立体的に捉えられるわけです。

神様にお願いした後は

こうして、福本渡船、御袖天満宮、艮神社と、今回訪れたかった3つの場所を巡ることができました。

作品の中でひとつの場所として描かれたものが、現実の尾道では複数の場所に分かれている。その違いを確かめながら歩くのも、聖地巡礼の楽しみです。

そして、今回の筆者には、もうひとつ大事な目的がありました。

先ほど、尾道焼きというメインイベントを完食したばかりです。

神様にお願いをした後は、歩いて腹ごなし。

……とはいえ、尾道の坂道と石段を巡れば、それだけで十分に運動になってしまうのですが。

こうして筆者は、作品の記憶をたどりながら、再び尾道の町を歩いていくのでした。

PHP「php2shell」脆弱性への恒久的対応:PHP8.3-FPMを更新した際のondrej/phpの一時的退避とロールバック

前項で書いた

「php2shell」(CVE-2026-109618、CVE-2026-109619)

への恒久的対応として、PPA提供の php8.3(バージョン 8.3.35)から、Ubuntu公式の修正版(8.3.6-0ubuntu0.24.04.13)へとロールバック・パッチ適用したときの作業メモです。

概要

Ubuntu 24.04 LTS(noble)環境において、php2shell 脆弱性への対応として Ubuntu 公式セキュリティリポジトリの PHP 修正版を適用しようとしたところ、サードパーティリポジトリのパッケージが優先され、通常のパッケージ更新では修正版へ切り替わらない事象が発生しました。

原因調査の結果、ppa:ondrej/php の PHP パッケージ(8.3.35)がインストール済みかつ更新候補として選択されていることを確認しました。APTの仕様上、バージョン番号が大きいPPA版が優先されていたため、PPAをパージして Ubuntu 公式パッケージへロールバックすることでパッチ適用を完了させました。

本記事では、発生した問題、原因調査、ロールバック手順、パッチ適用確認および復旧手順を記録します。

環境

  • OS:Ubuntu 24.04 LTS(noble)
  • 対象パッケージ:PHP 8.3
  • サードパーティリポジトリ:ppa:ondrej/php
  • ロールバック先:Ubuntu 公式セキュリティリポジトリ(noble-security)
  • PHP-FPM:php8.3-fpm
  • Webサーバー:Apache
  • 発生日時:2026年10月22日 02:54 JST
  • 関連事象:PHPパッケージ更新時にPPA側で503エラーが発生。PHP更新後にPHP-FPMおよびWebサイトの動作を検証。

さっくりとした手順

  1. PHPの脆弱性対応パッケージが更新されない事象を確認します。
  2. 一時的に Ubuntu 公式セキュリティリポジトリを直接参照する設定を追加して検証します。
  3. apt-cache policy で PHP のインストール済みバージョンと候補バージョンを確認します。
  4. ppa:ondrej/php のパッケージ(8.3.35)が更新を妨げていることを特定します。
  5. ppa-purge を導入し、PHP PPAをパージして公式パッケージへロールバックします。
  6. PHPのバージョンと関連パッケージを確認します。
  7. changelog から該当の CVE 修正パッチが含まれていることを確認します。
  8. PHP-FPMとWebサーバーを再起動します。
  9. PHP-FPMのソケット、拡張モジュール、Webサイトの応答を確認します。
  10. 一時的なAPT設定を整理し、必要に応じてPPAを再登録します。

特記事項

筆者の好みでaptitudeを用いています。必要に応じてaptに切り替えてください。

1. 発生した問題と初期事象

1.1. 脆弱性パッチが適用されない

php2shell 脆弱性への対応として、Ubuntu 公式セキュリティリポジトリ(noble-security)で配信される修正版パッケージを適用しようとしました。

しかし、以下のコマンドを実行しても、期待した PHP の更新が行われませんでした。

sudo aptitude update
sudo aptitude upgrade

一時的に security.ubuntu.com を直接参照する設定を追加して検証しましたが、更新対象として認識されない状態が続きました。

1.2. PPA側の応答遅延と503エラー

パッケージ更新を試みた際、ppa:ondrej/php 側の応答が一時的に滞り、リポジトリへのアクセスで 503 Service Unavailable が発生しました。

※この事象は、運用中のWebサイトで発生したエラーではなく、PHPパッケージの取得元である外部PPAサーバー側の応答遅延に関するものです。

PPA側の修正パッケージ配信を待たずに即時保護を図るため、Ubuntu公式セキュリティリポジトリの修正版へ切り替えるべく、PPAのパージによるロールバックを実施しました。

※これは緊急的な安全確保のための対処です。記事の後半に再び ppa:ondrej/php に戻す手順も記載しています※

2. 原因調査:APTの候補バージョンを確認

2.1. apt-cache policyを実行

apt-cache policy php8.3

実際の出力結果:

php8.3:
  インストールされているバージョン: 8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  候補:               8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  バージョンテーブル:
 *** 8.3.35-1+ubuntu24.04.1+deb.sury.org+1 500
        500 [https://ppa.launchpadcontent.net/ondrej/php/ubuntu](https://ppa.launchpadcontent.net/ondrej/php/ubuntu) noble/main amd64 Packages
        100 /var/lib/dpkg/status
     8.3.6-0ubuntu0.24.04.13 500
        500 [http://security.ubuntu.com/ubuntu](http://security.ubuntu.com/ubuntu) noble-security/main amd64 Packages
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble-updates/main amd64 Packages
     8.3.6-0ubuntu0.24.04.12 500
        500 [http://security.ubuntu.com/ubuntu](http://security.ubuntu.com/ubuntu) noble-security/main amd64 Packages
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble-updates/main amd64 Packages
     8.3.6-0maysync1 500
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble/main amd64 Packages

2.2. 原因を特定

実測結果から、以下の状態を確認しました。

  • インストール済みバージョン:8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  • APTの候補バージョン:同じく 8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  • Ubuntu公式セキュリティ版:8.3.6-0ubuntu0.24.04.13
  • PPA版と公式版のAPT優先度:いずれも 500

PPA版と公式版のAPT優先度は同じ(500)ですが、バージョン番号の比較(8.3.35 > 8.3.6)により、APTはPPA版を「より新しい最新版」と判定し、候補として固定していました。

その結果、Ubuntu公式セキュリティリポジトリに修正版が存在していても、APTからは「古いバージョンへのダウングレード」とみなされ、通常の更新では公式版への切り替えが行われない状態になっていました。

3. PPAのパージと公式パッケージへのロールバック

3.1. ppa-purgeをインストール

sudo aptitude install -y ppa-purge

3.2. PHP PPAをパージ

sudo ppa-purge ppa:ondrej/php

PPAを無効化し、関連パッケージを一括でUbuntu公式リポジトリのバージョン(8.3.6系列)へロールバックします。
※途中でパッケージの置き換えに関する確認([Y/n])が表示されたら、Y を入力して続行します。

3.3. 公式パッケージのインストール・整合性確保

ppa-purge の依存関係解決によって本体や FPM が外れてしまうケースを防ぐため、公式リポジトリから必要な主要パッケージが揃っていることを確実にします。

sudo aptitude install -y php8.3 php8.3-cli php8.3-fpm

→ ただし、実際に必要な PHP 拡張モジュールも別途確認してください。

php -v

実行結果:

PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.6, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.6, Copyright (c), by Zend Technologies

3.4. PHP関連パッケージの状態を確認

dpkg -l | grep php8.3

PHP本体、PHP-FPM、必要な拡張モジュールがすべて 8.3.6-0ubuntu0.24.04.13 に揃っていることを確認します。

3.5. 脆弱性に対応したパッチであることを確認

外部サーバーへの通信を行わず、ローカルに解凍された変更履歴から該当の CVE 修正を確認します。

zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -C 10 "CVE-2026-109618"

確認結果:

php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
      bailout in Zend/tests/bug40770.phpt, Zend/tests/bug54268.phpt,
      Zend/tests/bug76846.phpt,
...
      tests/basic/oom_rfc1867_upload_progress.phpt,
      tests/output/oom_in_internal_output_handler.phpt.
    - CVE-2026-109618
    - CVE-2026-109619

 -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Mon, 19 Oct 2026 11:16:58 -0400

パッチ(CVE-2026-109618_109619.patch)が確実に組み込まれていることを確認できました。

4. PHP-FPMとWebサーバーの復旧

4.1. PHP-FPMを再起動

sudo systemctl restart php8.3-fpm

4.2. PHP-FPMの稼働状態を確認

sudo systemctl status php8.3-fpm --no-pager

Active: active (running) となっていることを確認します。

4.3. Apacheを再起動

sudo systemctl restart apache2

Apacheが正常に稼働していることを確認します。

5. 動作検証

5.1. PHP-FPMのソケットを確認

ls -la /run/php/php8.3-fpm.sock

ソケットファイルが存在し、WebサーバーとPHP-FPM間の通信路が正常であることを確認します。

5.2. PHPの拡張モジュールを確認

php -m

アプリケーションで必要な拡張モジュールがロードされていることを確認します(mbstring, mysqli, xml, curl 等)。

※PPA削除時に外れたモジュールがある場合は、公式リポジトリから個別に追加します。

sudo aptitude install php8.3-<module_name>

5.3. Webサイトへのアクセスを確認

curl -I [https://example.com/](https://example.com/)

HTTPレスポンスを確認し、503 Service Unavailable や 502 Bad Gateway が発生せず正常(200 OK など)に応答することを確認します。ブラウザからも主要機能の動作を検証します。

6. PPAの再有効化

6.1. PPAを継続利用する場合の再登録

将来的にPPA側の修正パッケージが配信され、PPA環境へ復帰させる場合は以下の手順で再有効化します。

sudo add-apt-repository ppa:ondrej/php
sudo aptitude update

6.2. 再登録後の候補バージョン確認

apt-cache policy php8.3

PPA側で修正版(CVE対応済みビルド)が提供されていることを確認した上でアップグレードを実施します。

apt list --upgradable 2>/dev/null | grep php8.3
sudo aptitude upgrade

まとめ

今回の事象は、Ubuntu公式セキュリティリポジトリにパッチが配信されていたにもかかわらず、ppa:ondrej/php のパッケージ(8.3.35)がバージョン数値の優先度によってAPTの更新候補を占有していたことが原因でした。

apt-cache policy で優先度と候補を正確に把握し、緊急度に応じて ppa-purge による公式版への一時ロールバックを選択したことで、即座に脆弱性を塞ぎつつサービスの正常稼働を維持することができました。

PHP「php2shell」脆弱性への緊急暫定対応:PHP-FPMのSession Upload Progress無効化(追記に恒久的対応策を記載)(更に追記:CVE-2026-115560にも有効)

更に更に追記 2026/10/23 22:21

本記事でのUpload Progress無効化は、CVE-2026-115560にも有効だという点を添えておきます。

更に追記 2026/10/22 4:02

修正版にアップデートしました。

追記2026/10/21 18:25

2026/10/21 18:25現在、筆者vpsでは念には念を入れてphp-fpmを暫定停止しています。

これは付け焼き刃では対処できないと判断。

sudo systemctl stop php8.3-fpm

で止めています。

→ 修正版が出たために再開しています

概要

2026年10月21日、PHPの重大な脆弱性として報じられた「php2shell」(CVE-2026-109618、CVE-2026-109619)への暫定対応として、PHP-FPMのSession Upload Progress機能を無効化します。

本対応では、session.upload_progress.enabled を Off に設定し、PHP-FPMへ反映しますが、これは本当に緩和策でしかないようでしたが……

CVE-2026-115560の暫定措置としては依然として推奨される策のようです。

2026/10/21 20:27 追記

以下、Geminiによる要約

1. 一体どういう攻撃なのか?

「細工したHTTPリクエストをWebサイトに送るだけで、外部からサーバーのOSコマンドを実行されてしまう」攻撃です。

  • 攻撃の手口:
    攻撃者がWebブラウザやツール経由で特殊なパラメータ(セッション管理やマルチパートフォームの処理に関わるリクエスト)を送信します。
  • 発生する問題:
    PHPコア(C言語で書かれたエンジン部分)内部でメモリ破壊が発生し、Webサーバーの権限で任意のプログラム(シェルなど)を遠隔実行されます。
  • 結果:
    サーバーが丸ごと乗っ取られ、ランサムウェアの設置、データ漏洩、他サイトへの踏み台攻撃などに悪用されます。

2. 大騒ぎしている理由

主に以下の4つの理由から、世界中のエンジニアやセキュリティ企業(watchTowr、各国のCERT等)が大騒ぎしています。

  1. 深刻度スコアが最大級(CVSS 9.2 〜 10.0)
    認証(ログイン)不要、事前の権限不要で、外部ネットワークから直接狙えるため、危険度が最高レベルに設定されています。
  2. 影響範囲が広すぎる
    PHP 5系から8系に至るまで非常に幅広いバージョンが影響を受け、WordPress、Laravel、EC-CUBEなど、Web上の膨大なシステムが標的になり得ます。
  3. アプリ側の改修や設定変更では防ぎきれない
    PHPスクリプト(WordPressやPHPコード自体)の書き方で防げる問題ではなく、PHPエンジンそのもののバグです。php.ini で session.upload_progress.enabled を無効化するなどの緩和策も議論されましたが、完全な遮断には至らず「パッチ適用以外に根本解決がない」と判明したためです。
  4. PoC(実証コード)がパッチ前に出回り始めた
    公式パッチの公開直前(ゼロデイ/準ゼロデイ状態)の段階で、すでに悪用を試みる検証コードや解析情報がネット上に出回り始め、攻撃の自動ボット化が危惧されたためです。

上記理由により、本設定変更は暫定的な緩和策であり、脆弱性そのものの修正を保証するものではありません。正式な修正版PHPが提供されたら、対象バージョンと修正状況を確認したうえで更新します。

また、今回の対応前にApacheのModSecurity CRSが不審なリクエストをHTTP 403で遮断したことを確認しています。WAFによる防御とPHP実行環境の対策を重ね、複数の防御層を維持します。

環境

  • OS:Ubuntu 24.04 LTS
  • Webサーバー:Apache
  • PHP:8.3
  • PHP実行方式:PHP-FPM
  • PHP-FPM設定ファイル:/etc/php/8.3/fpm/php.ini
  • 対象設定:session.upload_progress.enabled
  • 対応目的:脆弱性に対する暫定的なリスク低減

14:00の時点で実施した、さっくりとした手順

  1. PHP-FPMの現在の設定値を確認します。
  2. PHP-FPMの設定ファイルをバックアップします。
  3. session.upload_progress.enabled を Off に変更します。
  4. PHP-FPMの設定を検査します。
  5. PHP-FPMを再読み込みします。
  6. 設定値とサービスの状態を確認します。
  7. Web経由での設定反映とアップロード機能を確認します。
  8. 正式な修正版PHPの公開状況を確認し、更新します。

詳細手順

1. 現在の設定値を確認します

PHP-FPMの設定値を確認します。

sudo php-fpm8.3 -i | grep -i 'session.upload_progress.enabled'

今回の確認結果は以下のとおりでした。

session.upload_progress.enabled => On => On

設定ファイル上では該当行がコメントアウトされていました。

;session.upload_progress.enabled = On

先頭の ; はコメントを示すため、この行自体は設定として適用されません。PHPのデフォルト値が On であるため、コメントアウトされていても機能が無効化されているとは限りません。

実際の設定値を確認し、無効化が必要であることを判断します。

2. 設定ファイルをバックアップします

変更前に、PHP-FPMの設定ファイルをバックアップします。

sudo cp -a /etc/php/8.3/fpm/php.ini /etc/php/8.3/fpm/php.ini.bak-20261021

バックアップファイルが作成されたことを確認します。

ls -l /etc/php/8.3/fpm/php.ini.bak-20261021

設定変更により問題が発生した場合は、このバックアップから元の設定へ切り戻します。

3. Session Upload Progressを無効化します

設定ファイルを編集します。

sudoedit /etc/php/8.3/fpm/php.ini

以下の設定項目を探します。

;session.upload_progress.enabled = On

コメントアウトを解除するだけではなく、値を Off に変更します。

session.upload_progress.enabled = Off

同じ設定項目を重複して追加しないようにします。

変更後、差分を確認します。

sudo diff -u /etc/php/8.3/fpm/php.ini.bak-20261021 /etc/php/8.3/fpm/php.ini

意図した設定項目だけが変更されていることを確認します。

4. PHP-FPMの設定を検査します

設定ファイルの構文を検査します。

sudo php-fpm8.3 -t

正常な場合は、設定ファイルのテストに成功した旨が表示されます。

エラーが表示された場合は、PHP-FPMを再読み込みせず、設定ファイルを修正します。

5. PHP-FPMへ設定を反映します

設定検査に成功したら、PHP-FPMを再読み込みします。

sudo systemctl reload php8.3-fpm

続いてサービスの状態を確認します。

systemctl status php8.3-fpm --no-pager

サービスが正常に稼働していることを確認します。

6. 設定値を再確認します

PHP-FPMの設定値を再確認します。

sudo php-fpm8.3 -i | grep -i 'session.upload_progress.enabled'

期待する結果は以下のとおりです。

session.upload_progress.enabled => Off => Off

ただし、このコマンドは新しく起動したPHP-FPMプロセスの設定を確認するものであり、稼働中のWebリクエストが使用する設定値を直接保証するものではありません。

必要に応じて、Web経由でPHPの設定値を確認します。確認用スクリプトを公開する場合は、外部からアクセスできないように制限し、確認後は必ず削除します。

7. Webアプリケーションの動作を確認します

設定反映後、対象のWebアプリケーションが正常に動作することを確認します。

  • Webサイトの表示
  • ログインとセッション維持
  • ファイルアップロード
  • アップロード後のファイル処理
  • ApacheとPHP-FPMのエラーログ

通常のファイルアップロード自体は、この設定変更によって原則として無効になりません。ただし、PHPのSession Upload Progress機能に依存した進捗表示などには影響する可能性があります。

作業上の注意

影響範囲

session.upload_progress.enabled = Off にすると、PHPがセッションにアップロード進捗情報を記録する機能が無効になります。

通常のファイルアップロード、ログイン、セッション管理などは、この設定変更だけで通常は影響を受けません。ただし、進捗情報を利用するアプリケーションについては動作確認が必要です。

切り戻し

変更後にアプリケーションの動作不良などが発生した場合は、バックアップから設定を復元します。

sudo cp -a /etc/php/8.3/fpm/php.ini.bak-20261021 /etc/php/8.3/fpm/php.ini

復元後、設定を検査します。

sudo php-fpm8.3 -t

検査に成功したら、PHP-FPMを再読み込みします。

sudo systemctl reload php8.3-fpm

最後にサービスの状態とWebアプリケーションの動作を確認します。

なお、切り戻しによって設定値が On に戻る場合、暫定緩和策も解除されます。切り戻しは必要な場合に限り、影響とリスクを確認して実施します。

根本対策

本対応は暫定的な緩和策です。正式な修正版PHPが公開されたら、PHP公式およびUbuntuのセキュリティ情報を確認します。

Ubuntuでは修正がバックポートされる場合があるため、バージョン番号だけで判断せず、使用中のリリースに対する修正状況を確認します。

修正版が提供されたら、実際にWebアプリケーションが使用しているPHP実行環境を更新し、動作確認を実施します。

まとめ

PHPの設定ファイルで該当項目がコメントアウトされていても、機能が無効になっているとは限りません。PHPのデフォルト値が On であれば、コメントアウトされた状態でも機能は有効です。

今回の対応では、設定ファイルの記述だけで判断せず、実際の設定値を確認したうえで Off を明示し、PHP-FPMへの反映と動作確認を行います。

WAFによるリクエスト遮断、PHP実行環境の暫定対策、修正版への更新を組み合わせ、単一の防御機構に依存しない構成を維持します。

Page 1 of 308

次

Powered by WordPress & Theme by Anders Norén