タグ: Linux Page 18 of 24

検証: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のトップページが表示されれば成功です。

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

MySQLの定期バックアップ、現状の運用に修正。

こちらの記事を2023年2月時点での運用に併せ、以下、修正しました。

概要

Redmineのメンテナンスの中で、「データベースのバックアップ」は非常に重要なものです。

そこで、改めて、シェルスクリプトとCronによるバックアップ手順を整理しました。

動作を確認した環境

  • Ubuntu 20.04 LTS
  • Redmine 4.2
  • MySQL 8.0.32

実施前提

  • MySQLに管理者権限でログインできること。
  • Redmine用のDBとDBユーザ、DBパスワードを把握していること。
  • また、DBサーバはローカルホストです。

確認した手順

  • Redmineが稼働しているUbuntuサーバのターミナル上での操作です。
  • MySQL以外は全て一般権限で実行します。

さっくりとした手順

  1. Redmineのデータベースユーザに権限を付与します。
  2. バックアップディレクトリを作成します。
  3. アカウントファイルを作成します。
  4. バックアップスクリプトを作成します。
  5. crontabに登録します。

データベース設定

管理者権限でMySQLにログインします。

mysql -u root -p

データベースのユーザ権限を変更します。

これを行わないとDump処理ができませんでした。

GRANT RELOAD ON *.* TO '【RedmineのDBユーザ】'@'localhost';
FLUSH PRIVILEGES;
EXIT

ディレクトリとスクリプト作成

バックアップディレクトリ作成

sudo mkdir -p /home/backup/mysql
# 運用に合わせて指定ください。ファイルサーバや別パーティションにマウントしている方がサーバ事態の障害発生でも冗長化を持たせられます。

sudo chown -R hoge:hoge /home/backup/mysql
# ディレクトリの所有者をログインユーザに修正します

cd /home/backup/mysql && pwd
# 指定したディレクトリに移動します

アカウントファイル作成

※このファイルを作成しないと、「安全ではない」とエラーが出ます。

以下の内容を教義・信仰に沿ったエディタで作成します。(【】内は取り除き、自分の設定に合わせます)

  • アカウントファイル内容
  • ファイル名:account.txt
[client]
user = 【RedmineのDBユーザ】
password = "【RedmineのDBユーザ用パスワード】"

アカウントファイルでアクセスできることを確認

mysql --defaults-extra-file=account.txt

MySQLのプロンプトが出れば成功です。exitで抜けます。

スクリプト作成

以下の内容を教義・信仰に沿ったエディタで作成します。

  • スクリプト内容
  • スクリプト名:mysql_daily_backup.sh
#!/bin/bash

# スクリプトの日付形式を定義します
date=$(date +"%Y%m%d")

# バックアップディレクトリを定義します
# 上記手順で示したディレクトリを指定してください
backup_dir="/home/backup/mysql"

# アカウントファイルを指定します
credentials_file="$backup_dir/account.txt"

# バックアップ時に指定するオプションを定義します
options="--defaults-extra-file=$credentials_file --no-tablespaces --single-transaction"

# バックアップファイル名を定義します
backup_file="$backup_dir/redmine.sql.$date.gz"

# バックアップを実行し、.gz形式でバックアップをします
mysqldump $options -h localhost redmine | gzip > $backup_file

# 10世代前の圧縮ファイルを削除します(運用に合わせて指定ください)
find $backup_dir -type f -name "redmine.sql.*.gz" -mtime +10 -delete
  • 実行権限の付与
chmod +x mysql_daily_backup.sh

動作確認

sh mysql_daily_backup.sh

以下を確認します。

  • エラーなく実行できること
  • redmine.sql.実行日付.gz形式でファイルが作成されること
  • gunzip redmine.sql.実行日付.gzでファイルが解凍できること

Crontab設定

Cron登録

crontab -e

登録内容例

0 0 * * * /home/backup/mysql/mysql_daily_backup.sh
# 実行時刻、頻度などは自分の運用形態に合わせます。

Cron登録確認

sudo tail -20 /var/log/cron.log

操作時刻に

  • BEGIN EDIT
  • REPLACE
  • END EDIT

が表示されれば設定は完了です。

動作確認日

2023/02/08

Redmine4.2にQ & Aを導入。(RedmineUP プラグイン)

概要

設定やメモなど、ハマりポイントは結構な頻度で発生します。

そこで、あらかじめQ & A形式のメモで残せるようなプラグインをRedmineに導入します。(利用例)


メール登録が必要ではありますが無料(light version)です。

プラグイン名

動作を確認した環境

  • Redmine 4.2

導入時

プラグインのダウンロード:要
Gem追加:要
DBマイグレーション:要

手順

さっくりとした手順

  1. サイトからプラグインをダウンロードしてサーバに転送
  2. SSHログイン後、Redmineプラグインに移動
  3. 新規ジェムをインストール
  4. DBマイグレーション
  5. Webサービス再起動

プラグインの入手

Redmine UP Webサイトにアクセスします。

https://www.redmineup.com/pages/ja/plugins/questions

プラグインのダウンロードをします。

  1. 自身のメールアドレスを入力
  2. 受信したメールからプラグインをダウンロード

任意の方法でサーバに転送します。

安全性が担保されるのであれば任意の方法を選びます。

プラグインの展開と配置

ファイルの配置

ターミナルクライアントで作業をします。

cd /path/to/saved/directory/
# プラグインを保存したディレクトリに移動します。

unzip redmine_questions-1_0_4-light.zip
# 2023/02/05現在のバージョンです

sudo chown -R www-data:www-data redmine_questions

sudo mv redmine_questions /home/www-data/redmine/plugins/
# 自分の環境に合わせます。

ls -ld /home/www-data/redmine/plugins/redmine_questions
# ディレクトリがあることとファイルの所有権がwww-dataであることを確認します。

プラグインのインストールを行います。

Gemをインストールします

cd /var/lib/redmine/
# 自分の環境に合わせます。

sudo -u www-data bundle install

sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production

Webサービスを再起動します。

sudo systemctl restart apache2

導入後の動作確認

  1. Redmineに管理者アカウントでログインします。
  2. 管理>プラグインからRedmine Q&A plugin (Light version)があることを確認します。
  3. ロールと権限から、アクセス権を適切に設定します。(Questionの項目です)
  4. 任意のプロジェクトの設定を開きます。
  5. モジュールからQuestionを有効にして保存します。
  6. タブとヘッダに「Help & Support」があることを確認します。
  • 英語メニューですが、「+ New question」などで追加、編集が可能です。

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コマースか否か

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

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

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

Redmineへの不正ログインをfail2banで制御する。

概要

インターネット環境にあるRedmineを不正ログインから防ぐため、不正ログイン対策パッケージfail2banと連携させました。

参考としたURL

https://www.redmine.org/projects/redmine/wiki/HowTo_Configure_Fail2ban_For_Redmine

環境

2023年1月現在、以下の環境で動かしています。

  • AWS Lightsailに立てているUbuntu20.04インスタンス

前提(導入済みパッケージ)

以下、既に導入済みです。

  • Redmine 4.2
  • fail2ban 0.11.1

本記事ではproduction.logの格納場所を

/var/log/redmine/production.log

としています。ご自身の環境に合わせてください。(通例は/var/lib/redmine/log の場合が多いです)

手順

さっくりとした手順

  1. fail2banの設定ファイルにredmine用の設定ファイルを作成します。
  2. jail.localファイルに上記設定ファイルを読み込ませます。(ファイルに追記します)
  3. fail2banサービスを再起動します。

稼働サービス(fail2ban)に修正を加えるので、必ずバックアップは取りましょう。

詳細手順

redmine用の設定ファイルを作成します。

cat <<- __EOF__ | sudo tee -a /etc/fail2ban/filter.d/redmine.conf
# redmine configuration file
#
# Author: David Siewert
#
# $Revision$
#
[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

datepattern = %%Y-%%m-%%d %%H:%%M:%%S %%Z$
failregex = Failed [-/\w]+ for .* from <HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

# Source:
#http://www.fail2ban.org/wiki/index.php/MANUAL_0_8
__EOF__
作成確認
ls -l /etc/fail2ban/filter.d/redmine.conf
# rootユーザで上記ファイルが作成されていることを確認します。

jail.localファイルのバックアップを取ります。

sudo cp -pi /etc/fail2ban/jail.local /etc/old/jail.local.$(date +%Y%m%d)
# バックアップの格納ディレクトリは自分の環境に合わせます。

diff -u /etc/fail2ban/jail.local /etc/old/jail.local.$(date +%Y%m%d)
# バックアップ元とバックアップ先の差分が無いことでバックアップが取れていることを確認します。(何も返ってこなければ正常にバックアップできています)

jail.localファイルに追記を行います。

cat <<- __EOF__ | sudo tee -a /etc/fail2ban/jail.local

[redmine]
enabled  = true
filter   = redmine
port     = 80,443
#backend  = polling
# 動作がうまくいかない場合は上記「backend」をコメントアウトしてください。
action   = iptables-allports[name=redmine]
logpath  = /var/log/redmine/production.log
# production.logの格納位置です。ここは自分の環境に合わせます。
maxretry = 3
# ログイン試行に3回失敗した場合、アクセスを拒否します。
findtime = 86,400
# 1日アクセスを禁止します。
bantime  = 20
# ログイン試行の判定です
# トータルで「20秒の間、ログインに3回失敗したときに1日アクセスを禁止する」設定です
__EOF__

追記した内容の差分を確認します。

diff -u /etc/old/jail.local.$(date +%Y%m%d) /etc/fail2ban/jail.local
差分内容
+
+[redmine]
+enabled  = true
+filter   = redmine
+port     = 80,443
+#backend  = polling
+# 動作がうまくいかない場合は上記「backend」をコメントアウトしてください。
+action   = iptables-allports[name=redmine]
+logpath  = /var/log/redmine/production.log
+# production.logの格納位置です。ここは自分の環境に合わせます。
+maxretry = 3
+# ログイン試行に3回失敗した場合、アクセスを拒否します。
+findtime = 86,400
+# 判定失敗時、1日アクセスを禁止します。
+bantime  = 20
+# ログイン試行の判定です
+# トータルで「20秒の間、ログインに3回失敗したときに1日アクセスを禁止する」設定です。

設定ファイルの動作確認を行います。

まず、自分のredmineのログイン画面でわざとログインを失敗させます。

このとき、

cat /var/log/redmine/production.log |grep Failed
# production.logのパスは自分の環境に合わせます。

とすることで、

Failed login for 'ユーザ名' from IPアドレス at 2023-01-01 00:00:00 UTC

のように、失敗させたときのログが表示されます。

次に、

fail2ban-regex /var/log/redmine/production.log /etc/fail2ban/filter.d/redmine.conf
# production.logのパスは分の環境に合わせます。

を実行します。

Results
=======

Failregex: 1 total
|-  #) [# of hits] regular expression
|   1) [1] Failed [-/\w]+ for .* from <HOST>
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [2] Year-Month-Day 24hour:Minute:Second Zone name$
`-

Lines: 4281 lines, 0 ignored, 1 matched, 4280 missed
[processed in 0.08 sec]

と、ログイン失敗時の行数分「X matched」と表示されます。これで、設定ファイルとログのパス設定に問題がないと確認が取れました。

設定を反映します。

sudo systemctl restart fail2ban.service

systemctl status fail2ban.service
#active (running)であることを確認します。

以上で、設定は完了です。

mod_securityが検知した不審なアクセスをufwで一括遮断。

あらまし

apacheにmod_securityを導入後、以下を実施しました。

  1. Mod_Securityが検知した不審なアクセスのうち、IPアドレスのみを抜き出す
  2. その抜き出したIPアドレスをMod_securityによってブロックする
  3. これを日次で追加していく

この方法はそこそこうまくいっています。ですが、「これら不審なアクセス元はWebだけでの攻撃だけか? メールやSSHへの攻撃もしているだろう」と思い立ち、不審なアクセスを元から絶つ方法を採りました。

環境

AWS Lightsailで以下を動かしています。

  • Ubuntu 20.04
  • いわゆるLAMP環境

前提

以下が準備済みです。

  • Mod_Security導入済み
  • 前述したmod_securityから不審なアクセス元のみを抜き出したIPアドレスのリストがある
    • このリストをnegativelist.txtとして用意しています。
リスト形式
192.168.0.1
192.168.1.123

のように、一行ずつIPアドレスだけが記述されているファイルです。

さっくりとした手順

  1. ufwを有効化します。
  2. 不審なアクセス元のIPアドレスのみを抜き出したnegativelist.txtを一行ずつ読み込みアクセスを遮断するシェルスクリプトを作成します。
  3. 作成したスクリプトを実行します。

実行の前の注意事項

  • 自環境のアクセスが遮断される可能性があることに注意してください。
  • 事前にスナップショットやバックアップを取り、失敗した時に備え切り戻しができる準備を強く推奨します
  • この方法によりアクセスができなくなった等に対し、筆者は責任を負いかねます。

手順

全て管理者権限で実施しています。

ufwがインストールされていることを確認します。(導入済みの場合はスキップ)

apt list ufw
#  [インストール済み] となっていることを確認します。

ufwを有効化します。(導入済みの場合はスキップ)

ufw enable

許可するサービスを指定します。(導入済みの場合はスキップ)

ufw limit ssh
# 連続したSSHアクセスを遮断します
ufw allow http
ufw allow https
# その他の許可するサービスは必要に応じて指定してください

この段階で、以下を確認します。

  • ターミナルクライアントからSSH接続ができること
  • 既存のサービスが外部NWからアクセスできること

サービス確認

ufw status
実行例
状態: アクティブ

To                         Action      From
--                         ------      ----
22                         LIMIT       Anywhere                  
80                         ALLOW       Anywhere                  
443                        ALLOW       Anywhere                  
22 (v6)                    LIMIT       Anywhere (v6)             
80 (v6)                    ALLOW       Anywhere (v6)             
443 (v6)                   ALLOW       Anywhere (v6)             

シェルスクリプトを作成します。

vi /hoge/add_ufw.sh
スクリプト内容
#!/bin/bash

# UFWを念のため事前に有効化します
ufw enable

# ファイルに書かれたIPアドレスを一行ずつ読み込みアクセスを遮断します。
while read line; do
    ufw deny from $line
# 読み込むファイルを指定します
done < /path/to/negativelist.txt

シェルスクリプトに実行権限を与えます。

chmod +x /hoge/add_ufw.sh

シェルスクリプトを実行します。

./hoge/add_ufw.sh
# 行数によっては相当な時間がかかります

実行後の確認を行います。

ufw status
実行例(抜粋)
Anywhere                   DENY        192.168.0.1              
Anywhere                   DENY        192.168.1.111              

まとめ

これで、「Webサイトに対して不審なアクセスを行ったIPをまるごと遮断する」ことが可能になりました。相当乱暴な方法ではあることにご注意ください。

AWS LightsailでのUbuntu20.04立ち上げとUbuntu22.04へのアップグレード。

概要

定額でAWSのインスタンスを利用できるLightsail。

Ubuntu系OSを利用できるものの、2022年12月時点ではUbuntu22.04に対応していません。

20.04は選べますので、

  1. Ubuntu20.04で新たなインスタンスを立ち上げる
  2. Ubuntu22.04にアップグレードする

方法を紹介します。

どハマりしたこと

結論を言うと、Ubuntu 22.04にアップグレードするとLigtsailの管理画面から直接SSHすることはできません。
(SSH-1アルゴリズムによるRSA認証が無効化されます)

つまり、 何も設定せずWeb画面のSSH接続で最初にアップグレードをすると、再起動した瞬間にログインできず詰みます。

これに気づかず、アップグレード後に全くログインできずインスタンスを作り直す羽目になりました。以下はメモとして残しておきます。

成功した手順(さっくりした手順)

以下、ある程度の知識がある方ならこの手順を行えば問題ないと思います。

  1. Lightsail上でUbuntu 20.04のインスタンスを立ち上げる。
  2. 静的IPを付与してIPを固定化する。
  3. 必要に応じてDNSレコードに登録する。
  1. Lightsail管理画面から初期ユーザーでログインする。
  2. 初期ユーザー以外のrootに昇格可能なユーザーを作成する。
  3. そのユーザーで強力な暗号による秘密鍵/公開鍵を設定する。
  4. Ubuntu 20.04 → 22.04にアップグレードする。

成功した手順(より詳細な記述)

インスタンスの作成

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

https://lightsail.aws.amazon.com/ls/webapp/home/instances

「インスタンスの作成」をクリックします。

インスタンス作成

自分は以下のように選択しました。

  • リージョン:東京
  • インスタンスイメージの選択:Linux (OSのみ)
  • Ubuntu 20.04 LTSを選択。
  • 月次料金:10USD/月
  • インスタンス名:任意のもの
  • そのほかは空白

→設定後、「インスタンスの作成」をクリックします。
 → 作成後、「ネットワーキング」から静的IPを付与します。
  → 必要に応じてDNSを設定し、名前解決できるようにします。

管理画面のWebコンソール(SSH)操作

Web画面からログインし、rootに昇格します。

sudo su -
# この時、パスワードは設定されていないのでそのまま昇格できます。

ここから、ローカルのターミナルクライアントから接続できるようにユーザーを作成し、設定します。

ここではhogeとしていますので、任意のユーザーを指定して下さい。

adduser hoge
# パスワードなどを設定します

usermod -G sudo hoge
# ユーザーhogeを管理者グループに入れます

su - hoge
# ユーザーhogeに変われることを確認します

sudo su -
# パスワード入力後にrootに昇格できることを確認します

exit
# ユーザーhogeに戻ります

whoami
# ユーザーhogeであることを確認します

ssh-keygen -t ed25519
# 鍵の格納場所は初期値でいいので空Enter。(/home/hoge/.ssh/
# パスワードを設定します。

cd .ssh
ls -l
# 以下のファイルを確認します
# └id_ed25519
# └id_ed25519.pub
# ※これらのファイルはscp等で自分のクライアントにコピーします

rm id_ed25519
# sshサーバ上でそのまま鍵を作成したので秘密鍵は*クライアントにコピー後*削除します

mv id_ed25519.pub authorized_keys
chmod 600 authorized_keys
# 公開鍵をauthorized_keysに変更し、パーミッションを厳密にします

この後、ローカルにコピーしたid_ed25519をSSHターミナルクライアントに保存して設定し、接続確認を行います。

接続ができたらいよいよUbuntu 20.04→Ubuntu22.04へのアップグレードです。

ローカルPC(ターミナルクライアント)からの操作

whoami
#上記、作成したユーザーであることを確認します

sudo su -
# rootに昇格できることを確認します

apt update && apt upgrade && apt autoremove
# パッケージを最新版にして不要パッケージを削除します。途中で不要パッケージを消すかを求められるので[y]で消去します

reboot
# 一度再起動をします
# 再起動後、ログインします

Ubuntu20.04→22.04へのアップグレード

whoami
#上記、作成したユーザーであることを確認します

sudo su -
# rootに昇格できることを確認します

do-release-upgrade
# *ここからの作業は中断せず、一気通貫で行います*
アップグレード中にプロンプトから質問されたこと

以下、主要な質問事項です。コメント(#の後)に概要を書いています。

Reading cache

Checking package manager

Continue running under SSH?

This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.

If you continue, an additional ssh daemon will be started at port
'1022'.
Do you want to continue?

# SSHのポートを追加するか
# → y

Starting additional sshd 

To make recovery in case of failure easier, an additional sshd will 
be started on port '1022'. If anything goes wrong with the running 
ssh you can still connect to the additional one. 
If you run a firewall, you may need to temporarily open this port. As 
this is potentially dangerous it's not done automatically. You can 
open the port with e.g.: 
'iptables -I INPUT -p tcp --dport 1022 -j ACCEPT' 

To continue please press [ENTER]

# 設定を変更するか
# → Enter

Do you want to start the upgrade?


4 packages are going to be removed. 85 new packages are going to be
installed. 555 packages are going to be upgraded.

You have to download a total of 247 M. This download will take about
49 seconds with a 40Mbit connection and about 6 minutes with a 5Mbit
connection.

Fetching and installing the upgrade can take several hours. Once the
download has finished, the process cannot be canceled.

 Continue [yN]  Details [d]

# アップグレード前の最終確認
# → y

There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded. Since these restarts may cause interruptions of service for the system, you will     x
   x normally be prompted on each upgrade for the list of services you wish to restart.  You can choose this option to avoid being prompted; instead, all necessary restarts will be done for you automatically so you can avoid being   x
   x asked questions on each library upgrade.                                                                                                                                                                                            x
   x                                                                                                                                                                                                                                     x
   x Restart services during package upgrades without asking?

# アップグレード時、各種サービスを再起動前にプロンプトでy/nを確認するか
# → 質問されるのがめんどいので yes

# この間、SSH等の設定変更を行うか訊いてきます。プロンプトの選択を変えずに先に進みました
# keep the local version currently installed

Remove obsolete packages? 

# 不要パッケージの削除
# → Yes

System upgrade is complete.

Restart required

To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.

Continue [yN]

# アップグレード完了後にリブートするか
# → y

こうして、再起動後、無事にアップグレードが完了です。

cat /etc/lsb-release

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"

アップグレード後の操作

以下、速やかに行います。

管理者に昇格できることを確認します。

sudo su -

rootのパスワードを設定します。

passwd root

初期ユーザー(ubuntu)が物理的にログインできないようにします。

cd /home/ubuntu/.ssh

rm authorized_keys

chatGPTが作成したシェルスクリプト。

こちらにより、apacheのバーチャルファイルをAIで作成できると知り、そこから更に発展させました。

作成して欲しいと思った機能

こちらのスクリプトで抜き出したIPアドレスを、

  • 10.0.0.0/24
  • 10.3.3.0/24
  • 172.28.3.0/24
  • 192.168.1.0/24

のように、ネットワークアドレスにした上でNWごとにブロックできないかと思い立ち、その前段として「IPをソートしてネットワークアドレスを付与できないか」

と、以下のようにして書いてもらいました。

AIへの質問

192.168.1.3
192.168.1.2
10.0.0.2
10.3.3.2
10.3.3.254
172.28.3.4
172.28.3.5

などのIPアドレスが書かれたテキストファイルip.txtがあります。

これを読み込んだ後にソートして

192.168.1.0/24
192.168.1.0/24
10.0.0.0/24
10.3.3.0/24
10.3.3.0/24
172.28.3.0/24
172.28.3.0/24

とネットワークアドレスに変換後、

10.0.0.0/24
10.3.3.0/24
172.28.3.0/24
192.168.1.0/24

と重複を排除し、アドレスごとに改行した上でnetwork.txtに出力するシェルスクリプトを書いてください。

AIの回答

以下のようなシェルスクリプトを作成することで、指定した要件を満たすことができます。

#!/bin/bash

# ip.txtを読み込んで、1行ごとに処理する
while read line; do
  # IPアドレスを/24のサブネットマスクで分割する
  network=$(echo "$line" | cut -d "." -f 1-3).0/24

  # 分割したサブネットアドレスを出力する
  echo "$network"
done < ip.txt | sort | uniq > network.txt

上記のスクリプトでは、ip.txtを読み込んで1行ごとに処理しています。

その後、cutコマンドを使用して、IPアドレスを"."で分割し、最初の3つのフィールドを取り出します。

最後に、取り出したフィールドに".0/24"を追加して、サブネットアドレスを生成します。

生成したサブネットアドレスをsortコマンドでソートし、uniqコマンドで重複を除外した上で、network.txtに出力するようにしています。

作成結果

以下、作成しました。

vi script.sh
# 上記のスクリプトを貼り付けて保存
chmod +x script.sh
# 平行してIPアドレスを抜き出したip.txtを用意します
./script.sh

で、予想通りの出力が得られました。

後は少しずつ応用していけば、まるごとブロックしたり他のセキュリティソフトとの連携も可能になります。

Ubuntu 22.04でZabbix 6.2(MySQL/nginx構成)を設定するときにハマったこと。

以下の環境でZabbixを導入してみましたが、いくつかハマったことがあったのでメモを残しておきます。

導入した環境

  • Ubuntu 22.04
  • 導入しようとしたZabbix : 6.2
  • MySQL / nginx構成
  • 他サービス未導入(OSインストールと初期設定を終えたのみです)
  • ドメイン登録済みです。
  • ワイルドカードSSL証明書を発行済みです。

導入手順(ハマりポイント込み)

前提

  • 全て管理者権限で実施しています。
  • パッケージ管理は基本的にaptitudeを利用しています。
  • ローカルNWで設定しているのでufwなどは考慮していません。

参考URL

Zabbixレポジトリを追加してインストールします。

aptitude update
aptitude upgrade
wget https://repo.zabbix.com/zabbix/6.2/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.2-1+ubuntu22.04_all.deb
dpkg -i zabbix-release_6.2-1+ubuntu22.04_all.deb
aptitude update
aptitude install zabbix-server-mysql zabbix-frontend-php zabbix-nginx-conf zabbix-sql-scripts zabbix-agent

MySQLの初期設定

aptitude install mysql-server
systemctl start mysql
systemctl enable mysql

必要に応じて: mysql_secure_installation

参考 https://level69.net/archives/28557
vi /etc/mysql/mysql.conf.d/mysqld.cnf
追記内容
#末尾に以下を追加
default_authentication_plugin=mysql_native_password

設定後にmysqlサービス再起動

systemctl restart mysql

MySQL rootパスワード設定

mysql -u root -p
# 未設定のためパスワードは不要です
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'パスワード';
#パスワードは任意のものを入力ください
flush privileges;
exit

mysql初期設定

mysql_secure_installation
初期設定内容
Enter password for user root: 
# 上記で設定したパスワードを入力します

VALIDATE PASSWORD COMPONENT can be used to test passwords
and improve security. It checks the strength of password
and allows the users to set only those passwords which are
secure enough. Would you like to setup VALIDATE PASSWORD component?

Press y|Y for Yes, any other key for No: 
# Yを入力してEnter

There are three levels of password validation policy:

LOW    Length >= 8
MEDIUM Length >= 8, numeric, mixed case, and special characters
STRONG Length >= 8, numeric, mixed case, special characters and dictionary                  file

Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG:
# ポリシーに合わせて0/1/2を入力(ローカル環境のため0としました)

Estimated strength of the password: 50 
Change the password for root ? ((Press y|Y for Yes, any other key for No) : 
# 既に設定しているのでn

By default, a MySQL installation has an anonymous user,
allowing anyone to log into MySQL without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother.
You should remove them before moving into a production
environment.

Remove anonymous users? (Press y|Y for Yes, any other key for No) : 
# anonymousユーザーを削除するためY

Normally, root should only be allowed to connect from
'localhost'. This ensures that someone cannot guess at
the root password from the network.

Disallow root login remotely? (Press y|Y for Yes, any other key for No) : 
# rootユーザのリモートログインを禁止するためY

Remove test database and access to it? (Press y|Y for Yes, any other key for No) : 
# テストDBを削除するためY

Reload privilege tables now? (Press y|Y for Yes, any other key for No) : 
# 設定を反映するためy

MySQLでZabbix用のユーザーを作成

mysql -uroot -p
# 上記で設定したパスワードを入力します
CREATE DATABASE zabbix character set utf8mb4;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'パスワード';
# 任意のパスワードを設定
GRANT ALL ON redmine.* TO 'zabbix'@'localhost';
flush privileges;
exit

ハマりポイント1:SQL実行時にエラーが出る

ERROR 1419 (HY000) at line 2123: You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

と出たので、設定をしておきます。

対処方法
mysql -uroot -p

rootでmysqlにログイン後、以下を実行します。

SHOW VARIABLES LIKE 'log_bin_trust_function_creators';
# OFF を確認
set global log_bin_trust_function_creators=1;
# 設定を有効化
 SHOW VARIABLES LIKE 'log_bin_trust_function_creators';
 # ONを確認

ハマりポイント2: インポート用SQLが存在しない(正しい手順を後述)

Webサイトの手順によると、

zcat /usr/share/doc/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix

とありますが、該当ディレクトリにmysql用のSQLが存在しません。

対処方法
apt reinstall zabbix-sql-scripts

として、sqlを再インストールします。

updatedb
 locate server.sql.gz
 →  /usr/share/zabbix-sql-scripts/mysql/server.sql.gz

SQLをインポートします。

zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix
# zabbixのDBパスワードを入力します。

Zabbixの設定を行います。

vi /etc/zabbix/zabbix_server.conf
追記/編集内容
DBName=zabbix
DBUser=zabbix
DBPassword=zabbix

nginx用のconfファイルを設定します。

vi /etc/zabbix/nginx.conf
編集内容
        listen          443 ssl http2 default_server;
        # ポートを443のみで受け付けるようにします。
        server_name     ドメイン名;

        ssl_certificate "/SSL証明書と中間証明書を結合したファイル";
        ssl_certificate_key "秘密鍵ファイル";
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers "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:ECDHE-RSA-AES128-SHA";
        ssl_prefer_server_ciphers off;
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout 10m;

設定内容を確認します。

nginx -t
# Syntax OKを確認します

設定内容を反映します。

systemctl restart zabbix-server zabbix-agent nginx php8.1-fpm
systemctl enable zabbix-server zabbix-agent nginx php8.1-fpm

セットアップ確認

ブラウザから

https://ドメイン名/setup.php

が表示されれば問題ないです。その後、Next Stepに進んでください。

Page 18 of 24

Powered by WordPress & Theme by Anders Norén