Scribble at 2024-08-08 13:12:27 Last modified: 2024-08-08 15:54:05

さきに構築したサーバは、某団体が運営するものであるため、KUSANAGI に WAF を追加するにあたっては、まずウェブ・サーバを Apache として、WAF は ModSecurity を選択した。そもそも、ロシア人が書いたウェブ・サーバ（Nginx）なんて日本の法人が運営するサイトに選べるわけがないので、httpd は必須であろう。すると、KUSANAGI では WAF として KUSANAGI がディフォールトでサポートしている ModSecurity か、もしくは後から手動でインストールする SiteGuard Server Edition という二択が多いのだけれど（もちろん自力で他の WAF を導入してもいいが、僕のそういう技術費用が予算から出るわけがないから、無償で使えるものを選ぶのが限度だ）、やはり導入のしやすさと実績から言っても ModSecurity がいいだろうと判断した。実際、SiteGuard Server Edition もインストールはしたのだが、初期設定だけでも工数オーバーになってしまうし、iPad でマニュアルを読む際に PDF にすらいちいちパスワードが掛かっているのが、情報セキュリティの実務家としてすら耐えられないほど面倒臭い。マニュアルすら公のウェブ・ページにできず秘匿しないといけない方針なんて、時代錯誤も甚だしい。よって、技術的にも信用に値するかどうか不安がある。

ということで、ModSecurity に手をつける。まず、導入そのものは非常に簡単だ。最初にやることとして、KUSANAGI はディフォールトのウェブ・サーバが Nginx であるため、これを Apache に変更する必要がある。これは # kusanagi httpd --use httpd24 で Apache 2.4.x に入れ替わり、念の為 # systemctl enable httpd でスタート・アップのサービスとして登録する。これは、ModSecurity が Nginx ではなく Apache だけの WAF だからだ。こうして httpd に切り替えておくと、# kusanagi waf on というコマンドで、ModSecurity が有効になる。確認として # httpd -M を叩くと、ロードされるモジュールの一覧に "security2_module" が追加されていることが分かるだろう。そして、この表示によって KUSANAGI では現在も ModSecurity の 2.x 系列を使っていることがわかる。正確には、httpd のエラー・ログを見ると、"Producer: ModSecurity for Apache/2.9.7 (http://www.modsecurity.org/); OWASP_CRS/4.5.0." のように出ているので、ヴァージョンが "2.9.7" になっている。

で、実は標準的な設定は最初から有効になっているため、詳しく具体的なルールを必要としないのであれば、特に何もしなくてよいのである。標準的なルールは、KUSANAGI を運用しているインスタンスであれば何であれ、

/etc/opt/kusanagi/httpd/modsecurity.d/kusanagi_activated_rules/wordpress

にある。KUSANAGI は WordPress のサイトを構築・運用するための専用 OS であるため、特に WordPress で使う PHP ファイルごとにルールが指定してあるから、一般的な防御としてはこれだけでも役に立つ。あとは、管理画面についてはベーシック認証、IP アドレス制限、そして管理画面のログイン用スクリプトを（mod_rewrite で）別の URI とするプラグインなどを使えばいいだろう。

その他の細かい設定は、上のリンク先でマニュアルを一読するのがよい。開発・メンテナンスのプロジェクトが OWASP に譲渡されてから、マニュアルの所在がわかりにくくなっているため、敢えて自分自身の忘備録としても上のリンクを残しておく。

なお、勉強用に自宅の Raspberry Pi Zero W にも導入しておいた。もともと Apache を入れていなかったので、# apt install apache2 から始めたのだが、これもきちんと ModSecurity の 2.x 系列を入れて使えるようになった（Debian 系統の Linux では、"httpd" ではなく "apache2" がサービスやディレクトリや実行可能ファイルの名前になっている）。ModSecurity は Apache の後から # apt install libapache2-mod-security2 で追加して、"/usr/sbin/a2enmod" という管理コマンドを使ってモジュールとして追加する。こういうのも、同じ Linux であってもディストリビューションごとの手順を知らないと、余計な調べ物に時間がかかる。LIPC-1 とかを持ってるていどでは、現実のエンジニアとして使い物にならないのは、そういうことも理由になっている。（ていうか、そもそもこれは、インストール時にターミナル画面で表示される英語のメッセージが読めるなら問題ないことなのだが。）

それから、たまに見かけるのだが、ModSecurity のルール・セットをメール・アドレスなどとのバーター取り引きで見せるなどというインチキな無料サービスは、ありていに言って無視して良い。上に述べたのと同じ理由だが、ModSecurity のルールていどを個人情報と引き換えにしかリリースできない企業に、情報セキュリティのプロとして信用するだけの値打ちはないと思う。その企業が ModSecurity の開発にスポンサーとして寄与しているとか、社内のスタッフがメンテナーだとか、そういう事情でも無い限り、彼らにしても「ただのユーザの一人」にすぎないからだ。ということは、僕のような情報セキュリティの実務家が当サイトで論説を（もちろん無償で）公開しているのと立場は同じなのである。

なお、この文章で "#" から始まっているフレーズは、実際に入力したコマンドの実例である。"#" は、プロンプトで root 権限のユーザであることを示す記号であることが多い（もちろん設定で幾らでも変更できるが）。root 権限をもたないユーザのプロンプトは "%" と表されることが多いため、そういうユーザが root 権限を必要とする apt や systemctl のようなコマンドを使う場合は、"% sudo apt install apache2" のように、sudo を最初に使う（もちろん、サーバの管理者から sudo できる権限を付与されていなくてはならない）。