投稿者: manualmaton Page 1 of 287

進む誘惑、留まる勇気。(IDEA SPHERE)

雑多な事柄を無理矢理一つにまとめるエッセイに似た何か『IDEA SPHERE』の一節。

拙稿で取り上げているサーバ運用時の心構え

この大本のきっかけとなった「なぜ、切り戻しが大切か」という原体験を述べようと思います。

遭難、一歩手前。

話はかなり昔。筆者が訪れたベルナー・オーバーラント地方の4泊滞在

ものすごくさっくり言うと

  1. 観光ガイド地図では近そうだからと歩くのを試みた。
  2. 人気が無い道だけど下れば平気と思い込んでいた。
  3. 軽食を取っているときにユングフラウの雲に傘がかかっていた
  4. これはヤバいと引き返し
  5. 駅に着くと同時に雨
  6. そして本当に正しい道が分かった

この、「一歩でも間違えば客死寸前」というよりも「生きていたのが不思議」という体験。なぜ、人はこれに陥るのか?

それを紐解いていきます。

STOPの原則とサンクコスト

その背景には、人間の判断を狂わせる強力な心理的トラップと、それを打破するための基本的なプロトコルが欠けていたことにあります。

ここで重要になるのが、「サンクコスト(埋没費用)のバイアス」と、回避策としての「STOP」の概念です。

サンクコストの罠:「ここまで来たから」という呪縛

「せっかくここまで歩いたのだから」「もう少し進めば着くはずだ」という思考こそが、サンクコストのバイアスです。それまでに費やした時間や労力を惜しむあまり、客観的に見て「引き返すのが正解」という状況でも、損を認めたくない心理から無理な続行を選択してしまいます。

ガチャなどでも「10連でお目当てのSSRが引けないから次の10連こそ」で石を使い切り、追い課金をしてドツボにハマるアレです。

STOP:冷静さを取り戻すための技術

このバイアスを断ち切り、致命的な結果を回避するために有効なのが、登山の危機管理などでも用いられる「STOP」の法則です。

  • S (Stop) / 止まる:
    • 異変を感じたら、物理的に足を止める。焦燥感から逃れるための第一歩です。
  • T (Think) / 考える:
    • 現在の状況を冷静に分析する。感情を切り離し、事実のみを見つめます。
  • O (Observe) / 観察する:
    • 周囲の天候、道筋、自分の体力を客観的に見る。「雲に傘がかかっている」という兆候を見逃さないことです。
  • P (Plan) / 計画する:
    • 進むべきか、退くべきか。最善の安全策を再構築する。

「進む誘惑」を振り切り、「留まる(あるいは引き返す)勇気」を持つこと。この判断の遅れが、システム運用における障害の深刻化や、山岳における遭難の引き金となります。私の体験を、もう少し詳しく紐解いていきましょう。

いつものように長い全文(マクラ)と筆者の実例というスタイルです。

当初の「問題」:タグの数珠つなぎ検索

筆者が運営しているRedmineサイト。特定のプロジェクトページ(/projects/hoge)に対し、以下のようなリクエストが大量に発生していました。

GET /projects/hoge/search?tag=A,B,C,D,E,F...

カンマ(,)やURLエンコードされた区切り文字を使い、タグを5個も10個も連結して検索を繰り返す挙動です。これは明らかにサイト構造を網羅しようとするスクレイピング(採取)ボットの動きであり、アプリケーションのDB負荷を無駄に高めていました。

当初の「改善案」:ModSecurityでの防御

この「異常なタグの連結」を検知するため、ModSecurity(WAF)にカスタムルールを投入しました。

# 引数 "tag" の中にカンマが3つ以上あればブロック
SecRule REQUEST_URI "@contains /projects/hoge" \
    "id:10010,phase:1,chain,deny,status:404,nolog,msg:'Excessive tag stacking'"
    SecRule ARGS:tag "(?i)(?:%2c|,).?(?:%2c|,).?(?:%2c|,)"

「404を返し、かつ nolog で静かに処理する」という、完璧な罠を仕掛けたはずでした。

失敗:静寂を破る「Googlebot」のログ浮上

ルールを適用した直後、おかしな現象が起きました。これまでアクセスログへの出力を抑制(dontlog)していた Googlebot などの正規クローラーのログが、突如として出力され始めたのです。

ボットを黙らせるために設定を追加したのに、逆に「普段は隠れているはずのログ」が溢れ出す本末転倒な事態。ここで私は、

「軽微な修正ですぐに直るはずだ」

という思い込みに囚われました。ModSecurityのフラグをいじり、設定の微調整を繰り返します。しかし、ログの奔流は止まりません。

画面を埋め尽くす不毛なログ。高まる焦燥感。私は「なぜ」と自問しながら、STOP原則から最も遠い場所にいました。

踏み止まる勇気:サンクコストを捨てる「STOP」

「せっかくここまでルールを書いたのだから」
「あと一行修正すれば動くはずだ」

この心理こそが、ベルナー・オーバーラントの脇道で感じた「進む誘惑」、すなわちサンクコストのバイアスでした。

混濁する思考を救ったのは、かつての教訓から学んだ「STOP」の原則です。

  • S (Stop):
    • キーボードを叩く手を止め、一旦モニターから目を逸らす。
  • T (Think):
    • 「なぜ、本来無関係なログが出るのか?」という根本に立ち返る。
  • O (Observe):
    • 自分の呼吸が浅くなっていること、そして「何か食べて落ち着こう」と、判断する。
  • P (Plan):
    • 復旧策はそこからでも遅くない、と計画する。

炭酸水で出したお茶を飲み、空腹を満たして一息ついたとき、ようやく冷静な判断が戻ってきました。

「今の自分は、壊れた防衛線を直そうとして、さらに傷を広げている」と。

ここで私は、事前に取っておいたバックアップによる「切り戻し」を決断します。設定を完全に修正前の状態へロールバックしたのです。

失敗の原因:「ModSecurityの干渉」

真っ新な状態に戻って観察して、ようやく原因が見えてきました。ModSecurity の phase:1deny を行うと、Apache の処理サイクルがその時点で中断してしまいます。

本来、Apache側で「このUser-Agentならログを出さない」という env=!dontlog の判定を通る前に、WAF側の処理が割り込んだことで、ログ制御のフラグ管理がバイパスされていたのです。

次のアプローチ:Apacheレイヤーでの「入口断絶」

WAFに固執するのをやめ、より手前の Apache レイヤー(mod_rewrite)で、物理的に遮断とログ抑制を同時に行う作戦に切り替えました。

また、ボットが「カンマ」を「読点()」に変えてフィルターを回避しようとする動きも見せたため、それらも網羅する正規表現に強化しました。

修正後の設定(.conf)

<IfModule mod_rewrite.c>
    RewriteEngine On

    # 1. パスと異常なクエリ(タグ3つ以上のスタッキング)を特定
    SetEnvIf Request_URI "^/projects/hoge" is_target_path
    SetEnvIf Query_String "tag=.(%2c|,|%e3%80%81).(%2c|,|%e3%80%81).(%2c|,|%e3%80%81)" bad_bot

    # 2. 条件一致ならログを抑制(dontlog)しつつ、404で追い返す
    RewriteCond %{ENV:is_target_path} 1
    RewriteCond %{ENV:bad_bot} 1
    RewriteRule ^ - [E=dontlog:1,R=404,L]
</IfModule>

成功:ログの静寂

この設定を反映した結果、効果は絶大でした。

  • 採取ボット:
    • 404を返されつつ、dontlog によってアクセスログから完全に姿を消しました。
  • 正規ユーザー:
    • 普段通り 200 OK でアクセスでき、ログも正しく記録されます。
  • Googlebot:
    • 以前のように、音もなく巡回を続けています。

一度すべてを白紙に戻す「勇気」が、結果として最短ルートでの解決を導いたのです。

まとめ

きちんとした手順に則ったリリース作業などと違い、個人でやっているサイト運営は「このぐらいなら大丈夫だろう」が甚大な被害を生むことが多々あります。

これこそ、

  • プログラム1つの更新
  • 設定ファイルの修正
  • コマンドミス

などで、サーバは瓦解します。しかも、自分の指先一つで壊れるのですから、何があっても

誰かのせいにしたいが自分の顔しか思い浮かばない
I'm casting around in my head for someone to blame and it's just me, keeps coming back at me.

と筆者が冒頭で述べたことであり、『むこうぶち』で江崎が言った

「船が陸にたどり着く寸前に生憎の嵐……
どうすればいいと思います?
いったん沖に引き返すんですよ
船ってのは水に浮かぶようにできているんです
無闇に上陸を焦って座礁する事が一番怖い」

を自分が引き合いに出しておきながらそれを無視したという超特大のブーメランが自分に向かって飛んできたというお話しでした。

可搬性とサイズダウン(弁当メモ)

ランチバッグを新調したことで弁当箱もサイズアップしましたが……

「やはり鞄の中でずれてしまい傾く」リスクがあったので、

この、丸い縦型に戻りました。ややサイズダウンは否めませんが、ここのところ体重も増えてきたのでちょうどいいサイズと見ます。

今回の副菜は、いつものポテサラよりも大きく簡便化。

  • 中華クラゲ
  • 切り落としのサラダチキン
  • カニカマ
  • 刻みネギ

以上。ネギ以外の全てに味がついているので

単に混ぜるだけというのもお気に入りです。

桜と魚。

平日の休みで軽い花見と昼食。

今回、試したレンズは頂き物の

汎用ズームレンズとキャップレンズのフィッシュアイです。

愛宕神社の桜

いつものレンズと勝手が違ったという印象。これはもう少し精進が必要です。

葛西臨海水族園

おなじみのフィッシュカクテル。季節に合わせて桜のソーダと甘み、クラゲの水まんじゅうをチョイス。

  • 醤油風味のマグロのナゲットという他では見られないチョイス
  • 大容量のフライヤーと常に循環する油による抜群の油の切れ
  • 人が絶えない場所柄、常に揚げたてが提供される

それで650円という絶妙なチョイスにより、ここの隠れた人気メニューまで見えます。

なお、フィッシュアイでの水槽が取れたので満足でした。

NAS移行後の展望。

  • 初期設定
  • NAS構築後のHDD初期不良

を乗り越え、無事に移行も完了。次のフェイズに関する簡単なメモです。

宅内サーバ環境の刷新。

さすがにUbuntu 20.04が動き続けるというのは忍びないので、これもHWを変えたいです。昨今、ミニPCも高くなってきているのでその辺は様子を見ながら。

それこそ転がっているノートPCあたりをベースにするのも視野に入れています。

旧NASの外部ディスク転用。

2015年に購入したNASですが、メインのストレージではなく、先のサーバ環境の外部ディスクとして用いるには十分。(さすがにこの際はディスクを変えないとですが)

いずれにしても、これまでのデータを複数取り込むことができたのはありがたい限り。

余談

膨大な写真データのなから、コーンウォールを訪れた際のこういう写真を発掘できたのは割と収穫です。

Growi環境:axiosサプライチェーンの影響確認。

2026年3月31日に発覚したaxiosのサプライチェーン攻撃

内容を聞くだけでゾッとする話だったので、調べつつ筆者がインターネット上に設置しているgrowiサーバでの影響を調べました。

筆者環境

  • Growi v7.4.7
  • npm 11.4.0
  • Apache 2.4によるリバースプロキシー
  • Ubuntu 24.04

自環境の白黒確認

まずは、動いている環境のaxiosバージョンを特定することが最優先。筆者はこのライブラリを恥ずかしながら聞くまで知らなかったのですが 、JavaScriptのデファクトスタンダード的なHTTPクライアントライブラリ と聞いたので「絶対に入っているだろう」の断定で動きました。

調査コマンド

  • Growiのルートディレクトリに移動
cd /path/to/growi

自分の環境に合わせます(筆者環境/home/www-data/growi)

  • インストール済みaxiosの調査 
npm ls axios

または

 cat pnpm-lock.yaml |grep axios
  • 調査結果
axios@1.11.0

axios@0.26.1

axios@0.21.4

判定:安全

影響を受けるバージョンは

  • axios@1.14.1
  • axios@0.30.4

そのため、攻撃対象となったaxiosを利用していない(つまり、攻撃コードは混入していない)ものとなっています。

念のための確認

ほぼないとは思いますが「npm updateを実行してしまったかも」の場合は、今回のケースで攻撃者が埋め込んだマルウェアが生成するディレクトリの有無を調べます。

find node_modules -name "plain-crypto-js"

結果、何もなければ物理的にもクリーンです。

また、筆者は該当vpsでBookStackやsnipe-itなどのLaravelライブラリを動かしていますが

cd /path/to/BookStack && pwd
npm ls axios
BookStack@ /home/www-data/BookStack

└── (empty)

と、いずれも(PHPメインであるためか)動いていない状態が分かりました。

サプライチェーン攻撃の危険さ

開発者が信頼している公式ツールをそのまま使っただけで感染する状態であった点にあります。供給者のツールに攻撃ツールを仕込んでいたということで「サプライチェーン攻撃」だそうで。(発覚後、npm が悪性 axios バージョンを削除)

シーケンス

これをmermaid.jsにまとめたのがこちら。

sequenceDiagram participant Dev as 開発者 / サーバー participant NPM as npm レジストリ participant Mal as 悪意のあるパッケージ<br/>(plain-crypto-js) participant C2 as 攻撃者サーバー<br/>(C2サーバー) Note over Dev, NPM: 1. 汚染された axios@1.14.1 を要求 Dev->>NPM: npm install (axios要求) NPM-->>Dev: axios と依存の plain-crypto-js を配信 Note over Dev: 2. インストール直後にフックが発動 Dev->>Dev: postinstall: node setup.js を自動実行 Note over Dev, C2: 3. OSを判別し、マルウェアを落とし込む Dev->>C2: 難読化解除 + OS情報送信 + 通信開始 C2-->>Dev: 各OS用ペイロード (Mac/Win/Linux) を送信 rect rgb(240, 240, 240) Note right of Dev: Linuxの場合: /tmp/ld.py を実行<br/>Windowsの場合: 隠しPowerShellを実行 end Note over Dev: 4. 証拠隠滅 (セルフデストラクト) Dev->>Dev: setup.js を削除 Dev->>Dev: package.json をクリーンな状態に書き換え Note over Dev: node_modules 内は<br/>一見シロに見える

恐ろしさのポイント

  1. 自動実行: npm install した瞬間に、何も操作せずともウイルス(RAT)が仕込まれます。
  2. OS別の狙撃: Linux、Windows、macOSそれぞれに最適な攻撃コードが送り込まれます。
  3. 証拠隠滅: 実行後に自分自身の痕跡(setup.js)を消去し、package.json を書き換えて「何事もなかったかのように」振る舞います。

今後の対策と教訓

たまたまGrowiのアップデートタイミングとずれていた、そして、 pnpm-lock.yamlがあるおかげで、意図しない汚染版の混入を防ぐことができました。

なお、今回のケースで「黒」だった場合は、該当axiosの除去に留まりません。

VPS乗の全ての認証情報

  • SSH鍵
  • APIトークン

などが漏洩されたものとして作り直す必要があります。

以上、4月1日に公開すべき内容ではないものでした。

TS-216Gセットアップ中の初期不良対応。2/2

NASセットアップ中に起きたHDD初期不良。

これに対してどのようなサポートをし、復旧させたかのメモです。

大前提

サポートを受けられる権利の確認。

これが一番大切です。そもそも、メーカーにしても代理店にしても「故障した」って連絡はまず受け取りたくないもの。

  • 購入したという証跡(レシートや注文番号)
  • 機器のシリアルナンバー

は必須です。特に、大手代理店やメーカーは、「これは確実にうちのメーカーの正当なものである」というデータベースを持っていますから、その紐付けのためにも上記二つは持っておきましょう。

現状維持。

また、機器の外箱や梱包材なども持っておいたことが今回のスムーズな解決につながります。購入したらすぐ捨てるという断捨離精神は「機器の移行」では命取りになりやすいです。

問い合わせの内容

上記、準備ができたらメールなり問い合わせフォームなどで確認。

サポートへの報告例の前の余談

買ったばかりの製品がいきなり故障。そら、感情的になります。「高い金払わせておいて」の気持ちが先に来るのは当然です。

しかし、前項で示した「バスタブ曲線」であるように、初期不良はつきものです。実際に秋葉原などのパーツ屋で「初期不良は○日以内」ということを聞いた方もいるでしょう。

  • 初期不良は起こり得るもの。だから販売店はその方法を明示している
  • であれば、そのプロトコルに則る

が、結果的に最速の復旧となります。

サポートへ聞いてみる

これは、筆者の祖母が生前によく言っていたことですが;

「丸い卵も切り様で四角。言葉も言い様で角が立つ」
「聞き間違いは言い手の責任。言い間違いは聞き手の責任」

は、今の大炎上時代を見越したとしか思えない言葉。

  1. サポート担当が「じゃあ、助けよう」と気持ちよく手配できる
  2. 互いに誤解を生まない表現

は必要です。

筆者はこんな感じでサポートに聞きました。

ご担当者様

お世話になっております。

○月X日、購入店(または購入サイト名)にて

- 購入したもの1
- 購入したもの2
- 購入したもの3...

を、注文番号:xxxxxxxx で購入いたしましたところ、以下の不良が発生しましたので対応をお願いしたいです。

【不良が起きた製品】

HDD (シリアルナンバー)

【状況概略】
セットアップ中、ディスク読み取りエラーとなって認識されない状況となっております。

【具体的なメッセージ】

TS-216Gの管理画面で
「1つ以上の回復不能な読み取り/書き込みエラーが検出されました。ディスクを交換することを検討してください

のエラーが発生しています。(添付をご参照ください)

QNAP本体もDisk2が赤く点灯しておりました。

〔QNAP本体のエラー〕
以下を確認しております。
エラー    2026-03-27    01:02:40    ---    ---    localhost    ---    Storage & Snapshots    Disk    [Storage & Snapshots] Disk "Host: 3.5" SATA HDD 2" failed. Volume: HOLD, Storage pool: 1.

【事象発生時の操作】
以下を行いました。

1. HDD装填
2. ディスクの認識
3. RAID構築
4. ボリューム作成
5. ボリューム作成後に上記エラーを発見。

【事象発生後に実施したこと】

1. QNAP本体の再起動 → 変化無し
2. ディスクのさし直し → 変化無し

【推定される事象と依頼】

初期不良と思われます。同品交換をお願いできますでしょうか。
または、そうでないならば、対応方法をご教示ください

ここでのポイント

5W1Hの確認

「いつ、どの様な操作で、何が起きたか」は確実に伝えましょう。

あくまでも人為的な/故意ではないことを伝える

これが「サポート埒外の操作をしていた」「ブチ切れて機器を床にたたき落とした」等は話を聞いてもらえないでしょう。

何をやっていたかは正常に伝えましょう。

事象の概略→詳報の順番。

相手は何百、何千と問い合わせに対応しています。その対応の是非をトリアージしています。なので「これは早急に対処が必要だ」という書き方のためにも

  1. まず何が起きたか
  2. 何をしたらこうなったか
  3. どうして欲しいか

の3点の順番で伝えると、担当者は「これはすぐに動かねば」となります。

サポートの対応結果

驚くほど迅速でした。

  1. 障害が起きたパーツ(HDD)を交換する
  2. その手配をしたので都合のつく日時を教えてほしい

旨を伝えられたので、それを連絡。

そして、すぐに到着。もちろん、それに備えて

  • 可能な限りの原状復帰
    • HDDを静電気保護袋
    • 梱包材
    • 外箱

に入れて、その中に

  1. 購入履歴のコピー
  2. 発生した障害のメモ

を添えて、担当者が分かりやすい様にしておきます。

状況解決

新しいHDDが到着して、ディスクをQNAPのベイに入れたところ無事認識!

RAIDの構築も正常に行えたので本当に良かったです。

今回のまとめ

構築中に起きた出来事に救われた

これに尽きます。移行時のミスだったので切り戻し、手戻りは容易です。
バスタブ曲線の最初の段階で起きたので迅速な対応ができました。

信頼できる店舗で買えたこと。

そもそも、15年以上も前のデータや父のデジタル遺産を引き継いだ背景もあり「製品の信頼性」が第一でした。
そのため、「どこで買うか」というのは「どのメーカーのもので買うか」以上に重要です。

今回、QNAP/WDという信頼と実績あるメーカーを、信頼できる店舗(TSUKUMO)で買ったのは、販売実績とサポートが厚いという2点によるところが大きいです。

本当のコストパフォーマンスとは

この言葉が叫ばれて久しいですが、筆者は「コストとやらの本質を見失っていないか」という疑問があります。

というのも、「近所のスーパーより10円安いから」といって卵を隣町のスーパーで

  • 交通費
  • 時間

をかけて手に入れるという行為は、「10円の価値があるのか?」です。特に人間というやつ、かかったコストは計算できてもかかった時間は無頓着になりがちです。

例えばこれが出所が怪しい店舗で、連絡手段がよくわからない店で買っていたら障害発生後の即交換は望めなかったでしょう。

新たな10年に向けて

購入して10年超というNASの移行はなかなかのドラマがありましたが:
新たなデータストレージの引き継ぎがなんとか解決に向かって一安心でした。

次の10年も無事に持つかどうか、それこそ、大切に適切に扱っていきたいです。

TS-216Gセットアップ中の初期不良対応。1/2

TS-216Gセットアップ中、まさかの事象が起き、それを解決しようとしたときのメモです。

  1. NASの初期設定を終えて
  2. ストレージプールとボリュームを作成し
  3. いよいよデータの移行をしよう

と、一番大事な写真データを新しいNASに移行し、目処が立ったところでNAS本体を確認すると「LEDが一つ赤点灯」。

「赤?」思いながらNASの管理画面を見ると

2026-03-27 01:02:40 --- --- localhost --- Storage & Snapshots Disk [Storage & Snapshots] Disk "Host: 3.5" SATA HDD 2" failed. Volume: vol01, Storage pool: 1.

と、マウントしていない旨の連絡。更に、ディスクの状況でも

「ディスクS.M.A.R.T情報を読み取ることができません。全てのディスクが公式互換性リストに登録されていることを確認してください。
ディスクアクセス履歴:エラー
ディスクS.M.A.R.T情報:エラー

また、ストレージプールを見ても「メンバーではない」という状況です。

導入して1週間も経っていないので、対応を行います。

やったこと

NAS本体の再起動

この手のハードウェア初期構築時の基本です。

しかしNG。

ディスクのさし直し

幸い、RAID1で組んだディスクは「ホットスワップ」可能です。つまり、1本ダメでももう1本が正常であれば機器の通電中だろうとディスクの取り外しと交換が可能です。

しかしこちらもNG。

導かれる結論:初期不良

バルク品だろうとリテール品だろうと発生する「初期不良」にとっ捕まりました。いわゆる「バスタブ曲線」の最初の高い位置にあるところです。

そもそもバスタブ曲線とは?

以下、Geminiによる解説。

  • 初期故障期 (Infant Mortality Period)
    • 使い始めの時期に発生する故障です。
      • 特徴: 稼働開始直後は故障率が高く、時間の経過とともに急速に減少します。
      • 主な原因: 設計ミス、製造不良、不適切な部品の混入など。
  • 偶発故障期 (Random Failure Period)
    • 初期故障が収まり、故障率が低く安定している時期です。
      • 特徴: 故障がいつ起こるか予測しにくく、一定の低い故障率を維持します。
      • 主な原因: 予期せぬ過負荷、操作ミス、落雷などの外部要因。
  • 摩耗故障期 (Wear-out Failure Period)
    • 長期間の使用により、故障率が再び上昇し始める時期です。
      • 特徴: 部品の寿命や劣化が原因で、故障が多発します。
      • 主な原因: 摩耗、疲労、腐食、酸化などの物理的・化学的な劣化。

この、「初期故障機」に捕まりました。

嘆いていっても事態が変わるわけでもなし。やれることをやっていきます。

『未来戦隊タイムレンジャー』の

未来は変えられなくたって、自分達の明日ぐらい変えようぜ!

の精神。それに、「初期対応が可能な帰還。それも移行中」にこの不良が見つかったのはむしろ幸いと言えます。正当な権利として購入店に対応を依頼できるのですから。

というわけで、次のエントリーではこの対応のメモを記します。

TLSの矛盾で読み解くエージェント偽装の対応。

筆者はUbuntu環境のApache設定で

  • 不審なIP/NWをブロック
  • 過剰にアクセスしてくるクローラーをエージェントで判別してブロック

というセキュリティ対策を取っています。(詳細)

しかし、これは相手もその辺りの呼吸をわきまえていて、

  • まだブロックされていない/もしくは攻撃者がよく使うASN「ではない」アクセス元から
  • 正常なアクセスを装って
  • 情報を袖手したり攻撃の糸口をつかもうとする

パターンが割とあります。今回、それを検知した時のお話。

不自然に見えたログ

例によってURLとIPアドレスはダミーですが、以下のような奇妙なログを見つけました。

192.0.2.10 - - [27/Mar/2026:10:28:03 +0900] "GET /images/?1770681132 HTTP/1.1" 404 5506 "-" "Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.4601.1280 Mobile Safari/537.36"

一見、ただの404エラーではありますが、強烈な違和感を覚えました。

違和感1「古いAndroid端末」

Android 5.0は、2018年頃に公式セキュリティサポート終了。GooglePlay開発者サービスも2024年7月には終わっています。

違和感2「古いChrome」

同じくChrome60。これも2017年と古いバージョンです。

違和感3「TLS1.3貫通」

そんな古いAndroidが筆者のサイトにアクセスできるということはまず、あり得ません。種を明かしてしまうと、筆者のWebサイトは

#SSL対応
  SSLEngine on
    Protocols h2 http/1.1
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2

として、TLS1.3未満のアクセスができないようになっています。 この暗号化形式をサポートするようになったのはAndroid10以降。

結論:エージェント偽装。

古いAndroidが新しいSSL暗号が施されたサイトには、そもそもアクセス不可能です。リクエストの段階でハンドシェイクが拒否されるため、404エラーどころかWebサイトそのものが見られません。

しかし、上記のアクセスログは「古いAndroidのバージョンからTLS1.3のSSLログが残る」。つまり、残る結論はほぼ「エージェントを偽装してくるクローラー」に限られます。

アプリ開発者が Conscrypt(Google製のセキュリティライブラリ)などをアプリに同梱している場合は、Android 4.4以降の古い端末でもアプリ単位でTLS 1.3通信を行える場合がありますが、そんな回りくどい方法はないでしょう

措置:新たなエージェント拒否を追加。

筆者の「厄介なエージェントを拒否する」仕組みがこちら。

  • apache側
(省略)
    # botのアクセスリストを外部ファイルから読み込む
    Include /etc/apache2/conf-enabled/bad-bot-list.conf
(省略)
        <RequireAll>
            # bad_bot変数がセットされていたらアクセスを拒否
            Require not env bad_bot
            # それ以外は許可
            Require all granted
        </RequireAll>
  • bad-bot-list.conf
SetEnvIfNoCase User-Agent "facebookexternalhit/1\.1" bad_bot dontlog
SetEnvIfNoCase User-Agent "SemrushBot/7~bl" bad_bot dontlog
SetEnvIfNoCase User-Agent "AhrefsBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "MJ12bot" bad_bot dontlog
SetEnvIfNoCase User-Agent "DotBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Baiduspider" bad_bot dontlog
SetEnvIfNoCase User-Agent "YandexBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Sogou web spider" bad_bot dontlog

等。この、SetEnvIfNoCase User-Agentの箇所に、以下を加えます。

# Android 10.0未満  を排除する
SetEnvIfNoCase User-Agent "Android [1-9]\." bad_bot dontlog

# 10年以上前の古いOS(Windows XP/Vista等)を装うボットも排除
SetEnvIfNoCase User-Agent "Windows NT [3-5]\." bad_bot dontlog

# その他、不自然な挙動を示すUA群
SetEnvIfNoCase User-Agent "^$" bad_bot dontlog

後は

sudo apache2ctl configtest
sudo systemctl reload apache2.service

で、上記、不自然なログのアクセスはピタリと止まりました。

まとめ

不正アクセスにはユーザーのみならず

  • IPアドレス
  • ドメイン

はもとより、OSやエージェントを偽装してくる輩も多いので。

だが…………
マヌケは見つかったようだな

ぐらいの勢いでアクセスログを観察していきましょうというお話でした。

TS-216Gセットアップ完了。

昨日からの作業ログです。

ストレージ基盤の確定

※先日からのステータス

  • RAID同期完了:
    • RAID 1 (ミラーリング) のビルドが正常終了。

ボリューム、ドライブ作成

  • ボリューム作成:
    • ドライブの確認
      • タイプ: シックボリューム (Thick Volume)
      • 任意の名前のエイリアス
      • 容量: 4.2 TB (プール残容量 1.62 TB をバッファとして確保)

設定後、構築・フォーマット完了、「準備完了」を確認。

ネットワーク・セキュリティ設計

  • ドメイン連携:
    • 独自ドメインでの名前解決を確認。
  • SSL証明書省略:
    • 直接インポート試行時に手持ちのWebサイト用のワイルドカード証明書をインポートしようとしましたが、ECDSA アルゴリズム非対応によるエラーを確認。
    • 運用負荷(3ヶ月更新)と汎用性を考慮し、この段階でのWeb画面のSSL設定はオミット。リバースプロキシを試すなりを行います。

システムメンテナンス

  • ファームウェア更新:
    • バージョン: 5.1.5.2645 → 5.2.9.3410 (Build 20260214)

最新状態へのアップデートおよび再起動を実施。

最終疎通確認

  • SMBアクセス:
    • Windowsエクスプローラーより \\NASのドメイン へのアクセスおよび Public/work フォルダの視認を確認。

TS-216Gセットアップ開始。

開封

本体を開封したのがこちら。重さはずっしり。

作業ログ

1. 導入フェーズ

  • 機材選定:
    • QNAP TS-216G / WD Red Plus 8TB (WD80EFPX) ×2
  • 物理セットアップ:
    • HDD装填、ネットワーク接続完了

2. 初期初期化フェーズ

  • デバイス検出:
    • Qfinder ProをPCにインストール。ネットワーク上の対象機器を補足
  • NAS名と管理者名をセットアップ。パスワードも設定。
  • 時間設定:
    • タイムゾーン(JST)、NTP同期 (pool.ntp.org) 成功
  • NW設定:
    • 静的IPアドレス固定。後にサーバでも使うことになるため。
  • ファームウェア運用:
    • 通知のみ、自動更新なし(管理者手動制御)操作中のファイル操作を防ぐため。

ストレージ構築フェーズ

  • 物理確認:
    • HDD 2基の正常認識を確認
  • プール作成:
    • ストレージプール 1 の構築開始
  • RAID構成:
    • RAID 1 (ミラーリング)
  • データ保護:
    • スナップショット領域 20% 確保
  • ボリューム設計:
    • シックボリューム(Thick Volume)採用確定

現在状況:

RAID同期(リシンク)実行中。8TBのディスクの同期なので、これは待ちの状況。新しい機器のセットアップは面倒ですが子心躍ります。

Page 1 of 287

Powered by WordPress & Theme by Anders Norén