タグ: Ubuntu Page 1 of 22

免責事項:これは甲斐谷忍先生の作品『ONE OUTS』に敬意を表したシステム名/ファンアートであり、公式(集英社、製作委員会など)とは一切関係ありません。

『ONE OUTS』システム番外:ipsetによるUFWの効率化。

はじめに

筆者が用いているWebへの攻撃を防ぐ、MOD_SECURITYとApache設定、シェルスクリプトの連携「ONE OUTSシステム」。これは「実際にWebサイトにアクセスした者」への盾として機能していますが、「アクセス未満」での低レイヤーでの攻撃を仕掛ける者を防ぎきることができません。

例えば、SYNフラッド攻撃はWebサイトへの攻撃を仕掛けるわけではないのでログに残らず、じわじわとリソースを奪っていきます。

かといって、これらのSYNフラッド攻撃は極めて広範囲のIPレンジから仕掛けてくるので

sudo ufw insert 1 deny from xxx.xxx.xxx.xxx

とするには、ufwでのルールが広範になりすぎてメンテナンス性ならびにシステムパフォーマンスの低下を招きます。

これを解決するための手段を設けました。

環境

  • Ubuntu 24.04
  • ufw導入済み

行ったこと

  1. ipsetコマンドをインストールします。
  2. ブロックリストの設定を行います。
  3. ipsetコマンドでSYNフラッド攻撃を行う攻撃者をレンジごとブロックします。

事前注意

これは、カーネルメモリにufwのブロックリストを付与する、「破壊的アップデート」の可能性が発生します。

  • セキュリティポリシー
  • 明確な運用基準

組織単位 で行う必要があります。

手順

ipsetコマンドのインストール

※筆者の好みでaptitudeを用いています。環境に合わせてapt等に読み替えます。

  • パッケージアップデート
sudo aptitude update
  • ipsetインストール
sudo aptitude install ipset

※ 要注意 ※

ここでは、ipset-persistantコマンドを入れていません。なぜなら、ufwと競合する結果、パッケージ管理はufwを破壊する可能性があるからです。

  • ipsetインストール確認
ipset -v
ipset v7.19, protocol version: 7
ipset v7.19: Kernel error received: Operation not permitted

※この、not permittedは、root権限で実行していないため許可されていないというメッセージです。

ipsetのルール変更

  • ブロックしたいIPを格納するための「セット」をメモリ上に作成します。

これは再起動時に消えます

sudo ipset create ufw-blocklist hash:net

ufwにipsetを参照するルールを追加します。

  • ufwの前段ルールをバックアップ
sudo cp -pi /etc/ufw/before.rules /path/to/backup/before.rules.$(date +%Y%m%d)

→ バックアップ先は任意のものを指定します

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

※ここでsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです

  • ファイル修正

上記、/etc/ufw/before.rulesの内容を慎重に修正します。 *.filterのすぐ下の行です。

# ===================================================================
# "ufw-blocklist" セットに含まれるIPからの全パケットを破棄する
-A ufw-before-input -m set --match-set ufw-blocklist src -j DROP
# ===================================================================

# ok all existing rules
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
  • ファイル修正確認
sudo diff -u /path/to/backup/before.rules.$(date +%Y%m%d) /etc/ufw/before.rules 

以下の差分になっていることを確認します。

 *filter
+# ===================================================================
+# "ufw-blocklist" セットに含まれるIPからの全パケットを破棄する
+-A ufw-before-input -m set --match-set ufw-blocklist src -j DROP
+# ===================================================================
+
+# ok all existing rules

リロード前確認(最重要)

さて、ここまで手順通りに行えばufwのリロードは正常に完了します。しかし、ここで今一度

  • sudo ipset create ufw-blocklist hash:netを実行したか?
  • /etc/ufw/before.rulesを編集したか?
  • この編集は既存ファイルの内容を削除していない(追記のみ)か?

を確認しましょう。確認しなければ、この先に待ち構えているのは「失敗した場合の自分自身のロックアウト」にもつながります。

ufwリロード

よく深呼吸しましょう。実行前に何か飲み物を飲んでおいてもいいぐらいです。

sudo ufw reload

ファイアウォールを再読込しましたのメッセージが出れば成功です!

sudo ufw status

でも状態:アクティブを確認します。

ipset のリストを「永続化」する

ipset-persistent の代わりに、UFW自身の起動・停止スクリプトに、リストの保存・復元を組み込みます。

  • A. 保存用ファイルのパスを定義

まず、ipset のリストを保存するファイルを決めておきましょう。 ここではIPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"と定義します。

  • B. UFW起動時にリストを「復元」する設定

ufw が起動する前に、保存したリストを読み込むようにします。

sudo cp -pi /etc/ufw/before.init /path/to/backup/before.init.$(date +%Y%m%d)

でバックアップを取ります。(バックアップディレクトリを一括にしているならbefore.init.$(date +%Y%m%d)の前にbefore.rules.$(date +%Y%m%d)を作っているはず。「タブの補間はせず、確実にファイルのバックアップを取りましょう)

sudo diff -u /path/to/backup/before.init.$(date +%Y%m%d) /etc/ufw/before.init

で、バックアップが成功していることも確認します。※diffでもsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです

/etc/ufw/before.initを編集します。

ファイルの一番上(#!/bin/sh の直後)に、以下の行を追記します。

IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"

# 起動時に ipset リストをファイルから復元する
if [ -f "$IPTABLES_IPSET_SAVE_FILE" ]; then
    ipset restore -f "$IPTABLES_IPSET_SAVE_FILE"
fi
sudo diff -u /path/to/backup/before.init.$(date +%Y%m%d) /etc/ufw/before.init
 #!/bin/sh
+IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"
+
+# 起動時に ipset リストをファイルから復元する
+if [ -f "$IPTABLES_IPSET_SAVE_FILE" ]; then
+    ipset restore -f "$IPTABLES_IPSET_SAVE_FILE"
+fi

を確認。

  • UFW停止時にリストを「保存」する設定

ufw が停止(またはリロード、シャットダウン)する後に、現在のリストをファイルに保存するようにします。

sudo cp -pi /etc/ufw/after.init /etc/conf_backup/after.init.$(date +%Y%m%d)
sudo diff -u /etc/conf_backup/after.init.$(date +%Y%m%d) /etc/ufw/after.init 

※diffでもsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです

/etc/ufw/after.initを管理者権限で編集します。 ファイルの一番上(#!/bin/sh の直後)に、以下の行を追記します。

IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"

# 停止時に現在の ipset リストをファイルに保存する
ipset save -f "$IPTABLES_IPSET_SAVE_FILE"

追記後、

sudo diff -u /etc/conf_backup/after.init.$(date +%Y%m%d) /etc/ufw/after.init 

で差分を確認します。

 #!/bin/sh
+IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"
+
+# 停止時に現在の ipset リストをファイルに保存する
+ipset save -f "$IPTABLES_IPSET_SAVE_FILE"
  • コマンド実行権付与
sudo chmod +x /etc/ufw/before.init /etc/ufw/after.init

→ コマンドを追記しているので重要です!

再度のufwリロード前の確認

ここでも

  • /etc/ufw/before.initを編集し、差分通りか?
  • etc/ufw/before.initを編集し、差分通りか?
  • この編集は既存ファイルの内容を削除していない(追記のみ)か?
  • /etc/ufw/before.init /etc/ufw/after.initに実行権限が付与されているか?

を確認しましょう。確認しなければ、こちらも自分自身のロックアウトにつながります。

ufwリロード

よく深呼吸しましょう。今度は手元にあればお茶菓子を食べてもいいぐらいです。

sudo ufw reload

ファイアウォールを再読込しましたのメッセージが出れば成功です!

sudo ufw status

でも状態:アクティブを確認します。

ここまで来たら:SYNフラッド攻撃への対処

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

ブロック対象は慎重に慎重を期します。

  • メモリ上のリストに即時追加
sudo ipset add ufw-blocklist IPアドレス・NWアドレス

→ 実際のIPアドレスを半角で入力しましょう。

  • メモリ上のリストをファイルに「永続化」
sudo ipset save ufw-blocklist -f /etc/ufw/ipsets.save

(sudo ipset save ではない点に注意してください)

  • 永続化確認
cat /etc/ufw/ipsets.save 

として

create ufw-blocklist hash:net family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xcce80b68
add ufw-blocklist IPアドレス・NWアドレス

等と表示されれば成功です。

※この作業はufwリロード不要です。※

まとめ

「相手が回りくどい攻撃をしてきたら、更に回りくどい方法をとらなければならない」という形。

正直、この作業は二度とやりたくない部類に入ります。ですが、一度設定してしまえば

sudo ipset add ufw-blocklist IPアドレス・NWアドレス

で永続的に執拗な攻撃を仕掛ける攻撃者に対処することが可能です。

Linuxにおけるrootの特別感

  • なんとなくrootを使っている
  • そもそもrootしかアカウントを使っていない

と言う方への注意喚起としても書いている記事です。

Linuxにおける「root」の特別性:システムを司る絶対的な権限

Linuxサーバーを運用する上で、誰もが耳にする最も重要なアカウント、それが「root」ユーザーです。このアカウントは、単なる管理者権限を持つユーザーという枠を超え、システム全体を司る絶対的な権限を持つ存在として位置づけられています。

なぜrootはそれほどまでに特別か、というその問題提起を行います。

システム全体を制御する「神」の権限

Linuxは、セキュリティと安定性のために「権限分離(Privilege Separation)」の原則に基づいて設計されています。一般ユーザーは、自分のホームディレクトリや許可されたファイルに対してのみ操作が可能で、システムの中核に関わる重要な設定ファイルやディレクトリには基本的に触れることができません。

一方でrootユーザーは、この権限の壁を完全に超越します。

  • 全ファイルの読み書き・実行権限: システム内のすべてのファイルとディレクトリに対して、制限なくアクセス、変更、削除が可能です。
  • カーネル操作: システムの心臓部であるLinuxカーネルの設定変更や、重要なモジュールのロード/アンロードが可能です。
  • 全ユーザーの管理: どのユーザーのパスワードでも変更でき、プロセスを強制終了させ、システムを再起動・シャットダウンできます。
  • ポートの利用: 予約された特別なポート(1024未満)を利用したサービスを起動できます。

絶大な力と隣り合わせの危険性

この絶大な力は、システム管理者にとっては不可欠なツールですが、一歩間違えれば致命的な破壊に繋がりかねません。

例えば、一般ユーザーであれば誤って自分のファイルしか削除できませんが、rootユーザーが誤って / (ルートディレクトリ) で rm -rf のようなコマンドを実行すれば、システム全体が一瞬にして破壊されてしまいます。(システム権限に関する部分は維持されるでしょう。しかし、/homeディレクトリにあるユーザデータは消し飛びます。

そのため、システム管理者であっても、普段の作業は権限の制限された一般ユーザーとして行い、root権限は本当に必要な時だけ susudo コマンドで一時的に利用することが鉄則です。

ちょっとした具体例

例えば:

systemctl status apache2.service

は本当によく使うコマンドです。

同様に

exit

はコンソールから抜ける時にも使う初歩的なコマンドでしょう。

しかし、

systemctl 

を打った状態で電話があった、声をかけられ中座する必要があった場合。 (これは本当に頻発します)
「まぁいいや、そっちに集中したいからコンソールを抜けよう」と

systemctl exit

を実行すると

shutdown -h now

と全く同じ効果が得られます。これは笑い事ではない事実です。

systemctl exit一般権限のユーザで実行した場合は

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
'exit.target'を開始するには認証が必要です。
Authenticating as:

と、「ん? なんか様子が違うぞ?」で思い直すことができますが、これがrootユーザーの場合は

システム停止を自然に、言葉通りに受け止め実行します。

話は戻しましょう。

「全能である」がゆえの危険性と不可欠な存在という側面が、rootユーザーを他のアカウントと一線を画す「特別」な存在にしているのです。

一般的にrootのプロンプトが「#」とされているのは、この 「システムを破壊する力」 を持っていることを常に意識し、コマンドの入力に細心の注意を払うための、管理者自身への視覚的な警告として機能しているのです。

それを防ぐためのちょっとしたTIPS

これを防ぐために私がLinuxサーバを設定時に真っ先に指定する記述がこれです。

/home/hoge/.bashrc

hogeは自分のログインユーザです。

ここの末尾に以下のように記します。

PS1="[\u@\H \W]\$ "

# 一般ユーザ向けのプロンプト設定
if [ "$PS1" ]; then
  if [ "$(id -u)" -eq 0 ]; then # rootユーザの場合
    PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
  else # 一般ユーザの場合
    PS1='\[\e[0;32m\][\u@\H \W]$\[\e[0m\] '
  fi
fi

プロンプト設定の意図解説

このPS1設定の主要な意図は、セキュリティの確保と作業効率の向上のために、ユーザーの種別(rootか一般ユーザーか)と現在のコンテキストを視覚的に明確化の措置です。

ユーザー種別による視覚的な区別

最も重要な意図は、誤操作を防ぐためにrootユーザー(管理者)と一般ユーザーの環境を瞬時に見分けられるようにすることです。

  • rootユーザーの場合 (id -u0)
    • 色: \e[0;31m は赤色を設定しています。絶大な権限を持つroot環境では、コマンド入力に細心の注意が必要であることを、視覚的な警告として管理者に促します。
    • プロンプト末尾: \#(通常は#に展開)は、伝統的にrootユーザーを示す記号です。
  • 一般ユーザーの場合:
    • 色: \e[0;32m は緑色を設定しています。通常作業を行う安全な環境であることを示します。
    • プロンプト末尾: $ は、伝統的に一般ユーザーを示す記号です。

コンテキストの明確化

ユーザーの種別に関わらず、プロンプトには以下の情報を含めることで、管理者が「誰として」「どのサーバーの」「どのディレクトリにいるか」を一目で把握できるようにしています。

記号意味
\u現在のユーザー名rootadmin
\Hホスト(サーバー)の完全な名称server.example.com
\W現在の作業ディレクトリのベース名/var/log/ の場合は log

設定スクリプトの技術的な解説

初期設定

PS1="[\u@\H \W]\$ "

これは、色の設定が機能しない場合や、条件分岐(if文)に入る前のデフォルトのプロンプトとして機能します。

条件分岐によるプロンプトの切り替え

if [ "$PS1" ]; then
    if [ "$(id -u)" -eq 0 ]; then # rootユーザの場合
        PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
    else # 一般ユーザの場合
        PS1='\[\e[0;32m\][\u@\H \W]$\[\e[0m\] '
    fi
fi
  • if [ "$(id -u)" -eq 0 ]; then: コマンドid -uを実行し、現在のユーザーIDを取得します。0はrootユーザーを意味します。このIDに基づいてプロンプトを切り替えます。
  • \[\]: これらは、エスケープシーケンス(色の設定部分)をbashに非表示文字として認識させるための重要な記号です。これがないと、bashがプロンプトの長さを誤認し、コマンド入力時の行がずれてしまう不具合が発生します。
  • \e[0m: これは色のリセットコードです。プロンプトの末尾にこれを記述することで、プロンプト以降に入力されるユーザーのコマンドや出力が色付きにならないように戻しています。

Ubuntu/Debian系での重要な留意点

このプロンプト設定は、ログインするユーザーの環境に適用される必要があります。

UbuntuやDebian系のシステムでは、rootユーザーとしてログイン(またはsu -で環境を切り替え)する際の.bashrcの扱いが、他のシステム(例:CentOS/RHEL)と異なる場合があります。

多くのシステムでは、rootユーザーのホームディレクトリは /root です。

  • 一般ユーザーのプロンプト設定は、/home/(ユーザー名)/.bashrc に記述します。
  • rootユーザーのプロンプト設定は、通常 /root/.bashrc に記述する必要があります。

この設定は、root環境にも適用。コンソールログインなどでrootでログインした場合にも備え、/root/.bashrcにも明記する必要があります。

補足:

/etc/bash.bashrc などのシステム全体の設定ファイルに記述することも可能ですが、特定のユーザーのみに設定を適用したい場合は、ユーザーごとの.bashrcファイルを使用するのが最も確実な方法です。

まとめ

RHEL系で最初にsudo su -をしたときに明示される

「大いなる力には大いなる責任が伴う」

をより明確にした言葉があります。『鉄人28号』でも高らかに歌われている

あるときは正義の味方
あるときは悪魔の手先
いいもわるいもリモコンしだい

この3行は、まさにLinuxのrootアカウントという「大いなる力」の二面性を表しています。

サーバ管理者は、この力が「悪魔の手先」とならないよう、使う一瞬一瞬に

  • 「自分は今、強大な力を得ているのか?」
  • 「この力は良き目的、必要な手段として用いるのか?」

を自問する必要があります。 その『意識のリモコン』を操作するために、筆者は明確にプロンプトで視覚化しているというお話でした。

CPU/メモリの利用状況を確認するスクリプト

Webサーバのみならず、サーバ運用において「どのプロセスがCPU/メモリを喰っているか」というボトルネックの把握は重要です。

それを把握するためのスクリプトのご紹介です。

なぜボトルネックの把握が重要なのか

以下の3点が主な理由です:

  1. リソースの最適化と安定運用
     高負荷プロセスを特定することで、不要な消費を抑え、他のサービスへの影響を防げます。
  2. 障害予防と早期対応
     異常なリソース使用は障害の前兆であることが多く、早期発見によりダウンタイムを回避できます。
  3. 攻撃予兆への対応
     DDoS/執拗な攻撃などはリソース量にダイレクトに現れます。

把握するためのシェルスクリプト

といっても、topwコマンドなどでは煩雑な情報が多いため、シンプルに

  1. CPUを多く使っているプロセス
  2. メモリを多く使っているプロセス

に絞り込みを行います。というのも、プロセスの暴走は先に示したとおり、CPU/メモリを多く使うからです。

それをより分かりやすく視覚化するスクリプト例が以下の通り。

top-procs.sh等の名前で、任意の場所に作成します。

#!/bin/bash

# スクリプト名: top-procs.sh
# 説明: CPU使用率またはメモリ使用率が高い上位5つのプロセスを表示します。

# 表示するプロセス数の設定
TOP_N=5

# ヘルプ表示関数
show_help() {
    echo "--- プロセス監視スクリプト ---"
    echo "このスクリプトは、システムのCPU使用率またはメモリ使用率が高い上位${TOP_N}つのプロセスを表示します。"
    echo ""
    echo "使用方法: $0 [オプション]"
    echo ""
    echo "オプション:"
    echo "  -c          : CPU使用率 (%\$CPU) の高い上位${TOP_N}つのプロセスを表示します。"
    echo "  -m          : メモリ使用率 (%\$MEM) の高い上位${TOP_N}つのプロセスを表示します。"
    echo "  -a          : CPUとメモリの両方の上位${TOP_N}つのプロセスを表示します。(引数なしと同じ)"
    echo "  -h          : このヘルプを表示します。"
    echo ""
    echo "出力形式: 割合(%) PID COMMAND"
    echo "-----------------------------------------"
}

# プロセス情報表示関数
# 引数1: ソート対象 (CPU/MEM)
# 引数2: ソートフィールド番号 (ps auxの3番目か4番目)
# 引数3: タイトル
show_top_procs() {
    local type=$1
    local field=$2
    local title=$3

    echo ""
    echo "--- ${title} (上位 ${TOP_N} プロセス) ---"
    echo " %${type}   PID  COMMAND"
    echo "-----------------------------------------"

    ps aux |
        # ヘッダー行をスキップ
        tail -n +2 |
        # 指定フィールド (CPU:%3, MEM:%4) で降順ソート
        sort -k ${field} -r |
        # 上位N行を抽出
        head -n ${TOP_N} |
        # PID ($2)、割合 ($field)、COMMAND ($11以降) を整形して表示
        awk -v field="${field}" '{
            cmd="";
            for(i=11;i<=NF;i++){
                cmd=cmd" "$i
            };
            # $fieldには$3(%CPU)または$4(%MEM)の値が入る
            printf "%6.2f%% %6s %s\n", $field, $2, cmd
        }'
}

# メインロジック

if [ "$#" -eq 0 ] || [ "$1" == "-a" ]; then
    # 引数なし、または -a の場合 (全て表示)
    show_top_procs "CPU" 3 "CPU使用率"
    show_top_procs "MEM" 4 "メモリ使用率"
elif [ "$1" == "-c" ]; then
    # -c の場合 (CPUのみ)
    show_top_procs "CPU" 3 "CPU使用率"
elif [ "$1" == "-m" ]; then
    # -m の場合 (メモリのみ)
    show_top_procs "MEM" 4 "メモリ使用率"
elif [ "$1" == "-h" ]; then
    # -h の場合 (ヘルプ)
    show_help
else
    # 不正な引数の場合
    echo "不正なオプションです: $1" >&2
    show_help
    exit 1
fi

仕組み

メインロジックは非常に簡単。

ps , sort, 等のコマンドとawkを発展させたもの。

./top-procs.sh

を実行することで、

--- CPU使用率 (上位 5 プロセス) ---
 %CPU    PID  COMMAND
-----------------------------------------
 52.10%  12345  ruby_app_server: /var/www/webapp1 (production)
  9.40%   1086  /usr/sbin/database_server [...]
  3.80%  42162  /usr/sbin/web_server -k start
  1.50%  42161  /usr/sbin/web_server -k start
  0.90%   7978  nodejs_process /path/to/nodejs_app/server.js

--- メモリ使用率 (上位 5 プロセス) ---
 %MEM    PID  COMMAND
-----------------------------------------
 13.10%   1984  /usr/bin/java -Xms256m -Xmx256m [...] search_engine -Des.path.home=/usr/share/search_engine [...]
 10.00%   1086  /usr/sbin/database_server [...]
  7.50%  12345  ruby_app_server: /var/www/webapp1 (production)
  3.90%  78630  ruby_app_server: /var/www/webapp2 (production)
  3.80%  76583  ruby_app_server: /var/www/webapp3 (production)

が出てきます。

この例では、rubyアプリが圧倒的にCPUを消費し、ElasticSearchがメモリを食っているというのが分かります。

そして、

  • -a / 引数無し : CPUとメモリの両方を表示
  • -c : CPU情報のみを表示
  • -m : メモリ情報のみを表示
  • -h : これら引数やスクリプトの内容を表示

と、目的に合わせた柔軟な表示も可能にしています。

ついでにコマンド化

こういった障害発生時のボトルネック判定時、いちいちスクリプトの場所を探すという悠長なことはできません。

なので、余裕がある(つまりこのスクリプトを作成した直後です)状況で、

sudo ln -sf /path/to/script/top-procs.sh /usr/local/bin/top-procs

として、どこからでもコマンドを呼び出せるようにします。(スクリプトの場所は自分がこれを保存した絶対パスを指定してください)

which top-procs

/usr/local/bin/top-procs

と表示されればコマンド化は完了。こうすることにより、どのユーザーでもこのコマンド一発で上記のボトルネック判定が可能になります。

Redmineインストール後に行う避難訓練(Redmineの再作成)

ここでは、Redmineを立ち上げ、基本的な設定を済ませた人が行っていただきたい「避難訓練」について述べます。

環境

  • Ubuntu 22.04
  • 動かしていたRedmine:5.1
  • Apache 2.4 / mod-passangerでRubyアプリを使用(Ruby 3.2.3)
  • MySQL 8.0.3

避難訓練の内容

  • 最終的な目的
    • Redmineの再構築
  • 避難訓練で行うこと
    • DBバックアップ
    • 「稼働環境のDBの削除」
    • Redmine再構築
    • バックアップしたDBの流し込み
    • 再構築確認

何故このタイミングで?

「他の人が誰も使っていない状態だから」に尽きます。

自分以外の誰かが使っている中で

  • 障害が発生してしまった状況でいきなりリストアを行う
  • 最初にリストア訓練を行っている

状況下、安心できるのはどちらでしょうかという単純な問題。

そして、Redmineは古くから(2006年)使われているため

  • プラグインの相性問題
  • チューニングミス
  • 設定変更

などで簡単にぶっ壊れます。筆者は2桁単位で壊してます。なので「壊れないようにする」ではなく「壊れてもすぐ元に戻せる」心構えがRedmineは特に重要です。

作業前のチェック

以下が必須です。

  • [ ] 慎重な心構え
  • [ ] ある程度リラックスできて集中できる環境。

さっくりとはならない手順

  1. スナップショットのバックアップ (推奨)
  2. DBのバックアップ
  3. redmineのディレクトリを一度mvでリネームしてバックアップ。
  4. apache停止
  5. redmineのDBを消す。
  6. redmineのDBを新たに作る。(ユーザは全て権限があるので問題なし)
  7. apache再開
  8. ディレクトリを再作成。
  9. themesとpluginを再配置。
  10. themesとpluginを再配置した状態でDBマイグレーション。
  11. DBリストア。
  12. 動作確認。

システム全体のバックアップ(推奨)

万一に備え、システム全体のバックアップを取ることを推奨します。AWSや仮想サーバ等の場合は、インスタンスをまるごとバックアップしておくと良いでしょう。

mysqldumpによるDBバックアップ

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

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

mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql

DB名やDBユーザは自分の環境に合わせます。

データ退避

  • Redmineのルートディレクトリの上に移動
cd /home/www-data && pwd

Redmineが格納されているディレクトリの親ディレクトリに移動します。筆者環境は/home/www-dataなので、自分の環境に合わせます。

  • ディレクトリがあることを確認
ls -ld redmine

退避対象のディレクトリがあることを確認します。

  • リネームして退避
sudo mv redmine redmine_$(date +%Y%m%d)
  • 退避確認
ls -ld redmine_$(date +%Y%m%d)

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

apache停止

ここでWebサービスを停止するのは、DBを削除するためです。

  • apache停止前確認
systemctl status apache2.service

active(running)を確認します

  • apache停止
sudo systemctl stop apache2.service
  • apache停止後確認
systemctl status apache2.service

inactive(dead)を確認します

DB削除と再作成

この作業は慎重に行って下さい。

  • 管理者権限でmysqlにログイン
sudo mysql -u root -p
  • DB確認
SHOW DATABASES;

redmineのDBがあることを確認します。

  • RedmineのDBを削除
DROP DATABASE redmine;

DB名は再確認してください。この作業前に3回ほど深呼吸して、何か飲み物をゆっくり飲んでからにしましょう。

  • RedmineのDB削除確認
SHOW DATABASES;

RedmineのDBがないことを確認します。

  • 空のDB再作成
CREATE DATABASE redmine CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

同じDBを作り直します。

  • 空のDB再作成確認
SHOW DATABASES;

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

EXIT
  • redmineDBユーザでログイン
mysql -u redmine -p

DB再作成前、redemineのDBにアクセスできるユーザー名です。上記操作はDBの削除は行いましたがユーザーの削除は行っていません。従って、削除前のユーザー名とパスワードでRedmineのDBにアクセス可能です。

  • DB確認
SHOW DATABASES;

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

EXIT

ディレクトリ退避

  • Web格納ディレクトリに移動
cd /home/www-data && pwd

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

  • 退避前ディレクトリ確認
ls -ld redmine

Redmine格納ディレクトリは自分の環境に合わせます。このでぃれくとりがあることを確認します。

  • Redmineディレクトリ退避
sudo mv redmine /path/to/backup/redmine_$(date +%Y%m%d)

バックアップ環境は自分の環境に合わせます。

  • Redmineディレクトリ退避確認
ls -l /path/to/backup/redmine_$(date +%Y%m%d)

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

  • 退避後ディレクトリ確認
ls -ld redmine

退避させたディレクトリが元のでぃれくとりにないことを確認します。

ソースダウンロード

  • ディレクトリ作成
sudo mkdir /home/www-data/redmine

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

  • ディレクトリの所有者変更
sudo chown -R www-data:www-data /home/www-data/redmine
  • svnダウンロード
sudo -u www-data svn co https://svn.redmine.org/redmine/branches/5.1-stable /home/www-data/redmine

5.1系の最新安定版をダウンロードします

退避させたディレクトリからconfigファイルコピー

  • 退避させたRedmine→ 新規に作成したRedmineにコンフィグをコピー
sudo cp -pi /path/to/backup/redmine_$(date +%Y%m%d)/config/database.yml /home/www-data/redmine/config/database.yml

コピー元・コピー先は自分の環境に合わせます。

  • コンフィグの中身確認
cat /home/www-data/redmine/config/database.yml

コピーされていることを確認します。

  • 退避させたRedmine→ 新規に作成したRedmineにメール設定情報などをコピー
sudo cp -pi /path/to/backup/redmine_$(date +%Y%m%d)/config/configuration.yml /home/www-data/redmine/config/configuration.yml

コピー元・コピー先は自分の環境に合わせます。

  • 設定情報の中身確認
cat /home/www-data/redmine/config/configuration.yml

Redmineインストール

  • ディレクトリ移動
cd /home/www-data/redmine
  • bundle
sudo -u www-data bundle install --without development test --path vendor/bundle
  • シークレットトークン発行
sudo -u www-data bundle exec rake generate_secret_token
  • DBマイグレーション
sudo -u www-data RAILS_ENV=production bundle exec rake db:migrate
  • 言語設定
sudo -u www-data RAILS_ENV=production REDMINE_LANG=ja bundle exec rake redmine:load_default_data

apache再開

  • apache再開前確認
systemctl status apache2.service

inactive(dead)を確認します

  • apache再開
sudo systemctl start apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

再作成後の仮パスワード作成

対象のRedmineにアクセスします。

IDとパスワードがadmin / admin に戻っている状態のため、ログイン後、仮パスワードを発行します。

退避したディレクトリからデータを再配置

この状況では単に「再作成されたRedmine」だけができている状況です。ここから、バックアップを流し込んでいきましょう。

  • 退避したRedmineのプラグインディレクトリに移動
cd /hpath/to/backup/redmine_$(date +%Y%m%d)/plugins && pwd
  • プラグイン一式のコピー
sudo cp -pir ./* /home/www-data/redmine/plugins/
  • 退避したRedmineのテーマディレクトリに移動
cd /path/to/backup/redmine_$(date +%Y%m%d)/public/themes
  • テーマ一式のコピー
sudo cp -pir ./* /home/www-data/redmine/public/themes/

いくつかのファイルを上書きするか求められるので、yで返します。

  • 退避したRedmineの添付ファイル格納ディレクトリに移動
cd /path/to/backup/redmine_$(date +%Y%m%d)/files
  • 添付ファイル一式のコピー
sudo cp -pir ./* /home/www-data/redmine/files/
  • 退避したRedmineのログディレクトリに移動
cd /path/to/backup/redmine_$(date +%Y%m%d)/log
  • ログ一式のコピー
sudo cp -pir ./* /home/www-data/redmine/log/

プラグイン再マイグレーション

  • Redmineのルートディレクトリに移動
cd /home/www-data/redmine
  • bundle
sudo -u www-data bundle install
  • プラグインのDBマイグレーション
sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production

apacheリスタート

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

DBリストア

  • mysqldumpを行ったディレクトリに移動
cd /hoge && pwd
  • DBリストア
mysql -h localhost -u redmine -p redmine < redmine_backup.$(date +%Y%m%d).sql

パスワードはredmineインストール時に設定したDBユーザのパスワードです。

apacheリスタート

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

動作確認

この状態でRedmineに管理者権限でログインします。手順通りなら

  • テーマ
  • 添付ファイル
  • プラグイン
  • チケット一覧

などが有効に動いています。

オプション:作業後-退避前のディレクトリ一式を削除-

  • 退避させたディレクトリの直上に移動
cd /path/to/backup

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

  • 退避ディレクトリ確認
ls -ld redmine_$(date +%Y%m%d)

ディレクトリがあることを確認します。

  • 退避ディレクトリ削除
sudo rm -rf redmine_$(date +%Y%m%d)
  • 退避ディレクトリ確認
ls -ld redmine_$(date +%Y%m%d)

ディレクトリが無いことを確認します。

オプション:作業後-MySQLのダンプファイルを削除-

  • mysqldumpを行ったディレクトリに移動
cd /hoge && pwd
  • ダンプファイル確認
ls -l redmine_backup.$(date +%Y%m%d).sql

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

  • ダンプファイル削除
rm redmine_backup.$(date +%Y%m%d).sql
  • ダンプファイル削除確認
ls -l redmine_backup.$(date +%Y%m%d).sql

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

備考

Redmineはバージョンさえ合っていれば

  • DB
  • 設定ファイル
  • 添付ファイル
  • プラグイン
  • テーマ
  • ログ

を移行することで、Redmineの作り直しのみならず、別のサーバへの引っ越しが可能になります。

この、避難訓練さえ行っていけば「何かがあってもバックアップさえあれば動かせる」という心の安定につながるでしょう。

免責事項:これは甲斐谷忍先生の作品『ONE OUTS』に敬意を表したシステム名/ファンアートであり、公式(集英社、製作委員会など)とは一切関係ありません。

『ONE OUTS』システム(Apache/Mod_Security/テキストファイル連携によるWeb防御)解説。 3 OUT

概要

  • Apache
  • Mod_Security
  • テキストファイル

連携によるWeb防御『ONE OUTS』3回目。

ここでは応用編として、筆者の具体的なチューニングや追加設定などをご紹介します。

Cron設定

前項で説明したone_outs.sh。これは、筆者はCron化して自動運用しています。そのため、スクリプトは以下のように簡素化しています。

#!/bin/bash
#
# ONE OUTS System - IP Blacklist Auto-Generator (for cron)
#
# このスクリプトは、Tor出口ノードのリストとApacheのエラーログから
# 不審なIPアドレスを抽出し、ModSecurity用のブラックリストを自動生成します。
# cronなどで定期的に実行することを想定しています。
#

# === 変数の定義 ===

# --- 基本設定 ---
SCRIPT_BASE_DIR="/usr/local/scripts/security"
APACHE_LOG_DIR="/var/log/apache2"
MODSEC_BLACKLIST_FILE="/etc/modsecurity/ip-blacklist.txt"

# --- 除外設定 ---
EXCLUDE_IPS_FILE="${SCRIPT_BASE_DIR}/conf/exclude_ips.txt"

# --- 中間ファイル設定 ---
TOR_EXIT_LIST_RAW="${SCRIPT_BASE_DIR}/work/tor_exit_nodes_raw.txt"
TOR_EXIT_LIST_IPS="${SCRIPT_BASE_DIR}/work/tor_exit_nodes_ips.txt"
SUSPICIOUS_IPS_DAILY="${SCRIPT_BASE_DIR}/work/suspicious_ips_daily.txt"
SUSPICIOUS_IPS_ALL="${SCRIPT_BASE_DIR}/work/suspicious_ips_all.txt"

# === 処理の開始 ===

# 1. Tor出口ノードリストの取得
curl -s -o "${TOR_EXIT_LIST_RAW}" "https://check.torproject.org/exit-addresses"
if [ $? -ne 0 ]; then
    # エラーが発生した場合は syslog に記録
    logger "ONE OUTS Script Error: Failed to download Tor exit node list."
    exit 1
fi
awk '/^ExitAddress/ {print $2}' "${TOR_EXIT_LIST_RAW}" | sort -u > "${TOR_EXIT_LIST_IPS}"

# 2. Apacheエラーログからの不審IP抽出
grep "ModSecurity" "${APACHE_LOG_DIR}/error.log" | \
    grep -o -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | \
    sort -u > "${SUSPICIOUS_IPS_DAILY}"

touch "${SUSPICIOUS_IPS_ALL}"
cat "${SUSPICIOUS_IPS_ALL}" "${SUSPICIOUS_IPS_DAILY}" | sort -u > "${SUSPICIOUS_IPS_ALL}.tmp" && mv "${SUSPICIOUS_IPS_ALL}.tmp" "${SUSPICIOUS_IPS_ALL}"

# 3. ブラックリストの生成
# 変更前のチェックサムを保存
PREV_CHECKSUM=$(md5sum "${MODSEC_BLACKLIST_FILE}" | awk '{print $1}')

# Torリストと不審IPリストを結合して一時ファイルを作成
cat "${TOR_EXIT_LIST_IPS}" "${SUSPICIOUS_IPS_ALL}" | sort -u > "${MODSEC_BLACKLIST_FILE}.tmp"

# 4. 除外IPの削除
if [ -f "${EXCLUDE_IPS_FILE}" ]; then
    grep -v -f "${EXCLUDE_IPS_FILE}" "${MODSEC_BLACKLIST_FILE}.tmp" > "${MODSEC_BLACKLIST_FILE}"
else
    mv "${MODSEC_BLACKLIST_FILE}.tmp" "${MODSEC_BLACKLIST_FILE}"
fi
rm -f "${MODSEC_BLACKLIST_FILE}.tmp" # -f オプションでファイルがなくてもエラーにならないように

# 変更後のチェックサムを取得
POST_CHECKSUM=$(md5sum "${MODSEC_BLACKLIST_FILE}" | awk '{print $1}')

# 5. ファイルに変更があった場合のみApacheをリロード
if [ "${PREV_CHECKSUM}" != "${POST_CHECKSUM}" ]; then
    logger "ONE OUTS Script: Blacklist updated. Reloading Apache."
    systemctl reload apache2.service
fi

exit 0

これをcrontabで設定。(その際にはchmod +x one_outs.shを忘れないように)

# ONE OUTS
0 4 * * * sleep $(shuf -i 0-59 -n 1)m && /home/hoge/script/server/one_outs.sh

として実行します。この、実行分をランダムにするのは、リストが更新されるというトリガーをつかみにくくするためです。

スローロリス攻撃への対処

この、ONE_OUTSの自動実行を行った頃、サーバのレスポンスが悪くなると言う状況を確認しました。以下のようなログを確認(アクセス元などはダミーに置き換えています)

# [クライアントIP] [タイムスタンプ]
# --- 攻撃検知 (1/2): カスタムルールが矛盾したConnectionヘッダーを検知 ---
[Mon Oct 20 11:30:05 2025] [security2:error] [client 198.51.100.201] ModSecurity: Warning. ... [id "10001"] [msg "[CUSTOM RULE] Contradictory Connection header, possible Slowloris probe."] [hostname "your-domain.com"] [uri "/search?query=some-long-query"]

# --- 攻撃検知 (2/2): CRSの標準ルールも同じ異常を検知 (スコア+3) ---
# data "keep-alive, close" の部分で、実際にどのようなデータが送られてきたかを確認できます。
[Mon Oct 20 11:30:05 2025] [security2:error] [client 198.51.100.201] ModSecurity: Warning. ... [id "920210"] [msg "Multiple/Conflicting Connection Header Data Found"] [data "keep-alive, close"] [severity "WARNING"] [hostname "your-domain.com"] [uri "/search?query=some-long-query"]

# --- 最終報告: 合計スコアとブロックに至らなかった状況を記録 ---
# この攻撃単体ではスコアが3のため、ブロックしきい値の5には達していません。
# 他の攻撃と組み合わさった場合に、ブロックの判断材料となります。
[Mon Oct 20 11:30:05 2025] [security2:error] [client 198.51.100.201] ModSecurity: Warning. ... [id "980170"] [msg "Anomaly Scores: (Inbound Scores: blocking=3, detection=3, ... threshold=5)"] [hostname "your-domain.com"] [uri "/search?query=some-long-query"]

これは典型的なスローロリス攻撃。

「Connectionヘッダーにkeep-aliveとcloseを同時に送信する」ことで、コネクションを矛盾させリソースを奪い最終的に枯渇を狙うというのは、攻撃者がCRS(Core Rule Set)に基づいた防御を行っていると確認した際/または単純な威力偵察の際によく使う手です。

漫画『ドリフターズ』に曰く

「こりゃ堕とせんと思ったら
その時から目的は変わるのよ
占領からいやがらせに変わる」

この、いやがらせ目的のため、自分のサーバのリソースが奪われるという状況は見過ごせません。以下のような処置を設けます。

免責事項:これは甲斐谷忍先生の作品『ONE OUTS』に敬意を表したシステム名/ファンアートであり、公式(集英社、製作委員会など)とは一切関係ありません。

『ONE OUTS』システム(Apache/Mod_Security/テキストファイル連携によるWeb防御)解説。 2 OUT

概要

  1. IPアドレスリストによるブロック
  2. エージェントのブロック
  3. ModSecurityのブラックリストのブロック

の3段階のフィルタを設けたONE OUTSシステム。その核となる「ModSecurityのブラックリストの自動生成」です。

スクリプト内容

  • one_outs.sh

こちらを、変数を自分の環境に合わせた状態で 修正していきます。性質上、root権限で作成します。

#!/bin/bash
#
# ONE OUTS System - IP Blacklist Auto-Generator
#
# このスクリプトは、Tor出口ノードのリストとApacheのエラーログから
# 不審なIPアドレスを抽出し、ModSecurity用のブラックリストを自動生成します。
# cronなどで定期的に実行することを想定しています。
#

# === 変数の定義 ===

# --- 基本設定 ---
# スクリプトのベースディレクトリ。環境に合わせて変更してください。
SCRIPT_BASE_DIR="/usr/local/scripts/security"
# Apacheのログディレクトリ。環境に合わせて変更してください。
APACHE_LOG_DIR="/var/log/apache2"
# ModSecurityのブラックリストファイル。SecRuleで指定したパスに合わせます。
MODSEC_BLACKLIST_FILE="/etc/modsecurity/ip-blacklist.txt"

# --- 除外設定 ---
# ブラックリストから除外したいIPアドレスを記述したファイル
# (例: 自分のIPアドレスや、正常なクローラーのIPなど)
EXCLUDE_IPS_FILE="${SCRIPT_BASE_DIR}/conf/exclude_ips.txt"

# --- 中間ファイル設定 (通常は変更不要) ---
# Tor出口ノードの生データをダウンロードする一時ファイル
TOR_EXIT_LIST_RAW="${SCRIPT_BASE_DIR}/work/tor_exit_nodes_raw.txt"
# Tor出口ノードのIPアドレスのみを抽出したリスト
TOR_EXIT_LIST_IPS="${SCRIPT_BASE_DIR}/work/tor_exit_nodes_ips.txt"
# Apacheのエラーログから抽出した不審なIPリスト (日次)
SUSPICIOUS_IPS_DAILY="${SCRIPT_BASE_DIR}/work/suspicious_ips_daily.txt"
# 過去分も含めた、全ての不審なIPリスト
SUSPICIOUS_IPS_ALL="${SCRIPT_BASE_DIR}/work/suspicious_ips_all.txt"
# スクリプト実行時の日付 (YYYYMMDD形式)
TODAY=$(date +%Y%m%d)

# === 処理の開始 ===

echo "--- IP Blacklist Generation Started at $(date) ---"

# 1. Tor出口ノードリストの取得
echo "[Step 1] Downloading Tor exit node list..."
curl -s -o "${TOR_EXIT_LIST_RAW}" "https://check.torproject.org/exit-addresses"

if [ $? -ne 0 ]; then
    echo "Error: Failed to download Tor exit node list."
    exit 1
fi

# ExitAddress行からIPアドレスのみを抽出し、ソートして重複を排除
awk '/^ExitAddress/ {print $2}' "${TOR_EXIT_LIST_RAW}" | sort -u > "${TOR_EXIT_LIST_IPS}"
echo " -> Tor IP list created: ${TOR_EXIT_LIST_IPS}"


# 2. Apacheエラーログからの不審IP抽出
echo "[Step 2] Extracting suspicious IPs from Apache error log..."
# エラーログの中からModSecurityが検知したIPアドレスを抽出
# (grepとsedでIPアドレスのパターンのみを抜き出す)
grep "ModSecurity" "${APACHE_LOG_DIR}/error.log" | \
    grep -o -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | \
    sort -u > "${SUSPICIOUS_IPS_DAILY}"
echo " -> Daily suspicious IP list created: ${SUSPICIOUS_IPS_DAILY}"

# 過去の不審IPリストと今日の日次リストを結合し、最新の完全なリストを作成
# (ファイルが存在しない場合のエラーを避けるため、touchで空ファイルを作成)
touch "${SUSPICIOUS_IPS_ALL}"
cat "${SUSPICIOUS_IPS_ALL}" "${SUSPICIOUS_IPS_DAILY}" | sort -u > "${SUSPICIOUS_IPS_ALL}.tmp" && mv "${SUSPICIOUS_IPS_ALL}.tmp" "${SUSPICIOUS_IPS_ALL}"
echo " -> All suspicious IPs list updated: ${SUSPICIOUS_IPS_ALL}"


# 3. ブラックリストの生成
echo "[Step 3] Generating the final blacklist..."
# TorのIPリストと、これまで蓄積した不審なIPリストを結合
cat "${TOR_EXIT_LIST_IPS}" "${SUSPICIOUS_IPS_ALL}" | sort -u > "${MODSEC_BLACKLIST_FILE}.tmp"


# 4. 除外IPの削除
echo "[Step 4] Removing excluded IPs from the blacklist..."
if [ -f "${EXCLUDE_IPS_FILE}" ]; then
    # grep -v -f を使い、除外リストにあるIPを行ごと削除
    grep -v -f "${EXCLUDE_IPS_FILE}" "${MODSEC_BLACKLIST_FILE}.tmp" > "${MODSEC_BLACKLIST_FILE}"
else
    mv "${MODSEC_BLACKLIST_FILE}.tmp" "${MODSEC_BLACKLIST_FILE}"
fi
rm "${MODSEC_BLACKLIST_FILE}.tmp"
echo " -> Final blacklist created: ${MODSEC_BLACKLIST_FILE}"


# 5. Apacheの再読み込み (設定の反映)
# echo "[Step 5] Reloading Apache to apply changes..."
# systemctl reload apache2.service
# echo " -> Apache reloaded."
# ※ cronで実行する際は、再起動処理が多発しないよう注意が必要です。
#    ファイルに差分があった場合のみ再起動する、などの工夫を推奨します。


echo "--- IP Blacklist Generation Finished at $(date) ---"

作成後、

chmod +x oune_outs.sh

で実行権限を付与します。

そもそも、何故このスクリプトに至ったか?

Torという絶好の隠蔽手段のアクセス者を「バッターボックスに立たせない」

Tor (The Onion Router)はインターネット上での通信を匿名化するための技術とネットワークです。

  • プライバシー保護
  • 検閲回避
  • ジャーナリストや活動家の安全確保

が利用目的。

  1. 入り口ノード(本来のアクセス元からここにアクセス)
  2. 中継サーバ(タマネギの皮を重ねる/剥くように暗号化と複合化で通信の秘匿性を維持)
  3. 出口ノード(アクセス先のサーバにはこの出口ノードからのIPアドレスが表示される)

の三段階で高い匿名性を保っています。ですが、

通信元のIPアドレスが隠されるため、誰がアクセスしているか特定しづらい。

という、サイバー攻撃者にとって非常に都合がいい技術となっています。そのため、この隠蔽手段は最初からアクセスを排除します。

また、このTorの出口ネットワークはほぼ日替わりで更新。

https://check.torproject.org/exit-addresses

この、「攻撃者にとって都合のいい情報」を「防御側も利用できる情報」として転用。

上記スクリプトでは、このURLにアクセスし、出口ノードをダウンロード。その後、IPアドレスの形式で出力します。

攻撃を試みた者は「二度目のチャンスを与えない」

Torを失ってでも不審なアクセスを試みた場合は、Mod_Securityが検知。以下のようなログを検出します。(IPやURLはダミーにしています)

免責事項:これは甲斐谷忍先生の作品『ONE OUTS』に敬意を表したシステム名/ファンアートであり、公式(集英社、製作委員会など)とは一切関係ありません。

『ONE OUTS』システム(Apache/Mod_Security/テキストファイル連携によるWeb防御)解説。 1 OUT

概要

これは、筆者が自分のサーバに組み込んでいるWebセキュリティシステム(と言ってもスクリプトと設定の組み合わせ) 『ONE OUTS』について述べたものです。

  1. OSSで動くこと
  2. シンプルな仕組みであること
  3. メンテナンス性と再現性が高いこと

を目標に構築しました。

メンテナンスが高いとは言え、少々複雑な流れを含むため、いくつかに分けて解説します。

名前の由来

甲斐谷忍先生による同名の野球漫画『ONE OUTS』から来ています。

  • 持ち玉はストレートのみ
  • パワーよりも心理戦で打者を翻弄
  • ルールの裏をかきながらもルールに従う姿勢

などをイメージしながら構築しました。

環境

以下の環境で動いています。

  • Ubuntu 24.04
  • Apache 2.4
    • モジュール
      • mod_rewrite
      • mod_ssl
      • mod_header
      • mod_alias
      • mod_security2
  • シェルスクリプト

次のページから、実際のファイル群を示します。

Growi アップデートのエラーに対応。(node_module再インストール)

概要

Growiをアップデートをする中でエラーが発生したので対処した時のメモです。

環境

  • Growi v7.3.2 → v7.3.3にアップデートする際の出来事
    • こちらの手順でv7.3.xにアップデート済み
    • Growiの実行ユーザはroot
  • node v20.19.2
  • npm 11.4.0
  • Apacheによるリバースプロキシ

どの段階でエラーが発生したか

sudo git checkoutsudo pnpm isudo npm run app:buildを実行時に

Tasks:    0 successful, 7 total
Cached:    0 cached, 7 tota
  Time:    25.08s 
Failed:    @growi/pdf-converter#gen:swagger-spec
 ERROR  run failed: command  exited (1) 

が出たのでappのビルドが通りませんでした。

エラーの原因

@growi/pdf-converterが利用する@tsed/openapi-utilsというパッケージが、@tsed/diという別のパッケージからcontextという機能をインポートしようとしていますが、インストールされている @tsed/di のバージョンにその機能が存在しないため、SyntaxError となっています。

これは、pnpm のキャッシュや node_modules ディレクトリの状態が不整合になっている場合に発生するということを突き止めました。

もっと有り体に言うと、筆者環境はGrowiはv7.2.x→v7.3.xと順調にアップデートを重ねていったので、パッケージの混在が発生。言うなれば、複数の設計図が混じっていたので(依存関係の不適合)、建設を担当するnpmが「設計図と実装が矛盾している」としてエラーを吐いた次第です。

大前提

Growiプロセス停止確認(systemdに登録している場合)

systemctl status growi.service

で、growiが完全に停止していることを確認してください。

さっくりとした対処

  1. 依存関係をクリーンにします。
  2. 混在しているパッケージを退避します。
  3. パッケージを再インストールします。
  4. Growiのビルドを改めて実行します。

依存関係をクリアする

  • Growiルートディレクトリに移動&確認 (特に重要な作業)

※調査中に別のディレクトリに遷移しているということは極めて多く発生します。特にエラーの対処となればなおさらです。改めて、作業の現在地を確認します。

cd /growi/root/directroy && pwd

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

  • キャッシュクリア
sudo pnpm store prune

node_modulesディレクトリの退避

  • ディレクトリ退避前確認
ls -ld node_modules

ディレクトリがあることを確認します。

sudo mv node_modules /path/to/backup/directory/node_modules.$(date +%Y%m%d)

任意のバックアップディレクトリを退避。$(date +%Y%m%d)変数をつけることで現在の日付を付与します。

  • ディレクトリ退避確認
ls -ld node_modules

ディレクトリがないことを確認します。

  • 退避ディレクトリ確認
ls -ld /path/to/backup/directory/node_modules.$(date +%Y%m%d)

退避ディレクトリがあることを確認します。

node_modules再配置

  • 再配置
sudo pnpm install

再びnode_modulesが配置されます。

  • 再配置確認
ls -ld node_modules

ディレクトリがあることを確認します。

  • ビルド
sudo npm run app:build

Growiの再開

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

active(running)を確認します。サービスが完全に上がっていないとブラウザでGrowiにアクセスしても503エラーが出ます。しばらく待ちましょう。

アップデート確認

Growiが最新バージョンにアップデートされていれば対処完了です。

【改訂・再編集】ApacheにWAF・Mod_Security導入。

こちらの記事の改訂・再編集版です。

そもそもWAFとは?

WAFとはWeb Application Firewallの略で、Webアプリケーション層の脆弱性を狙った攻撃を防ぐためのセキュリティシステムです。

  • UFWやFail2banがIPアドレスやポート番号といった家の玄関を監視するのに対し、WAFは、Webサーバーへ届く手紙(HTTPリクエスト)の中身を解析し、悪意あるスクリプトやコマンドの有無をチェックします。
  • UFWでは、通常のポート(80番や443番)を通る攻撃は防げませんが、WAFは攻撃の内容を解析し、独自のルールセットに基づき「このアクセスは許可するが、このコードがアクセスすることは許可しない」という、より柔軟で厳しいセキュリティチェックを施します。

この機能により、Webサーバーやアプリケーション本体に脆弱性が見つかったとしても、WAFが前段の盾としてこれをカバーできます。

ModSecurityとは?

ModSecurityは、IIS/Apache/Nginxといった主要なWebサーバープログラムにモジュールとして組み込みが可能なオープンソースのWAFです。

  • 導入コスト: ライセンス費用が不要であり、既存のWebサーバーと連携する形で容易に組み込めます。
  • 柔軟性: OSSであるため、高い柔軟性を持ち、設定(チューニング)次第でピンポイントの防御や包括的な防御を併せ持つことができます。

備考(バージョンの選択):

本稿で導入するModSecurityは、Ubuntu 24.04系のパッケージ管理で提供されるEOL (End-of-Life) となっているv2ですが、機能性は単一VPSの防御としては十分です。

v3への移行は、セキュリティ強度とメンテナンス性を考慮し、パッケージ化ないしはOSアップデートなどのタイミングでまた後日検討していきます。

環境

  • Ubuntu 24.04 (22.04でも動作確認)
  • Apache 2.4

※ パッケージ管理にaptitudeを用いています。必要に応じてaptに読み替えてください。

さっくりとした手順

  1. mod_securityのインストールを行います。
  2. mod_securityの設定を行います。
  3. Apacheのバーチャルサイトにmod_securityを組み込みます。
  4. 設定を反映して動作を確認します。

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

  • パッケージ全体のアップデート
sudo aptitude update
  • mod_securityインストール
sudo aptitude install libapache2-mod-security2
  • インストール確認
sudo apache2ctl -M |grep security
security2_module (shared)

と表示されていることを確認します。

ModSecurityの設定

  • 設定ファイル書き換え
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

推奨ファイルをそのまま設定ファイルとして書き換えます。

OWASP Core Rule Set (CRS)のインストールと設定

  • ディレクトリ移動
cd /usr/share/modsecurity-crs && pwd
  • ルールセットのダウンロード
sudo git clone https://github.com/coreruleset/coreruleset.git
  • ルールセットの設定書き換え
sudo mv /usr/share/modsecurity-crs/coreruleset/crs-setup.conf.example /usr/share/modsecurity-crs/coreruleset/crs-setup.conf

mod_securityモジュールにCRSを読み込む設定を追記

  • ディレクトリ移動
cd /etc/apache2/mods-available/ && pwd
  • ファイルのバックアップ
sudo cp -pi security2.conf /path/to/backup/directory/security2.conf.$(date +%Y%m%d)

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

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

エラーがなければバックアップは成功です。

  • ファイル追記

/etc/apache2/mods-available/security2.confを、以下の差分になるように教義・信仰に沿ったエディタで編集します。(要root権限)

 <IfModule security2_module>
-       # Default Debian dir for modsecurity's persistent data
-       SecDataDir /var/cache/modsecurity
+    # Default Debian dir for modsecurity's persistent data
+    SecDataDir /var/cache/modsecurity

-       # Include all the *.conf files in /etc/modsecurity.
-       # Keeping your local configuration in that directory
-       # will allow for an easy upgrade of THIS file and
-       # make your life easier
-        IncludeOptional /etc/modsecurity/*.conf
+    # Include all the *.conf files in /etc/modsecurity.
+    # Keeping your local configuration in that directory
+    # will allow for an easy upgrade of THIS file and
+    # make your life easier
+    IncludeOptional /etc/modsecurity/*.conf

-       # Include OWASP ModSecurity CRS rules if installed
-       IncludeOptional /usr/share/modsecurity-crs/*.load
+    # --- OWASP Core Rule Set (CRS) の読み込み ---
+
+    # 1. CRSのセットアップファイルを読み込む(必須)
+    IncludeOptional /usr/share/modsecurity-crs/coreruleset/crs-setup.conf
+    
+    # 2. CRSのルールファイルを読み込む
+    #    パフォーマンス問題を起こすSQLデータ漏洩検知ルールを除外
+    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/REQUEST-*.conf
+    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-950-DATA-LEAKAGES.conf
+    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
+    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
+    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
+    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
+    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-980-CORRELATION.conf
+    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

→ 修正後のsecurity2.conf全文

<IfModule security2_module>
    # Default Debian dir for modsecurity's persistent data
    SecDataDir /var/cache/modsecurity

    # Include all the *.conf files in /etc/modsecurity.
    # Keeping your local configuration in that directory
    # will allow for an easy upgrade of THIS file and
    # make your life easier
    IncludeOptional /etc/modsecurity/*.conf

    # --- OWASP Core Rule Set (CRS) の読み込み ---

    # 1. CRSのセットアップファイルを読み込む(必須)
    IncludeOptional /usr/share/modsecurity-crs/coreruleset/crs-setup.conf

    # 2. CRSのルールファイルを読み込む
    #    パフォーマンス問題を起こすSQLデータ漏洩検知ルールを除外
    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/REQUEST-*.conf
    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-950-DATA-LEAKAGES.conf
    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-980-CORRELATION.conf
    IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
</IfModule>

※ なぜここまで除外するか?

この、RESPONSE-9x系のルールは、ページの内容に機密情報(クレジットカードのデータなど)が入っていないかを精査します。

これは重要なものですが、昨今のAIボットによる過剰なクロールが挟むと、サーバそのものへの負荷を強め、更にログの圧迫(実際にサーバ容量120GB全てを食い尽くしました)とサーバダウンにつながります。

こちらは個人サイト、単一VPSの運用を旨としているため、ここに関するデータはオミットです。 その分、他の設定の補強でセキュリティ強度を担保します。

  • 設定追記の整合性を確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動確認
systemctl status apache2.service

active (running) を確認します。

Apacheのバーチャルサイト編集

稼働済みのApacheバーチャルサイトの設定ファイルをいじります。バックアップ確認は入念に行ってください。

  • ディレクトリ移動
cd /etc/apache2/sites-available && pwd
  • バーチャルサイトの設定ファイルバックアップ
sudo cp -pi your_site.conf /path/to/backup/directory/your_site.conf.$(date +%Y%m%d)

.confファイルやバックアップディレクトリは自分の環境を指定します。

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

エラーがなければバックアップは成功です。

  • ファイル追記

/etc/apache2/sites-available/your_site.confを、以下の差分になるように教義・信仰に沿ったエディタで編集します。(要root権限)

# Mod Security

## ModSecurity有効化
SecRuleEngine On
## ModSecurity検知モード
### 検知モードで動かす場合はSecRuleEngine Onをコメントアウトしてこちらを有効化します
#SecRuleEngine DetectionOnly

## ファイルのアップロードをできるようにします。
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000

## テスト用の検知パラメータを付け加えます。
    SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"
  • ファイル差分
diff -u /path/to/backup/directory/your_site.conf.$(date +%Y%m%d) your_site.conf
+# Mod Security
+
+## ModSecurity有効化
+SecRuleEngine On
+## ModSecurity検知モード
+### 検知モードで動かす場合はSecRuleEngine Onをコメントアウトしてこちらを有効化します
+#SecRuleEngine DetectionOnly
+ 
+## ファイルのアップロードをできるようにします。
+SecRequestBodyInMemoryLimit 524288000
+SecRequestBodyLimit 524288000
+
+## テスト用の検知パラメータを付け加えます。
+    SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"
+
  • 設定追記の整合性を確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動確認
systemctl status apache2.service

active (running) を確認します。

mod_security動作確認

  1. ブラウザで、上記の設定を行ったWebサイトにアクセスし、閲覧できることを確認します。
  2. アドレスバーの末尾に?modsecparam=testを追加してアクセスします。

のように、アクセスできないことを確認します。

また、サーバでも

sudo cat /path/to/sites_log/directory/sites_error.log

※ログの格納場所やログの名前は自分の環境に合わせます。

を開き、

ModSecurity: Access denied with code 403 (phase 2). String match "test" at ARGS:modsecparam. [file "/etc/apache2/sites-enabled/your_site.conf"] [line "53"] [id "4321"] [msg "ModSecurity test rule has triggered"] [hostname "host_address"] [uri "/"] [unique_id "xxxxxxx"]

のように、エラーが発生していることを確認します。

備考

WordPress、Redmine等のWebアプリは自身の操作によって「不審なアクセス」として遮断することが極めてよくあります。(偽陽性)

そのため、テストを行った後は

## ModSecurity有効化
#SecRuleEngine On
## ModSecurity検知モード
### 検知モードで動かす場合はSecRuleEngine Onをコメントアウトしてこちらを有効化します
SecRuleEngine DetectionOnly

として検知モードとして動かした方が良いでしょう。

「インターネット接続をする際のApache設定」の常時SSL化とログ設定の手順(長文)

なぜ2020年代から(或いはその5年前から)常時SSL化が必須と言えるのか?

セキュリティの確保

  • 通信の暗号化
    • SSL/TLSの技術により、Webブラウザ~サーバ間の通信が暗号化。第三者による盗聴や改ざんを防ぎます。
  • 入力情報の保護
    • ログイン情報、個人情報、問い合わせフォームの内容など、機密性の高い情報のやりとりが安全になります。

ユーザーの信頼性向上

  • ブラウザの警告表示への対処
    • 2020年代より、Chrome/Safari/Edgeと言った主要なブラウザは従来のhttp通信を「保護されていない通信」としてブラウザに表示するようにしました。これは読者、アクセス者に対してユーザの不安を招きます。
  • 攻撃者にとっての絶好の餌を与えない
    • HTTP通信の状態であるというのは、攻撃者にとっての「オイシい」獲物です。ログイン情報やセキュリティの脆弱性などをより好んで狙うという状況を防ぎます。

(筆者には余り関係ないが) SEOへの影響

  • Googleを筆頭とする各種検索エンジンは、2014年以降、SSL対応を検索上位の評価要因に含めています。
  • HTTPS化されたサイトはSEOで有利になります。

Web標準としての定着

  • HTTPS by default機能
    • Chrome/Edge/ChromiumなどはHTTPSを標準接続とする仕様を導入。これにより、HTTPサイトはますます排除される傾向になります。

企業・サービスの信頼性維持

  • SSL化はもはや企業サイトの基本マナーとされています。
    • 未対応のままでは信頼性を損なう可能性があります。

余談 (私怨かつ直接的な動機)未対応企業への溜飲

  • 強烈なパワハラを喰らい去ることになった会社が「辞めてから10年経ってもHTTP通信のまま」というIT企業の存在は、「あんたは未だにHTTPS化をしていないわけ?」という精神的な勝利に繋がっています。
    • 器が小さいとかみみっちいと言われていても、かなり重要な動機です。

ログが重要な理由

トラブルシューティングが容易になる

  • 最も重視する項目です。先般の「記憶に頼るな。ログを信じろ」の全ての根拠です。
    • 特定のサイトでエラーが発生した場合、該当サイトのエラーログだけを確認できるため、原因特定が迅速になります。
  • バーチャルサイトごとにログがないと以下を招きます。
    • ノイズが多いことによる調査効率の低下。
    • 不審なアクセスの迅速な検知の非効率化。

セキュリティサービスとの連携

  • WAF連携
    • 筆者が用いているModSecurityの連携は、ひとえに「この、エラーログ・アクセスログ」を根拠にセキュリティの強化や利便性強化を図っています。
  • 攻撃のトレンドを知る
    • どのような攻撃があるからサーバはパフォーマンスが落ちているのか? を知る上でもこれは重要です。

サイトごとのアクセス解析が可能/容易になる

  • 複数のドメインやサービスを1台のサーバで運用している場合、ログを分けることで書くサイトのアクセス状況を個別に把握できます。
    • 例えば「example.com」と「sample.jp」のPV数や人気ページを比較したいとき、ログが分かれていないというのは分析が困難になります。

セキュリティ監査に対応しやすい

  • サイトごとにログを分けることで、不正アクセスや改竄の痕跡を個別に追跡可能です。
    • 仮に、何らかの法的なインシデントに巻き込まれたとしても、そのログを元に、迅速な対応が可能になります。

読者への回答

「これだけ長いのに何故2つに分けないのか?」は

  • SSL化
  • ログの設定

は、先に示した「加害者にならないための具体的手順」の1つ。「この両者は不可分であり、インターネットで公開する上では必須」だからです。

  • SSL化という2020年代セキュリティの標準
  • ログの可視化というインターネット黎明期から続くトラブルシューティングと解析

は絶対に必要な項目です。次ページから具体的な手順です。

Page 1 of 22

Powered by WordPress & Theme by Anders Norén