月: 2026年10月 Page 2 of 5

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

はじめに

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実行環境の暫定対策、修正版への更新を組み合わせ、単一の防御機構に依存しない構成を維持します。

To Buy, or Not to Buy ――シェイクスピアの悲劇を経て、自宅サーバ用の小型PCを買った話

はじめに

人間は、なぜ決断に苦しむのでしょうか。

シェイクスピアの『ハムレット』と『マクベス』には、決断を前にして葛藤する二人の人物が描かれています。

考え続けることで行動できなくなるハムレット。行動の代償を理解しながらも、野心に突き動かされるマクベス。

この二人の独白を思い返していた私は、電車の中でひとつの決断を迫られていました。

自宅サーバ用の小型PCを買うか、買わざるか。

という、前置きは壮大なのに結論がしょぼい、いつもの筆者の与太話が始まります。

1. ハムレットとマクベスに学ぶ、決断のコスト

To be, or not to be

『ハムレット』第3幕第1場。あまりにも有名な独白は、こう始まります。

To be, or not to be: that is the question.

「生きるべきか、死ぬべきか。それが問題だ。」

ハムレットが考えているのは、生き続ける苦痛と、すべてを終わらせることの間にある葛藤です。

何かを選ぶことは、別の可能性を捨てることでもあります。しかも、選択した先に何があるのか、必ずしもわかっているわけではありません。

ハムレットは、苦難に耐えることと、苦難に立ち向かうことを比較します。

Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles

「不条理な運命の投げる石や矢に耐えることが気高いのか。それとも、苦難の海に武器を取って立ち向かうことなのか。」

ここで重要なのは、行動することにも、行動しないことにも、それぞれ代償があるという点です。

何もしなければ現状が続く。行動すれば、今まで存在しなかった問題まで引き受けることになる。

これは心理学でいう接近・回避葛藤に通じます。ある選択肢に望ましい結果と望ましくない結果が同居していると、人はその選択に引き寄せられながら、同時にそこから逃れようともします。

さらにハムレットは、死後の世界について考えます。

The undiscover’d country, from whose bourn
No traveller returns

「誰ひとり帰ってきたことのない、未知の国。」

未知の国へ踏み出せば、元の場所には戻れないかもしれない。そもそも、その先に何があるのかさえわからない。

ここには、決断の不可逆性と不確実性が凝縮されています。そして独白は、思考が行動を妨げるという結論へ向かいます。

Thus conscience does make cowards of us all

「こうして思慮は、われわれを皆臆病者にしてしまう。」

考えること自体が悪いのではありません。問題は、考えるほど不安が増え、検討すべき可能性が際限なく広がり、いつまでも行動に移れなくなることです。

いわゆる分析麻痺。判断材料を集めるための思考が、判断そのものを先送りするための思考へと変わってしまうのです。

If it were done when ’tis done

一方、『マクベス』第1幕第7場の独白は、別の方向から決断の苦しみを描きます。

If it were done when ’tis done, then ’twere well
It were done quickly.

「もし、事を成し遂げた瞬間にすべてが終わるのなら、さっさとやってしまうのがよい。」

マクベスが考えているのは、ダンカン王の暗殺です。

王を殺害すれば、王位を手に入れられるかもしれない。しかし、殺害という行為が終わったからといって、その結果まで終わるわけではありません。

マクベスは、暴力が自分自身に返ってくる可能性を認識しています。

Bloody instructions, which, being taught, return
To plague th’inventor

「血塗られた教訓は、それを世に教えた者自身を苦しめるために戻ってくる。」

自ら暴力を行使すれば、その暴力が自分を脅かす世界を作り出すことにもなる。決断の結果は、実行した瞬間だけでなく、その後の人間関係や社会のあり方にまで及びます。

さらにマクベスは、自分を行動へ駆り立てるものの正体を理解しています。

I have no spur
To prick the sides of my intent, but only
Vaulting ambition

「私の決意を駆り立てる拍車はない。ただ、身の程を越えて跳ね上がる野心があるだけだ。」

彼には、王を殺さなければならない正当な理由がありません。それでも王になりたいという欲求を捨てられない。

ハムレットは、考え続けることで行動できなくなります。一方のマクベスは、行動の代償を理解しながらも、欲望によって一線を越えようとします。

両者に共通するのは、決断が単なる選択ではないという認識です。

何かを選べば、別の可能性を手放す。そして、選択によって変わった世界を完全に元へ戻せるとは限らない。

だからこそ、決断は苦しいのです。

2. それでも、私は小型PCを買うか悩んでいた

さて、ここからが本題です。

今まで自宅サーバとして使っていたのは、Let's note CF-XZ。

  • CPU:Core i5-7300
  • メモリ:8GB
  • SSD:256GB

これを使って、自室のサーバ環境を構築していました。

試しにNextcloudとAdGuard Homeを導入してみたところ、思いのほか快適だったのです。

何しろローカル運用。外部公開するサーバと比べれば、外部からの攻撃に備えるためのセキュリティ対策や運用上の手間は段違いに少なくなります。もちろん、ローカルだからといってセキュリティ対策が不要になるわけではありませんが、用途を絞った自室の環境としては、かなり具合がよかった。

ところが、使い続けるうちに、ひとつの問題が気になり始めました。

「いや、いい加減古い」

そして、もうひとつ。

「自室の単一障害点になりつつある」

Nextcloudが止まれば、ファイルへのアクセスが不便になる。AdGuard Homeが止まれば、DNSの名前解決に影響が出る。

つまり、DNSが死んだら自室環境が死ぬという恐怖。

便利な環境を作ったつもりが、その環境を支える機器が、今度は自分にとっての弱点になっていたのです。

もちろん、CF-XZはまだ動きます。使えるものをわざわざ買い替える必要があるのか。サーバ用途なら、今の性能でも十分なのではないか。

「それでもまだ動くし」

この言葉が、頭の中で繰り返されます。

一方で、古い機器を使い続けることにもリスクがあります。故障してから慌てて移行するより、余裕があるうちに次の環境を用意しておいた方がよい。

つまり、買い替えないことにもコストがある。

ハムレットなら、ここからさらに数幕分は悩んでくれそうです。

3. そして、セールがやってきた

そんな折、タイミングよく開催されたAmazonプライム感謝セール。

そこで見つけてしまったのです。

ほぼ4万円という、お手頃価格の小型PCを。

今回購入したのはこちら。

BOSGAME E5

項目仕様
OSWindows 11 Pro
CPUAMD Ryzen 3 5300U
メモリ16GB DDR4 RAM
ストレージ512GB M.2 NVMe PCIe 4.0 SSD
購入価格ほぼ4万円

CF-XZと比較すれば、メモリ容量は8GBから16GBへ、SSDは256GBから512GBへと増加。自室のサーバ用途として使うには、なかなか手頃な構成です。

もちろん、購入しただけで単一障害点の問題が解決するわけではありません。移行方法を考え、サービスを構築し、必要なら切り戻せるようにしておく必要があります。

それでも、約4万円で新しい環境を用意できるのであれば、検討する価値は十分にあります。

しかし、ここで再び、あの二人が頭の中に現れました。

ハムレットが問いかけます。

「To buy, or not to buy. 買うべきか、買わざるべきか」

マクベスが答えます。

「If it were done when ’tis done, then ’twere well it were done quickly. やってしまえば片がつくのなら、さっさとやってしまえばよい」

……いや、マクベスの場合は王を殺す話なので、PCの購入と同列に並べるのはさすがに問題がありますが。

それでも、両者の独白は頭の中で続きます。

まだ使える。けれど、古い。買い替えれば費用がかかる。買い替えなければ、故障時のリスクが残る。

買うか、買わざるか。

4. 決断を下したのは、時間だった

そんな逡巡を続けていたのは、電車の中でした。

ThinkPadを広げ、Amazonをブラウザで開き、小型PCを物色し、価格を確認し、仕様を比較する。

そして、ふと気づきました。

あと少しで、自宅の最寄り駅に着く。

このまま悩み続けるのか。それとも、もう決めてしまうのか。

ここで、ひとつの事実に思い至りました。

「こんな逡巡を繰り返すんだったら、サパッと決めるべき」

価格も、用途も、必要なスペックも、おおよその条件はそろっています。今ここでさらに悩んだところで、劇的に判断材料が増えるわけではありません。

  • ハムレットは、なおも考え続けるでしょう。
  • マクベスは、やってしまえば片がつくと言うでしょう。

そして私は、電車が最寄り駅に到着する前に決断しました。

購入。

かくして、注文を終えた私は、いつもの自宅へと帰っていったのでした。

おわりに

そして、現物が届きました。

BOSGAME E5。自宅サーバ用の小型PCです。

シェイクスピアの悲劇から、決断の不確実性、機会損失、不可逆性について考察し、最後に得られた結論は、ほぼ4万円の買い物でした。

しかし、今回の決断には、それなりの理由があります。古くなった機器を使い続けるリスクがあり、ローカル環境の利便性を実感しており、手頃な価格で次の環境を用意できる機会があった。

あとは、実際に移行して、安定して動く環境を作るだけです。

考え続けて何も始められないのも困る。勢いだけで進んで後始末に追われるのも困る。

必要な条件を確認し、許容できるコストを見積もり、決断する。そして、決断した後の問題に備える。

これが、今回の小型PC購入から得られた教訓です。

もっとも、シェイクスピアの悲劇を経て自宅サーバを増強するという結論が、果たして文学的に正しいのかはわかりません。

少なくとも、私の自宅サーバ環境は、またひとつ拡張されることになりました。

To buy, or not to buy.

今回は、買いました。しかも、こんな写真と共に

「買っちった」

ええ、決断の重さと得られたリターンなんて、しょせんはこの程度という、いつもの前置きは壮大、結論は単純というお話でした。

ピボット旅行2026-17『かならず腹はへる』

はじめに

先の章でも触れた『かならず朝は来る』。そして、それに呼応する『かならず腹はへる』。

この言葉を、今回の尾道旅行で使わない手はありませんでした。

NHKの朝ドラ『てっぱん』は、尾道と大阪を舞台にした作品です。そのテーマ曲「ひまわり」も、物語を彩る大切な一曲。そして、作品のキャッチコピーは「かならず、朝は来る かならず、腹は減る」。

先の章では「かならず、朝は来る」という言葉を取り上げました。ならば、こちらの言葉が出番を迎える場所は、もちろん食事です。

しかも、ただの食事ではありません。尾道に来たからには、どうしても食べたかったものがあります。

お好み焼き、そして尾道焼きです。

では、スタートです。

再訪の尾道焼き

今回の旅で、尾道に行く最大の目標が「この店でお好み焼き(尾道焼き)を食べる」ことでした。

これは、自転車で巡る予定を立てていた段階から変わりません。昼食、あるいは夕食はここで食べる。そのために行程を組むほどの目的地でした。

観光地を巡ることも、写真を撮ることも、もちろん旅の楽しみです。しかし、何を食べるかもまた、旅の軸になり得ます。

今回は、その軸が最初からはっきりしていました。

そもそも尾道焼きとは?

尾道焼きの大きな特徴は、砂ずり(砂肝)が入っていることです。

一般的なお好み焼きでおなじみの豚肉とは、ひと味違うパンチがあります。砂ずり特有の歯ごたえと味わいが、全体の印象をしっかり引っ張ってくれるのです。

この個性の強い具材を、ほかのトッピングとどう組み合わせるか。そこもまた、尾道焼きの楽しみです。

トッピングのマシマシ

今回選んだトッピングは、お餅と生だこ。

注文の際、女将さんからひとつご意見をいただきました。

「砂ずりの味が勝ちすぎるから、海老やアサリは尾道焼きに向かない」

なるほど、具材を足せば足すほどよいというものでもありません。主役の砂ずりを生かしつつ、どう組み合わせるかが大切なのです。

そう考えると、今回の選択は正解でした。いや、実際に食べた後の感想まで含めれば、大正解です。

焼き上げというエンターテインメント

注文が通った後、脳内のリングアナが高らかに宣言しました。

Following contest is scheduled for one meal, and is for main event of this Travel...

From Onomichi, Hiroshima, weighing 500g. "The Teppan", Onomichi Yaki!

……と。

旅のメインイベント、尾道焼きの登場です。

まず、小麦粉の生地を鉄板にのばす。そこに、これでもかとキャベツを載せ、中華麺を載せる。

そして、主役を迎える準備が整ったところで、具材が次々と投入されます。

  • イカ天
  • レンコン(このお店の特徴です)
  • 生だこ
  • 切り餅
  • そして、砂ずり

これらが鉄板の上に並び、焼き上がりを待つ。

注文してから食べるまでの時間も、ただ待っているだけではありません。目の前で少しずつ完成していく様子そのものが、ひとつのエンターテインメントなのです。

食べる前から、すでにメインイベントは始まっていました。

そして、この焼き上げの過程は、今でも目の前に浮かぶほど鮮明に思い出せます。

Here is your winner!!

夢にまで見た尾道焼き。しかも、今回の旅のメインイベントです。

このために、この時のために、食事を調整していたまであります。いよいよ実食。最高でした。

  • 砂ずりのパンチ力
  • 定番のイカ天がもたらす、脂のうまみと香ばしさ
  • 薄切りレンコンという、心憎い演出

それぞれが個性を発揮しながら、ひとつのお好み焼きとしてまとまっています。

そして、トッピングも大当たりでした。

生だこのコリコリした歯触りが、実に絶妙です。確かに、砂ずりと海老では、歯触りも味も砂ずりの存在感が勝ってしまいそうです。しかし、生だこなら歯ごたえがぶつかり合わず、違った方向から食感を加えてくれます。

何より、お餅がいい仕事をしています。ソースも、肉も、中華麺も、まとめて受け止めてくれる。具材それぞれの個性をつなぐ、頼もしい存在でした。

切り分ける。食べる。ソースやこしょう(尾道焼きならではのトッピング)を足す。そして、また食べる。

最後の一口を食べ終えたところで、「Cover!」からの3カウントフォールがしっかり決まりました。

今回の旅のメインイベント、決着です。

伝えられたお礼

会計の際、女将さんに「2年前にも伺いましたが、美味しくて感動しました」と伝えることができました。

前回の訪問で感じた感動を、今回もきちんと伝えられた。これもまた、再訪したからこその満足です。

旅先で食事をすることは、その土地のものを味わうだけではありません。もう一度来たいと思った場所に戻り、以前の体験を確かめ、そこで感じたことを伝える。そうした時間も、旅の一部なのだと思います。

そして、食事を終えた筆者には、ひとつ大きな問題が残されていました。

この食事のインパクトが激しすぎて、「次の目的地、どうしようか?」と思ったのです。

……それは、また別のお話です。

Page 2 of 5

Powered by WordPress & Theme by Anders Norén