これは、筆者が自分のサーバに組み込んでいるWebセキュリティシステム(と言ってもスクリプトと設定の組み合わせ) 『ONE OUTS』について述べたものです。
を目標に構築しました。
メンテナンスが高いとは言え、少々複雑な流れを含むため、いくつかに分けて解説します。
甲斐谷忍先生による同名の野球漫画『ONE OUTS』から来ています。
などをイメージしながら構築しました。
以下の環境で動いています。
次のページから、実際のファイル群を示します。
Growiをアップデートをする中でエラーが発生したので対処した時のメモです。
rootsudo git checkout→sudo pnpm i→sudo 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が完全に停止していることを確認してください。
※調査中に別のディレクトリに遷移しているということは極めて多く発生します。特にエラーの対処となればなおさらです。改めて、作業の現在地を確認します。
cd /growi/root/directroy && pwd自分の環境に合わせます。(筆者環境/home/www-data/growi)
sudo pnpm store prunenode_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:buildsudo systemctl restart growi.servicesystemctl status growi.serviceactive(running)を確認します。サービスが完全に上がっていないとブラウザでGrowiにアクセスしても503エラーが出ます。しばらく待ちましょう。
Growiが最新バージョンにアップデートされていれば対処完了です。
こちらの記事の改訂・再編集版です。
WAFとはWeb Application Firewallの略で、Webアプリケーション層の脆弱性を狙った攻撃を防ぐためのセキュリティシステムです。
この機能により、Webサーバーやアプリケーション本体に脆弱性が見つかったとしても、WAFが前段の盾としてこれをカバーできます。
ModSecurityは、IIS/Apache/Nginxといった主要なWebサーバープログラムにモジュールとして組み込みが可能なオープンソースのWAFです。
本稿で導入するModSecurityは、Ubuntu 24.04系のパッケージ管理で提供されるEOL (End-of-Life) となっているv2ですが、機能性は単一VPSの防御としては十分です。
v3への移行は、セキュリティ強度とメンテナンス性を考慮し、パッケージ化ないしはOSアップデートなどのタイミングでまた後日検討していきます。
※ パッケージ管理にaptitudeを用いています。必要に応じてaptに読み替えてください。
sudo aptitude updatesudo aptitude install libapache2-mod-security2sudo apache2ctl -M |grep securitysecurity2_module (shared)と表示されていることを確認します。
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf推奨ファイルをそのまま設定ファイルとして書き換えます。
cd /usr/share/modsecurity-crs && pwdsudo git clone https://github.com/coreruleset/coreruleset.gitsudo mv /usr/share/modsecurity-crs/coreruleset/crs-setup.conf.example /usr/share/modsecurity-crs/coreruleset/crs-setup.confcd /etc/apache2/mods-available/ && pwdsudo 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 configtestSyntax OKを確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive (running) を確認します。
稼働済みのApacheバーチャルサイトの設定ファイルをいじります。バックアップ確認は入念に行ってください。
cd /etc/apache2/sites-available && pwdsudo 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 configtestSyntax OKを確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive (running) を確認します。
?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として検知モードとして動かした方が良いでしょう。
「これだけ長いのに何故2つに分けないのか？」は
は、先に示した「加害者にならないための具体的手順」の1つ。「この両者は不可分であり、インターネットで公開する上では必須」だからです。
は絶対に必要な項目です。次ページから具体的な手順です。
Apacheの初期設定とWebコンテンツのルートディレクトリを変更する理由と、たとえサイトが一つでもVirtualHostを設定する必要性についてのメモです。
なぜなら、これはインターネット上サーバでの絶対的なルールが抜けています。
この2つは別の項でも解説しますが、これらを考慮しないと
の2点が重くのしかかります。
標準でapacheを入れると、Webサーバーのコンテンツディレクトリとして使われるのは /var/www です。
しかし、本稿では/home/www-data へとホームディレクトリを変更します。これには、以下の明白な理由があります。
| 理由 | 詳細 |
|---|---|
| セキュリティ上の分離 (Preference) | /var ディレクトリは、ログ（/var/log）や一時ファイル（/var/tmp）など、システムが頻繁に書き換える揮発性のデータを格納するために設計されています。Webコンテンツを /home に置くことで、システムデータとユーザーデータ（コンテンツ）を明確に分離し、万が一のシステム障害や冗長化の際に管理が容易になります。 |
| ユーザープロファイルの整合性 (Practicality) | www-data ユーザーは通常シェルログインできませんが、Ruby on RailsやNode.jsなどのモダンなアプリケーションが bundle install やパッケージのインストールを行う際や、gitを利用する際に環境変数として自身のホームディレクトリを参照することがあります。これを /home/www-data に設定することで、アプリケーションがスムーズに動作し、予期せぬエラーを防ぐことができます。 |
VPS/ローカルサーバでで公開するサイトが一つだけであっても、デフォルトの設定ファイル (000-default.conf など) ではなく、個別のVirtualHost設定ファイルを作成して運用すべきです。
| 理由 | 詳細 |
|---|---|
| セキュリティ（デフォルト設定の無効化） | デフォルト設定 (000-default.conf) は通常、/var/www/html を DocumentRoot としています。これを無効化し、カスタムVirtualHostのみを有効にすることで、意図しないディレクトリが公開されるリスクや、デフォルト設定のバージョン情報などが露出するリスクを防ぎます。 |
| スケーラビリティと将来性 | 将来、サブドメイン（例: blog.example.com）や別のドメインを追加する際に、既存の設定をコピーして修正するだけで済みます。最初からVirtualHostの構造を採用することで、設定の拡張が容易になり、メンテナンス性が向上します。 |
| HTTPS（SSL）対応の必須要件 | HTTP（ポート80）からHTTPS（ポート443）への強制リダイレクトや、独自のSSL証明書の設定は、VirtualHostブロック (<VirtualHost *:443>) ごとに行うのが一般的です。VirtualHostが基本となることで、この必須のセキュリティ対策をスムーズに組み込めます。 |
VPSのコンテンツ保存場所を /home/www-data に統一します。
sudo mkdir -p /home/www-datasudo chown -R www-data:www-data /home/www-datals -ld /home/www-data→ 所有者がwww-dataになっていることを確認
/etc/passwd ファイルの書き換えwww-data ユーザーのホームディレクトリの定義を /var/www から変更します。
** 注意:**
/etc/passwdはシステムアカウントを制御する重要ファイルです。必ずバックアップを取り、変更は一行のみであることを確認してください。
sudo cp -pi /etc/passwd /path/to/backup/directory/passwd.$(date +%Y%m%d)→ 任意のバックアップディレクトリを指定します。また、$(date +%Y%m%d)を仕込むことで、「いつ」このバックアップを取ったかが明白になります。
sudo diff -u /path/to/backup/directory/passwd.$(date +%Y%m%d) /etc/passwd→ 面倒でもこの作業は必須です。というのも、差分を取ることで「オリジナルとバックアップの両方が作成されている」というのを、コマンドという第三者の絶対的な目で見ることができるからです。
→ また、先ほどのcpと逆になっていることにも注意してください。これは、変更後に「どの行が惹かれ、どの行が足されたか」を明確化するためです。
sudo sed -i 's|/var/www|/home/www-data|' /etc/passwd→ 特に注意が必要です。これをミスるとサーバ全体のロックアウトなども容易に発生します。
diff -u /path/to/backup/directory/passwd.$(date +%Y%m%d) /etc/passwd差分が以下のみであることを確認します。
-www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
+www-data:x:33:33:www-data:/home/www-data:/usr/sbin/nologin→ ここで、「なぜ、逆にして差分を取るのか」を明確化。
diff -u /etc/passwd /path/to/backup/directory/passwd.$(date +%Y%m%d)とした場合、得られる情報は「まるで逆」になります。
+www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
-www-data:x:33:33:www-data:/home/www-data:/usr/sbin/nologinとなり、「バックアップの方が正しい修正」となってしまうからです。
Redmine（動的アプリケーションの例）を /home/www-data 内のディレクトリで公開するためのベース設定を作成します。
cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/redmine.conf
<VirtualHost *:80>
ServerName 【hoge.example.com】
# ServerNameは自身が設定したドメイン名に置き換えてください。
DocumentRoot /home/www-data/redmine/public
<Directory /home/www-data/redmine/public>
# .htaccessによる設定変更を許可
AllowOverride All
# 複数Viewを無効化（アプリケーションのルーティングを優先させるため）
Options -MultiViews
# 全てのアクセスを許可
Require all granted
</Directory>
</VirtualHost>
__EOF__作成したVirtualHostを有効化し、デフォルトサイトを無効化します。
sudo a2dissite 000-default.confsudo a2ensite redmine.confsudo apache2ctl configtest→ Syntax OKとなることを必ず確認してください。でないと、apacheサービスが停止したままとなってしまい、サービス断が発生します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
これで、Apacheの基盤がセキュリティと運用効率を考慮したカスタム設定で動作するようになりました。
この記事を今のトレンドに合わせた上でのステップバイステップとした記事です。
Ubuntu24.04にWebサーバーApacheをインストールします。最近のトレンドではNginxではあるものの、
を考慮してのApache設定です。
この作業、サーバ移設などになれている人ほど陥る罠です。「設定はしっかりしている。なのにサンプルページすら引っかからない！」という場合、大概が「UFWでポート80/443を空けていない」パターンが大半を占めます。
SSH接続を許可（ポート22はSSH記事で許可済みを前提とする）。
設定の前の心構え：
UFWは堅牢であると同時に融通の利かない門番です。設定を間違えると「自分のサーバにログインできない」事態が易々と発生します。
そのため、この作業に臨む際は落ち着いて臨みましょう。コマンドを打つ際に3回ぐらい深呼吸してもいいぐらいの心構えです。
sudo ufw allow http comment 'Allow HTTP traffic for Apache'sudo ufw allow https comment 'Allow HTTPS traffic for Apache' sudo ufw status verbose上記、http/httpsが有効になっていることを確認します。
sudo ufw enable sudo aptitude update sudo aptitude install apache2apache2ctl -vServer version: Apache/2.4.62 (Ubuntu)
Server built: 2024-07-22T12:37:10systemctl status apache2.serviceenabledとactive (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 /etc/apache2/apache2.conf > /dev/null << 'EOF'
ServerSignature Off
ServerTokens Prod
ServerName example.com # <-- ここに実際のドメイン名またはホスト名を指定
EOF自分のサーバー名を英数字で置き換えてください。
内容です。
diff -u /path/to/backup/directory/apache2.conf.$(date +%Y%m%d) /etc/apache2/apache2.conf+ ServerSignature Off
+ ServerTokens Prod
+ ServerName 自分のサーバー名sudo apache2ctl configtestSyntax OKを確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive (running)を確認します。
curl -I http://localhost以下のように、ServerヘッダーにApacheのみが表示されていることを確認します。
Server: Apache
出先、ノートPCのバッテリーが心許なくなり、ノートPC充電可能なバッテリーにつないだのですがなぜか充電できず。
もう一本のケーブルはPDに対応していないためそもそも電流が流れず。
そして、こちらの（PD非対応の）ケーブルはiPhoneを充電できたので「ケーブルの故障」と判断。安価でPD充電に対応したUSB-Cケーブルはないかと探していたら
ダイソーで売られていたType-Cのケーブル。流行のマグネットでまとめるタイプです。
と、ケーブルはしっかりした作り。マグネットの固定もいい感じです。
接続した結果、きちんと認識。
この、100均のこの手の充実は、出先でも重宝です。
前回の続き。Linuxサーバ運用上の注意を述べましたが、更に難易度が上がり
「このLinuxサーバをインターネットで公開するとき」
の心構えについて述べます。
そもそも、ローカル環境とインターネットにこれを公開するというのは
が何もかも違います。その中で一番気をつけなければならないのは
「自分自身が加害者になってしまうこと」
です。これはもっと具体的に言うと
「管理者権限を乗っ取られ、自分のサーバが攻撃ツールのフロントエンド/バックエンドとして機能すること」
を意味します。攻撃者は自分自身が表立って行動することを嫌います。そのため、
などにつけ込み侵入を試み、それを自らの配下として利用します。これは、先に述べた
とは何もかもレベルが違うリスクです。
ぶっちゃけ、自分自身が運営しているサーバの瓦解は自分が泣けばそれで済む話ではありますが、自分が管理しているサーバが攻撃に関与したというのは、法的/金銭的/社会的な失墜が絡む大問題。
この、理不尽なまでの非対称性が絡むということを最初に意識してインターネット上サーバでの運営を意識しましょう。
とはいえ、趣味や勉強の範囲でインターネット接続環境でもLinuxサーバを立ち上げたいという方はいるかと思います。
ここからは、メソロドジーから一歩踏み込み、「より具体的な手段」について述べます。
ちょっとした茨の道を進みたい方向けです。
※ ここからは筆者の過去記事から「特に必要な設定」を抜き出し、加筆編集を加えた記事です。※
を用います。つまり、makeやリビルドなどは発生しない、再現性の高い環境でのステップバイステップです。
この作業は極めて重要です。というのも、先に示したとおり、攻撃者が真っ先に/そして最終的に狙うのは管理者権限。つまり、(root)です。
rootへのネットワークを介したログインを禁止すると同時に、メンテナンス用のユーザを作成し、NW上からは、ここから接続することを厳命します。
adduser [メンテナンス用ユーザ]※[メンテナンス用ユーザ]は英数字です。その後、パスワード設定などを対話式で求められるので、指示に従って入力します。
exit物理コンソール/VPSのWebシリアルコンソールから抜けます。
Webコンソールで、作成したユーザ名とパスワードでログインできることを確認。
whoamiで、設定したアカウントであることを確認します。
sudo su -としても、rootに昇格することはできません。なので、一度
exitでコンソールを抜け、rootでログインし直します。
rootでログイン後、
usermod -aG sudo [メンテナンス用ユーザ]で、sudoグループにこのユーザを加えます。
id -a [メンテナンス用ユーザ]で、以下のように表示されることを確認します。
uid=1000(hoge) gid=1000(hoge) groups=1000(hoge),27(sudo),100(users)修正したユーザのグループに、27(sudo)と表示されることがポイントです。
確認後、
exitで更にrootを抜け、今度はメンテナンス用のユーザでログインします。
メンテナンス用のユーザでログイン後、
sudo su -で、rootに昇格できることを確認します。
whoamiでroot表示されることも確認します。
passwd -l rootとして、rootそのものをロックします。
exitを2回行い、Webコンソールから抜けます。
これ以降はメンテナンス用のユーザで作業を行います。
Ubuntu Desktop系と違い、Ubuntu Serverではsshdがデフォルトでインストールされていない場合があります。
sudo apt install sshで、sshdをインストールします。
インストール後、
ssh -Vでバージョンが表示されることを確認し、
systemctl status ssh.serviceで、runningとenabledを確認します。
このSSHは鍵認証でログインできるようにします。この鍵認証のセキュリティ強度はパスワードと段違い。
ssh-keygen -t ed25519cd .sshls -l以下のファイルを確認します。
公開鍵をauthorized_keysに変更し、パーミッションを厳密にします。
cat id_ed25519.pub >> authorized_keyschmod 600 authorized_keysこの秘密鍵（id_ed25519）は、サーバー全体のアクセス権を持つ、言葉通りの意味でのマスターキーです。
この秘密鍵を奪われることは、サーバーの全権限を奪われることと同義です。 そのため、管理は厳密に、そして自分だけがアクセスできる安全な手段（パスワードマネージャーや暗号化されたストレージなど）で、必ずバックアップをこの段階で行ってください。
その後、適切なターミナルクライアントでこの秘密鍵を登録。接続を確認できたという確証が取れて、初めて実機の前から解放されます。
fail2banは、サーバーのログファイルを監視し、設定されたパターンに一致する不審なアクセス（パスワード総当たり攻撃など）を検知すると、そのアクセス元のIPアドレスを自動的にファイアウォールの拒否リストに追加する、侵入防止ソフトウェアです。
一度設定すれば、アンインストールしない限りは有効化し続けます。
まず、サーバーの玄関となるファイアウォールufwを設定します。
UFWとfail2banは基本的である分、設定に極めて忠実です。そのため、設定をミスして自分自身のアクセスを禁止した場合、そこに入るための手段はなくなります。
そのため、vps/仮想サーバと言った物理的なログイン手段を持たない場合は、スナップショットやディスクイメージ全体のバックアップを行い、「失敗したときのリカバリー」を行えるようにします。
現に、筆者は、これを怠ったばかりにサーバを作り直したことが3回ほどあります。
物理サーバで、サーバ室やデータセンターなどの場合は、この設定が終わるまでは実機の前にいるべきです。
最初に「入ってくる通信は原則すべて拒否、出ていく通信はすべて許可」という基本方針を設定します。これが最も安全な基本設定です。
sudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw logging onこれを行わないと、後述するfail2banのアクセスがうまくいきません。
次に、必要なサービスへの通信を個別に許可します。SSHの接続を許可する前にufwを有効化すると、サーバーから締め出されてしまうので、必ず先に設定してください。
sudo ufw allow ssh comment 'Allow SSH connections'sudo ufw allow http comment 'Allow HTTP traffic'sudo ufw allow https comment 'Allow HTTPS traffic'commentオプションで、後からルールを見返したときに分かりやすいようにコメントを付与できます。
これはもちろん基本的な構成です。他のポートを開放・閉じる場合は必要に応じて行います。
ルールを設定したら、ufwを有効化します。
sudo ufw enable実行すると、「この操作は既存のSSH接続を切断する可能性があります」という警告が出ますが、ステップ1.2でSSHを許可していれば問題ありません。yを入力して実行します。
最後に、設定が正しく反映されているか確認します。
sudo ufw status verboseStatus: activeと表示され、許可したルールが一覧に出ていれば成功です。
SSHターミナルで
telnet localhost 22と行ってみます。
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.と通信が可能です。逆に、通信を許可されていないポートでは
telnet localhost 23Trying 127.0.0.1...
telnet: Unable to connect to remote host: 接続を拒否されましたとして、接続することはできません。
次に、fail2banをインストールし、ufwと連携させる設定を行います。
sudo aptitude updatesudo aptitude install fail2ban筆者の好みでaptitudeを用いていますが、aptでも同様です。
Fail2banの設定は、/etc/fail2ban/ディレクトリにあります。重要なルールとして、jail.confのような.confファイルを直接編集してはいけません。
代わりに、jail.localのように.localという拡張子のファイルを作成し、変更したい項目だけを記述します。.localファイルの内容が.confの内容を上書きする仕組みになっており、これにより、将来Fail2banがアップデートされても、自分が行ったカスタム設定が消えてしまうのを防げます。
教義・信仰に沿ったエディタで、/etc/fail2ban/jail.local というファイル名で新規作成し、以下の内容を記述します。
# SSHへの総当たり攻撃を監視・ブロックする設定
[sshd]
enabled = true # このsshd用の設定を有効にする
maxretry = 3 # 3回試行を失敗したら
bantime = -1 # 無期限にBANする
logpath = /var/log/auth.log # この認証ログファイルを監視する
ignoreip = 127.0.0.1/8 ::1 【ここに自分のIPアドレスを追加】
# ignoreipには、絶対にBANしたくない自分のIPアドレスなどをスペース区切りで指定
# UFWがブロックしたログを監視・ブロックする設定
[ufw]
enabled = true
filter = ufw-aggressive
action = iptables-allports
logpath = /var/log/ufw.log
maxretry = 1 # 1回でもUFWの拒否ログに記録されたら
bantime = -1 # 無期限にBANする
ignoreip = 127.0.0.1/8 ::1 【ここに自分のIPアドレスを追加】
上記の[ufw]セクションで指定したufw-aggressiveというフィルターは、自分で作成する必要があります。これは、ufw.logから攻撃元IPアドレスを抜き出すためのルールです。
/etc/fail2ban/filter.d/ufw-aggressive.conf というファイル名で新規作成し、以下の内容を記述します。
[Definition]
failregex = [UFW BLOCK].+SRC=<HOST>
ignoreregex =failregex: この正規表現パターンに一致するログ行を探し、<HOST>の部分を攻撃元IPアドレスとして認識します。
sudo systemctl enable fail2bansudo systemctl start fail2bansudo systemctl status fail2banactive (running)と表示されていれば成功です。
sudo fail2ban-client statusJail list:に、sshdとufwが表示されていれば、監視が開始されています。
これで、不審なアクセスは次回以降、有無を言わせずブロックされる設定となりました。
BANされたIPアドレスは sudo fail2ban-client status sshd や sudo fail2ban-client status ufw で確認できます。
Linuxの学習で実機を触った方(特にRocky/AlmaなどのRHEL系ディストリビューション)で
sudo su -を実行したとき、以下のような文言を見かけるのではないでしょうか。
あなたはシステム管理者から通常の講習を受けたはずです。
これは通常、以下の3点に要約されます:
#1) 他人のプライバシーを尊重すること。
#2) タイプする前に考えること。
#3) 大いなる力には大いなる責任が伴うこと。この#3の「with great power there must also come -- great responsibility」は特に重要です。
少なくとも、Linuxサーバのインターネット公開という「1つの世界」を「他の世界と接続する」行為を試みた者は、この言葉を言葉ではなく魂で理解していきましょう。
なお、これを力説するのは「筆者が加害者になりかけたことがある」からです。上記の設定などを全く理解せず、rootの意味/覚悟を知らぬままLinuxサーバを自宅から運用するということを行ってしまったため……
たちまちのうちに制御を乗っ取られ、「善意の第三者からの通報」により阻止されたという苦い思いがあります。
この経験は15年もの間、Linuxと筆者を遠ざけ、趣味で触ってもローカル環境で運用するというトラウマとなりました。
ようやく、このトラウマから脱却できつつあるので、初心に立ち返る意味でもこの文章を残します。
旅行で購入したトラベラーズノート。
こちらの専門店を東京駅で発見したので購入。
購入したのはこちらのクリアファイルと連結バンド。
更に追加のリフィルとしおりなど。
クリアファイルはそのまま外にかけることで防護カバーとしても機能。
リフィルの追加は、中央のページ同士を連結させるという、かなりダイナミックで合理的なやり方。
そうして、スタンプノートが追加されたことで、
出先での「ログ」が更に満足いく物になりました。
BookStackの404記事を自分好みの文章に差し替えたときのメモです。
www-datacd /path/to/BookStack/resources/views/errors/ && pwd自分の環境に合わせます。(筆者環境/home/www-data/BookStack/resources/views/errors/)
sudo mv 404.blade.php /path/to/backup/404.blade.php.$(date +%Y%m%d)ファイル全体を差し替えるので、mvを利用します
ls -l /path/to/backup/404.blade.php.$(date +%Y%m%d)ファイルがあることを確認します。(mvなのでlsで確認)
を、新たなファイルに差し替えます。筆者はこのようにしました。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>404 | もう逃げられない、アーサー</title>
<style>
/* 全体設定 */
body {
font-family: 'Times New Roman', Times, serif;
background-color: #f7f7f7;
color: #333;
margin: 0;
padding: 20px;
line-height: 1.6;
}
/* コンテナ */
.container {
max-width: 800px;
margin: 40px auto;
background-color: #fff;
padding: 30px;
box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
border: 1px solid #ddd;
}
/* 404ヘッダー */
.header {
text-align: center;
margin-bottom: 30px;
border-bottom: 2px solid #a00; /* 赤いライン */
padding-bottom: 10px;
}
.header h1 {
font-size: 3em;
color: #a00;
margin: 0;
}
.header p {
color: #666;
font-style: italic;
}
/* 対話スタイル */
.dialogue-box {
margin-bottom: 20px;
padding: 15px;
border-left: 5px solid;
}
.dialogue-box.editor {
border-color: #4CAF50; /* 緑色 (編集者/外部の声) */
background-color: #e8f5e9;
}
.dialogue-box.arthur {
border-color: #2196F3; /* 青色 (アーサー/コナン・ドイル) */
background-color: #e3f2fd;
}
.speaker {
font-weight: bold;
display: block;
margin-bottom: 5px;
font-size: 0.9em;
text-transform: uppercase;
}
/* 結びのフッター */
.footer {
text-align: center;
margin-top: 30px;
padding-top: 20px;
border-top: 1px dashed #ccc;
}
.footer a {
color: #007bff;
text-decoration: none;
margin: 0 10px;
font-weight: bold;
}
.footer a:hover {
text-decoration: underline;
}
</style>
</head>
<body>
<div class="container">
<div class="header">
<h1>404 Not Found</h1>
<p>ページが見つかりません。探偵の不在は、常に混乱をもたらします。</p>
</div>
<div class="dialogue-box editor">
<span class="speaker">編集者（あるいは「声」）</span>
<p>**もう逃げられない。**<br>
続きを書け。馬車でストランドの編集部へ行こう。<br>
よく考えろ。自宅は葬列で包囲されている。<br>
喪章をつけたロンドン市民が続きを望んでいるんだ。<br>
君は探偵の大敵を出した直後に滝に落として、雑誌に大損害を与えた。<br>
もういい、歴史小説は終わりだ。<br>
**ホームズを生還させるんだアーサー。**<br>
君は既に有名作家として評価されているんだ！<br>
母上からの手紙を読め。読むんだ！<br>
母上も探偵の話を続けろと言っているぞ。<br>
ファンから殺されたいのか？<br>
君の作家性を高めるんだ！</p>
</div>
<div class="dialogue-box arthur">
<span class="speaker">アーサー・コナン・ドイル</span>
<p>**未だ何も評価されちゃいないんだ！ 何も！**<br>
俺にとって本当の小説とは戦争小説のことなんだ！<br>
アレは俺の小説じゃ無かった！<br>
生活費を稼ぐため、もっと書けと頼まれた！<br>
俺は100年戦争小説の為にリアルな騎士道を学び尽くした！<br>
これを書くために自キャラを滝に落としたら蛆虫どもが非難してくるんだ。<br>
俺のことを探偵殺しとか駄文を書く暇あったら生き返らせろとか悪口の限りを並べやがった！<br>
あいつら何なんだ？<br>
歴史物のなんたるかも知らずに！<br>
**頭にきたぜ！**</p>
</div>
<div class="dialogue-box editor">
<span class="speaker">編集者（あるいは「声」）</span>
<p>君にとってホームズの物語は<br>
**今の栄光の時代だ。断じて過去にはない**</p>
</div>
<div class="dialogue-box arthur">
<span class="speaker">アーサー・コナン・ドイル</span>
<p>俺は**大英帝国の未来**を書きたいんだ！</p>
</div>
<div class="dialogue-box editor">
<span class="speaker">編集者（あるいは「声」）</span>
<p>未来？ 未来だと？<br>
君はまだ少年兵のように、戦場に夢を見ているのか？<br>
ペンで帝国を救うつもりか、アーサー？</p>
</div>
<div class="dialogue-box arthur">
<span class="speaker">アーサー・コナン・ドイル</span>
<p>救うだと？ 違う！ **断罪する**んだ。<br>
俺は帝国の瓦礫の上で、真実の騎士を描く！<br>
硝煙の中に詩を見た。あの幻を、誰も読もうとしなかった。<br>
ホームズは観察するだけだ。<br>
だが俺の騎士は、**行動する！**</p>
</div>
<div class="footer">
<a href="/">本棚へ戻る (Go Home)</a>
<p style="font-size:0.8em; margin-top:10px;">（探偵は...未だ見つかっていません。）</p>
</div>
</div>
</body>
</html>sudo chown www-data:www-data 404.blade.php && ls -l 404.blade.phpwww-dataはBookStackの実行ユーザに合わせます。合わせた後、所有者を確認します。
sudo -u www-data php artisan view:clearsudo -u www-data php artisan cache:clearBookStackのサイトにアクセスし、存在しない適当な文字を入れます。
上記、設定した文書があることを確認します。
Powered by WordPress & Theme by Anders Norén