タグ: Linux Page 1 of 35

Zram運用後のメモリ量の推移

昨日運用を開始したzram。その効果を実感できる「単体テスト」にぶち当たりました。

  • 必要に応じて動かし
  • アップデートでメモリを恐ろしく消費する

Growiのアップデートです。

zram導入・運用環境 メモリ推移比較

項目1. 導入直後2. Growiアップデート後3. Growi起動中(安定時)
物理メモリ(使用/Total)2.78 / 5.78 GiB(高負荷)2.9 / 5.8 GiB
物理メモリ(空き/可用)0.42 GiB (Free)-2.9 GiB (Available)
zram展開サイズ (DATA)-1.4 GiB927.6 MiB
zram実占有 (TOTAL)-333.6 MiB258.1 MiB
圧縮率 (zstd)-約4.3倍約5.5倍
ディスクスワップ使用量0.02 GiB0 B0 B
主な状態初期クリーン状態ビルド等のメモリ最大消費時安定稼働・メモリ余裕あり

数値から見る運用の要諦

  • 導入直後はFreeが0.42GiBと心許ない数値でしたが、安定稼働時にはAvailableが2.9GiBまで回復しており、OSが自由に使える「机の広さ」が広くなっています。
  • Growiアップデートという最大の難所においても、Disk Swapを0Bに抑え込めたことが、システム全体のレスポンス維持に直結しています。
  • 安定稼働時に圧縮率が5.5倍まで向上しているのは、メモリ内の重複データやテキストデータが効率よく整理されているzstdの底力を見ました。

ここからのまとめ

「取り敢えず私のサーバには合っている」という形。他、気がついた事項は随時フィードバックしていきます。

UbuntuサーバにZramを導入したときの記録。

概要

筆者が運用しているWebサーバ。興味が向くまま様々なWebアプリを入れているため、メモリが心許ない事態が発生します。
単にスワップを増やすのではなく、Linuxの物理メモリ(RAM)の上に圧縮された専用領域(ブロックデバイス)を作成する、zramを導入します。

  • 通常の構造: RAM <---> Disk (HDD/SSD)
  • zram導入後: RAM [ 通常領域 | zram(圧縮領域) ] <---> Disk

環境

  • Ubuntu 24.04

メモリ環境

free -b | awk '
/Mem:/ {
  mem_total=$2/1024/1024/1024;
  mem_used=$3/1024/1024/1024;
  mem_free=$4/1024/1024/1024;
}
/Swap:/ {
  swap_total=$2/1024/1024/1024;
  swap_used=$3/1024/1024/1024;
  swap_free=$4/1024/1024/1024;
}
END {
  printf "| 項目 | 値 |\n| --- | --- |\n";
  printf "| Mem Total | %.2f GiB |\n", mem_total;
  printf "| Mem Used | %.2f GiB |\n", mem_used;
  printf "| Mem Free | %.2f GiB |\n", mem_free;
  printf "| Swap Total | %.2f GiB |\n", swap_total;
  printf "| Swap Used | %.2f GiB |\n", swap_used;
  printf "| Swap Free | %.2f GiB |\n", swap_free;
}'
項目
Mem Total5.78 GiB
Mem Used2.78 GiB
Mem Free0.42 GiB
Swap Total2.00 GiB
Swap Used0.02 GiB
Swap Free1.98 GiB

Caution! 導入の前に

これは万能薬ではありません。

メモリ上にブロックデバイスを作成しますが、その分、マシンパワーを喰います。

元々のメモリ量が少なければ効果を発揮しません。

例えば1GB未満のWebサーバでの運用は厳に慎むべきです。

破壊的アップデートを伴います。

「スワップをいじることのヤバさ」が知らない方は、この先の文章は読まないでください。(正直、DDoS喰らった時以上に神経を使う作業でした)

フェイズ・ゼロ(政治交渉)の必要性-再掲-

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

  • メモリが心許ない。
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、サーバそのものの再起動を伴う

など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

当然、設定の大幅変更に関わるので設計書や運用のドキュメント化も待っています。

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

さっくりとした手順

以下、フェイズ・ゼロをクリアした(必要ない)方向けです。

  1. カーネルモジュールを追加インストールします。
  2. zramをインストールします。
  3. zramの設定を行います。
  4. zramを有効化します。
  5. zramの内容を確認します。

※筆者の好みでaptitudeを用いています。必要に応じてaptに読み替えてください。

強く推奨:イメージ全体のバックアップ

仮想サーバ、vps等で運用している場合は、イメージ全体をバックアップ(スナップショット)などとしておき、何かあったときにすぐに戻せるようにします。

カーネルモジュールの追加インストール

これが地味にハマりました。

sudo apt install linux-modules-extra-$(uname -r)

これを入れていないと「現在のカーネルにzramモジュールが存在しない、あるいはロードできない」事態が発生します。(発生しました)

zramインストール

sudo aptitude install zram-tools

と、コマンド一発で済む作業です。しかし、コマンド一発で済む作業であるからこそ、チューニングは細心の注意が必要です。

zramの設定

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

エラーがなければOKです。diffを逆にしているのは、この後で説明します。

  • ファイルの修正

/etc/default/zramswapを以下のように修正します。自身の環境に合わせます

# 圧縮アルゴリズムの指定
ALGO=zstd
# 物理メモリの半分ほどを指定します
PERCENTAGE=50
# 念のため、ディスクサイズも指定します
SIZE=2048
# 既存スワップ(通常の-2)より高く設定します
PRIORITY=100
  • ファイルの修正確認
diff -u /path/to/backup/zramswap.$(date +%Y%m%d) /etc/default/zramswap
 #ALGO=lz4
+ALGO=zstd

 # Specifies the amount of RAM that should be used for zram
 # based on a percentage the total amount of available memory
 # This takes precedence and overrides SIZE below
 #PERCENT=50
+PERCENTAGE=50

 # Specifies a static amount of RAM that should be used for
 # the ZRAM devices, this is in MiB
 #SIZE=256
+SIZE=2048

 # Specifies the priority for the swap devices, see swapon(2)
 # for more details. Higher number = higher priority
 # This should probably be higher than hdd/ssd swaps.
 #PRIORITY=100
+PRIORITY=100

等と表示されればOKです。そして、ここで、先ほど示したdiffのsrcとdstを逆にした理由です。

  • 逆にする(バックアップからの差分)とすることで
    • 「何を足したか(つまり、現時点での正」が明白になります。
  • 逆にしないと
    • 正しい設定が「引かれている」状態となり、視覚的に危険な状態になります。

zramの有効化

  • zram再起動
sudo systemctl restart zramswap

`

※筆者がハマったのはここです。ここでエラーが発生してカーネルモジュールをインストールする手戻りが発生しました。

  • zramサービス確認
systemctl status zramswap.service 

active(exited)を確認します。(これは、apache/mysqlなどの常駐型サービスと異なり「カーネルにロードしてしまえば後はOK」という状態のためexitedとなっています。

サーバ再起動

sudo reboot

行います。再起動に慎重を要する(クラスタリングなど)はその手順に従ってください。

ここで再起動しない事態が発生したら?

「さぱっと死せい 黄泉路の先陣じゃ 誉れじゃ」

ぐらいの潔さを持ちましょう。(持てなければそもそも筆者はサーバ運用をしていません

潔さがない方のためのイメージ全体のバックアップであり、スナップショットなので。

zramの有効化確認

swapon --show
NAME       TYPE      SIZE USED PRIO
/swapfile  file        2G   0B   -2
/dev/zram0 partition   2G   0B  100

/dev/zram0がリストにあれば、カーネルがスワップとして認識中です。

zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd            2G   4K   59B   20K       4 [SWAP]

で、数字がカウントされればOKです。

Matomo連携時にハマったこと。(連携手順とSSL設定)

概要

オープンソースのWeb解析、

WordPressとMatomoを別々のサーバーで運用し、wp-matomo(現在の名称は「Connect Matomo」)を使用して連携させる手順を整理しました。

この設定により、WordPress側で収集したデータを別サーバーのMatomoへ送信し、WordPressの管理画面内でアクセス統計を確認できるようになります。

環境

Matomo側

  • Ubuntu 24.04
  • Apache 2.4
  • Mod Security v2

WordPress専用サーバ

  • Connect Matomoプラグイン

さっくりとした手順

  1. Matomo サーバでセキュリティトークンを発行します。
  2. WordPressのプラグインを設定します。

1. Matomoサーバー側での準備

まず、データの受け皿となるMatomo側で「接続許可証(トークン)」と「サイトID」を確認します。

  1. Matomoにログインします。
  2. サイトの追加: まだWordPressサイトを登録していない場合は、[管理(歯車アイコン)] > [ウェブサイト] > [管理] から「新しいウェブサイトを追加」でWordPressサイトを登録します。この際表示される 「サイトID」(通常は1, 2…といった数字)をメモしておきます。
  3. Authトークンの発行:
    [管理(歯車アイコン)] > [個人] > [セキュリティ] を開きます。
    ページ下部の 「認証トークン(Auth tokens)」 セクションで「新しいトークンを作成」をクリックします。
    パスワードを入力し、用途(例: WP-Connection)を入力して作成します。
    表示された 長い英数字の文字列(トークン) をコピーして控えておきます。

注意
※注意
トークンは一度しか表示されません。必ずこのタイミングでコピーしてください。

2. WordPress側での設定

次に、WordPressにインストールしたプラグインにMatomoの情報を入力します。

  1. 設定画面を開く: WordPress管理画面の [設定] > [WP-Matomo](または Connect Matomo)を開きます。
  2. 接続設定(Matomoへ接続o)タブ:
  • Matomo モード: 「自己ホスト (HTTP API, デフォルト)」を選択します。
  • Matomo URL: MatomoがインストールされているサーバーのURLを入力します(例: https://analytics.example.com/)。末尾に / を含めてください。
  • 認証トークン: 先ほどMatomo側でコピーしたトークンを貼り付けます。
  1. 変更を保存: 「変更を保存」をクリックします。
  • 接続に成功すると、上部に緑色のメッセージが表示され、「Select site」 ドロップダウンからMatomoに登録したサイト名が選べるようになります。

3. トラッキングの有効化

接続しただけでは計測が始まらない場合があるため、以下の設定を確認します。

  1. トラッキングを有効化タブ をクリックします。
  2. トラッキングコードを追加: 「デフォルトのトラッキング」を選択します。これにより、WordPressの各ページに自動で計測タグが挿入されます。
  3. 変更を保存 をクリックして完了です。

よくあるトラブルと確認事項

別サーバー構成でうまく動かない場合は、以下をチェックしてください。

-URLの正確さ: Matomo URLが httphttps か、またサブディレクトリ(/matomo/ など)にインストールしていないか再確認してください。

  • ファイアウォール: WordPressサーバーからMatomoサーバーへの通信(ポート80または443)が許可されているか確認してください。
  • キャッシュ: WordPress側でキャッシュプラグインを使用している場合、設定反映後に一度キャッシュをクリアしてください。

自分がドハマリしたポイント

接続に失敗し、その接続ログが出てこない事態も発生しました。

その答えは、筆者が設定したapacheの.confファイルに入りました。

SSL設定を、筆者の標準の

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2

から、以下の形で修正。

SSLProtocol -ALL +TLSv1.2 +TLSv1.3

これにより通信ができるようになりました。これには以下の理由があります。

1. 通信プロトコルの不一致(ハンドシェイクの失敗)

当初の設定: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 (意訳:TLS 1.3 のみを許可し、それ以外をすべて禁止する)

修正後の設定: SSLProtocol -ALL +TLSv1.2 +TLSv1.3 (意訳:TLS 1.2 と 1.3 の両方を許可する)

WordPressサーバーがMatomo APIにアクセスする際、内部ではPHPの cURL や openssl ライブラリが使用されます。もしWordPress側のOSやライブラリのバージョンが少し古い場合、あるいは最新であってもクライアント側の設定が TLS 1.2 までしか対応していない場合、Matomoサーバーが「TLS 1.3以外は受け付けない」という設定になっていると、共通の通信言語が見つからず、接続が即座に遮断されます。

2. PHP / cURL / OpenSSL の依存関係

WordPress(PHP)が外部サーバーと通信する際、バックグラウンドではシステム標準のOpenSSLライブラリが動いています。

TLS 1.3 を利用するには、OpenSSL 1.1.1以上が必要です。

もしWordPress側のサーバーOSが少し前の世代(例:Ubuntu 18.04やCentOS 7など)であったり、PHPのコンパイル環境が古い場合、TLS 1.3でのハンドシェイクを完遂できず、TLS 1.2での接続を試みようとします。

このとき、Matomo側が -TLSv1.2(1.2禁止)としていると、WordPress側は「接続できるプロトコルがない」と判断し、エラーを出します。

3. 「接続ログが出ない」という現象の理由

Apacheのアクセスログ(access.log)には、HTTPリクエストが成功または失敗した記録が残ります。しかし、SSL/TLSのハンドシェイク(暗号化の交渉)は、HTTPリクエストが送られる前段階で行われます。

TLS 1.2が禁止されている場合: 通信路を確立する前の「挨拶(ハンドシェイク)」の時点でサーバー側が「そのプロトコルは使えません」と接続を切断します。

こういうとき、以下のコマンドが有効です。

openssl s_client -connect analytics.example.com:443 -tls1_2

もし、このコマンドを実行して CONNECTED(00000003) と表示され、その後に証明書の情報がズラッと出てくれば、「インフラ(OS/ネットワーク/Apache)の土台は完璧である」という証明になります。

逆にここでエラーが出るなら、WordPressの設定(プラグイン)をいくらいじっても解決しないということが一瞬で分かります。

そのため、Apacheは「Webサイトへのアクセス」として認識する前に通信が終了してしまい、通常のアクセスログには一行も記録されないという事態が起こった話。

厳格な設定が裏目に出たという話でした。

ModSecurity環境下でのWP-Matomo連携設定

こちらの記事の続き。WebアクセスシステムMatomoをWordpressと連携させ、wp-matomoと連携するときに、Mod_Securityが邪魔をしたので処置を行いました。

環境

Matomo側

  • Ubuntu 24.04
  • Apache 2.4
  • Mod Security v2

WordPress専用サーバ

  • Connect Matomoプラグイン

発生していた問題(症例)

1. Expectヘッダーによるブロック(ID: 920450)

Matomoがデータ送信の準備として送った Expect ヘッダーが、WAFのポリシーによって「制限されたヘッダー」と判定されたログです。(IP/ホストなどはダミーに置き換え)

[Wed Jan 21 20:55:18.015915 2026] [security2:error] [pid 34746:tid 133273950865088] [client 192.0.2.100:56166] [client 192.0.2.100] ModSecurity: Warning. String match within "/content-encoding/ /proxy/ /lock-token/ /content-range/ /if/ /x-http-method-override/ /x-http-method/ /x-method-override/ /x-middleware-subrequest/ /expect/" at TX:header_name_920450_expect. [file "/usr/share/modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1187"] [id "920450"] [msg "HTTP header is restricted by policy (/expect/)"] [data "Restricted header detected: /expect/"] [severity "CRITICAL"] [hostname "matomo.example.com"] [uri "/"] [unique_id "aXC-pq-hNmFZwWUY4ipYBAAAAEg"]

2. スコア超過によるアクセス拒否(ID: 949110)

上記の Expect ヘッダー検知により、異常スコアがしきい値(5点)に達したため、通信が遮断(403 Forbidden)されたログです。

[Wed Jan 21 20:55:18.044159 2026] [security2:error] [pid 34746:tid 133273950865088] [client 192.0.2.100:56166] [client 192.0.2.100] ModSecurity: Warning. Operator GE matched 5 at TX:blocking_inbound_anomaly_score. [file "/usr/share/modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "233"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [hostname "matomo.example.com"] [uri "/"] [unique_id "aXC-pq-hNmFZwWUY4ipYBAAAAEg"]

3. 相関ログ(ID: 980170)

最終的にどのカテゴリの攻撃として判定されたかをまとめた報告ログです。

[Wed Jan 21 20:55:18.307310 2026] [security2:error] [pid 34746:tid 133273950865088] [client 192.0.2.100:56166] [client 192.0.2.100] ModSecurity: Warning. Unconditional match in SecAction. [file "/usr/share/modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "98"] [id "980170"] [msg "Anomaly Scores: (Inbound Scores: blocking=5, detection=5, per_pl=5-0-0-0, threshold=5) - (Outbound Scores: blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) - (SQLI=0, XSS=0, RFI=0, LFI=0, RCE=0, PHPI=0, HTTP=0, SESS=0, COMBINED_SCORE=5)"] [hostname "matomo.example.com"] [uri "/index.php"] [unique_id "aXC-pq-hNmFZwWUY4ipYBAAAAEg"]

行った措置:アプリケーション別除外ルールの作成

サーバー全体のセキュリティを下げるのではなく、特定のホスト(Matomoドメイン)に限定して、干渉しているルールのみを無効化します。

設定ファイルの記述例

/etc/modsecurity/rules/request-900-exclusion-rules-before-crs.conf 等に、以下の内容を追記、または作成します。

# ===================================================================
# アプリケーション別除外ルール: Matomo (matomo.example.com)
# ===================================================================

# 1. ターゲットとなるホスト名を指定し、それ以外は処理をスキップ
# ※ホスト名はご自身の環境に合わせて適宜読み替えてください
SecRule HTTP_HOST "@streq matomo.example.com" \
    "id:5001,phase:1,nolog,pass,chain,skipAfter:END_MATOMO_RULES_PRE"

    # 2. 特定されたホストに対し、干渉しているIDのみを無効化(外科手術)
    SecAction "ctl:ruleRemoveById=920450,ctl:ruleRemoveById=932370,ctl:ruleRemoveById=930130"

# スキップ先マーカー
SecMarker END_MATOMO_RULES_PRE

設定のテストと反映

上記、設定を行ったら

  • 構文チェック
sudo apache2ctl configtest

apache 再起動

sudo systemctl restart apache2.service

apache 再起動確認

systemctl status apache2.service

active(running)を確認します。

その後、wordpressのConnect Matomoのページに難度アクセス。

tail -f /var/log/matomo/matomo_error.log

等として(エラーログの場所は自分の環境に合わせます)

上記のログが出なければOKです。

今回の教訓

「最初にDetectionOnlyにしていたから助かった」に尽きます。

apacheの設定で

# Mod_security
<IfModule security2_module>
## 最初は検知モード
SecRuleEngine DetectionOnly
#SecRuleEngine On

と、コメントでオフオンを切り替えられる運用を組み込んでいたため、失敗を回避しました。

とはいえ

どハマりしたのがその、wp-connectとmatomoの連携だったのはまた改めて記します。

Ubuntu 24.04にMatomoをインストール。(PHP-FPM版)

概要

オープンソースの解析システムであるMatomoをインストールしたときのメモです。

  • Google Analysticにお金を払う余裕がない
  • WordPressのアクセス解析Jetpackは重い

ということで運用しました。

以前のメモがPHP8.3(mod-php)のインストールだったので、php-fpm版を改めて書き起こしています。

参考としたURL

  • https://matomo.org/faq/on-premise/matomo-requirements/

注意点

リアルタイムでアクセスする性質上、PVが非常に多いWebサイトではサーバ自体の冗長化構成が必要です。(上記URL参照)

筆者のサイトは10万ページ/月に満たないので、そこそこのスペックで運用できています。

前提

既に以下のシステムがWAN環境に揃っていること。

  • Ubuntu 24.04
  • Apache 2.4
  • mod_ssl
  • mod_rewrite
  • mod_header
  • ※実行ユーザーはwww-dataです。
  • mysql 8.3
  • PHP 8.3 → インストール方法
  • 必須の拡張機能(curl, gd, mbstring, mysql等)が有効になっていること。
  • PHP-FPM → インストール方法
  • ドメインで名前解決できること。
  • ドメインに沿った証明書があること。

さっくりとした手順

  1. MySQLのDBとユーザを作成します。
  2. ディレクトリにmatomoプログラムを配置します。
  3. Apache設定ファイルを作成します。
  4. matomoサイトにログインできることを確認します。
  5. matomo Web画面で初期設定をおこないます。

データベースを作成します。

  • MySQLログイン
sudo mysql -u root -p
  • DB作成
 CREATE DATABASE IF NOT EXISTS matomo CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; 

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

  • DBユーザー、パスワード設定
CREATE USER 'matomo'@'localhost' IDENTIFIED BY 'YOUR_STRONG_PASSWORD';

DBユーザーは自身の環境に合わせます。パスワードはポリシーに沿って強固なものを設定してください。

  • DBユーザーに作成したDBへの権限を付与
GRANT ALL PRIVILEGES ON matomo.* TO 'matomo'@'localhost';
  • MySQLコンソールからログアウト
exit;
  • DB作成確認
mysql -u matomo -p

DB名・ユーザー名は適宜自分が設定したものに読み替えてください。

  • DB確認
SHOW DATABASES;

作成したDBがあることを確認します。

EXIT

MySQLコンソールから抜けます。

matomoプログラムをディレクトリに配置します。

  • 保存用ディレクトリに移動
cd /hoge &&pwd

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

  • プログラムダウンロード
wget https://builds.matomo.org/matomo-latest.zip
  • ZIP展開
unzip matomo-latest.zip
  • ディレクトリの所有者変更
sudo chown -R www-data:www-data matomo

ディレクトリ一式をApache実行ユーザー(www-data)に修正します。

  • プログラム実行権に移動
sudo mv matomo /home/www-data/

自分の環境に合わせます。(筆者環境は/home/www-data/matomo で動かします)

ls -ld /home/www-data/matomo

該当ディレクトリにファイル一式があることを確認します。

Apache設定ファイルを作成します。

【】内を自分の環境に合わせます。
コマンド一式をコピー → 別のエディタにペースト
その後、【】内を自分の環境に修正してコピー
コマンド一式をSSHクライアントに貼り付ける

cat <<- __EOF__ | sudo tee  /etc/apache2/sites-available/matomo.conf > /dev/null
<VirtualHost _default_:80>
ServerName 【設定したドメイン名】
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName 【設定したドメイン名】
    CustomLog 【/var/log/matomo/matomo_access.log combined】
    ErrorLog 【/var/log/matomo/matomo_error.log】
    # アクセスログとエラーログは自分の環境に合わせて設定します。

    DocumentRoot 【/home/www-data/matomo】
     # PHPファイルの処理をFPMに渡す設定
    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/var/run/php/php8.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
    # -----------------------
    <Directory 【/home/www-data/matomo】>
    # DcoumentRootとDirectoryは自分の環境に合わせて設定します
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Require all granted
    </Directory>

#SSL設定
  SSLEngine on
    Protocols h2 http/1.1
  # SSLを有効化します

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
#TLS1.3に対応していないクライアントがアクセスする場合は以下を用います
#SSLProtocol -ALL +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:/var/run/apache2/ssl_stapling(32768)"
# 2025年5月よりLet's EncryptはSSL Staplingに伴うOCSPを廃止しました。そのため、証明書をLet's Encryptにしている場合は上記2行をコメントアウトし、代わりにこちらを用いてください。
# SSLUseStapling Off

SSLCertificateFile 【/etc/certs/example.com.crt】
# SSL証明書を指定します
SSLCertificateKeyFile 【/etc/private/example.com.key】
# 秘密鍵を指定します

# SSLCACertificateFile 【/etc/certs/example.com.CA.crt】
# 中間証明書が発行元から別ファイルで提供されている場合は、この直上をコメントアウトして中間証明書を指定します

    # index.php への転送設定
    DirectoryIndex index.php

#セキュリティヘッダー付与

    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"

    # Matomo: 機密情報が含まれるディレクトリへの直接アクセスを禁止
    <DirectoryMatch "/(config|core|lang|tmp|vendor)">
        Require all denied
    </DirectoryMatch>

    # Matomo: .ini や .json といった設定ファイルへの直接アクセスを禁止
    <FilesMatch "\.(ini|json)$">
        Require all denied
    </FilesMatch>

</VirtualHost>
__EOF__
  • ファイル作成確認
ls -l /etc/apache2/sites-available/matomo.conf

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

Apache設定を反映します。

  • .conf読み込み
sudo a2ensite matomo.conf
  • 設定確認
sudo apache2ctl configtest

Syntax OKを確認します

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
sudo systemctl status apache2.service
  • ブラウザ表示確認。

ブラウザで

https://【matomoを設定したドメイン名】

にアクセスし、初期画面が出ることを確認します。

初期インストール画面の設定

  1. 初期インストール画面が出たら「次へ」をクリックします。
  2. 全てチェックされていることを確認して「次へ」をクリックします。
◎データベースを設定します。
  • ログイン: MySQLのユーザー(matomo)
  • パスワード: 設定したパスワード
  • データベース名:作成したDB (matomo)

をそれぞれ入力し、「次へ」をクリックします。正常に入力されれば「テーブルを作成されました」と出るので「次へ」をクリックします。

◎スーパーユーザーを設定します。
  • スーパーユーザーログイン:ログインするユーザー名
  • パスワード:ログイン時のパスワード
  • パスワード(再入力)
  • メールアドレス

をそれぞれ入力して「次へ」をクリックします。

◎アクセス解析を行うウェブサイトを設定します。
  • アクセス解析対象のウェブサイトの名前
  • ウェブサイトのURL (このmatomoサイトではなく、アクセス解析を行いたいWebサイト)
  • ウェブサイトのタイムゾーン
  • eコマースか否か

を設定して「次へ」をクリックします。

これらを設定後、トラッキングタグが表示されます。これらを控えて「次へ」をクリックします。

「おめでとうございます!」と表示されればインストールの一連の作業は完了します。

Mod_Securityが検知したOpen Proxy スキャニングログ

2026年1月20日、筆者が管理するサーバにて、典型的な Open Proxy スキャニング(公開プロキシ探索攻撃) を検知しました。
WAF(ModSecurity)が、いかにして「身勝手な中継依頼」を門前払いしたか、実際のログからそのメカニズムを記録します。

1. 検知ログの概要(実録)

以下は、攻撃者が CONNECT メソッドを使用して外部ドメイン(www.baidu.com)へ接続しようとした際のログです。

[Tue Jan 20 05:43:59 2026] [security2:error] [client xx.xx.xx.xx] 
ModSecurity: Warning. Match of "within %{tx.allowed_methods}" against "REQUEST_METHOD" required. 
[id "911100"] [msg "Method is not allowed by policy"] [data "CONNECT"] [severity "CRITICAL"]
[hostname "www.baidu.com"] [uri "/"]

2. 攻撃の構造解析:何が起きていたのか?

このログから、攻撃者の明確な意図が読み取れます。

A. メソッドの悪用(CONNECT)

通常、Web閲覧(GET/POST)には使われない CONNECT メソッドが使用されています。これは本来、プロキシサーバに対して「外部サーバへのトンネルを作れ」と命じるためのコマンドです。

B. Hostヘッダの偽装

[hostname "www.baidu.com"]

攻撃者は、筆者のサーバに接続していながら、リクエストの宛先に www.baidu.com を指定しています。これは、筆者のサーバを「踏み台(Open Proxy)」にして、中国の検索エンジンにアクセスしようとする試みです。

これは、ほぼ、金盾の影響下にある者が当局の規制を逃れるため、私のvpsを利用しようとしたという背景でしょう。

3. 防御のロジック:なぜ止まったのか

ID 911100 の発動: ModSecurity CRS は、許可リストにないメソッド(CONNECT)を検知した瞬間、問答無用で CRITICAL 判定を下しました。

4. 結果:404ページへの誘導。

また、筆者のapacheのバーチャルサイトの設定もいい動きをしました。

ErrorDocument 403 404.html

としていたため、ModSecurity がアクセスを拒絶した後、Apache は設定された ErrorDocument に従い、403 forbiddenではなく、内部的に 404 not found を返しています。
攻撃者側から見れば、外部へのトンネルが開通するどころか、「そんなページ(機能)は存在しない」 という素っ気ない返答を掴まされて終わったことになります。

5. まとめ

今回の事例は、WAFのポリシーを「必要なものだけを許可し、不要なものは拒否する」状態に保ったことが防御につながった例です。

オレだけが外に出る事を
許可しろォォォ─────ッ

だが!
ウイルスは
許可しないィィィ────ッ

感染した部分は
出る事は
許可しないィィィィィ───ッ!!

というイルーヅォの言葉は割とセキュリティで重要という言葉を以て、本記事を締めくくります。

Linuxのディスク使用状況をMarkdown形式で一発表示するワンライナー

サーバーの構築メモやドキュメント作成時に、「現在のディスク使用状況をサクッとMarkdownの表にしたい」と思ったのがこちらのワンライナーのきっかけ。

通常、df -h などのコマンドを使いますが、結果をブログやGitHubのIssueに貼り付けるには整形の手間がかかります。

今回は、lsblkjq を組み合わせて、実行するだけで綺麗なMarkdownテーブルを出力する魔法のワンライナーをご紹介します。

使用するコマンド

以下のワンライナーを使用しました。

{ echo -e "| デバイスパス | 全サイズ | 使用率 | 空き容量 | マウントポイント |"; echo -e "| --- | --- | --- | --- | --- |"; lsblk -lnpo NAME,SIZE,FSUSE%,FSAVAIL,MOUNTPOINT --json | jq -r '.blockdevices[] | select(.mountpoint != null and (.name | contains("loop") | not)) | "| \(.name) | \(.size) | \(.["fsuse%"] // "0%") | \(.fsavail // "-") | \(.mountpoint) |"'; }

出力結果のイメージ

実行すると、以下のようなMarkdown形式のテキストが得られます。

デバイスパス全サイズ使用率空き容量マウントポイント
/dev/vda1149G24%109.9G/
/dev/vda15106M6%98.2M/boot/efi
/dev/vda16913M13%702.4M/boot

このワンライナーの仕組み

このコマンドは大きく分けて3つのパートで構成されています。

1.ヘッダーの作成

echo -e を使って、Markdownの表の1行目(項目名)と2行目(区切り線)を出力しています。

2. lsblkによるデータ取得(JSON形式)

lsblk コマンドに複数のオプションを渡しています。

  • -l: リスト形式で表示
  • -n: ヘッダーを非表示にする
  • -p: フルデバイスパスを表示(/dev/vda1など)
  • -o ...: 必要な項目(名前、サイズ、使用率、空き容量、マウントポイント)を指定
  • --json: データを扱いやすいJSON形式で出力します。

3. jqによるフィルタリングと整形

JSONデータを jq で加工し、Markdownの行 | ... | ... | の形に変換しています。

  • select(.mountpoint != null): マウントされていないデバイスを除外します。
  • contains("loop") | not: Snapパッケージなどで増えがちな loop デバイス(仮想デバイス)を除外してスッキリさせています。
  • \(.name) | ...: JSONの値をMarkdownのパイプ記号で囲んで出力します。

まとめ

このワンライナーを使えば、サーバー調査の結果をそのままドキュメントに記録できるため、作業効率が大幅にアップします。特にファイルサーバやWebサーバの定点観測に役立つでしょう。

GROWIスタックの運用を効率化するBashスクリプトの作成

1. はじめに

GROWI(Wikiシステム)をセルフホストする場合、本体の他にMongoDB、Elasticsearch、そしてリバースプロキシとしてのApacheなど、複数のサービスを管理する必要があります。これらを個別に手動で起動・停止するのは手間がかかり、手順ミスも起きやすくなります。

そこで、サービス間の依存関係を考慮し、安全かつ簡潔に管理するためのBashスクリプトを作成しました。

1-1. 筆者環境

  • Ubuntu 24.04
  • Growi (systemdにサービス登録済み)
  • Apacheのバーチャルホストでリバースプロキシ運用
  • mongodb
  • elasticsearch

2. スクリプトの主な特徴

  • 依存関係を考慮した起動順序:
    • DB → 検索エンジン(起動待ち含む) → Apache設定 → GROWI本体の順で確実に立ち上げます。
  • Apache設定の動的切り替え:
    • a2ensite / a2dissite を活用し、サービス停止時にはApache自体は止めず、GROWIへのアクセスパスのみをクリーンに遮断します。
  • 対話モードとコマンドライン引数の両対応:
    • 単体実行ではメニューが表示され、引数を渡せば自動実行が可能です。
  • エラーハンドリング: 各ステップで実行状態をチェックし、異常があれば即座に中断・通知します。

3. 管理スクリプト: manage-growi.sh

systemctlをいじるので、root権限で作っておきます。

#!/bin/bash

# ==============================================================================
# GROWIスタック管理スクリプト
# 対応サービス: MongoDB, Elasticsearch, Apache2, GROWI
# ==============================================================================

# --- [ 設定セクション ] ---
APACHE_CONF_NAME="growi.conf"
SITE_NAME="${APACHE_CONF_NAME%.conf}"
SERVICES=("mongod.service" "elasticsearch.service" "apache2.service" "growi.service")

# カラー出力設定
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
BLUE='\033[0;34m'
NC='\033[0m'

# --- [ ユーティリティ関数 ] ---

log_info() { echo -e "${BLUE}[INFO]${NC} $1"; }
log_warn() { echo -e "${YELLOW}[WARN]${NC} $1"; }
log_err()  { echo -e "${RED}[ERROR]${NC} $1"; exit 1; }
log_ok()   { echo -e "${GREEN}[SUCCESS]${NC} $1"; }

# 実行権限チェック
if [[ $EUID -ne 0 ]]; then
   log_err "このスクリプトの実行にはroot権限(sudo)が必要です。"
fi

# サービスの状態確認
is_active() {
    systemctl is-active --quiet "$1"
    return $?
}

# --- [ メイン機能 ] ---

start_services() {
    log_info "GROWIスタックの起動を開始します。"

    # 1. MongoDB
    log_info "データベース (MongoDB) を起動中..."
    systemctl start mongod.service
    is_active mongod.service || log_err "MongoDBの起動に失敗しました。"

    # 2. Elasticsearch
    log_info "検索エンジン (Elasticsearch) を起動中..."
    systemctl start elasticsearch.service
    # 応答待ち(最大75秒)
    for i in {1..15}; do
        if is_active elasticsearch.service; then break; fi
        [[ $i -eq 15 ]] && log_err "Elasticsearchの起動がタイムアウトしました。"
        sleep 5
    done

    # 3. Apache (設定の有効化)
    log_info "Apacheのリバースプロキシ設定を有効化しています..."
    if [ ! -L "/etc/apache2/sites-enabled/${APACHE_CONF_NAME}" ]; then
        a2ensite "${SITE_NAME}" > /dev/null
    fi
    systemctl reload apache2.service || systemctl start apache2.service

    # 4. GROWI 本体
    log_info "GROWI本体を起動中..."
    systemctl start growi.service
    sleep 3
    if is_active growi.service; then
        log_ok "すべてのサービスが正常に起動しました。"
    else
        log_err "GROWIの起動に失敗しました。ログを確認してください。"
    fi
}

stop_services() {
    log_info "GROWIスタックを停止します。"

    # サービス影響を最小限にするため、リバースプロキシから先に遮断
    log_info "GROWI本体を停止中..."
    systemctl stop growi.service

    log_info "Apacheの設定を無効化しています..."
    if [ -L "/etc/apache2/sites-enabled/${APACHE_CONF_NAME}" ]; then
        a2dissite "${SITE_NAME}" > /dev/null
        systemctl reload apache2.service
    fi

    log_info "バックエンドサービスを停止中..."
    systemctl stop elasticsearch.service
    systemctl stop mongod.service

    log_ok "すべての関連サービスが正常に停止しました。"
}

show_status() {
    echo -e "\n${YELLOW}--- サービス稼働状況 ---${NC}"
    printf "%-25s %s\n" "サービス名" "ステータス"
    printf "%-25s %s\n" "------------------------" "-------"
    for s in "${SERVICES[@]}"; do
        if is_active "$s"; then
            printf "%-25s ${GREEN}RUNNING${NC}\n" "$s"
        else
            printf "%-25s ${RED}STOPPED${NC}\n" "$s"
        fi
    done

    if [ -L "/etc/apache2/sites-enabled/${APACHE_CONF_NAME}" ]; then
        echo -e "Apache設定 (${APACHE_CONF_NAME}): ${GREEN}ENABLED${NC}"
    else
        echo -e "Apache設定 (${APACHE_CONF_NAME}): ${RED}DISABLED${NC}"
    fi
    echo ""
}

# --- [ エントリポイント ] ---
ACTION=${1:-"menu"}

case "$ACTION" in
    start)   start_services ;;
    stop)    stop_services ;;
    status)  show_status ;;
    restart) stop_services; start_services ;;
    menu)
        echo -e "${YELLOW}実行する操作を選択してください:${NC}"
        select opt in "Start" "Status" "Stop" "Restart" "Exit"; do
            case $opt in
                Start) start_services; break ;;
                Status) show_status; break ;;
                Stop) stop_services; break ;;
                Restart) stop_services; start_services; break ;;
                Exit) exit 0 ;;
                *) echo "無効な選択です。" ;;
            esac
        done
        ;;
    *)
        echo "Usage: $0 {start|stop|status|restart}"
        exit 1
        ;;
esac

4. 利用前の事前準備

スクリプトを使用するには、実行権限の付与と、システム上のファイル名の確認が必要です。

  1. 保存と実行権限の付与

ファイルを manage-growi.sh として保存した場合、以下のコマンドを実行します。

sudo chmod +x manage-growi.sh
  1. 設定の確認(重要)

スクリプト内の APACHE_CONF_NAME="growi.conf" が、実際に /etc/apache2/sites-available/ に存在するファイル名と一致しているか確認してください。

5.使い方(コマンド一覧)

このスクリプトは root権限(sudo) が必要です。

A. 対話型メニューで操作する

引数なしで実行すると、メニューが表示されます。

sudo ./growi-stack.sh

B. 直接コマンドを指定する

特定の操作を即座に実行したい場合に使用します。

  • 起動: sudo ./growi-stack.sh start
  • 停止: sudo ./growi-stack.sh stop
  • 状態確認: sudo ./growi-stack.sh status
  • 再起動: sudo ./growi-stack.sh restart

6. 表示・実行例

ステータス確認時の表示 (status)

現在の各サービスの稼働状況が一覧で表示されます。

--- サービス稼働状況 ---
サービス名                  ステータス
------------------------   -------
mongod.service             RUNNING
elasticsearch.service      RUNNING
apache2.service            RUNNING
growi.service              RUNNING
Apache設定 (growi.conf): ENABLED

起動処理の実行例 (start)

依存関係を考慮し、DBから順に起動していきます。

[INFO] GROWIスタックの起動を開始します。
[INFO] データベース (MongoDB) を起動中...
[INFO] 検索エンジン (Elasticsearch) を起動中...
[INFO] Apacheのリバースプロキシ設定を有効化しています...
[INFO] GROWI本体を起動中...
[SUCCESS] すべてのサービスが正常に起動しました。

7. スクリプトの主な特徴と処理順序

このスクリプトは、単なる一括起動ではなく、GROWIの依存関係を考慮した設計になっています。

順序起動時 (Start)停止時 (Stop)理由
1MongoDBGROWI本体DBがないとアプリが落ちるため / 停止は入り口から。
2ElasticsearchApache設定無効検索エンジンを準備。
3Apache設定有効Elasticsearchインフラが整ってから外部公開。
4GROWI本体MongoDB最後にアプリを立ち上げる。

8. 運用のヒント

  • トラブルシューティング: もし [ERROR] が出た場合は、個別のログを確認してください。
  • GROWIのログ: journalctl -u growi.service -f
  • Elasticsearchのログ: journalctl -u elasticsearch.service -f
  • 自動起動設定: サーバー再起動時に自動で立ち上げたい場合は、このスクリプトを使わず systemctl enable [サービス名] を各サービスに設定するのが一般的です。このスクリプトは、メンテナンス時の手動メンテナンス用として最適です。

防衛戦の後始末。広域IPブロックによる外部ストレージ(Wasabi)およびNextcloudの疎通不能と復旧

クリスマスに喰らった広域IPからのDDoSを排除した話。そこでの「友軍相撃(Friendly Fire)」をやらかしたという失敗談です。

事前背景

  1. クリスマスに自分のWebサイトを狙ったDDoSを喰らいました。
  2. そのとき、ipsetで /8という超高域ブロックを実施。

このときのメモはこちらにまとめています

その結果 何が起きたか(事象)

  • s3fsの不調: Wasabi(東京リージョン)のバケットがマウントされず、df -h コマンドが数分間フリーズ(Dステート一歩手前の待機状態)。
  • Nextcloudの孤立: 管理画面に「このサーバーにはインターネット接続がありません」と警告が表示され、アプリストアやアップデートチェックなどの外部通信がすべて遮断された。
  • システム負荷: 通信のタイムアウト待ちにより、VFS(仮想ファイルシステム)レイヤーでプロセスが滞留しました。

2. 原因切り分け(診断)

調査の結果、ネットワーク層およびカーネル層での遮断を確認しました。

エンドポイント疎通確認:

curl -v を実行した際、特定のIP帯域(103.151.x.x 等)へのTCPハンドシェイクが Trying... のまま進まず、タイムアウトすることを確認。

この時点で、「ああ、超・広範囲のブロックが徒になったか」と実感です。

ブロックルールの特定:

ipset list コマンドにより、自作の防御システム『ONE OUTS』で使用している ufw-blocklist に、以下の広域ブロックが登録されていることを突き止めました。

  • 103.0.0.0/8 (Wasabi東京リージョンを含むアジア圏の広大な帯域)
  • 85.0.0.0/8 (Nextcloud公式サーバーを含む欧州圏の広大な帯域)

結論: 昨年末のDDoS攻撃を鎮圧するために設定した「第1オクテット(/8)単位のブロック」が、正常な業務通信を巻き添えにする(Friendly Fire)結果を引きおこしたのです。

3. 対処(ufw-blocklistの解除)

干渉していた巨大なブロックエントリを ipset から削除し、通信路を復旧させました。

  • Wasabi (Tokyo) への疎通を確保
sudo ipset del ufw-blocklist 103.0.0.0/8
  • Nextcloud 公式サーバーへの疎通を確保
sudo ipset del ufw-blocklist 85.0.0.0/8
  • 設定の永続化
sudo ipset save ufw-blocklist -f /etc/ufw/ipsets.save

この状態では、まだs3fsプロセスが固まっていますので、これも対処。

  • 念のためs3fsプロセスを強制終了。
sudo killall -9 s3fs
  • 固まっていたマウントを解除。
sudo fusermount -u -z /mnt/wasabi2
  • fstabに基づく再マウント
sudo mount -a

4. 復旧確認(検証)

各サービスが正常なステータスに戻ったことを確認しました。

通信確認:

curl -I https://s3.ap-northeast-1.wasabisys.com303 See Other が即座に返ることを確認。

マウント確認:

df -h が遅延なく応答し、Wasabiバケットの容量が表示されることを確認。

Nextcloud確認:

管理画面の「インターネット接続なし」の警告が消え、外部連携機能が復旧したことを確認。

なぜ気づくのが遅れたか?

「このマウントはバックアップのため、普段めったに触れなかった」に尽きます。

今回、バックアップをいじるようになってからようやく気づいた次第です。これに関しては反省。

「使ってなければそれは見えていないのと同じ」というバイアスでした。

今回の教訓

私がipsetの搭載で言及した

これは、対象のIPアドレスをシャットアウトする「慈悲なき王」です。

を身を以て体感しました。なので、これを振るう時は更に注意する必要がありました。

それにしても、「自分だけが使うサーバのため、被害が自分だけで済んで良かった」と改めて思った次第です。こちらの記事にて

「『いい鉄砲は打ち手を選ぶ』ってことわざ知ってるか?
威力のある鉄砲は その分扱いも難しく危険
だから未熟者が使うと打ち手の方がケガをするってことさ」

が自分へ向かうことのないよう、日々、管理/監視を怠らないようにする必要があると知った出来事でした。

が、まさに自分に向かっていったというお話しで、本件を締めます。

SSH不正アクセス元の傾向(geoiplookupの使い方)

「取り敢えず乗っ取れそうなサーバがあるなら攻撃する」ぐらいの勢いでSSHに接続する輩。その数は浜の真砂のなんとやらです。

そこでふと思ったのが「どこの国からの不正攻撃が多いのか」という興味。これを調べてみます。

環境

  • Ubuntu 24.04
  • 公開鍵認証
  • fail2ban導入済み

まず、現在のBANリストの傾向を見る

以下を使って調べます。

 sudo fail2ban-client status sshd | grep "Currently banned"

結果

   |- Currently banned: 8473

なんと、8500にも及ぶIP群。これらをnslookup / digで調べるのは非効率。そして、それらを一覧してシェルスクリプトを組むのもDNSのクエリーを食い潰します。

geoiplookupによる調査

そこで、geooplookupを用います。

インストールは以下の方法で。(筆者は好みでaptitudeを用いています)

sudo aptitude install geoip-bin geoip-database

インストール後、

geoiplookup 8.8.8.8

を入力。

GeoIP Country Edition: US, United States

が帰ってくればOKです。

では、GeoIPで実際に、fail2banが検知したものを見てみます。

sudo fail2ban-client status sshd | grep "IP list" | sed 's/.*IP list: \+//' | tr ' ' '\n' | while read ip; do geoiplookup "$ip" | cut -d: -f2; done | sort | uniq -c | sort -rn | head -n 20

こちらの結果は

   1716  CN, China
   1134  US, United States
    498  CA, Canada
    487  SG, Singapore
    476  VN, Vietnam
    394  ID, Indonesia
    344  HK, Hong Kong
    327  DE, Germany
    314  IN, India
    229  RU, Russian Federation
    212  KR, Korea, Republic of
    175  BR, Brazil
    167  GB, United Kingdom
    164  IR, Iran, Islamic Republic of
    149  NL, Netherlands
    124  FR, France
     95  JP, Japan
     86  TH, Thailand
     71  IT, Italy
     69  ES, Spain

ここから分かること

組織的なスキャンの存在:

上位10カ国だけで、全体の半分近く(約5,700件)を占めています。特定の地域に設置されたデータセンターやクラウドプロバイダーのIP群から、システマチックに攻撃が来ていることが推測できます。

「日本国内」がランク外の安心感:

上位10カ国に日本(JP)が入っていないことから、ターゲットを絞った攻撃というよりは、「世界中を無差別に絨毯爆撃しているボット」に私のサーバーが見つかり、それをFail2Banがコツコツと捕獲し続けている状況です。

まとめ

「vps一本でサーバを公開する」という宣言は自由ではありますが「これだけの悪意と戦う自由」との隣り合わせ。

こちらの記事を再掲しますが、

鍵交換認証にする理由
  • パスワードが送信されない
  • パスワード認証では、パスワード自体がネットワーク上を流れるため盗聴リスクがあります。
  • 鍵認証では、秘密鍵が署名を生成し、署名のみが送信されるため、秘密情報が直接送られることはありません
  • 総当たり攻撃に強い
  • パスワードは文字数が少ないと短時間で破られる可能性があります。
  • 鍵認証では、2048ビット以上の鍵が使われることが多く、現在の一般的なサーバの計算能力では事実上破ることが不可能です。
  • 盗聴されても再利用できない
  • 鍵認証では毎回異なるチャレンジに対して署名を行うため、録音や再送信による攻撃(リプレイ攻撃)が通用しません。
  • フィッシング耐性が高い
  • パスワード認証は偽サイトに入力してしまうリスクがあります。
  • 鍵認証では秘密鍵がローカルに保管されており、外部に送信されないためフィッシングに強いです。

は、心に留めておくべきSSHの運用です。

Page 1 of 35

Powered by WordPress & Theme by Anders Norén