カテゴリー: PC Page 1 of 65

Growi v7.5.0のアップデートメモ(nodeのアップデート含む)

Grwoiをv7.5.0にアップデートしたときのメモです。

アップデート概要

  • 対象バージョン: v7.4.7 → v7.5.0
  • 実行環境:
    • Ubuntu 24.04
    • Apache 2.4によるリバースプロキシー

主要な変更点:

  • Node アップデートによる Next.js v16 / Vite v6 / Turbopack への移行
  • リバースプロキシにy-websocket への変更、
  • RegExp.escape() の採用

前提

  • nvmでnodeのバージョンを管理していること。
  • リバースプロキシの変更手順が整っていること。

事前準備・環境更新

最新のGROWI要件に合わせ、Node.jsランタイムをアップデートしました。

-Node.jsの更新:

nvm を使用して v24.14.1 をインストール。 筆者はroot環境で実施しているため

sudo su -

で管理者権限になってから実施しました。

  • nvm バージョンアップ
nvm install 24

bash
nvm use 24

nvm alias default 24
  • ビルドツールの更新:

はまったポイントです。一度バージョンアップするとv24環境で pnpmが消えてしまうので再有効化します。

corepack enable
corepack prepare pnpm@latest --activate

ビルドプロセスの修正

後は基本的に筆者が行っているものに習います。

growiディレクトリに移動します

cd /home/www-data/growi && pwd

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

リリースタグを確認します。

  • リリースタグ取得
sudo git fetch --tags
  • リリースタグ確認
sudo git tag -l

スペースで確認していき、上記リリースサイトと同じバージョンがあることを確認します。

チェックアウトとインストールを行います。

  • 変更を一時的に退避
sudo git stash
  • チェックアウト
sudo git checkout 【バージョン】

リリースタグは再確認しましょう。今回は 2026/04/07にリリースされたv7.5.0を選択しました。

メモリ不足の対処

  • pnpm install 時のセキュリティ警告(sharpのビルド停止)およびメモリ不足対策を実施しました。
  • ネイティブバイナリの許可:
    ```bash
    pnpm approve-builds
リストから sharp を選択して許可

bash
pnpm install

- Turbopackによるビルド:

メモリ消費を抑えるため、上限を指定して実行。

bash
NODE_OPTIONS="--max-old-space-size=4096" pnpm run app:build

### リバースプロキシ (Apache) の修正


同時編集プロトコルが `y-websocket` に変更されたことに伴い、`growi.conf` の書き換えルールを厳密化しました。

修正内容: すべてのWS通信ではなく、`/yjs` パスのみをWSプロキシへ流すよう変更。

apache
# リバースプロキシー設定
RewriteEngine on

# 1. /yjs へのアクセスのみ WebSocket プロキシへ飛ばす
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{REQUEST_URI} ^/yjs [NC]
RewriteRule /(.) ws://localhost:3000/$1 [P,L]

# 2. それ以外の通常の HTTP リクエスト
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
```

起動スクリプトの修正

2度目のはまりポイントです。RegExp.escape is not a function エラー(Node.jsのバージョン不足)を解消するため、サービスが参照する PATH を更新しました。
(これは筆者環境なので)

growi-start.sh の修正:

# 旧: v20.19.2 -> 新: v24.14.1
export PATH="/root/.nvm/versions/node/v24.14.1/bin:$PATH"

Growiの再起動

  • Growiサービス開始
sudo systemctl restart growi.service
  • サービス開始確認
systemctl status growi.service

active(running)を確認します。

完了確認

  • [x] 管理画面「システム情報」にて GROWI 7.5.0 / Node.js 24.14.1 を確認。
  • [x] ページリストの取得エラー(APIエラー)が解消されたことを確認。
  • [x] ページ複製時の RegExp.escape エラーが解消されたことを確認。
  • [x] Elasticsearch v9 への接続および検索ができることを確認。

AIツールを狙ったログのメモ

筆者の公開VPSにて、昨今のトレンドと言えるようなログを確認しましたので解説です。

攻撃者のIPやホスト名をダミー(例: ATTACKER_IP, TARGET_IP)に置き換えています。わざわざIP晒しをしないのは「テロリストに名前を与えない」の精神からです。

[DATE] [security2:error] [client ATTACKER_IP_1] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/"]
[DATE] [security2:error] [client ATTACKER_IP_1] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/favicon.ico"]
[DATE] [security2:error] [client ATTACKER_IP_2] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/.git/config"]
[DATE] [security2:error] [client ATTACKER_IP_3] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/api/tags"]
[DATE] [security2:error] [client ATTACKER_IP_3] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/v1/models"]
[DATE] [security2:error] [client ATTACKER_IP_3] ModSecurity: Access denied... [id "10004"] [msg 
[DATE] [security2:error] [client ATTACKER_IP_3] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [/update_weights_from_tensor]
"Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/.well-known/mcp.json"]
[DATE] [security2:error] [client ATTACKER_IP_3] ModSecurity: Access denied... [id "10005"] [msg "Missing Host Header"] [hostname "example.com"] [uri "/"]

解説の前に

  • header is a numeric IP address
  • Missing Host Header

があることに気づく方はいるかと思います。

これは、筆者が導入しているMod_Securityに以下のカスタムルールを設けているからです。

# 1-3. IPアドレス直打ちアクセス対策 
# ポート番号が付いていても即座に拒否する
SecRule REQUEST_HEADERS:Host "@rx ^[\d.]+(:\d+)?$" \
    "id:10004,\
    phase:1,\
    deny,\
    status:404,\
    log,\
    msg:'[CUSTOM RULE] Host header is a numeric IP address (incl port). Blocked immediately.',\
    tag:'application-attack',\
    tag:'PROTOCOL_VIOLATION/INVALID_HREQ'"

# Hostヘッダーが存在しない場合は即ブロック
SecRule &REQUEST_HEADERS:Host "@eq 0" \
    "id:10005,\
    phase:1,\
    deny,\
    status:404,\
    log,\
    msg:'[CUSTOM RULE] Missing Host Header. Blocked immediately.'"

攻撃の全体的な意図:なぜ「IPアドレス」でアクセスしてくるのか?

ログの多くが 「HostヘッダーがIPアドレスである」 という理由でModSecurity(WAF)に遮断されています。これには以下の意図があります。

  • 無差別スキャン:
    • ドメイン名を知らなくても、IPアドレスの範囲(例: 192.168.0.0/16)を片っ端から叩くことで、管理が甘い「生」のサーバーを見つけ出そうとしています。
  • デフォルト設定の探索:
    • 多くのWebサーバーは、不明なドメインやIP直接指定でアクセスされた際に「デフォルトのバーチャルホスト」を表示します。ここにはテストページや管理ツールが放置されていることが多いため、そこを突こうとしています。
  • WAF/CDNの回避:
    • CloudflareなどのCDNを経由せず、サーバーの「本当のIP」に直接攻撃を仕掛けることで、上位の保護層をバイパスしようとする手法です。

各パス(URI)が狙われた理由とケーススタディ

情報漏洩の古典:/.git/config

  • 意図:
    • Gitリポジトリの露出確認。
  • 背景:
    • 開発者が誤って .git ディレクトリを公開サーバーにアップロードしてしまうミスを狙っています。これが取得されると、ソースコード、DBのパスワード、APIキー、過去の全変更履歴が盗まれます。

AI・LLM時代の新潮流:/v1/models, /api/tags, /api/version

  • 意図:
    • OllamaやLocalAI、OpenAI互換API などのエンドポイント探索。
  • 背景:
    • 昨今、自宅サーバー等でローカルLLMを動かす人が増えています。これらのツールはデフォルトで /v1/models などのパスを使用するため、認証なしでAIリソースを悪用(AI寄生)したり、モデル情報を盗んだりするためにスキャンされています。

2026年での最新トレンドの追跡:/.well-known/mcp.json, agent.json

  • 意図:
    • Model Context Protocol (MCP) 設定ファイルの探索。
  • 背景:
    • MCPは2024年末〜2025年にかけて普及し始めた、AIエージェントとツールを接続するための規格です。これがあるサーバーは「AIエージェントが操作可能なリソース」を持っている可能性が高いため、攻撃者は踏み台やデータ奪取の対象としてリストアップしようとしています。

AI学習モデルの改竄:/update_weights_from_tensor

  • 意図:
    • 学習済みモデルの「重み(Weights)」を外部から直接書き換えようとしています。
  • 背景:
    • もし成功すれば、攻撃者はサーバにインストールされているAIの判断を密かに操作できます。例えば「特定の条件の時だけ誤判定させる(バックドア)」や「特定の顔をスルーさせる」といった、AIジャックが可能です。

監視・インフラの隙:/metrics, /queue/status

  • 意図:
    • Prometheusや監視ツールの露出確認。
  • 背景:
    • /metrics にはサーバーの負荷、プロセス一覧、時には内部ネットワークの構成情報がプレーンテキストで出力されます。攻撃者にとっては、攻撃の戦略を立てるための「設計図」を手に入れるようなものです。

ここから得られること

総括

「攻撃者はドメイン名で選んでいるのではない。露出している機能(Git, AI API, 監視ツール)をポートスキャンとパス探索で機械的に探り当てている」

今後の教訓:

  • ホワイトリスト運用:
    • /api//metrics などのパスは、特定のIP以外からは404にしましょう。
  • 「隠しファイル」の禁止:
    • .git.env など、ドットで始まるディレクトリへのアクセスはWebサーバーレベルで一括拒否しましょう。

いくら最新の(今回のようなAIサーバ)を狙ったところで

  • 「対策の甘いところから狙われる」
  • 公開されたらヤバいところは共有される

という普遍性は同じ。それこそ『緋色の研究』でホームズが言う

「日の下に新しきものなし」 (Nihil novi sub sole)

ぐらいの勢いで、基本的な対策をしていきましょうという話でした。

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日に公開すべき内容ではないものでした。

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やエージェントを偽装してくる輩も多いので。

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

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

Grwoi/Apacheリバースプロキシ、セキュリティ判断FからB+まで改善した記録

昨日の続き。

HTTP ObservatoryでRedmineサイトをB-→B+に改善しましたが、

筆者環境の

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

環境のHTTP診断もそのぐらいであろうと思ったらまさかのF判定を食らいました。

Fランクの内訳

最初の診断結果では、以下の項目で派手に減点を食らっていました。

  • CSP (Content Security Policy):
    • 未設定 (-25)
  • Cookies:
    • Secure属性なし (-20)
  • HSTS: 認識されず
    • (-20)
  • X-Frame-Options / X-Content-Type-Options:
    • 認識されず (-25)

特に謎だったのが、「Apache側でHeader設定を入れているはずなのに、認識されない(Failed)」という点でした。

アプリとApacheの二重出力。

原因を調査するため、curl -I コマンドで生のレスポンスヘッダーを確認しました。

curl -I https://growi-site
Strict-Transport-Security: max-age=63072000
Strict-Transport-Security: max-age=15552000; includeSubDomains  # <-- 2重に出ている
X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff # <-- 2重に出ている
Set-Cookie: connect.sid=...; Path=/; HttpOnly  # <-- Secure属性がない

原因の分析:

リバースプロキシ構成では、「バックエンド(アプリ側)が吐き出すヘッダー」と「Apacheが追加しようとするヘッダー」が両方ブラウザに届いてしまい、重複が発生。

診断ツール側が「どの設定を信頼すべきか判断できない」としてエラーになっていたのです。

これを回避するための手段が以下の通りです。

さっくりとした手順

  1. Apacheの設定ファイルを書き換えます。
  2. 設定を反映します。
  3. 設定反映を確認します。

Apacheの設定ファイルを書き換え

  • 設定ファイルのバックアップ
sudo cp -pi /etc/apache2/sites-available/growi-site.conf /path/to/backup/growi-site.conf.$(date +%Y%m%d)

.confの名前やバックアップディレクトリは自分の環境に合わせます。

  • 設定ファイルのバックアップ確認
diff -u /path/to/backup/growi-site.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi-site.conf

エラーがないことを確認します。

/etc/apache2/sites-available/growi-site.confを以下のように修正していきます。(要管理者権限)

  • 修正前
    Header always set Strict-Transport-Security "max-age=63072000"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-XSS-Protection "1; mode=block"
  • 修正後
        # 重複を防ぐため、通常のレスポンスとProxyレスポンスの両方から一旦削除
        Header unset Strict-Transport-Security
        Header always unset Strict-Transport-Security
        Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

        Header unset X-Content-Type-Options
        Header always unset X-Content-Type-Options
        Header always set X-Content-Type-Options "nosniff"

        Header unset X-Frame-Options
        Header always unset X-Frame-Options
        Header always set X-Frame-Options "SAMEORIGIN"

        # 足りなかった重要ヘッダーを新規追加
        Header always set Referrer-Policy "strict-origin-when-cross-origin"

        # CSP: アプリの動作を維持しつつ、安全性を高める(object-src 'none' を追加)
        Header always unset Content-Security-Policy
        Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' ws: wss:; object-src 'none';"

        # CookieのSecure属性をApache側で強制付与
        Header edit Set-Cookie ^(.-)$ "$1; Secure; SameSite=Lax"

この「2重出力」を解消し、かつアプリ側で足りない属性を付与するために、Apacheの設定を「既存ヘッダーの完全掃除 + 強制セット」という戦略に変更しました。

  • 修正後の差分確認
diff -u /path/to/backup/growi-site.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi-site.conf

以下のような差分を確認します。

-    Header always set X-Content-Type-Options "nosniff"
-    Header always set X-Frame-Options "SAMEORIGIN"
-    Header always set X-XSS-Protection "1; mode=block"
+        # 重複を防ぐため、通常のレスポンスとProxyレスポンスの両方から一旦削除
+        Header unset Strict-Transport-Security
+        Header always unset Strict-Transport-Security
+        Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
+
+        Header unset X-Content-Type-Options
+        Header always unset X-Content-Type-Options
+        Header always set X-Content-Type-Options "nosniff"
+
+        Header unset X-Frame-Options
+        Header always unset X-Frame-Options
+        Header always set X-Frame-Options "SAMEORIGIN"
+
+        # 足りなかった重要ヘッダーを新規追加
+        Header always set Referrer-Policy "strict-origin-when-cross-origin"
+        
+        # CSP: アプリの動作を維持しつつ、安全性を高める(object-src 'none' を追加)
+        Header always unset Content-Security-Policy
+        Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' ws: wss:; object-src 'none';"
+
+        # CookieのSecure属性をApache側で強制付与
+        Header edit Set-Cookie ^(.-)$ "$1; Secure; SameSite=Lax"

設定反映を確認します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • サービス再起動
sudo systemctl restart apache2.service
  • サービス再起動確認
systemctl status apache2.service

active (running)を確認します。

設定反映の確認

curl -I https://growi-site
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' ws: wss:; object-src 'none';

など、ヘッダーのダブりがないことを確認します。

HTTP Observe に再度アクセスし、セキュリティ診断を行いました。

再スキャンの結果、主要な項目はすべて Passed となり、無事に B+ を獲得。

  • HSTS / XFO / NoSniff: 重複が解消され、正しく認識された。
  • Cookies: Secure/SameSite属性が付き、満点。
  • Referrer Policy: 合格。

なぜ「A+」ではないのか?

CSPにおける 'unsafe-inline''unsafe-eval' が「安全ではない」として減点対象になっています。しかし、これらを外すとモダンなWebアプリ(Wikiのエディタなど)は動かなくなることが多いため、利便性とのトレードオフとして 「B+」は現実的な落とし所と言えます。

まとめ

  1. 診断ツールで「Recognizedできない」と言われたら、まずは curl -I で重複を疑う。
  2. Apache側で Header always unset してから set することで、バックエンドとの競合を確実に排除できる。
  3. CookieのSecure化もApacheの Header edit で一発解決。

HTTP外部診断で公開用RedmineをB-からB+に向上させたときの記録。

HTTP Observe サイトのセキュリティ診断。

これで、筆者が公開しているRedmineのセキュリティを上げたときのメモです。

どう判断されたか

結果はB-。特に引っかかったのは

  • Content Security Policy(CSP)
    • Content Security Policy (CSP) header not implemented
  • Cookies
    • Session cookie set without the Secure flag, but transmission over HTTP prevented by HSTS.

何が問題なのか

クッキーの「剥き出し」状態(Secure Flag の欠如)

セッション情報(ログイン情報を保持する)が記録されたクッキーにSecureフラグが付与されていなかったため、たとえ常時httpsで通信していたとしても、ブラウザの設定や不慮の事故で通信が発生した差違に、クッキーがそのままNWに漏洩するリスクがあります。

これが漏洩し、奪われると、悪意ある第三者のなりすまし(セッションハイジャック)を可能にします。

CSPの未実装

Content-Security-Policy (CSP) ヘッダーが全く存在していなかったため、ブラウザに対して「どのスクリプトを実行していいか」が確認されていない状態。Redmineそのものや導入しているプラグインに脆弱性があった場合、攻撃者は外部から悪意あるスクリプトを注入し、閲覧者のブラウザ上で実行させるXSSに無防備となります。

個の2点を直していきます。

環境

  • Redmine 5.1
  • Apache 2.4
    • 常時SSL化設定済み。
  • Ruby 3.2.3

さっくりとした手順

  • 設定ファイルを作成します。
  • 設定を反映します。
  • セキュリティ診断でのランクアップを確認します。

設定ファイルの作成

cd /path/to/redmine/config && pwd

自分の環境のRedmineconfigディレクトリに合わせます。(筆者環境/home/www-data/redmine/config)

  • 設定ファイル作成前確認
ls -l ./initializers/additional_environment.rb

ファイルが無いことを確認します。

  • 設定ファイル作成
sudo -u www-data tee ./initializers/additional_environment.rb > /dev/null << 'EOF'
Rails.application.configure do
  # Cookie の Secure フラグを立てます
  config.session_store :cookie_store, key: '_redmine_session', secure: true

  # CSP の設定を追加します
  config.content_security_policy do |policy|
    policy.default_src :self, :https
    policy.font_src    :self, :https, :data
    policy.img_src     :self, :https, :data
    policy.object_src  :none
    # Redmine はインラインのスクリプトとスタイルを多用するため、これを許可します。
    policy.script_src  :self, :https, :unsafe_inline, :unsafe_eval
    policy.style_src   :self, :https, :unsafe_inline
  end

  # ブラウザが違反を報告するだけで、ブロックしないモードです。(デバッグ用)
  # config.content_security_policy_report_only = true
end
EOF

設定ファイル作成前確認

ls -l ./initializers/additional_environment.rb

ファイルがあることを確認します。

設定反映を確認します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • サービス再起動
sudo systemctl restart apache2.service
  • サービス再起動確認
systemctl status apache2.service

active (running)を確認します。

まとめ

HTTP Observe に再度アクセスし、セキュリティ診断を行いました。

結果はB+。

  • Contents Security Policy (CSP)
    • Content Security Policy (CSP) implemented unsafely. This includes 'unsafe-inline' or data: inside script-src, overly broad sources such as https: inside object-src or script-src, or not restricting the sources for object-src or script-src.
    • Remove unsafe-inline and data: from script-src, overly broad sources from object-src and script-src, and ensure object-src and script-src are set.

依然として課題は残るものの、ここを下手にいじると、外部プラグインとの連携などに支障を来します。

これらを狙った脆弱性はWAFで埋めて生きつつ、これらの改善案を図っていくのが今後の課題です。

Nextcloudで大容量ファイルを安定して扱うためのApacheチューニング:RequestReadTimeoutの調整

スマートフォンからの画像を自分のPCに転用する形で用いているNextcloud。

アップロードが途中で失敗したり、特定の条件下で接続が切れたりすることがあります。Apacheビルトインのmod_reqtimeout設定を最適化し、サーバーの安定性と利便性を両立させるためのチューニングを行いました。

環境

  • Nextcloud 32
  • Apache 2.4
  • PHP-FPM8.3
  • Ubuntu 24.04

そもそもmod_reqtimeoutとは?

Slowloris(スローロリス)攻撃への対策

このモジュールがビルトインされたのは、Slowlorisという、非常に低コストで強力な攻撃手法への対抗があります。

通常のDoS攻撃は大量の通信を送りますが、Slowlorisは逆に「極めてゆっくり」通信します。

  1. サーバーに接続を開始する。
  2. リクエスト(ヘッダーやボディ)を、タイムアウトにならないギリギリの遅さで、1バイトずつ小出しに送る。
  3. サーバー側は「まだデータが来るはずだ」と判断し、その接続(スレッドやプロセス)を維持し続ける。

結果 サーバーの同時接続数の上限が攻撃者の「待ち」状態で埋まってしまい、正規のユーザーがアクセスできなくなります。

mod_reqtimeout は、この「嫌がらせ」を許さないための防衛線です。

サーバーリソースの適正管理

Apacheサーバーが1つの接続を維持するには、メモリやCPUリソースを消費します。
もしタイムアウト設定がない、あるいは極端に長い場合、以下のような問題が発生します。

  • ゾンビ接続の蓄積: ネットワークが切れたのにクローズ処理が終わっていない接続が残り続ける。
  • リソースの浪費: 応答の遅いクライアント(意図的か否かに関わらず)のために、サーバーの貴重な作業枠をいつまでも空けておくことになります。

なぜこれがNextcloudで徒になるのか

Nextcloudのデータの性質と通信の仕組みにあります。

巨大なファイルを細切れにする

Nextcloudは、数MBから数GBあるような大きなファイルを送る際、一気に送らずにファイルを分割して、「チャンク(塊)」に分割して送信します。

  • 動作の流れ:
    • チャンクAを送信 → サーバーが処理 → チャンクBを送信……
  • 問題点:
    • チャンクとチャンクの間に、クライアント側でのファイル読み込みやハッシュ計算などで一瞬「無通信」の時間が流れます。
  • 結果:
    • Apacheのmod_reqtimeoutは、この無通信を先のSlowlorisと誤認して、接続をバッサリ切ってしまいます。

モバイル回線の不安定さ

Nextcloudは外出先のスマートフォンから使うことを想定しています。

  • 電波の瞬断:
    • 移動中にWi-Fiから4G/5G回線に切り替わったりする。
  • 上り速度の制限:
    • モバイル回線は「下り」は速くても「上り」が極端に遅いことが多い。

これも、先のSlowloris攻撃と見做されてしまいます。

チューニングの必要性

だからといって、このmod_reqtimeoutを無効にすると、それらの攻撃への備えがなくなります。

Nextcloudの利便性を高めつつ不審な攻撃を守るというのは

「任務」は遂行する「部下」も守る
お前ごときに「両方」やるというのはそう難しいことじゃあないな

ぐらいの精神でやっていきましょう。

さっくりとした手順

  • mod_reatimeoutの設定ファイルのバックアップを取る。
  • mod_reatimeoutの設定ファイルを修正する。
  • サービス再起動を行う。

mod_reatimeoutの設定ファイルのバックアップ

  • 念のためのモジュール確認
sudo apache2ctl -M |grep req

reqtimeout_module (shared)を確認します。(apacheをapt等で入れていれば、まず入っています)

  • ファイルバックアップ
sudo cp -pi /etc/apache2/mods-available/reqtimeout.conf /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d)

/path/to/backup/directoryは自分の環境に合わせます。

  • ファイルバックアップ確認
diff -u /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d) /etc/apache2/mods-available/reqtimeout.conf 

エラーがないことを確認します。

mod_reatimeoutの設定ファイルを修正

/etc/apache2/mods-available/reqtimeout.confを管理者権限で修正します。

筆者は以下のように行いました。

-RequestReadTimeout body=10,minrate=500
+RequestReadTimeout body=20,minrate=500

具体的には、リクエストボディ(データの送信本体)の読み取り開始を待機する時間を10秒から20秒へ延長しています。

  • body=20:
  • リクエストボディの最初の1バイトを待つ時間を20秒に設定。
  • minrate=500:
  • データが送り始められた後、最低でも秒間500バイトの転送速度を要求する。これより遅い状態が続くとタイムアウトします。
  • ファイルの差分確認
diff -u /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d) /etc/apache2/mods-available/reqtimeout.conf 

以下のような差分を確認します。

-RequestReadTimeout body=10,minrate=500
+RequestReadTimeout body=20,minrate=500

設定反映

  • 構文チェック
sudo apache2ctl configtest

Syntax OKとなることを必ず確認してください。でないと、apacheサービスが停止したままとなってしまい、サービス断が発生します。

  • Apache サービス再起動
sudo systemctl reload apache2.service
  • Apacheサービス再起動確認
systemctl status apache2.service

active(running)を確認します。

まとめ

Nextcloudサーバーにおいて、RequestReadTimeout のbody待ち時間を延長することは、「モバイル環境や大容量ファイル送信時の安定性」を向上させるために非常に有効な手段です。

もし、ログ(Apacheのerror_log)に The timeout specified has expiredrequest body read timeout といった記録が残っている場合は、この値を調整してみることをお勧めします。

  • 参考コマンド
sudo grep "request body read timeout" /var/log/apache2/error.log

Nextcloud Ver 32にアップデート後、高性能バックエンドのDockerをアップデート。

警告: 実行中のバージョン: 2.0.4~docker; サーバーはこのTalkバージョンの全ての機能をサポートしていません。欠落している機能: chat-relay

と出たので、それに対応していきます。

環境

  • Nextcloud 33.0
  • Dockerを利用して高性能バックエンドサーバ(Signaling Server)を構築。構築手順
  • それ以外はLAMP環境。
    • Apache 2.4
    • MySQL
    • PHP-FPM
    • その上でNextcloud

アップデートは、こちらの手順で、コマンドラインから行いました。

その後、管理画面で上記のエラーが出たという次第です。

やっぱり必要なフェイズ・ゼロ

このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

  • NextcloudのアップデートによりDockerコンテナもアップデートが必要。
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる
    など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

さっくりとした手順

  1. Nextcloudのメンテナンスモードを有効化します。
  2. Dockerの設定ファイルを修正します。
  3. Dockerコンテナを最多値揚げします。
  4. Nextcloudのメンテナンスモードを無効化します。
  5. エラーの解消を確認します。

メンテナンスモードを有効化

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

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

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

設定ファイル (server.conf) の構成

  • ファイルのバックアップ
sudo cp -pi /hoge/docker/files/nextcloud-signaling/server.conf /path/to/backup/directory/server.conf.$(date +%Y%m%d)

自分の環境に合わせます。

  • ファイルのバックアップ確認
diff -u /path/to/backup/directory/server.conf.$(date +%Y%m%d) /hoge/docker/files/nextcloud-signaling/server.conf

差分がないことを確認します。

  • server.confファイル修正

chat-relay 機能を有効にするため、以下のように項目を付け加えます。

  • [chat] セクション(新規追記)
[chat]
enabled = true

追記したら保存を行います。

  • ファイル修正確認
diff -u /path/to/backup/directory/server.conf.$(date +%Y%m%d) /hoge/docker/files/nextcloud-signaling/server.conf

以下の差分を確認します。

+ [chat]
+ enabled = true

Docker アップデート・再起動

これが地味にハマりました。古い docker-compose (v1.29.x等) を使用している環境だと、イメージのメタデータ構造の違いによるエラー(KeyError: 'ContainerConfig')が発生。

それを避けるための手順です。

  • 最新イメージの直接取得

docker-compose を介さず、Docker本体で最新イメージをプルする。

sudo docker pull strukturag/nextcloud-spreed-signaling:latest
sudo docker pull nats:2.9
  • 不完全なコンテナの掃除

作成失敗などで残った残骸を削除し、競合を防ぐ。

sudo docker container prune -f
  • コンテナの起動
sudo docker-compose up -d

Nextcloudのメンテナンスモードの無効化

  • メンテナンスモード無効化
sudo -u www-data php occ maintenance:mode --off
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、管理画面に入ります。

Nextcloud管理画面での反映

Nextcloudの「設定」>「Talk」にある高性能バックエンド設定で、URL横の「チェックマーク(保存)」を押し、chat-relayAvailable features に含まれたことを確認して対処完了です。

改めて思ったこと

Dockerは確かに便利な代物ですが、管理が複雑になっていくというのが難点。それ故、Dockerは最小限にして登録していきたいものです。

緊急対応:Ubuntu搭載PCが不調となったとき(initramfsエラー)の対処。

宅内でのサーバとして立てているUbuntu20.04という完全にEOLを迎えている機体。それがエラーを起こしたときのメモです。

1. 発生した事象

Ubuntu 20.04を入れているミニPCの起動時、画面に以下のメッセージが表示され、デスクトップが立ち上がらずに (initramfs) というプロンプトで停止しました。

  • sgx: disabled by BIOS
  • (initramfs) _ (入力待ち状態)

2. 原因切り分け

以下、Geminiからのアドバイス。

  • SGXのメッセージ: これは単なる「通知」であり、起動不可の直接的な原因ではないことが多い。
  • initramfsでの停止: 真の原因は、ファイルシステムの整合性エラー。強制終了や停電などで、Ubuntuがインストールされているディスク領域(パーティション)が正常に読み込めなくなったために発生します。

3. 対処手順(修復方法)

これに従って対処を行いました。

エラーを起こしたパーティションの特定

(initramfs) プロンプトで exit を入力

エラーの詳細(どのパーティションが壊れているか)を確認するために、まず exit と打ちます。

エラーメッセージからデバイス名を特定

The root filesystem on /dev/sdb2 requires a manual fsck

というメッセージが表示されました(筆者環境)これをメモします。

パーティション修復

特定したデバイス名に対して修復コマンドを実行します。

fsck /dev/sdb2 -y

-y オプションを付けることで、すべての修復箇所を自動で「Yes」として処理します。

修復完了後の再起動

FILE SYSTEM WAS MODIFIED と表示されたら、以下のコマンドで再起動(またはブート続行)を試みます。

reboot

または

exit

結局原因は?

機器が古すぎたためのディスクエラー につきます。

これが仕事でしたら「さっさと取り替えろ」「いや、取り替えないように準備する」なのですが、自分の環境なのでそうはいかず。

なんとか予算と時間を見つけてリプレースをする必要に迫られました。

Page 1 of 65

Powered by WordPress & Theme by Anders Norén