カテゴリー: PC Page 1 of 66

Ubuntu26.04とQNAPの連携。

QNAPの構築も一段落したため、やりたいこと「LinuxサーバとQNAPをつなぎ、冗長化を持たせた大容量ストレージにする」を開始します。

そもそもNFS (Network File System) とは?

NFSは、主にUNIXやLinuxなどのOS間でファイルを共有するために開発されたプロトコルです。

一番の特徴は、リモート(NASなど)にあるフォルダを、自分のコンピュータのディレクトリツリー(/mnt/qnap など)の一部として組み込めることです。
一度マウントしてしまえば、ユーザーやアプリからはそれがネットワーク経由であるということを意識せず、通常のファイル操作と同じコマンド(ls, cp, mvなど)で扱えるようになります。

主な用途

  • Webサーバーのデータ共有: 複数台のサーバーで同じ画像データなどを参照する場合。
  • バックアップ: サーバーのログやDBのダンプファイルをNASに直接書き込む。
  • 仮想化環境: 仮想マシンのディスクイメージを保存する場所(ストレージ)として利用。

他の共有方式(SMB/CIFS)との違い

よく比較されるものに、Windowsで一般的に使われる SMB (Server Message Block) があります。QNAPはどちらも使えますが、以下のような違いがあります。

特徴NFSSMB (Windows共有)
主なOSLinux / UNIXWindows (Linuxでも可)
設定のしやすさ非常にシンプル(IPベース)ユーザー名/パスワードが基本
パフォーマンスLinux間なら非常に高速以前は遅かったが今は高速
権限管理LinuxのUID/GIDに依存WindowsのACLに依存

今回目指したこと。

sequenceDiagram autonumber participant U as ユーザー participant S as Linuxサーバ (OS) participant NC as Nextcloud (アプリ) participant Q as QNAP (NAS) Note over S, Q: 1. インフラ層のマウント設定 S->>Q: NFSマウント要求 (linuxserver:/NFS) Q-->>S: 接続許可・ディレクトリを /mnt/qnap に結合 Note over U, Q: 2. Nextcloudでの外部ストレージ利用 U->>NC: ファイル一覧を表示 NC->>S: 外部ストレージ設定に基づき /mnt/qnap を参照 S->>Q: NFSプロトコル経由で実データにアクセス Q-->>S: フォルダ・ファイル情報を返す S-->>NC: データを透過的に引き渡し NC-->>U: ブラウザ上にQNAP内のファイルを表示 Note over U, Q: 3. ファイルのアップロード時 U->>NC: ファイルをアップロード NC->>S: /mnt/qnap 配下に書き込み命令 S->>Q: ネットワーク経由でQNAPにデータを転送・保存 Q-->>U: 保存完了

手順

以下、作業メモです。

ステップ1:QNAP側でのサービス有効化

  1. コントロールパネル > ネットワークとファイルサービス > Win/Mac/NFS/WebDAV を開く。
  2. NFSサービス タブで「NFSサービスを有効にする(v2/v3, v4)」にチェックを入れ、「適用」。

ステップ2:共有フォルダの権限設定

  1. コントロールパネル > 権限 > 共有フォルダ で対象フォルダ(例:NFS)の「アクセス権の編集」を開く。
  2. 「権限タイプの選択」を NFSホストのアクセス に切り替える。
  3. 「追加」 を押し、ホスト名に *(またはLinuxのIP)を入力。
  4. 重要設定:
    • 権限: 「読み取り/書き込み」を選択。
    • Squashオプション: rootユーザーで操作する場合は「なし(NO_ROOT_SQUASH)」を推奨。
  5. 設定を保存し、表示されている ネットワークパス(今回なら /NFS)をメモする。

ステップ3:Linuxサーバー側でのマウント操作

  1. ツールのインストール(未導入の場合):
    • sudo apt install nfs-common (Ubuntu/Debian)
    • sudo yum install nfs-utils (RHEL/CentOS)
  2. マウントポイントの作成:
    • sudo mkdir -p /mnt/qnap
  3. 手動マウントの実行:
    • sudo mount -t nfs QNAPのIP、ホスト名:/NFS /mnt/qnap
  4. 確認:
    • df -h を実行し、ファイルシステム欄に QNAP のパスと容量が表示されれば成功。

ステップ4:自動マウントの設定(永続化)

サーバー再起動後も自動で接続されるよう設定します。

/etc/fstabは正直編集したくないファイル筆頭です。可能な限り先にやっておくことを強く勧めます。

  • /etc/fstabバックアップ

※バックアップと言ったところで、失敗した瞬間にサーバが立ち亜が楽なるは普通に発生します。慎重を期してください。

sudo cp -pi /etc/fstab /path/to/backup/fstab.$(date +%Y%m%d)
  • バックアップ確認
diff -u /path/to/backup/fstab.$(date +%Y%m%d) /etc/fstab

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

  • /etc/fstab追記:
QNAPのIP、ホスト名:/NFS  /mnt/qnap  nfs  defaults,_netdev  0  0

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

  • /etc/fstab追記確認:
diff -u /path/to/backup/fstab.$(date +%Y%m%d) /etc/fstab

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

+ QNAPのIP、ホスト名:/NFS  /mnt/qnap  nfs  defaults,_netdev  0  0

テスト

  • NFSマウント解除
sudo umount /mnt/qnap
  • fstabマウント
sudo mount -a
  • マウント確認
df -h

は味気ないので

{
  echo "| デバイスパス | タイプ | 全サイズ | 使用率 | マウントポイント |"
  echo "| --- | --- | --- | --- | --- |"
  df -hPT | grep -vE 'tmpfs|shm|devtmpfs' | tail -n +2 | awk '{printf "| %s | %s | %s | %s | %s |\n", $1, $2, $3, $6, $7}'
}

のワンライナーを用います。

デバイスパスタイプ全サイズ使用率マウントポイント
/dev/sda2ext4233G6%/
efivarfsefivarfs256K12%/sys/firmware/efi/efivars
/dev/sda1vfat1.1G1%/boot/efi
QNAP:/NFSnfs44.2T30%/mnt/qnap

などが表示されればOKです。

サーバの再起動

この段階で

sudo reboot

をかけておきます。序盤でfstabの不具合に気づかないと、後のサーバ運用そのものが詰みます。

Ubuntu26.04にPHP8.5/PHP8.5-FPMをインストール。

概要

Ubuntu 26.04でWebアプリ(Nextcloudを想定)を動かす際の柱であるPHPのインストールを行います。

盛大にはまったポイント

2026/04/23にリリースされた26.04。導入されるミドルウェアの最新性がキモでした。

筆者が前項でやったレポジトリ追加は「26.04には対応してない。そもそもミドルウェアが合ってない」など言われましたが、
「リポジトリを追加するまでもなく最新版がインストールされる」ことに気づきませんでした。

さっくりとした手順

  1. システムを最新化します。
  2. PHP 8.5本体を導入します。
  3. 必須モジュールをインストールします。
  4. PHP-FPMを導入します。
  5. 高速化設定を行います。(OPcache, APCu周り)
  6. 設定を反映します。

システムの更新

まずは標準リポジトリを最新の状態にします。

sudo aptitude update

PHP 8.5 本体と Redis サーバーのインストール

メタパッケージ(バージョン指定なし)を使用することで、OSが最適な 8.5 系を自動選択します。

sudo aptitude install php php-fpm php-common php-cli php-readline redis-server

当初筆者はPHP8.4を選択していたのですが、そこが盛大なはまりポイントでした。(PHPの動向を追っていなかったという失態もあります)

Nextcloud 必須・推奨拡張モジュールのインストール

Nextcloudの動作に不可欠なモジュール群を一括で導入します。

sudo aptitude install php-{bcmath,bz2,curl,gd,gmp,intl,ldap,mbstring,mysql,sockets,xml,zip,imagick,redis,apcu,memcached}

Apache 連携設定 (PHP-FPM版)

Apacheで PHP 8.5 を FPM 経由で動作させる設定です。

sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.5-fpm
sudo systemctl restart apache2

5. PHP 8.5 高速化設定 (OPcache / APCu)

Nextcloudの警告を消し、パフォーマンスを最大化するための設定です。

  • OPcache設定の作成
cat <<- __EOF__ | sudo tee /etc/php/8.5/mods-available/opcache.ini > /dev/null
; configuration for php opcache module
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__

→ 既にあるファイルを上書きます。(切り戻し想定せず)

  • APCu設定の作成
cat <<- __EOF__ | sudo tee /etc/php/8.5/mods-available/apcu.ini > /dev/null
extension=apcu.so
[apcu]
apc.enabled=1 apc.shm_size=32M apc.ttl=7200 apc.enable_cli=1 apc.serializer=php __EOF__

 設定の有効化

sudo phpenmod opcache apcu

このphpenmodもハマりポイントでした。従来の ln -sではなく、専用コマンドを用いることでfpm / cli / apache-mod でも安定した運用が可能になります。

サービスの再起動と確認

sudo systemctl restart php8.5-fpm
sudo systemctl restart redis-server
sudo systemctl restart apache2
  • バージョンの確認
php -v

with Zend OPcache v8.5.4 等 と表示されれば正解です。

備考:PHPを用いるWebアプリ設定の確認

Apacheの各サイト設定ファイル (/etc/apache2/sites-available/*.conf) 内で、必ず 8.5 のソケットを指定してください。

<FilesMatch \.php$>
&nbsp; &nbsp; SetHandler "proxy:unix:/var/run/php/php8.5-fpm.sock|fcgi://localhost/"
</FilesMatch>

これを入れないと、

The requested URL was not found on this server.   
    
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

の非情なるメッセージが返ってきます。

Apacheのインストールと初期設定(Ubuntu 26.04)

概要

Ubuntu26.04にWebサーバーApacheをインストールします。最近のトレンドではNginxではあるものの、

  1. 豊富なモジュールとカスタマイズ
  2. 動的コンテンツの設定をしやすい
  3. 小規模サイトを立ち上げる上での手間の少なさ
  4. 外部ファイルやモジュールの連携により、以下のような細かい設定が可能
  • 自宅等からのアクセスログを残さず、ログの透明化を図る
  • Robots.txtを無視する悪質なクローラーの排除
  • mod_securityに代表されるWAF(Web Application Firewall)の設置

を考慮してのApache設定です。

さっくりとした手順

  1. (未実施の場合必須)UFWの設定を行います。
  2. Apacheのインストールを行います。
  3. Apacheの設定を行います。
  4. 設定の反映を確認します。

(未実施の場合必須)UFWの設定

この作業、サーバ移設などになれている人ほど陥る罠です。「設定はしっかりしている。なのにサンプルページすら引っかからない!」という場合、大概が「UFWでポート80/443を空けていない」パターンが大半を占めます。

大前提

SSH接続を許可(ポート22はSSH記事で許可済みを前提とする)。

設定の前の心構え:

UFWは堅牢であると同時に融通の利かない門番です。設定を間違えると「自分のサーバにログインできない」事態が易々と発生します。

そのため、この作業に臨む際は落ち着いて臨みましょう。コマンドを打つ際に3回ぐらい深呼吸してもいいぐらいの心構えです。

  • http通信を許可する
sudo ufw allow http comment 'Allow HTTP traffic for Apache'
  • https通信を許可する
sudo ufw allow https comment 'Allow HTTPS traffic for Apache'
  • 設定を確認する
 sudo ufw status verbose

上記、http/httpsが有効になっていることを確認します。

  • UFWが有効になっていない場合:有効化
sudo ufw enable 

インストールを行います。

  • パッケージ全体のアップデート
sudo aptitude update 
  • apacheのインストール
sudo aptitude install apache2
  • バージョン確認
apache2ctl -v
  • 表示例
Server version: Apache/2.4.62 (Ubuntu)
Server built:   2024-07-22T12:37:10
  • サービス稼働確認
systemctl status apache2.service

enabledactive (running)を確認します。

設定を行います。

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

任意のバックアップディレクトリを指定します。

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

差分が無いことでバックアップを確認します。

  • 設定ファイル追記
sudo tee -a /etc/apache2/apache2.conf > /dev/null << 'EOF'
ServerSignature Off
ServerTokens Prod
ServerName example.com
EOF

自分のサーバー名を英数字で置き換えてください。

  1. サーバーの署名をオフにして
  2. 最小限の情報のみを公開し
  3. Webサーバの名前を指定する

内容です。

  • 追記確認
diff -u /path/to/backup/directory/apache2.conf.$(date +%Y%m%d) /etc/apache2/apache2.conf
  • 差分内容
+ ServerSignature Off
+ ServerTokens Prod
+ ServerName 自分のサーバー名

設定反映を確認します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

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

active (running)を確認します。

  • 設定反映確認
curl -I http://localhost

以下のように、ServerヘッダーにApacheのみが表示されていることを確認します。

Server: Apache

ノートPCサーバ化計画。(ノートPCのオートスリープオフ設定)

こちらで買っていた

LinuxデスクトップPCですら怪しい性能になったので、これをサーバに変えます。

  • Core i-5 7300
  • 8GB Memory
  • 256GB SSD

はサーバとして必要最小限以上の機能。何よりも「UPS/コンソールつきのサーバ」として家庭内運用ではこの上なく役立ちます。

今回の方針

  • Nextcloudサーバにする。
  • ローカルNWでのみ運用。DDNSやブロードバンドルータのポート解放などは行わない。
  • データストレージはNASをNFSマウントして利用。

Linuxサーバのインストール

今回選んだのは2026/04/23にリリースされたばかりのUbuntu26.04。

適当な方法でインストールメディアを作り、画面に従ってインストールするだけ。

ノートPCならではの制限解除

蓋を閉じてもスリープさせない設定

これが地味に重要です。

  • 設定ファイルのバックアップ
sudo cp -pi /etc/systemd/logind.conf /path/to/backup/logind.conf.$(date +%Y%m%d)
  • 設定ファイルのバックアップ確認
diff -u /path/to/backup/logind.conf.$(date +%Y%m%d)

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

  • 変更箇所

以下を修正していきます。

  • HandleLidSwitch=ignore
  • HandleLidSwitchExternalPower=ignore
  • HandleLidSwitchDocked=ignore
  • LidSwitchIgnoreInhibited=no

修正後、保存します。

  • 差分確認
diff -u /path/to/backup/logind.conf.$(date +%Y%m%d)

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

-#HandleLidSwitch=suspend
-#HandleLidSwitchExternalPower=suspend
-#HandleLidSwitchDocked=ignore
+HandleLidSwitch=ignore
+HandleLidSwitchExternalPower=ignore
+HandleLidSwitchDocked=ignore
 #HandleSecureAttentionKey=secure-attention-key
 #PowerKeyIgnoreInhibited=no
 #SuspendKeyIgnoreInhibited=no
 #HibernateKeyIgnoreInhibited=no
-#LidSwitchIgnoreInhibited=yes
+LidSwitchIgnoreInhibited=no
  • システム反映
sudo systemctl restart systemd-logind

システムの自動スリープ・サスペンドを分陰

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

→ システムのスリープ機能そのものを物理的にリンク切れにします。

これから

NASの設定確認やらApache設定やらが待っています。

Growi 7.5.x→7.5.yへのアップグレード

概要

Growi 7.5.x → Growi 7.5.yにアップデートする 手順です。

7.5.1 → 7.5.2への手順で実際に実施しています。

前提

さっくりとした手順

  1. Growiをメンテナンスモードにします。
  2. Growi・Elasticsearchのサービスを停止します。
  3. バックアップを取ります。
  4. gitコマンドで最新版をcheckoutします。
  5. アップグレードを行います。
  6. Growiのメンテナンスモードを解除します。
  7. アップグレードされたことを確認します。

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

  1. Growiに管理者権限でログインします。
  2. 管理トップ>アプリ設定に進み、「メンテナンスモードを開始する」をクリックします。
  3. トップページに戻り「メンテナンスモード」が表示されていることを確認します。

バックアップ

以下をバックアップします。

  • mongodbの格納データ
cat /etc/mongod.conf |grep dbPath

として、ここのディレクトリ一式を控えます。(筆者環境 /home/mongodb)

このディレクトリを任意の方法でバックアップします。

  • Growiの添付ファイル一式が納められているディレクトリ(ファイルアップロード先をlocalにしている場合のみ)
/growi/root/directory/apps/app/public

(筆者環境 /home/www-data/growi/apps/app/public)ここも念のためバックアップします。

※ 添付ファイルのアップロード先をAWSやAzureなどにしている場合は不要です

  • vpsや仮想ゲストの場合はシステム全体:推奨

スナップショット機能などでシステム全体をバックアップした方が確実で安心です。

ElasticsearchとGrowiの停止

  • Elasticsearchサービス停止
sudo systemctl stop elasticsearch.service
  • Growiサービス停止
sudo systemctl stop growi.service
  • サービス停止確認
systemctl status elasticsearch.service growi.service | grep Active

inactive(dead)を確認します。

作業前バックアップ

  • データディレクトリを丸ごとコピー (-aオプションでパーミッションを維持)
sudo cp -a /var/lib/elasticsearch/ /path/to/backup/dir/elastic_bk.$(date +%Y%m%d)

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

  • バックアップ確認
sudo ls -l /path/to/backup/dir/elastic_bk.$(date +%Y%m%d)

バックアップした内容があることを確認します。(※管理者権限でないとこのディレクトリを見ることはできません)

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/23にリリースされたv7.5.2を選択しました。

  • pnpm install
sudo pnpm i
  • ビルド
NODE_OPTIONS="--max-old-space-size=4096" sudo pnpm run app:build

→ ビルド時のメモリ大量使用を抑えるため上限を抑えています。

ElasticsearchとGrowiの再開

  • Elasticsearchサービス開始
sudo systemctl restart elasticsearch.service
  • Growiサービス開始
sudo systemctl restart growi.service
  • サービス開始確認
systemctl status elasticsearch.service growi.service | grep Active

active(running)を確認します。

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

  1. Growiに管理者権限でログインします。
  2. 管理トップ>アプリ設定に進み、「メンテナンスモードを終了する」をクリックします。
  3. トップページに戻り「メンテナンスモード」が表示されていないことを確認します。

バージョンアップを確認します。

  1. 画面下部にあるバージョンがチェックアウトしたバージョン(v7.5.x)であることを確認します。
  2. 各種機能(ページ閲覧や編集)などが正常に行えるかを確認します。

バージョンアップ後の作業

必要に応じてバックアップしたファイル一式やスナップショットを削除します。

狙われる.envファイル。

ログ解析をしていると、1分にも満たない大量の.envへのスキャンがありましたので、そのメモです。

「テロリストに名前を与えない」のポリシーから、IP等はダミーに置き換えています。

観測されたログデータ(IPはダミーに置き換え)

[Mon Apr 27 05:14:18 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [msg "[CUSTOM RULE] Host header is a numeric IP address. Blocked immediately."] [uri "/.env"]
[Mon Apr 27 05:14:18 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [uri "/app/frontend/.env"]
[Mon Apr 27 05:14:19 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [uri "/.gitlab-ci/.env"]
[Mon Apr 27 05:14:21 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [uri "/resources/.env"]
[Mon Apr 27 05:14:22 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [uri "/alpha/.env"]
[Mon Apr 27 05:14:23 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [uri "/.idea/.env"]
[Mon Apr 27 05:14:26 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [uri "/.env.sendgrid"]
[Mon Apr 27 05:14:27 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [uri "/new/.env.production"]
[Mon Apr 27 05:14:34 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [uri "/xampp/.env"]
[Mon Apr 27 05:14:36 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [uri "/kubernetes/.env"]
[Mon Apr 27 05:14:37 2026] [security2:error] [client 999.999.999.999] ModSecurity: Access denied with code 404. [uri "/stripe/.env"]

なぜ.envファイルを狙うのか?

.envファイルは通常、アプリケーションの設定情報を保存するために使われます。ここには、ソースコードには直接書けない機密情報(クレデンシャル)が凝縮されています。

データベースの接続情報: DB_PASSWORD, DB_USERNAME, DB_HOST

これが漏れると、DB内の個人情報や顧客データをすべて盗まれる(SQLインジェクションの手間すら不要になります)。

外部APIのキー: STRIPE_SECRET_KEY, SENDGRID_API_KEY, AWS_SECRET_ACCESS_KEY

ログにも .env.sendgrid/stripe/.env がありますが、これらが盗まれると、攻撃者はあなたの名義で勝手に決済を行ったり、大量のスパムメールを送信したり、クラウドサービス上で高額なマイニングマシンを動かしたりできます。

特にAWS関連が狙われると

  • あなたのお金で大量のサーバが立てられ
  • 見たくもない額の請求がAWSから届き
  • 更に海外当局から嫌疑をかけられる

などもあり得ます。

アプリケーションの秘密鍵: APP_KEY, SECRET_KEY

セッションの偽造やデータの復号が可能になり、管理者アカウントを乗っ取られる原因になります。

なぜこれほど多くのパスを試行するのか?

上記ログには様々なディレクトリ(/alpha/, /kubernetes/, /.idea/ など)を探索しています。これには2つの戦略があります。

  • フレームワークの特定:
    • パスのパターンから、そのサーバーがLaravelなのか、Djangoなのか、あるいはDockerKubernetesで動いているのかを推測しようとしています。
  • 不注意なバックアップや設定ミスの露呈:
    • 開発者が一時的に作成したコピー(.env.production)や、Gitの管理ディレクトリ(/.idea/)の中に残された設定ファイルを狙っています。本流のルートディレクトリがガードされていても、サブディレクトリの設定が甘いケースが多いことを彼らは知っています。

攻撃のメカニズム:スキャンから悪用まで

攻撃のプロセスは非常に効率化(自動化)されています。

  • 一斉スキャン:
    • ボットを使用して、世界中のIPアドレスに対して /.env へのリクエストを投げまくります。
  • 自動検知:
    • ステータスコード 200 OK が返ってきた瞬間に、中身を自動でパース(解析)します。
  • 即時悪用:
    • AWSのキーが見つかれば数分以内にインスタンスを立て、DB情報が見つかればデータをダンプしてランサムウェア(身代金要求)のメッセージを残します。

防御の鉄則

WAFは、もはやWEBサーバの必須装備となりつつあります。それに留まらず、基本を守りましょう。

  • 公開ディレクトリの外に置く:
    • .env は、Webブラウザからアクセスできる public_html や www の外側に配置するのが鉄則です。
  • Webサーバーの設定:
    • Apacheなら .htaccess、Nginxなら location ブロックで、ドットファイル(.*)へのアクセスを拒否する設定を入れます。
  • 権限設定:
    • 実行ユーザー以外が読み取れないよう、パーミッションを最小限(600 など)にします。

このように、多くの攻撃は「意志を持たず、目標を自動的に追尾する」ボットが大半以上を占めています。言うなれば「自動操縦型の群体スタンド」と言うべきでしょう。
スタンドそのものが意志を持たない(上に“本体”への直接攻撃が許されていない)以上、こちらも意志を持たずに防御していくというお話しです。

RHEL系LinuxにZabbixサーバをインストール

RHEL系Linux(Rocky Linux 9)にZabbixサーバを構築したときのメモです。

環境

  • Zabbix 7.0
  • PHP-FPM 8.3
  • MySQL 8.0
  • Apache 2.4

前提

  • Linuxの初期設定完了済み
  • 以下のミドルウェアをインストール済み。
  • Apache 2.4
  • MySQL 8.0 (mysql_secure_installation込み)
  • PHP-FPM 8.3

さっくりとした手順

  1. php.iniを修正します。
  2. Zabbixパッケージをインストールします。
  3. DBを作成しスキーマをインポートします。
  4. ZabbixのDBを設定します。
  5. Apacheのバーチャルホストを設定します。
  6. Zabbixサービスを有効化してFirewalldを設定します。
  7. 初期インストールを行います。

PHP 設定の最適化 (php.ini)

Zabbix Web UI の動作要件に合わせて PHP のパラメータを修正します。おそらく多くの方がWebインストールした後に怒られる設定です。

  • php.iniのバックアップ
sudo cp -pi /etc/php.ini /path/to/backup/directory/php.ini.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • php.iniのバックアップ確認
diff -u /path/to/backup/directory/php.ini.$(date +%Y%m%d) /etc/php.ini 

差分がなければバックアップ成功です。

  • php.ini 修正箇所:
  • post_max_size = 16M (8M から変更)
  • max_execution_time = 300 (30 から変更)
  • max_input_time = 300 (60 から変更)

上記は例です。環境に合わせましょう。

  • php.iniの編集確認
diff -u /path/to/backup/directory/php.ini.$(date +%Y%m%d) /etc/php.ini 

+の箇所に修正した値になっていることを確認します。

  • php-fpmサービス再起動(設定反映)
sudo systemctl restart php-fpm

Zabbix パッケージのインストール

  • レポジトリ追加

2026年4月の最新パッケージである7.0.xを使うため、レポジトリを追加します。

  • Zabbixリポジトリのインストール
sudo rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rocky/9/x86_64/zabbix-release-latest.el9.noarch.rpm
  • キャッシュのクリア
sudo dnf clean all
  • EPEL リポジトリとの競合を避けるため、リポジトリを指定してインストールします。

この指定が地味に詰まりました。

sudo dnf install -y --disablerepo=epel \
zabbix-server-mysql \
zabbix-web-mysql \
zabbix-apache-conf \
zabbix-sql-scripts \
zabbix-selinux-policy \
zabbix-agent2

データベースの作成と初期データの流し込み

MySQL (MariaDB) に Zabbix 用の DB とユーザーを作成し、初期スキーマをインポートします。

  • mysqlログイン
mysql -u root -p
  • DB作成
CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'あなたのパスワード';
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';
SET GLOBAL log_bin_trust_function_creators = 1;
EXIT

SET GLOBAL log_bin_trust_function_creators = 1;を指定しないと、zabbixに必要なスキーマを拒否することがあります。

  • スキーマインポート
zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix
  • 設定を元に戻す
mysql -u root -p -e "SET GLOBAL log_bin_trust_function_creators = 0;"

インポート後にこれを行っておかないと、MySQLがインジェクションとなり得るスキーマを許可することがあります。

Zabbix Server の DB 設定

サーバー本体が DB に接続するためのパスワードを設定します。

/etc/zabbix/zabbix_server.conf を以下のように修正します。

修正箇所:

  • DBPassword=あなたのパスワード (コメントアウト # を外して追記)

Apache (httpd) バーチャルホストの設定

上記、dnfで設定した標準設定を無効化し、/etc/httpd/virtual/ 配下で管理するように変更します。

これは、「一つのサーバにWebサーバとZabbixを同時に立てる必要がある」などで重要なテクニックです。

  • ディレクトリ準備
sudo mkdir -p /etc/httpd/virtual
  • 標準設定の退避
sudo mv /etc/httpd/conf.d/zabbix.conf /path/to/backup/direcotry/zabbix.conf.$(date +%Y%m%d)
  • バーチャルホスト設定の作成

/etc/httpd/virtual/zabbix.conf

等として、以下のようなファイルを作ります。

<VirtualHost *:80>
    # 自分の環境に合わせます
    ServerName zabbix.example.com
    DocumentRoot /usr/share/zabbix

    <Directory "/usr/share/zabbix">
        Options FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
    # FPM設定
    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost"
    </FilesMatch>
    # 任意のログディレクトリを指定します
    ErrorLog /var/log/httpd/zabbix_error.log
    CustomLog /var/log/httpd/zabbix_access.log combined
</VirtualHost>

サービスの起動と Firewalld の設定

全てのコンポーネントを起動し、必要なポートを開放します。これも地味にはまるポイントです。

  • サービスの有効化と起動
sudo systemctl enable --now zabbix-server zabbix-agent2 httpd php-fpm
  • Firewalld の許可
sudo firewall-cmd --permanent --add-service={zabbix-server,zabbix-agent,http}
  • Firewalldのリロード
sudo firewall-cmd --reload

Web セットアップとログイン

  1. ブラウザで http://(ServerName)/ にアクセス。
  2. 全てのチェック項目が OK であることを確認し、DB情報を入力して完了。
  3. 初期ログイン情報:
  • User: Admin (Aは大文字)
  • Password: zabbix

Apacheのインストールと初期設定(RHEL系)

概要

RHEL系(AlmaLinux / Rocky Linux 9等)にWebサーバーApacheをインストールします。最近のトレンドはNginxではあるものの、以下のメリットを考慮してApacheを選択します。

  1. 豊富なモジュールとカスタマイズ: 歴史が長く、情報の蓄積が膨大。
  2. 動的コンテンツの設定のしやすさ: PHP等との親和性が高い。
  3. 運用の手軽さ: 小規模サイトを迅速に立ち上げるのに適している。
  4. 高度なセキュリティ・ログ設定:
    • 自宅等からのアクセスログを除外するなどのログカスタマイズ。
    • 悪質なクローラーの排除。
    • mod_security(WAF)による防御。

さっくりとした手順

  1. firewalldの設定: 外部からのアクセス許可を与えます。
  2. Apacheのインストール: dnfを使用してインストールします。
  3. Apacheの設定: セキュリティとサーバー名の設定を行います。
  4. 設定の反映確認: 正常に動作しているかチェックします。

1. firewalldの設定

サーバー移設などでハマりやすいのが「設定は正しいのにページが表示されない」現象です。RHEL系ではデフォルトで強力なファイアウォール(firewalld)が動作しており、ポート80/443を明示的に開放する必要があります。

大前提

SSH接続(ポート22)は許可されている前提で進めます。設定を誤るとリモート操作ができなくなるため、慎重に行いましょう。

  • HTTP通信を許可する
sudo firewall-cmd --permanent --add-service=http
  • HTTPS通信を許可する
sudo firewall-cmd --permanent --add-service=https
  • 設定を反映させる
sudo firewall-cmd --reload
  • 設定を確認する
sudo firewall-cmd --list-all

services の欄に httphttps が含まれていればOKです。

2. インストールを行います

RHEL系ではApacheのパッケージ名は httpd です。

  • パッケージ全体のアップデート
sudo dnf update -y
  • Apache (httpd) のインストール
sudo dnf install httpd -y
  • バージョン確認
httpd -v

-(表示例)-
Server version: Apache/2.4.57 (AlmaLinux)

  • サービスの起動と自動起動設定
sudo systemctl enable --now httpd
  • サービス稼働確認
systemctl status httpd

enabledactive (running) を確認します。

3. 設定を行います

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

RHEL系の設定ファイルは /etc/httpd/conf/httpd.conf です。

sudo cp -pi /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.$(date +%Y%m%d)

※任意のバックアップディレクトリを指定してください。

  • 設定ファイルのバックアップ確認
diff -u /etc/httpd/conf/httpd.conf.$(date +%Y%m%d) /etc/httpd/conf/httpd.conf

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

  • 設定ファイルの書き換え(追記)

セキュリティ向上のため、署名の非表示化とサーバー名を追記します。

sudo bash -c "cat >> /etc/httpd/conf/httpd.conf" << 'EOF'

# Custom Settings
ServerSignature Off
ServerTokens Prod
ServerName example.com:80
EOF

example.com の部分は、ご自身のドメイン名またはホスト名に置き換えてください。

  • 差分の確認
diff -u /etc/httpd/conf/httpd.conf.$(date +%Y%m%d) /etc/httpd/conf/httpd.conf

末尾に指定した3行が追加されていることを確認します。

4. 設定反映を確認します

  • 構文確認
sudo httpd -t

Syntax OK と表示されることを確認します。

  • サービス再起動
sudo systemctl restart httpd
  • 設定の反映確認(ヘッダー確認)
curl -I http://localhost

以下のように、Server ヘッダーが Apache のみ(バージョン情報なし)になっていれば成功です。

HTTP/1.1 200 OK
Date: ...
Server: Apache
...

手なり作業の恐怖。(DNSの特異性)

ちょっとしたミスで地獄行きになるところだったので、自戒を込めてメモを記します。

何をやらかそうになったか?

「DNSの設定変更中、Aレコードとシリアル番号を間違えて登録するところだった」

なお、LinuxのDNS、BINDを用いての作業です。

なぜこれが危険なのか?

DNSレコードの設定は、インターネット上の住所録を書き換えるような作業です。一歩間違えると、メールが届かない、ウェブサイトが見られない、あるいは悪意のある第三者に通信を乗っ取られるといった甚大な被害に直結します。
というか、やらかしかけました。

なぜこれほどまでに慎重さが求められるか? 改めて、「自分に言い聞かせるレベルで」メモをします。

DNS設定ミスが引き起こす主なリスク

DNSは「一度間違えると修正が反映されるまで時間がかかる」という特性があるため、ミスが致命傷になりがちです。

サービス全停止(可用性の喪失)

AレコードCNAMEの記述ミスにより、全世界からサイトやAPIへの接続が断たれます。

メールの不達・消失(機会損失・信用リスク・レピュテーションリスク)

MXレコードの設定ミスは、ビジネス連絡の遮断を意味します。また、SPF/DKIM/DMARCなどの送信ドメイン認証に不備があると、正当なメールが「迷惑メール」として破棄されます。

サブドメイン乗っ取り(Subdomain Takeover)

これがある意味の恐怖です。不要になった外部サービス(SaaS等)へのCNAMEを残し続けると、そのドメインを第三者に取得され、せっかくのブランド名で偽サイトを運営されるリスクがあります。

キャッシュによる影響の長期化

後述するTTLの設定により、間違った設定が世界中のキャッシュサーバーに残り続け、即座に修正しても数時間は復旧しないことがあります。

BINDにおける「シリアル番号」とテキスト管理の罠

BIND(Berkeley Internet Name Domain)のようなテキストベースの管理では、私のようなエンジニアの「うっかり」が原因で同期不全が起きることがよくあります。

シリアル番号(Serial Number)の更新忘れ

BINDのゾーンファイルには、SOA (Start of Authority) レコード内にシリアル番号が存在します。

  • 仕組み:
    • セカンダリサーバーは、プライマリサーバーのシリアル番号が「現在より大きい数字」になった時だけ、新しい設定を同期(ゾーン転送)します。
  • リスク:
    • レコードの内容を書き換えても、シリアル番号を増やし忘れると、セカンダリサーバーには古い設定が残り続けます。 これにより、場所によって新旧の設定が混在する不安定な状態になります。

構文ミスとドット(.)の有無

BINDでは、FQDN(完全修飾ドメイン名)の末尾にドットを付け忘れると、オリジンのドメイン名が自動的に付加されてしまいます。

  • 例:
    -example.com と書くべきところを example.com.(末尾ドットあり)としなかった場合、example.com.example.com. という意図しないレコードとして解釈されます。

ミスを防ぐための4つの鉄則

これに関してはAIと壁打ちしながら設定しました。

1. TTL(Time To Live)を事前に短縮する

作業の数日前から、対象レコードのTTLを短く(例:300秒など)設定しておきます。

  • 理由:
    • 万が一ミスをしても、キャッシュが早く切れるため、被害を最小限に抑えられます。作業完了後に元の値に戻すのを忘れないようにしましょう。

2. BINDの構文チェックコマンドを活用

ファイルを保存した後、サービスを再起動(reload)する前に必ずチェックコマンドを叩く習慣をつけます。

named-checkzone [ドメイン名] [ゾーンファイル名]

`

ゾーンファイルの整合性確認(シリアル番号の形式ミスなども検知できます)

3. シリアル番号の運用ルール化

シリアル番号は YYYYMMDDNN(日付+その日の更新回数)の形式で運用するのが一般的です。

例: 2026年4月16日の1回目の修正 → 2026041601

この、第三者が見ても分かる増分をやりましょう。極端な話

  1. Friends
  2. Romans
  3. Countrymen

のような「ローマ的増分」は分かっているのが自分であっても混乱の元です。

4. 変更後の浸透確認(digコマンド等)

設定を反映したら、自分のPCのブラウザで確認するだけでなく、外部から正しく引けるかを確認します。

  • Google Public DNSで確認
dig @8.8.8.8 example.com A  
  • 同期設定をしたセカンダリDNSで確認
dig @[セカンダリDNSのIP] example.com A 

まとめ

DNS設定は、「間違えた瞬間に世界中にそのミスが拡散し、しかもすぐには消せない」という怖さがあります。

特にBINDなどの手動管理では、「シリアル番号のカウントアップ」と「末尾のドット」を指差し確認するだけでも、トラブルの多くを回避できます。作業前のTTL短縮と、作業後の多角的な検証をセットで行うようにしましょう。

「かんばん」を掲げる意味

拙稿にて、ドメインを掲げる意味として

  • Web上の住所
  • ブランドの顔
  • 信頼の証

の3つを挙げています。また、池波正太郎の

「人間、落ちるところへ落ちてしまっても、なにかこう、この胸の中に、たよるものがほしいのだねえ」
「たよるもの、ねえ…」
「いえば看板みたいなものさ」
「かんばん、かね…?」
「人間、だれしも看板をかけていまさあね。旦那のお店にもかけてござんしょう」
――『にっぽん怪盗伝』

にも感銘を受けています。「ちょっとしたミスによって看板に泥を塗る」事態が起きかけたという話でした。

Linux Webサーバの基本的な設定ミス(カモ)を狙ったログの傾向。

筆者のvpsに訪れる攻撃者。基本や最新のトレンドまで多くのパターンがあります。

そんな中、1分の間に大量の情報略取を試みる攻撃者のログがありました。

これらを紹介します。

ログ抜粋

例によって、テロリストに名前を与えないという哲学の元、アクセス者のグローバルIPは晒しません。

[Tue Apr 14 --:--:-- 2026] [security2:error] [client 192.0.2.10] ModSecurity: Access denied with code 404 (phase 1). [msg "[CUSTOM RULE] Host header is a numeric IP address. Blocked immediately."] [hostname "vps.example.jp"] [uri "/"]
[Tue Apr 14 --:--:-- 2026] [security2:error] [client 192.0.2.20] ModSecurity: Access denied with code 404 (phase 1). [hostname "vps.example.jp"] [uri "/.env"]
[Tue Apr 14 --:--:-- 2026] [security2:error] [client 192.0.2.20] ModSecurity: Access denied with code 404 (phase 1). [hostname "vps.example.jp"] [uri "/sendgrid.env"]
[Tue Apr 14 --:--:-- 2026] [security2:error] [client 192.0.2.20] ModSecurity: Access denied with code 404 (phase 1). [hostname "vps.example.jp"] [uri "/web/.env"]
[Tue Apr 14 --:--:-- 2026] [security2:error] [client 192.0.2.20] ModSecurity: Access denied with code 404 (phase 1). [hostname "vps.example.jp"] [uri "/static//etc/passwd"]
[Tue Apr 14 --:--:-- 2026] [security2:error] [client 192.0.2.20] ModSecurity: Access denied with code 404 (phase 1). [hostname "vps.example.jp"] [uri "/static//home/user/.aws/credentials"]

主な略取対象

どのようなファイルを見ようとしているのか?

言語・フレームワークの特定(Configuration Exploration)

  • 対象:
    • /settings.py (Django),
    • /config.js (Node.js),
  • 攻撃者の意図:
    • サーバの下調べです。フレームワークを特定することでどの脆弱性があるかを調べようとしています。

秘匿情報の取得(Environment Files)

  • 対象:
    • /.env
    • /sendgrid.env
    • /.env.local
    • /application.yml
    • /database.yml (Rails)
  • 攻撃者の意図:
    • 攻撃者がまず狙う情報です。ここにはデータベースの接続パスワード、SendGrid(メール配信サービス)のAPIキー、アプリケーションのシークレットキーがむき出し/平文で置かれていることが多いです。
  • 危険性:
    • ここが突破されれば、サーバのデータベースは私物化され、メール送信機能はスパムメール配信の踏み台にされます。

システムの脆弱性(Path Traversal & LFI)

  • 対象:
    • /static//etc/passwd
    • /static//etc/shadow
    • /static//proc/self/environ
  • 攻撃者の意図:
    • 静的ファイルのディレクトリから、強引にOSの中枢ファイルへ手を伸ばそうとしています。特に shadow ファイルなどは、ログイン情報の心臓部です。
  • 危険性:
    • /etc/passwd が奪われれば、サーバー内のユーザー一覧が露呈し、次の攻撃の正確な座標を与えてしまうでしょう。
    • /etc/shadow も暗号化されているとは言え、ローカル環境でハッシュ値を割り出されてしまいます。
    • 特に /proc/self/environ が読めると、実行中のプロセスの環境変数が丸見えになり、壊滅的な被害に繋がります。
  • 補足:
    • /staticこれは、特定のWAF(Webアプリケーションファイアウォール)や、リバースプロキシの設定(Nginxのエイリアス設定の不備など)をバイパスしようとする試みです。正規化の過程で // が / に変換される挙動を悪用し、本来アクセスできないディレクトリの外側へ飛び出そうとしています。

クラウドの鍵の窃取(Cloud Credentials)

  • 対象:
    • /static//home/user/.aws/credentials
  • 攻撃者の意図:
    • AWS(Amazon Web Services)のアクセスキー。サーバ内にこれを置きっぱなしにしている管理が甘い人たちを狙っています。
  • 危険性:
    • ある意味で最も危険と言えるでしょう。これを奪われれば、aws資産は攻撃者のビットコイン採掘場に変貌し、管理者の元には天文学的な請求書という地獄が待っています。

ここから分かること

彼らは「置き忘れ」や「甘い設定」を狙っています。

  • 初期値だから
  • 便利だからとstaticを使う
  • 管理が楽だから

などは組織の運用であって、攻撃者はそういうところが絶好のカモにしています。これは、私にも跳ね返る言葉ですが:

「ポーカーを始めて30分が過ぎても誰がカモか分からなければ、あなたがカモだ」

のウォーレン・バフェットの言葉はサーバ管理でも通用するというお話しでした。

Page 1 of 66

Powered by WordPress & Theme by Anders Norén