タグ: apache Page 1 of 3

Ubuntu 20.04 / 22.04で稼働しているApache HTTP Server 2.4の脆弱性対応。

2024年4月に発表された脆弱性への対処を行います。

脆弱性内容

  • Apache HTTP Serverのコア機能におけるHTTPレスポンス分割の問題(CVE-2023-38709)
  • 複数のモジュールにおけるHTTPレスポンス分割の問題(CVE-2024-24795)
  • HTTP/2 CONTINUATIONフレームの検証不備に起因したメモリ枯渇の問題(CVE-2024-27316)

https://jvn.jp/vu/JVNVU99032532

環境

  • Ubuntu 20.04 および Ubuntu 22.04
  • Apache 2.4系を利用

Apacheのレポジトリを追加します。

sudo add-apt-repository ppa:ondrej/apache2

Apacheのバージョンアップを行います。

  • パッケージ全体のアップデート
sudo aptitude update
  • パッケージのアップグレード
sudo aptitude upgrade

このリストの中にapache2とapache2関連パッケージが更新される(2024/04/10現在)ため、それぞれアップグレードを行います。

バージョンアップを確認します。

apache2ctl -v

Apache/2.4.59以降であることを確認します。2.4.58には、http/2プロトコルへの脆弱性があるので、左記のバージョンであることを確認します。

対応を行った日付

2024/04/10

ApacheコンフィグファイルによるIP拒否。(アドレスべた書き)

概要

WordPressなどの特定のディレクトリに対して攻撃を仕掛けてくるIPアドレスやNWをブロックする方法についてメモします。

環境

以下で動作を確認しました。

  • Ubuntu 20.04
  • Apache 2.4
  • /etc/apache2/site-available/example.confなど、バーチャルサイトを利用

さっくりとした手順

  1. バーチャルサイトのコンフィグのバックアップを取ります。
  2. コンフィグを追記します。
  3. 設定を反映します。
  4. 動作を確認します。

コンフィグファイルのバックアップ

  • ディレクトリ移動
/etc/apache2/sites-available && pwd
  • バックアップ
sudo cp -pi example.conf /path/to/backup/directory/example.conf.$(date +%Y%m%d)

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

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

バックアップがなければ(エラーがなければ)バックアップはできています。

コンフィグの追記

  • /etc/apache2/site-available/example.conf

以下のように追記します。

<Directory "/var/www/html/example">
    <RequireAll>
        Require all granted
        Require not ip 192.168.1.1
    </RequireAll>
</Directory>

拒否対象のディレクトリや、IPアドレスは対象に合わせて修正してください。

動作確認に万全を期すなら、自分が用意できるアクセス元のIPアドレスを指定します。(その後、設定を削除します)

  • 追記後の差分確認
diff -u /path/to/backup/directory/example.conf.$(date +%Y%m%d) /etc/apache2/site-available/example.conf

上記の追記内容が出ていることを確認します。

設定反映

  • 設定ファイル確認
sudo apache2ctrl configtest

SyntaxOKを確認します。

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

反映確認

  • 対象ディレクトリがあるサイトにアクセスして、通常にアクセスできることを確認。
  • 自分が用意できるアクセス元のIPアドレスを指定しているなら、そこからのアクセスができないことを確認。

今後の対応

  • ネガティブリストではなくポジティブリストでの運用
  • 別ファイルの参照

など、改良していきます。

Tips:apacheバーチャルサイトのオフオン(切り替え)

ちょっとした小技が役立ったのでメモに残しておきます。

環境

  • Ubuntu 20.04系
  • Apache 2.4系

で、バーチャルサイトでサイトを検証していました。

背景

検証で動かしているWebアプリAがaaa.hoge.comで動いていました。

そこに、同じ環境でWebアプリBを動かす需要がありました。

本来なら、DNSで

  • aaa.hoge.com
  • bbb.hoge.com

とするところ、

  • DNS登録が間に合わない
  • 2つ同時に動かせるようなスペックではない

という背景がありました。そこで、「一度WebアプリAを無効にしつつ、WebアプリBをaaa.hoge.com」として動かすようなすり抜けを使いました。

さっくりとした手順

  1. WebアプリAの設定ファイルを無効化します。
  2. WebアプリBの設定ファイルを作成します。
  3. WebアプリBを有効にします。

前に動いているサイトの無効化

sudo a2dissite app_a.conf

sudo systemctl restart apache2.service

WebアプリB用の設定ファイル作成

  • /etc/apache2/sites-available/app_b.conf

に以下のように作っていきます。

略
<VirtualHost *:443>
    # ドメイン名を指定します
    ServerName aaa.hoge.com
    # アプリB用のログディレクトリを指定します。
    CustomLog /var/log/nextcloud/nextcloud_access.log combined
    ErrorLog /var/log/nextcloud/nextcloud_error.log

    # アプリB用のドキュメントルートディレクトリを指定します。
  # アプリAno参照ドキュメントとは違うディレクトリにします
    DocumentRoot /home/www-data/nextcloud
    <Directory /home/www-data/nextcloud>
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>
略

サイトBを有効化します。

sudo a2ensite app_b.conf

sudo apache2ctl configtest

sudo systemctl restart apache2.service

動作を確認します。

aaa.hoge.com(など、今までアプリAが動いていたサイトのドメインで)アプリBのサイトが動くようになれば成功。

一時的な手段ではありますが、効果はありました。

同一サーバ内でRedmineのドメインを変更するときの設定。(apacheバーチャルファイル編集)

ちょっとした事情で、既に稼働しているRedmineのドメインを変更しました。以下、作業メモです。

環境

  • Ubuntu 20.04
  • Apache 2.4系
  • Redmine 4.2系

前提

  • apacheのバーチャルサイトでRedmineを設定していること。
  • 新しく割り当てるドメインが、稼働サーバと同じであること。
  • 新しいドメインの適切な証明書を取得し、所定の箇所に格納していること。

ここでは、aaa.hoge.comをbbb.hoge.comに変える手順を行います。

さっくりとした手順

  1. バーチャルサイトの設定ファイルをコピーします。(aaa→bbb)
  2. 新たなドメインの設定ファイルを編集します。
  3. 以前の設定ファイルを無効化します。
  4. 新たな設定ファイルを有効化します。
  5. apacheの再起動を行います。
  6. Redmineの設定変更を行います。

手順

設定ファイルコピー

cd /etc/apache2/sites-available && pwd
# 自分の環境に合わせます。

sudo cp -pi aaa.hoge.com.conf bbb.hoge.com.conf
# 設定ファイルは自身の環境に合わせます。

ファイル編集

以下の差分の通り修正します。信仰・教義に沿ったエディタで編集してください。

 <VirtualHost _default_:80>
-servername aaa.hoge.com
+servername bbb.hoge.com

 <VirtualHost _default_:443>
-    servername aaa.hoge.com
+    servername bbb.hoge.com

-SSLCertificateFile /etc/certs/aaa.hoge.com.crt
-SSLCertificateKeyFile /etc/private/aaa.hoge.com.key
+SSLCertificateFile /etc/certs/bbb.hoge.com.crt
+SSLCertificateKeyFile /etc/private/bbb.hoge.com.key
# 証明書と秘密鍵の適切な格納場所を指定します。
# ホスト名のみ変更し、ワイルドカード証明書を利用するのであれば証明書の部分は修正する必要はありません。

変更前設定ファイルの無効化

sudo a2dissite aaa.hoge.com.conf
# サービス再起動を求められますが、最後にまとめて行います。

変更後設定ファイルの有効化

sudo a2ensite bbb.hoge.com.conf

サービス再起動

  • 設定ファイル構文チェック
sudo apache2ctl configtest
# Syntax OKを確認します。
  • サービス再起動
sudo systemctl restart apache2.service

変更後の設定変更

  1. ブラウザで、変更後のドメインにアクセスします。
  2. 管理者権限でログインします。
    • ドメイン以外の設定は変えていないので、ログインは行えます。
    • ビルトインの2段階認証を利用している場合変更前のワンタイムパスワードを利用してください。
  3. 設定→管理に移動します。
  4. 概要タブのホスト名とパスを変更後のものに合わせます。

Apacheで動かしているWebサイトにセキュリティヘッダーを付与。

概要

AWS Lightsailを用いて外部公開しているWebサイトのセキュリティを高めるため、セキュリティヘッダを更に付与しました。

環境

  • Ubuntu 20.04
  • Apache 2.4系
  • Headerモジュール導入済み

また、/etc/apache2/sites-availavle配下にバーチャルサイトファイルで管理しています。

さっくりとした手順

  1. 現行のバーチャルサイトのコンフィグのバックアップを取得します。
  2. コンフィグにセキュリティヘッダを付与します。
  3. Webサービスの再起動を行います。

実施した手順

バックアップ

cd /etc/apache2/sites-available &&pwd
# 自環境のバーチャルサイトの格納場所に移動します

sudo cp -pi hoge.conf /path/to/directory/hoge.conf.$(date +%Y%m%d)
# バックアップ元とバックアップ先は自分の環境に合わせます。

diff -u hoge.conf /path/to/directory/hoge.conf.$(date +%Y%m%d)
# 差分がないことでバックアップが取れていることを確認します。

セキュリティヘッダ追記

教義・進行に沿ったエディタを用いて、以下の差分になるようにセキュリティヘッダをコンフィグに付与します。

+    Header set X-Content-Type-Options "nosniff"
+    Header always append X-Frame-Options "SAMEORIGIN"
+    Header set X-XSS-Protection "1; mode=block"

以下はChantGPTによる解説です。

X-Content-Type-Options: "nosniff"

このヘッダーは、ブラウザがレスポンスのContent-Typeヘッダーと実際のコンテンツの種類が一致しない場合に、ブラウザが自動的にコンテンツのタイプを推測するのを防止します。これにより、悪意のあるコンテンツが実行されるリスクを低減することができます。

X-Frame-Options: "DENY" または "SAMEORIGIN"

このヘッダーは、クリックジャッキング攻撃を防止するために使用されます。"DENY" を指定すると、ページがフレーム内で表示されることが完全に禁止されます。"SAMEORIGIN" を指定すると、同じオリジン(ドメインとプロトコルが一致)のフレーム内でのみページが表示されます。

X-XSS-Protection: "1; mode=block"

このヘッダーは、クロスサイトスクリプティング(XSS)攻撃からの保護を目的としています。ブラウザによって検出されたXSS攻撃が検出された場合、ブラウザはページをブロックするように指示されます。

コンフィグの整合性確認と再起動

  • コンフィグ確認
sudo apache2ctl configtest
#Syntax OKを確認します
  • サービス再起動
sudo systemctl restart apache2.service

systemctl status apache2.service
#Active(running)を確認します

ヘッダ付与確認

  1. Google Chromeを開き、対象のウェブサイトにアクセスします。
  2. ウェブサイトを表示した状態で、右クリックしてコンテキストメニューを表示し、「検証」を選択します。
  3. 開発者ツールが表示されたら、上部のメニューバーの中から「Network」(ネットワーク)タブを選択します。
  4. ページをリロードするか、ウェブサイト上で任意のアクションを実行してネットワークタブにリクエストが表示されるようにします。
  5. ネットワークタブで、対象のリクエストを選択します。
  6. 右側のパネルで、"Headers"(ヘッダー)セクションを展開します。
  7. ヘッダーセクションには、レスポンスヘッダーが表示されるので、以下を確認してください。
  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection

ヘッダーが正しく設定されていれば、それぞれのヘッダーの値が表示されます。

Mod_Securityが検知したIPアドレスの自動遮断スクリプト・修正。

以下のスクリプトを修正しました。

このスクリプトの主な動き

  1. Mod_Securityが検知したエラーログからIPアドレスのみを抜き出す。
  2. 重複を排除した上でsuscpicious_ip.YYYYMMDD形式で保存。
  3. 全てのsuscpicious_ip.YYYYMMDDを統合する。
  4. ここからnegativelist.txtを作成する。
  5. negativelist.txtの中に疑陽性(自身のアクセス元)のIPを排除する。
  6. Webサービスを再起動する。

そうして、「一度でもMod_Securityが疑わしいと検知すれば、次回以降のアクセスを許さない」という、言わば“ONE OUTS”システムを採用しています。

この可読性を高めました。

スクリプトが動く前提

  • ApacheとMod_Securityを運用している。
  • 以下のように、「negativelist.txt」に記録されたIP全てをブロックするようにしている。

apacheバーチャルサイト設定の抜粋

# Mod Security
SecRuleEngine On
## ModSecurity有効化
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
## ファイルのアップロードをできるようにします。
    # ネガティブリスト
    SecRule REMOTE_ADDR "@pmFromFile negativelist.txt" "phase:1,id:2,deny,msg:'Negativelisted IP address'"

修正したスクリプト

※ 教義・信仰に沿ったエディタで記載します。

  • negativelist.sh
#!/bin/bash
# このシェルスクリプトは、変数で定義したエラーログからIPアドレスを抽出し、
# suspicious_ipディレクトリに保存し、その後、特定のIPアドレスを削除して
# /etc/apache2/sites-available/negativelist.txtに書き込むものです。

# 読み込むログのディレクトリとファイル名を変数指定
log_dir="/var/lib/redmine/log"
log_file="error.log"

# 除外するIPアドレスをファイルで指定
exclude_ips_file="/path/to/exclude_ips.txt"

# IPアドレスを抽出して重複を排除し、ファイルに保存
cd "$log_dir"
awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "$log_file" | sort | uniq > "$log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"
chown www-data:www-data "$log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"

# 過去のIPアドレスを読み込んで重複を排除し、ファイルに保存
cat "$log_dir/suspicious_ip/suspicious_ip."2* | sort | uniq > "$log_dir/suspicious_ip_all.txt"
chown www-data:www-data "$log_dir/suspicious_ip_all.txt"

# 新たにリストに書き起こす
cat "$log_dir/suspicious_ip_all.txt" > /etc/apache2/sites-available/negativelist.txt

# 除外するIPアドレスをファイルから削除
while IFS= read -r exclude_ip; do
  sed -i "/$exclude_ip/d" /etc/apache2/sites-available/negativelist.txt
done < "$exclude_ips_file"

# Apacheを再起動
systemctl restart apache2.service
  • 除外するIPアドレスリスト

※ 教義・信仰に沿ったエディタで作成します。

  • exclude_ips.txt 記載例
192.168.0.1
172.28.0.1
# 一行ずつ記載

記載後の設定

  • スクリプトの所有者変更
sudo chown root:root negativelist.sh
  • スクリプトの実行権付与
sudo chmod 744 negativelist.sh
  • cron登録
sudo crontab -e -u root
  • cron内容
0 6 * * * /home/manualmaton/bin/negativelist.sh

これによって、スクリプトを変数化。他のサーバへの転用を行いやすくしました。

検証:Ubuntu 20.04にRedmine 5.0のインストールと4.2へのダウングレード。

ふと思い立っての検証です。

あらまし

別サイトに記載しているRedmine4.2のインストール手順。

https://atelier.reisalin.com/projects/zettel/knowledgebase/articles/19

この手順で「Redmine 5.0を設定できるか?」と思い立ち、検証用のまっさらなUbuntu 20.04を用意しました。

前提

以下を設定しています。

  • インターネット回線に接続されていること
  • ドメインで名前解決できること
  • SSH接続が可能なこと

実施手順

上記のリンクの手順に沿いました。異なっている点は、Redmine 5.0をダウンロードするため、

sudo -u www-data svn co https://svn.redmine.org/redmine/branches/5.0-stable /home/www-data/redmine

としただけです。

無事にRedmine5.0が動き、以下の参照どおりにSSLを設定。

https://atelier.reisalin.com/projects/zettel/knowledgebase/articles/20

これで試しにと思いましたが、

プラグインとの兼ね合い

「どうしても使いたいプラグインがRedmine 5.0に対応していない」事情により継続利用は無理だと断念。特に

  • knowlegebase
  • redmine_issue_badge_plugin

の2つが利用できないのは非常に痛い状況でした。

Redmine 5.0→4.2へのダウングレード

そこで、インストールしたばかりのRedmine5.0を4.2に即座に戻すことにします。

注意点

この手順は、データが全く入っていない状況で可能な作業です。「こんな手法を採ったのがいる」程度に参照ください。

前提

  • 上記手順を元にRedmine 5.0がインストールされ
  • なおかつデータが何も入っていない
  • RedmineのDB名は「redmine」
  • apache2設定ファイルは稼働済み

さっくりとした手順

  1. apache2サービスを落とします。
  2. データベースをまるごと削除します。
  3. 同じ名前でDBを再作成します。
  4. プログラムを再配置します。
  5. apache2サービスを起動します。

apache2サービス停止

sudo systemctl stop apache2.service
#これを行わないと後述のDBが消去できません

mysqlでDBを再作成します。

sudo mysql -u root -p
DROP DATABASE redmine;
# DBを削除します

CREATE DATABASE redmine character set utf8mb4;
# DB "redmine" を再作成します

exit

Redmineプログラムを再配置します。

sudo rm -rf /home/www-data/redmine
# Redmineを配置したディレクトリごと削除します

sudo -u www-data svn co https://svn.redmine.org/redmine/branches/4.2-stable /home/www-data/redmine
# 設定したときと同じディレクトリに4.2を再配置します

Redmineのコンフィグを設定します。

sudo cp -pi /home/www-data/redmine/config/database.yml.example /home/www-data/redmine/config/database.yml

sudo vi /home/www-data/redmine/config/database.yml
# 教義・信仰に従ったエディタで編集してください。

database.yml 編集内容

production:
  adapter: mysql2
  database: redmine
  host: localhost
  username: redmine
  # rootからredmineに変更します
  password: "redmine用のパスワード"
  encoding: utf8mb4
# 本番環境(production)のみ設定を行います

Redmineのマイグレーションを行います。

cd /home/www-data/redmine/ && pwd
# /home/www-data/redmine/ (Redmineを配置したディレクトリ)であることを確認します

sudo -u www-data bundle install --without development test --path vendor/bundle

sudo -u www-data bundle exec rake generate_secret_token

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

apache2サービスを起動します

すでにapache上でRedmineを動かす手はずは整っており、プログラムの実行ディレクトリも同じ。ならば、設定ファイルは修正せずに済むという判断のもとに実行。

sudo apache2ctl configtest
# Syntax OK を確認します

sudo systemctl restart apache2.service

systemctl status apache2.service

サイトの表示を確認します。

http://設定したRedmineドメイン

でRedmineのトップページが表示されれば成功です。

検証段階だからこそ行えた手荒な手段でした。

Apacheで特定のアクセス元からの通常アクセスをログに残さない設定。

概要

Webサービスの運用時、「誰がいつどこにアクセスしたか」を判別するアクセスログはとても重要なものです。


ではありますが、Webアクセス解析時に自分のアクセスログが邪魔になるケースがありました。

そこで、Apacheの設定ファイルで特定のアクセス元からのログを残さないようにしました。

確認環境

  • OS : Ubuntu 20.04 LTS
  • Apache 2.4.55

前提

  • 大本のコンフィグ(httpd.conf)ではなくバーチャルサイトで設定していること。
  • Apache設定ファイルに管理者権限で設定ができること。
  • 除外するIP/NWに対し、合意が取れていること。

注意事項

  • この方法でエラーログの除外設定はできません。

実施した手順

ほぼ全てSSHクライアントターミナルからの操作です。

さっくりとした手順

  1. コンフィグのバックアップを取ります。
  2. ログを残さない除外IP/NWを加えます。
  3. コンフィグの整合性を確認し、設定を反映します。
  4. 除外したIP/NWからのアクセスログが出ないことを確認します。

コンフィグ設定

コンフィグのバックアップを取ります。

sudo cp -pi /etc/apache2/sites-available/sites.conf /path/to/backup/directory/sites.conf.$(date +%Y%m%d)
# 自分が設定しているバーチャルサイトのコンフィグ / バックアップディレクトリに合わせます。

diff -u /etc/apache2/sites-available/sites.conf /path/to/backup/directory/sites.conf.$(date +%Y%m%d)
# 差分が無いことでバックアップが取れていることを確認します。

コンフィグファイルを編集します。

sudo vi /etc/apache2/sites-available/sites.conf
# 教義・信仰に従ったエディタで編集してください。
編集例

ここでは、以下の設定とします。

  • 除外IP: 192.168.1.11
  • 除外NW: 192.168.2.0/24
  • アクセスログの格納場所: /var/log/redmine/access.log
    # 以下のIP/NWはアクセスログに記録させません
    SetEnvIf Remote_Addr "192.168.1.11" dontlog
    SetEnvIf Remote_Addr "^192\.168\.2\." dontlog
    CustomLog /var/log/redmine/access.log combined env=!dontlog

保存後、以下のような差分を確認します。

diff -u /path/to/backup/directory/sites.conf.$(date +%Y%m%d) /etc/apache2/sites-available/sites.conf
  • ●差分
+    # 以下のIP/NWはアクセスログに記録させません
+    SetEnvIf Remote_Addr "192.168.1.11" dontlog
+    SetEnvIf Remote_Addr "^192\.168\.2\." dontlog
-    CustomLog /var/log/redmine/access.log combined
+    CustomLog /var/log/redmine/access.log combined env=!dontlog

設定反映

コンフィグの整合性を確認後に設定を反映します。

sudo apache2ctl configtest
# Syntax OKを確認します。

systemctl status apache2.service
# active (running)を確認します。

sudo systemctl restart apache2.service

systemctl status apache2.service
# active (running)を確認します。

動作確認

設定後の動作を確認します。

  • ●アクセスログ確認コマンド発行
tail -f /var/log/redmine/access.log
# 自分の環境(設定したアクセスログ)に合わせます。
  • ●エラーログ確認コマンド発行

※別ターミナルで開きます。

tail -f /var/log/redmine/error.log
# 自分の環境(設定したエラーログ)に合わせます。
  • ●ブラウザで以下を実施
  1. 設定したIP / NWから設定対象のWebサイトにアクセスする。
  2. 設定していないIP / NWから設定対象のWebサイトにアクセスする。
  3. 設定したIP / NWから設定対象のWebサイトにアクセスするがエラーを起こす。(404/403エラーなど)
  4. 設定していないIP / NWから設定対象のWebサイトにアクセスするがエラーを起こす。(404/403エラーなど)

その間、以下をターミナルで開いたアクセスログ/エラーログで確認できれば設定は完了です。

  1. 設定したIP / NWからのアクセスログが出ないこと。
  2. 設定していないIP / NWからのアクセスログが出ること。
  3. 設定したIP / NWからのエラーログが出ること。
  4. 設定していないIP / NWからのエラーログが出ること。

アクセス解析システム:matomoのインストール。

概要

オープンソースの解析システムであるmatomoをAWS Lightsail上にインストールしました。

参考としたURL

本記事で実施すること

  • AWSサーバに導入されているPHPがサポート終了しているため、7.4から8.1にアップグレードする。
  • Ubuntu 20.04にアクセス解析システム「matomo」をインストールする。
  • その際に常時SSL化を行う。
  • Web画面から初期設定を行う。

※アクセス対象のシステムへの設定は別の記事で紹介します。

前提

  • 既に以下のシステムがWAN環境に揃っていること。
  • Ubuntu 20.04
  • Apache 2.4
  • mysql 8
  • PHP 7.4
  • matomo用のサブドメインを取得していること。
  • それに即した証明書があること。

手順

さっくりとした手順

  1. PHPを7.4から8.1にアップグレードする。
  2. MySQLのDBとユーザを作成する。
  3. ディレクトリにmatomoプログラムを配置する。
  4. Apache設定ファイルを作成し、常時SSLで接続できるようにする。
  5. matomoサイトにログインできることを確認する。
  6. matomo Web画面で初期設定をする。

PHPのアップグレードを行います。

sudo apt-get --purge autoremove php*

sudo aptitude install php8.1
sudo aptitude install php8.1-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysql,mysqli,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml,dev}
sudo aptitude install php8.1-apcu
sudo aptitude install php8.1-memcached

sudo systemctl restart apache2.service

php -v
# PHP 8.1.14を確認しました。

PHPアップグレード後、PHPを動かしているサーバ内のサイトが正常に動くことを確認しました。

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

sudo mysql -u root -p
CREATE DATABASE matomodb;
CREATE USER 'matomouser'@'localhost' IDENTIFIED BY 'password';
/* パスワードは自身の環境に合わせ、強固なものを設定してください */
GRANT ALL ON matomodb.* to 'matomouser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

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

cd /tmp &&pwd
# tmpにいることを確認します

wget https://builds.matomo.org/matomo-latest.zip

unzip matomo-latest.zip

sudo chown -R www-data:www-data matomo

sudo mv matomo /var/www/html/
# 今回は/var/www/htmlに配置します。

ls -ld /var/www/html/matomo
# 該当ディレクトリにファイル一式があることを確認します

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

  • 【】内を自分の環境に合わせます。
  • コマンド一式をコピー → 別のエディタにペースト
  • その後、【】内を自分の環境に修正してコピー
  • コマンド一式をSSHクライアントに貼り付ける
cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/matomo.conf
<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 /var/www/html/matomo
    <Directory /var/www/html/matomo>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Require all granted
    </Directory>

  SSLEngine on

    Protocols h2 http/1.1
    Header always set Strict-Transport-Security "max-age=63072000"

SSLCertificateFile 【SSL証明書のファイルパス】
SSLCertificateKeyFile 【SSL秘密鍵のファイルパス】
# SSLCACertificateFile 【SSL中間証明書のファイルパス】
# 中間証明書が発行元から別ファイルで提供されている場合は、この直上をコメントアウトして中間証明書を指定します

</VirtualHost>

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

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
# これらのセクションはSSL暗号化強度を高めるための記述です
# </VirtualHost>の外側に書くことにご注意ください
__EOF__

設定を反映します。

cd /etc/apache2/sites-available && pwd
# 対象ディレクトリにいることを確認します

sudo a2ensite matomo.conf

sudo apache2ctl configtest
# Syntax OKを確認します

sudo systemctl restart apache2.service

ブラウザで

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

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

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

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

全てチェックされていることを確認して「次へ」をクリックします。

◎データベースを設定します。

  • ログイン: MySQLのユーザー(matomouser)
  • パスワード: 設定したパスワード
  • データベース名:作成したDB (matomodb)

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

◎スーパーユーザーを設定します。

  • スーパーユーザーログイン:ログインするユーザー名
  • パスワード:ログイン時のパスワード
  • パスワード(再入力)
  • メールアドレス

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

◎アクセス解析を行うウェブサイトを設定します。

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

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

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

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

ChatGPTが作成したapacheバーチャルファイル。

2022年12月頃にTwitterで大いに話題となったChatGTP。

https://chat.openai.com/chat

これは文書作成のみならずコードも書けると知ったので早速試してみました。

作成してほしいコード

  • apacheでwordpressを動かすためのコンフィグ。
  • httpアクセスをhttpsにリダイレクトする。
  • アクセスログとwordpressのプログラムの格納場所は指定。

質問した内容

以下の文章をChatGPTに入力しました。

apacheでwordpressを公開するためのバーチャルサイトのコンフィグを作成してください。
サーバはUbuntu22.04です。apacheとmod_sslは導入済みです。
ドメインはweblog.example.comです。
wordpressは/home/www-virtual/wordpressに格納されています。
アクセスログは/var/log/apache2/weblog.example.comを指定します。
httpアクセスを強制的にhttpsにリダイレクトし、TLS1.2のみを有効化します。
wp-adminディレクティブは192.168.1.0/24以外アクセスできないようにします。

返ってきた内容

結論から言って驚きの結果でした。


まず、/etc/apache2/sites-available/weblog.example.com.confという名前のファイルを作成します。 次に、以下の内容を記述します:

<VirtualHost *:80>
    ServerName weblog.example.com
    DocumentRoot /home/www-virtual/wordpress
    ErrorLog /var/log/apache2/weblog.example.com/error.log
    CustomLog /var/log/apache2/weblog.example.com/access.log combined
    <Directory /home/www-virtual/wordpress>
        Require all granted
    </Directory>
</VirtualHost>

次に、SSL用のバーチャルサイトの設定を追加します。

<VirtualHost *:443>
    ServerName weblog.example.com
    DocumentRoot /home/www-virtual/wordpress
    ErrorLog /var/log/apache2/weblog.example.com/ssl-error.log
    CustomLog /var/log/apache2/weblog.example.com/ssl-access.log combined
    SSLEngine on
    SSLCertificateFile /path/to/your/certificate.crt
    SSLCertificateKeyFile /path/to/your/privatekey.key
    SSLProtocol TLSv1.2
    <Directory /home/www-virtual/wordpress>
        Require all granted
    </Directory>
    <Location "/wp-admin/">
        Require ip 192.168.1.0/24
    </Location>
</VirtualHost>

最後に、httpアクセスをhttpsにリダイレクトするために、mod_rewriteモジュールを有効化し、以下の設定を追加します。

<VirtualHost *:80>
    ServerName weblog.example.com
    DocumentRoot /home/www-virtual/wordpress
    ErrorLog /var/log/apache2/weblog.example.com/error.log
    CustomLog /var/log/apache2/weblog.example.com/access.log combined
    <Directory /home/www-virtual/wordpress>
        Require all granted
        RewriteEngine on
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    </Directory>
</VirtualHost>

これで、バーチャルサイトの設定が完了しました。

注意: 上記の設定は一例であり、適切な設定はサイトの状況や環境によって異なります。また、必要に応じて、この設定をカスタマイズしてください。


注文通りです。想定通りの動きになるのはほぼ間違いないです。(後で検証したいぐらいです)これに付け加えるならば、

sudo a2ensite weblog.example.com.conf
sudo apache2ctl configtest
# Syntax OKを確認します
sudo systemctl restart apache2.service

ぐらいでしょう。

今後の各種サーバ設定に大いに貢献する予感です。

Page 1 of 3

Powered by WordPress & Theme by Anders Norén