カテゴリー: ガジェット Page 1 of 103

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のディスクの同期なので、これは待ちの状況。新しい機器のセットアップは面倒ですが子心躍ります。

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で埋めて生きつつ、これらの改善案を図っていくのが今後の課題です。

NAS新調。TS-216G選定理由。

デジタルデータの保管庫として、自室で稼働し続けてきたNAS。気づけば導入から10年という月日が流れていました。

なぜ今、リプレースが必要だったのか。そして数ある選択肢からなぜ冒頭の機種を選んだのか。その経緯のメモです。

限界を超えたHDD。

きっかけは、現在のNAS(ASUSTOR AS-202T)のディスクチェックを確認したことでした。そこに並んでいた数値は、まさに「驚愕」の一言です。

  • 稼働時間:
    • 約45,000時間(設計寿命の目安30,000時間を大幅超過)
  • ヘッド退避回数:
    • 約340万回(公称耐用回数60万回の5倍以上)

NAS本体は2015年の導入。2021年にディスクの状況が怪しくなって2TB→4TBに交換。

そこから大きなトラブルもなく動いてくれたのは奇跡に近いと言えるでしょう。そして、筆者が利用していただけというのも相まって、奇跡的に長持ちをしました。

決断の理由

実は2022年頃から「そろそろ機器も限界だろう」とは感じていました。しかし、日々の忙しさやコスト(何より2022年はコロナに罹患、そこからVPSの運用やらクラウドストレージの失敗と出費)を前に、騙し騙し運用を続けてきたのが本音です。

今回、重い腰を上げた決定的な要因は「ストレージ市場の激変」です。2025ね12月よりSSDの価格暴騰が続き、その波がHDDに波及するのも時間の問題という状況。

「今この瞬間が、最も安く、安全に逃げ切れる最後のチャンスだ」という直感が、4年越しの迷いを断ち切らせました。

そして注文して届いたのがこちらです。

なぜ「QNAP TS-216G」を選んだのか

選定にあたっては、同一メーカーであるASUSTORは候補に挙がっていましたが、エントリーモデルは市場で手に入れづらく、ミドルモデルは逆に高い。そこで、選択肢として上がったのが

  • QNAP
  • UGREEN

の2択。特に、圧倒的なスペックの新興勢力であるUGREENなども検討対象に挙がりました。しかし、最終的に老舗のQNAPを選んだ理由は、単なるスペック比較では測れない「データの重み」にありました。

  • ソフトウェアの信頼性:
    • 単なるファイル置き場ではなく、PCまるごとのバックアップや復旧(ベアメタル復旧)まで備えた信頼性の高く守備の広いソフトウェア群
  • 静音・排熱設計:
    • ホームNASにも一日の長があるメーカーです。リビングに置くことを前提とした、10年先を見据えたハードウェアの造り込み。
  • アップデートの継続性:
    • 長期間、最新のセキュリティパッチを供給し続けるエンタープライズ向けメーカーという信頼。
  • セキュリティと地政学的リスク:
    • これが一番の問題かもしれません。「かの国の法律は仕込もうと思えばバックドアを仕掛けられる」という懸念がありました。

特に、「自分だけの記録」という、失えば二度と手に入らない単一障害点を守るため、新興勢力への不安を捨て、実績あるQNAPを選びました。

HDDとしてこれを選んだ理由

NASの筐体が決まったら、次に決めるべきは最も重要な心臓部、HDDの選定です。今回、私は迷わずWestern Digitalの「WD Red Plus (8TB)」を2台選択しました。

これまで使用していたWD Blueも、10年・45,000時間という驚異的な耐久性を見せてくれましたが、「NAS専用品」を載せるべき明確な根拠がありました。

24時間365日の「常時稼働」を前提とした設計

現行のWD Blueが「PCを使っている間だけ動く」ことを想定しているのに対し、WD Red Plusは「1年365日、1秒も休まず動き続ける」ことを前提に設計されています。

今後、PCパーツの値上がりが予想されているので、逆にケチらない方が安上がりという判断。

「CMR方式」へのこだわり

近年のHDDには、安価ですが書き込み速度にムラが出やすい「SMR方式」が増えています。しかし、NASのRAID構成において書き込み遅延は致命的なエラーに繋がりかねません。
WD Red Plusは、安定した記録が可能な「CMR(従来型磁気記録)方式」を堅持しています。データの整合性を最優先するNASにおいて、この信頼性は譲れない一線でした。

NAS特有の「振動」への対策

2台、3台とドライブを並べて動かすNASでは、お互いの回転振動がエラーの原因になります。WD Red Plusには、この振動を検知し補正する仕様。
静音性に優れたQNAPの筐体と、振動に強いWD Redを選んだわけです。

今後の流れ

  1. セットアップ
  2. 基礎設計
  3. 運用方針決め
  4. データ移行の計画
  5. 移行と同時に実運用

先は長いのですが、HDDの寿命待ったなし。そこはFestina Lenteの精神で行きます。

ケーブル兼ストラップ。

いざというときに仕えるし、実用性もあるという品を入手です。

この、充電ケーブルそのものがストラップになっているという仕様。

スマートフォンケースにアタッチメントを取り付けるだけ。

これで、ショルダーストラップ完成。

保護カバーを取り外せば充電もできます。しっかりと落ちないようにストラップつきでした。

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

結局原因は?

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

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

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

USBメモリに割り当てられた特殊領域の解除メモ。

何かと現役なUSBメモリ。再セットアップ中に(Windows管理→ディスク管理)

このように見割り当て/もしくは複数のパーティションができた場合に対応するときのメモです。

注意点

この操作を行うと、USBメモリ内のデータはすべて消去されます。 必要なファイルがある場合は、作業前に必ずパソコン本体などへバックアップを取ってください。

ディスク番号は絶対に間違えないでください。

OSインストールドライブが文字通り吹っ飛ぶような操作です。

手順

コマンドプロンプトを管理者で実行。

Windowsキー→cmdを入力。コマンドプロンプトが入力されたら、右クリックで「管理者として実行」を選択。

コマンドプロンプトでdiskpartを起動

diskpart

を入力してEnterを実行。

ディスク番号を確認

list disk

を実行。

この時、上述したディスク3が操作をするUSBメモリであることを確認しましょう。

※ここでディスク番号を間違えると、パソコンのSSDなどを消去してしまうため慎重に選んでください。

USBメモリを選択

select disk 3

を実行します。「ディスク 3 が選択されました」と表示されます。

中身を消去

clean

を実行します。これで、ディスク内の全てのパーティションが消えます。

新しいパーティションを作成

create partition primary

を実行します。

USBメモリのフォーマット

fs=ntfs quick

等でフォーマットを行います。

終了

exit

でdiskpartを抜けます。

『ONE OUTS』システム番外:ASNごとIPSetで弾いたときの記録

はじめに

Webサイトを公開していると、必ず遭遇するのが「自動化された嫌がらせ」です。

ログを確認すると、1秒ごとに異なるURLへPOSTリクエストを送り続けてくるボットたちがいます。

今回は、特定のネットワークセグメントから行われた執拗な「PHPUnitのバックドア設置スキャン」に対し、アプリケーション層(ModSecurity)だけでなく、カーネル層(IPset)で物理的に遮断した際のメモです。

前提

以下の手順でipsetを導入していること。

1. ログに残る「執拗なアクセス」

ある日、アクセスログを眺めていると、以下のような文字列が並んでいることに気づきました。

# access.log の例 (ダミーデータ)
192.0.2.239 - - [06/Mar/2026:14:35:07] "POST /lib/phpunit/Util/PHP/eval-stdin.php HTTP/1.1" 404 3067 "-" "Mozilla/5.0..."
192.0.2.239 - - [06/Mar/2026:14:35:08] "POST /lib/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 3067 "-" "Mozilla/5.0..."
...

攻撃者は /vendor//lib/ などのディレクトリを総当たりし、脆弱性のあるPHPUnitファイルを探しています。

このアクセス元を調べてみました。

2. ASN(拠点のプロバイダー)を特定する

しかし、調べてIPをブロックするだけでは終わりません。相手は同じネットワーク(ASN)内の別IPから再び攻撃してくるからです。
そこで whois コマンドを用いて、この攻撃者が所属するネットワークの広がりを確認しました。

  • 攻撃者のIPから所属ASNを特定する

※ダミーIPにしています。

whois -h whois.radb.net -- '192.0.2.239'

結果、このIPは特定のホスティング事業者が管理する「広大なネットワーク帯域」の一部であることが判明しました(仮に AS_DUMMY_99 とします)。

3. 「IPset」による物理的遮断

単なるIPの拒否リストでは、数千に及ぶボットのIPを捌ききれません。数千ものIP/NWをufwでブロックすると、たちどころにその膨大なルールでufwは機能不全を起こします。

それが、上述したLinuxカーネルレベルで高速にパケットを破棄できる ipset を使用した形です。

手順:ASNを広域ブロックする

まず、そのASNが保持する全CIDRを取得し、aggregate コマンドで最適なサイズに集約します。

  • ASNからルートを取得し、整理する
whois -h whois.radb.net -- '-i origin AS_DUMMY_99' | grep -E '^route:' | aggregate > ban_list.txt

(aggregateがない場合はsudo apt install aggregateでインストールします)

これにより、手作業では到底管理できない広大なネットワーク帯域を、数行のルールに圧縮できます。最後に、このルールを ipset に投入します。

筆者手順ではこの形。

sudo ipset add ufw-blocklist IPアドレス・NWアドレス
sudo ipset save ufw-blocklist -f /etc/ufw/ipsets.save

まとめ

なぜASNごと切り捨てるのかは「彼らの根城だから」につきます。(そのあたりは筆者コラムに書いています)

そもそも、これらのボットは、海外の法が緩いVPSや出所の怪しいプロバイダに巣喰っています。

こん城ん奴ばら共は糞じゃ
撫で切りぞ
根切りぞ

ぐらいのブロックは必要です。

Page 1 of 103

Powered by WordPress & Theme by Anders Norén