投稿者: manualmaton Page 8 of 237

Mod_Securityで特定のルールを無視する設定(Nextcloudでの偽陽性を排除)

Nextcloudにmod_securityを導入するに当たり、気をつけなければならないのがファイルの閲覧や登録、入力処理中にMod_securityが不審な処理として判断してしまうこと(偽陽性)です。

そこで、

  1. 偽陽性と思われるログの調査
  2. 調査時の補助線引き
  3. 偽陽性になるルールを無視する設定

を行います。

ログ確認

/var/log/nextcloud_error.logから、以下のようなログを見ました。

[Wed Sep 11 16:35:02.048442 2024] [security2:error] [pid 32762:tid 32762] [client aaa.bbb.ccc.ddd:56994] [client aaa.bbb.ccc.ddd] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/usr/share/modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "92"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 5, 0, 0, 0"] [ver "OWASP_CRS/3.3.5"] [tag "event-correlation"] [hostname "nextcloud.hoge.com"] [uri "/ocs/v2.php/apps/user_status/api/v1/heartbeat"] [unique_id "ZuFIJU_udFaqxqrJvRLaPQAAAAA"]

ここで見たいのは

  • クライアントのIPアドレス
  • どのようなルールIDを
  • どのぐらい検知したか

です。

ログ確認のワンライナー

これらを確認するため、copilotの助けを借りてawkスクリプトを生成します。

awk '/ModSecurity/ {
ip = gensub(/.*\[client ([0-9.]+):.*/, "\\1", "g", $0);
rule_id = gensub(/.*\[id "([0-9]+)"\].*/, "\\1", "g", $0);
print rule_id, ip;
}' /var/log/nextcloud/nextcloud_error.log | sort | uniq -c

これを実行したところ、Mod_Securityがエラーとして検知したログの中から

     36 911100 127.0.0.1
    267 911100 aaa.bbb.ccc.ddd
     65 920420 aaa.bbb.ccc.ddd
     36 949110 127.0.0.1
    267 949110 aaa.bbb.ccc.ddd
     36 980130 127.0.0.1
    267 980130 aaa.bbb.ccc.ddd

という結果を確認しました。127.0.0.1はローカルアドレス、aaa.bbb.ccc.dddも自分がアクセスしてきたIPアドレス。この間、自分がしていたのはNextcloudの設定変更やファイルの閲覧のみです。

Mod_securityが検知したルールIDを「偽陽性」と判断し、処置していきます。

Mod_Securityで特定のルールを検知させない処理

Apacheのバーチャルサイトで設定しているという形です。

設定ファイルの修正

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

設定ファイルやバックアップディレクトリは自分の環境に合わせます。

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

エラー無く、差分も表示されていなければバックアップは成功です。

  • ファイル修正

/etc/apache2/sites-available/nextcloud.confを以下のように修正していきます。(要root権限)

# Mod_security
## 最初は検知モード

SecRuleEngine DetectionOnly

## 偽陽性と判断したID
SecRuleRemoveById 911100
SecRuleRemoveById 920420
SecRuleRemoveById 949110
SecRuleRemoveById 980130
  • ファイル修正確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

SecRuleRemoveById IDで、これにマッチするパターンは無視します。

  • 差分例
 ## 最初は検知モード

 SecRuleEngine DetectionOnly
+
+## 偽陽性と判断したID
+SecRuleRemoveById 911100
+SecRuleRemoveById 920420
+SecRuleRemoveById 949110
+SecRuleRemoveById 980130
+
 </VirtualHost>

設定ファイルの設定反映

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • 設定反映
sudo systemctl restart apache2.service
  • Apache稼働確認
systemctl status apache2.service

active(running)を確認します。

動作確認

ターミナルで

tail -f /var/log/nextcloud/nextcloud_error.log

としてエラーログを流します。(エラーログは自分の環境に合わせます)

  • 上記処理を行ったNextcloudにアクセスして操作をしていきます。
  • 処理を行ったIDが検知されないことを確認します。

Ubuntu 20.04で動いていたfirefly-iiiをUbuntu24.04にデータ移行。

Linuxで動く財務管理システムfirefly-iii。

Ubuntu 24.04で動くことを確認したので、20.04からのデータを移行しました。(自分の手順では)

環境

移行前

  • Ubuntu 20.04
  • PHP 8.1
  • firefly-iii 5.7.9

移行先

  • Ubuntu 20.04
  • PHP 8.3
  • firefly-iii 6.1.16

その他はApache、MySQL環境です。

さっくりとした(?)手順

  1. 移行先のfirefly-iiiを構築します。
  2. 移行前のSQLダンプファイルを取得します。
  3. 移行先でダンプファイルをインポートします。
  4. 動作を確認します。

【移行先】firefly-iiiを構築します。

方法はこちらです。

【移行元】DBのダンプファイルを取得します。

  • ディレクトリ移動
cd /hoge && pwd

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

  • ダンプファイル取得
mysqldump -u firelfy -p --no-tablespaces --single-transaction firefly > firefly_$(date +%Y%m%d).sql

-u DBユーザー >の左のfireflyはDB名です。自分の環境に合わせます。

  • パスワードを入力してもファイルが取得できないときは?

パスワードに!などの特殊文字が入っていると羽の肥えるパターンがあります。passwdといったファイルを作成し、以下のように記入します。

[mysqldump]
user=DBユーザー
password=''

※パスワードはシングルクォーテーションで囲みます。

こちらのファイルを作った上で、

mysqldump --defaults-extra-file=passwd --no-tablespaces --single-transaction firefly > firefly_$(date +%Y%m%d).sql

実行します。 このpasswdファイルは作業後に削除します。

  • ファイル取得確認
head -50 firefly_$(date +%Y%m%d).sql

ダンプファイルの内容が見られることを確認します。

このダンプファイルを任意の安全な方法で移行先にコピーします。

【移行先】DBのインポートを行います。

  • ディレクトリ移動
cd /hoge && pwd

ダンプファイルを転送したディレクトリを指定します。

  • DBインポート
mysql -h localhost -u firefly -p firefly < firefly_$(date +%Y%m%d).sql 

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

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

active(running)を確認します。

動作の確認を行います。

移行先のfirefly-iiiをインストールしたドメインにアクセスして

  • 移行元のアカウントで認証できること
  • 移行元のデータが確認できること
  • データの検索や登録ができること

を確認できればOKです。

作業の後処理を行います。

  • ディレクトリ移動
cd /hoge && pwd

ダンプファイルを転送したディレクトリを指定します。

  • ダンプファイル削除
sudo rm firefly_$(date +%Y%m%d).sql 

必要に応じて、移行元サイトの閉鎖を行います。

Ubuntuサーバ、コマンドラインでのパスワード入力時にアスタリスクを表示する。

運用の好みの問題です。

sudo su -

環境

  • Ubuntu 20.04 / 22.04 / 24.04

等でrootに昇格する際、入力されたかを確かめる*を表示するようにして視認性を高めます。

既存ファイルのバックアップ

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

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

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

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

ファイル書き換え

  • sedによるファイル書き換え
sudo sed -i 's/^Defaults\s\+env_reset$/Defaults env_reset,pwfeedback/' /etc/sudoers
  • 差分確認
sudo diff -u /path/to/backup/directory/sudoers.$(date +%Y%m%d) /etc/sudoers
-Defaults       env_reset
+Defaults env_reset,pwfeedback

設定反映確認

設定を行ったサーバに対して、新しくSSHセッションを作成します。

sudo su -

でパスワードを入力時に*が表示されれば設定は反映されています。

UbuntuサーバにMod_Securityを導入。

ApacheのWAFモジュールであるmod_securityを導入します。

  • AWS Lightsailで早々とインストールしていた
  • 各種不審なIPアドレスを弾くための盾

として機能しているにもかかわらず文書化していなかったので、Web Arenaでの検証を機に文章に残します。

環境

  • Ubuntu 24.04 (20.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>
+        # Include OWASP ModSecurity CRS rules if installed
+        IncludeOptional /usr/share/modsecurity-crs/*.load
+</IfModule>
  • 設定追記の整合性を確認
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

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

Ubuntu24.04にfirefly-iiiをインストール。(php8.3対応版)

ここから施行を繰り返し、「結局、Ubuntu24.04でなければ動かないだろう」という結論。

無事にインストールできたので、その記録です。

環境

以下、既に構築済みという状況です。

そして、以下を準備済みです。

  • サイトにアクセスするドメインとDNS登録
  • 上記に沿った適切な証明書

さっくりとした手順

  1. プログラムをダウンロードします。
  2. composerでインストールします。
  3. DBを作成します。
  4. .envを設定します。
  5. DBのマイグレーションを行います。
  6. ログファイルの格納ディレクトリを設定します。
  7. ApacheでWebサーバの設定を行います。
  8. アクセスを確認します。

Firefly III のダウンロード

  • ディレクトリ移動
cd /home/www-data

Web公開用のディレクトリを指定します。

  • プログラムのダウンロード
git clone https://github.com/firefly-iii/firefly-iii.git -b v6.1.19

※PHP8.3で稼働するバージョンを指定しています。

  • ダウンロード確認
ls -ld firefly-iii

ディレクトリが作成されていること、Web実行ユーザ(www-data)であることを確認します。

DB作成

  • mysqlログイン
mysql -u root -p
  • DB作成
CREATE DATABASE firefly character set utf8mb4;
CREATE USER 'firefly'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON firefly.* TO 'firefly'@'localhost';
FLUSH PRIVILEGES;
EXIT;

ポリシーに合わせて強固なパスワードを指定します。

.env設定

  • .envのサンプルをコピー
sudo cp -pi .env.example .env
  • ファイル修正
    • .env を教義・信仰に沿ったエディタで修正します。
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=firefly
DB_USERNAME=firefly
DB_PASSWORD=your_password

最低限、上記を指定します。パスワードはDB作成時のものです。

DBマイグレーション

sudo -u www-data php artisan firefly-iii:upgrade-database
sudo -u www-data php artisan firefly-iii:correct-database
sudo -u www-data php artisan firefly-iii:report-integrity
sudo -u www-data php artisan passport:install

ログファイルの格納ディレクトリを作成

  • ディレクトリ作成
sudo mkdir /var/log/firefly
  • ディレクトリの所有者変更
sudo chown -R www-data www-data /var/log/firefly
  • ディレクトリ作成確認
ls -ld /var/log/firefly

Apache設定

  • 以下のファイルを作成します。
  • /etc/apache2/sites-available/firefly-iii.conf
  • 【】の箇所は、自分の環境に合わせて修正してください。
cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/firefly-iii.conf
<VirtualHost *:80>
    servername 【bank.example.com】
    # ドメイン名を指定します
    RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# HTTPアクセスを強制的にHTTPSにリダイレクトします
</VirtualHost>

<VirtualHost *:443>
    ServerName 【bank.example.com】
    # ドメイン名を指定します
    CustomLog 【/var/log/firefly/firefly_access.log】 combined
    ErrorLog 【/var/log/firefly/firefly_error.log】
    DocumentRoot 【/home/www-data/firefly-iii/public】
    # 自身の環境に合わせます
    <Directory 【/home/www-data/firefly-iii/public】>
    # 自身の環境に合わせます
        AllowOverride All
        Require all granted
    </Directory>

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

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

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

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

    Header always set Strict-Transport-Security "max-age=63072000"
    Header set X-Content-Type-Options "nosniff"
    Header always append X-Frame-Options "SAMEORIGIN"
    Header set X-XSS-Protection "1; mode=block"

</VirtualHost>

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:EC6-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
__EOF__

設定反映

  • 設定反映
sudo a2ensite firefly-iii.conf
  • Webサービス再起動
sudo systemctl restart apache2

インストール確認

設定したURLにアクセスします。(ここではbank.example.com)

  • Email address
  • パスワード(16文字以上)

を設定して、「Register」をクリックします。

続いて初期設定(メインバンクや通貨、言語の指定など)完了後、ダッシュボードが出てくればインストール完了です。

Ubuntuサーバのサイト停止とLet’s Encryptの自動更新停止。

ドメイン変更を伴うサーバのサイト移転を行いました。そこで、旧サーバのサイトのみの停止措置を行います。

環境

  • Ubuntu 20.04
  • Apache 2.4のバーチャルサイトを利用
  • Let's Encryptの自動更新を止める

再確認

データの移行が完全に済んでいることを確認します。

手順

設定ファイルを無効化します。

  • ディレクトリ移動
cd /etc/apache2/sites-enabled && pwd
  • 有効化されているサイトの確認
ls -la

sites-le-ssl.confのように、Let's Encryptの自動更新を利用しているサイトにシンボリックリンクが張られていることを確認します。

コマンドによるサイト停止

sites-le-ssl.conf
  • リンクがないことを確認
ls -la

シンボリックリンクがないことを確認します。

旧サイトの設定ファイルを退避します。

  • ディレクトリ移動
cd /etc/apache2/sites-available/ && pwd
  • ファイル退避
sudo mv sites-le-ssl.conf /path/to/backup/directory/sites-le-ssl.conf.$(date +%Y%m%d)
  • ファイル退避確認
ls -la sites-le-ssl.conf

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

ls -la /path/to/backup/directory/sites-le-ssl.conf.$(date +%Y%m%d)

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

Apacheを再起動します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

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

active (running)を確認します。

旧サイトにアクセスできないことを確認します。

Let's Encryptの一部の自動更新を無効化します。

sudo certbot delete --cert-name 無効化するドメイン
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Deleted all files relating to certificate ドメイン
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

のように、メッセージが出ればOKです。

Ubuntu 24.04のphp環境構築と環境設定。

「Nextcloud等のLAMP環境が動くか」を考慮しながらUbuntu 24.04サーバを構築しています。

そこで、php8.3のインストール及びモジュールの追加を行います。

さっくりとした手順

  1. レポジトリを追加します。
  2. php並びに必要なパッケージを段階的にインストールします。
  3. Nextcloud等で必要になるように設定をしていきます。

レポジトリ追加とアップデート

  • phpレポジトリの追加
sudo add-apt-repository ppa:ondrej/php
  • パッケージ全体のアップデート
sudo aptitude update

段階的なインストール

  • php本体
sudo aptitude install php8.3
  • 周辺モジュール(APCuとMemcached)
sudo aptitude memcached php8.3-apcu
  • Webアプリに必要な周辺モジュール(MySQLを使う場合)
sudo aptitude install php8.3-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysql,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml,dev,imagick,gmp}
  • Webアプリに必要な周辺モジュール(Postgresを使う場合)
sudo aptitude install php8.3-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,pgsql,pdo_pgsql,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml,dev,imagick,gmp}
  • インストール確認
php -v
PHP 8.3.11 (cli) (built: Aug 30 2024 09:28:18) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.11, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.11, Copyright (c), by Zend Technologies

2024/09/06現在のバージョンです。

OPcacheとAPCuの有効化

Nextcloudはこの設定が無いと警告の対象となります。(或いはエラーが発生します)

  • 設定ファイル待避
sudo mv /etc/php/8.3/mods-available/opcache.ini /path/to/backup/directory/opcache.ini.$(date +%Y%m%d)
sudo mv /etc/php/8.3/mods-available/apcu.ini /path/to/backup/directory/apcu.ini.$(date +%Y%m%d)

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

  • 設定ファイル差し替え
cat <<- __EOF__ | sudo tee -a /etc/php/8.3/mods-available/opcache.ini
; configuration for php opcache module
; priority=10
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__
cat <<- __EOF__ | sudo tee -a /etc/php/8.3/mods-available/apcu.ini
extension=apcu.so
[apcu]
apc.enabled=1
apc.shm_size=32M
apc.ttl=7200
apc.enable_cli=1
apc.serializer=php
__EOF__

※ メモリ量などは環境に合わせます。

  • 設定反映
sudo systemctl restart apache2.service
  • Apache稼働確認
systemctl status apache2.service

active (running)を確認します。

Apacheのホームディレクトリを変更。

Ubuntu系LinuxにapacheやnginxといったWebサーバをパッケージ管理システムでインストールすると、通常は

/var/wwwがホームディレクトリとなります。

コンテンツ系を/varに余り入れたくないという好みの問題があるため、ここを変えていきます。

通常、www-dataは/usr/sbin/nologinとなっているためシェルでログインはできませんが、rubyでbundle installを行う際にホームディレクトリを参照するケースがあるため、この措置を執ります。

さっくりとした手順

  1. 新たなホームディレクトリを作成して設定します。
  2. /etc/passwdファイルを書き換えます。

ディレクトリの作成と設定

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

運用に合わせます。

  • ディレクトリの所有者変更
sudo chown -R www-data:www-data /home/www-data
  • 設定確認
ls -ld /home/www-data

所有者がwww-dataになっていることを確認します。

passwdファイルの書き換え

※システム全体のアカウントを制御する重要なファイルです。取り扱いは慎重に行ってください。※

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

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

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

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

  • ファイル書き換え
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

差分がこの2つだけであることを確認できたら設定完了です。

Ubuntu 24.04、Apacheのインストールと初期設定

概要

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

  1. 豊富なモジュールとカスタマイズ
  2. 動的コンテンツの設定をしやすい
  3. 小規模サイトを立ち上げる上での手間の少なさ

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

さっくりとした手順

  1. Apacheのインストールを行います。
  2. Apacheの設定を行います。
  3. 設定の反映を確認します。

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

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

enabledactive (running)を確認します。

設定を行います。

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

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

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

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

  • 設定ファイル追記
sudo tee /etc/apache2/apache2.conf > /dev/null << 'EOF'
ServerSignature Off
ServerTokens Prod
ServerName 自分のサーバー名
EOF

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

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

内容です。

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

設定反映を確認します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

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

active (running)を確認します。

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

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

Server: Apache

WebARENA Indigo®のファイアウォール設定。

ufwとfail2banの前段に、vpsが備えているファイアウォールを挟ませることで、サーバの負荷を抑えます。

手順

管理画面にログインします。

ネットワーク管理>ファイアーウォールをクリック。

右上の「ファイアウォールの作成」をクリック。

  • ファイアウォール名:任意の名前
  • インバウンドルール
    • HTTP(80) IPアドレス→0.0.0.0 (全てのIPアドレスを許可)
    • HTTPS(443) IPアドレス→0.0.0.0 (全てのIPアドレスを許可)
    • Custom / TCP / 22 IPアドレス→0.0.0.0 (全てのIPアドレスを許可)

を設定します。これは基本的なWebサーバ用の設定なので、許可したいポートが他にあればそれに合わせます。

設定後、インスタンスへの適用→作成したインスタンスを選び、設定を保存します。

固定IPを持っていれば、SSHのIPアドレスを指定することで、それ以外のIPをシャットアウト可能です。

Page 8 of 237

Powered by WordPress & Theme by Anders Norén