タグ: Linux Page 25 of 33

サイトのSSL強化。(HSTSプリロード)

概要

サイトのセキュリティを高めるため、HSTSプリロードを設定したときのメモとなります。

環境

  • OS: Ubuntu 20.04
  • Apache 2.4系
  • Let's Encryptで取得した証明書を利用

前提条件

  1. インターネット上に公開されたサイトであること。(非ローカル環境)
  2. 公開するWebサイトドメイン全てに適切な証明書が設定されていること。
  3. Webサーバの設定で、httpアクセス全てをhttpsに変換する設定になっていること。
  4. 必要なモジュール(header、SSL等)がインストールされていること。

ここでは、hoge.example.com というサイトに対してHSTSプリロードを設定します。

注意点

  • サブドメイン全てに対して適用されます。(hoge.example.comの場合はwww.example.comはもちろん、example.comも対象となることを注意してください)
  • https化されていないサイトに対してもhttps接続を強制します。つまり、他にhttps化されていないシステムに対してもです。
  • プリロードリストに登録された場合、解除はとても難しくなります。相応の運用が試されることに注意してください。

さっくりとした手順

  1. HSTSを有効にします。
  2. httpdサービスを再起動します。
  3. HSTSサイトにドメインを登録します。

実施手順

apacheのバーチャルサイトファイルを修正します。

  • 修正後のファイル

※ドメインやDocumentRoot等は書き換えてください。また、サブドメインごとに複数のサイトがある場合、その全てを修正します。

<VirtualHost _default_:80>
servername hoge.example.com
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost _default_:443>
    servername hoge.example.com
    ErrorLog /var/log/apache/error.log
    CustomLog /var/log/apache/access.log combined

DocumentRoot /var/www/html/hoge

    <Directory /var/www/html/hoge>
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>

  SSLEngine on
    Protocols h2 http/1.1
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

SSLCertificateFile /etc/certs/hoge.example.com.crt
SSLCertificateKeyFile /etc/private/hoge.example.com.key

</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: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
  • 主な差分
-    Header always set Strict-Transport-Security "max-age=63072000"
+    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

-SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
+SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
  • HSTSのプリロードを有効化しています。
  • ついでに弱いSSL(TLSv1.2)を無効化します。

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

sudo apache2ctl configtest
# Syntax OKを確認します
sudo systemctl restart apache2.service

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

HSTSプリロードサイトへの登録

  1. https://hstspreload.org/ にアクセスします。
  2. 上記で設定したドメイン名を入力して登録を進めていきます。(サブドメインは含みません)
  3. エラーがなければStatus: laplacemine.com is pending submission to the preload list.と表示されます。
  4. 2~3週間ほど待って正式に登録されるのを待ちます。

設定確認

  1. https://www.ssllabs.com/ssltest にアクセスします。
  2. HSTSを設定したサイトのドメイン名を入力して診断します。
  3. Strict Transport Security (HSTS) が「YEえs」となっていれば成功です。

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

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

Let’s Encryptの証明書をRSA方式で更新。

以前ご案内した、Let's Encryptのデフォルト暗号化形式がデフォルトでECDSA方式に変更されたという話。

ただ、サーバの環境によっては、この暗号化形式をサポートしていない事があります。(ワイルドカード証明書を様々なサーバに適用するケースでありがちです)
本来ならばサーバそのもののバージョンアップを図るべきでしょうが、運用によってはままならず。

そんなときにLet's Encryptの暗号化を従来のRSA方式に変える方法をメモしておきます。

前提

  • Let's EncryptでSSLを利用している。
  • 適用するサーバがECDSA方式の暗号化形式に対応していない。

作業手順

Let's Encrypt(Certbot)サーバで実施します。

ここでは、

  • hoge.example.com ドメインのワイルドカード証明書を取得し
  • 有効期限前にhoge@example.com宛にメールを送付する

として手順を示します。

証明書更新

sudo certbot certonly --manual -d\
*.hoge.example.com\
 -m hoge@example.com\
 --agree-tos --manual-public-ip-logging-ok\
 --key-type rsa --preferred-challenges dns-01
# ディレクトリやメールアドレスは自身の環境に合わせます。
# --key-type rsa を明示します

この後、DNSでTXTレコードを設定するよう求められるので、それに従いDNSの所有権を確認します。

確認されたら証明書は更新されます。

証明書と鍵の整合性確認

openssl x509 -pubkey -in /etc/letsencrypt/live/hoge.example.com/cert.pem -noout | openssl md5
(stdin)= ハッシュ値
# SSL証明書ファイル

openssl pkey -pubout -in /etc/letsencrypt/live/hoge.example.com/pprivkey.pem | openssl md5
(stdin)= ハッシュ値
# 秘密鍵ファイル

## Let's Encryptで指定されたディレクトリや証明書・秘密鍵を指定してください
## 2つのハッシュ値が合っていれば証明書と秘密鍵の整合性は取れています

証明書の鍵方式確認

openssl rsa -text -noout -in /etc/letsencrypt/live/hoge.example.com/pprivkey.pem
# 正常に表示されればRSA方式で暗号化されています

後は、指定したディレクトリの証明書や秘密鍵を適切に他サーバに適用します。

Redmineの不正アクセス対策。(ufwと二段階認証)

概要

AWS Lightsailに構築しているRedmine。 不審なアクセスがあったので対応を行いました。

アクセスの内容

とてもシンプルに、チケットの新規発行画面に何回もアクセスしているというもの。

正規のリクエストなのでWAFでブロックされません。(解析システム:matomoで検知した次第です)

そもそも自分しかアカウントを用意していないため、この時点で不正アクセスの兆候だと判断。以下、対処を行います。

ufwでの処理

  • ufwによるブロック
sudo ufw deny from IPアドレス
# より確実を期すためにIPアドレスのネットワークアドレスを指定しました (xxx.xxx.xxx.0/24)
  • 設定確認
sudo ufw status numbered
# Anywhere DENY IN 上記で指定したIP/ネットワークアドレスを確認します
  • 設定反映
sudo ufw reload
# ファイアウォールを再読込しましたと出れば反映完了です

これでひとまず不審なアクセス元は遮断。

Redmineログイン強化

筆者が用いているRedmine4.2は二段階認証が標準で備わっていますので、それを有効化します。

  1. Redmineに管理者権限でログインします。
  2. 万一に備えて別のブラウザでもログインしっぱなしにします。
  3. 管理>設定>認証に移動します。
  4. 二段階認証を「必須」にして保存します。

その後、(別ブラウザでログインしたまま)Redmineにログイン。

後は二段階認証プロセス(Google認証システムを用いました)で指示に従ってQRコードを読み込み、生成されたコードを読み込むだけ。

ひとまず、これでID/PWによるログインに加えて認証システムの二段階で不正アクセスの被害を抑えます。

growi v6.0.15 → v6.1.0へのバージョンアップ後の処理。

結論から始まる概要

「リリースノートはよく読んでおくこと」

です。

Growi v6.1.0の変更点

バージョンアップ後、今まで表示されていた画像がうまく表示されない問題点がありました。

どうしたものかと更新情報を読み返したら

https://docs.growi.org/ja/admin-guide/upgrading/61x.html#%E7%AE%A1%E7%90%86%E8%80%85%E5%90%91%E3%81%91

と思いっきり書かれておりました。

では、GrowiをインストールしたLinuxサーバで対処を行います。

前提

  • Growi v6.1.0にバージョンアップした
  • 添付ファイルをローカルに保存

が作業の前提です。また、

  • Ubuntu 20.04
  • ディレクトリは'/opt/growi'

となっています。

実施した手順

Growiインストールディレクトリに移動

cd /opt/growi/packages/app/public/uploads && pwd
# 上記ディレクトリにいることを確認します。

添付ファイルディレクトリを移動

sudo mv attachment /opt/growi/apps/app/public/uploads/
sudo mv user /opt/growi/apps/app/public/uploads/

移動確認

cd /opt/growi/apps/app/public/uploads/ && pwd
# 上記ディレクトリにいることを確認します。

ls -l attachment
ls -l user
# 移動したディレクトリがあることを確認します。

作業後の確認

バージョンアップ前に投稿した添付ファイルがある記事で、ファイルが表示されていることを確認しました。

growi v6.0.15 → v6.1.0へのバージョンアップでハマったこと。

概要

日々の記録に、ブログ/redmineの下書きに、思考の整理にと役立っているgrowi。

https://github.com/weseek/growi/releases/tag/v6.1.0

で、growiの新しいバージョンを確認したので実施しましたが、ハマりましたのでメモとして残します。

アップデートした環境

  • growi 6.0.15
  • Ubuntu 20.04
  • mongodb 4.4.13
  • node 14.21.3 (後述するバージョンアップによりv18.16.0)

また、以下を実施済みです。

実施手順

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

こちらに沿って実施しました。

  1. growiのサービスを停止します。
  2. gitコマンドで最新版を引っ張ります。
  3. アップグレードを行います。
  4. growiのサービスを再開します。
  5. アップグレードされたことを確認します。

ハマったこと1:nodeのバージョンが合わない

  • 実行コマンド
sudo yarn
  • エラー
[1/5] Validating package.json...
error growi@6.1.0: The engine "node" is incompatible with this module. Expected version "^16 || ^18". Got "14.21.3"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

とあったので、nodeのバージョンアップが必要でした。

ハマったこと1への対処

以下の記事で、最新安定版のnode.jsに差し替えました。

https://manualmaton.com/2023/03/15/

nodeのアップデート後、正常にyarnを行うことができました。

ハマったこと2: 起動スクリプトが動作しない。

sudo systemctl start growi.service

を実行しても起動せず。

systemctl status growi.service

で状況を確認します。

/bin/sh: 1: turbo: not found

というエラーが出ました。

ハマったこと2への対処

1への対処時、付随するnpmパッケージを削除したことが原因です。

sudo npm install -g turbo

として、再度

sudo systemctl start growi.service

を実行。

systemctl status growi.service

起動を確認しました。

実行後

このバージョンアップは是が非でも行いたいものでした。

なぜなら、念願のmermaid.jsが実装されたからです。

これで、別のアプリを起動せず、growiのみでのmermaid記法が楽になりました。

Nextcloud管理画面での警告対応。(occ実行)

概要

Nextcloudをバージョンアップ後、以下のような警告が管理画面で出てきました。

セットアップに関して警告がいくつかあります。
データベースにいくつかのインデックスがありません。 大きなテーブルにインデックスを追加すると、自動的に追加されないまでに時間がかかる可能性があるためです。 "occ db:add-missing-indices"を実行することによって、インスタンスが実行し続けている間にそれらの欠けているインデックスを手動で追加することができます。 インデックスが追加されると、それらのテーブルへのクエリは通常はるかに速くなります。
テーブル "oc_filecache"のインデックス "fs_parent"が見つかりません。

環境

  • Ubuntu 20.04
  • PHP8.1
  • Nextcloud 26.0.1
  • Apache 2.4

での対応です。

実施内容

  • コマンド
cd /var/www/html/ && pwd
# Nextcloudのあるディレクトリに移動します
          
sudo -u www-data /bin/php occ db:add-missing-indices
# Webサービスの実行者(ここではwww-data)を指定します  
  • 処理例
Check indices of the share table.
Check indices of the filecache table.
Adding additional parent index to the filecache table, this can take some time...
Filecache table updated successfully.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Check indices of the calendarobjects_props table.
Check indices of the schedulingobjects table.
Check indices of the oc_properties table.
Check indices of the oc_jobs table.
Check indices of the oc_direct_edit table.
Check indices of the oc_preferences table.
Check indices of the oc_mounts table.

実施後

Nextcloudの管理画面でリロードを行いました。

全てのチェックに合格しました。

と出たのでOKです。

プログラム自身がチェックを行ってくれるのがNextcloudの強み。

ChatGPTによるシェルスクリプト(パッケージの自動更新)の問題点と修正。

この記事の更に続きとなります。

以前作成したスクリプトに問題点があったので修正します。

問題点詳細

アップデートするパッケージによってはコンフィグを残すか否かをアップデート中に聞いてきます。

このプロンプトが表示されるとスクリプトは停止。処理を手動で中断して実行する羽目になります。

これを回避するため、以下のように修正いたしました。

修正差分

-    aptitude -y full-upgrade | tee $upgraded_packages >/dev/null
+    DEBIAN_FRONTEND=noninteractive aptitude -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade | tee $upgraded_packages >/dev/null

修正した処理の詳細

※chatGPTの回答なので信頼性は各自ご判断ください。

  1. DEBIAN_FRONTEND=noninteractive : DEBIAN_FRONTEND 環境変数に noninteractive を設定し、aptitude コマンドを非対話モードで実行します。これにより、パッケージの更新時に表示される確認メッセージを自動的に承認することができます。
  2. aptitude -y : aptitude コマンドに -y オプションを指定して、すべての質問に対して自動的に yes を返答するようにします。
  3. -o Dpkg::Options::="--force-confdef" : dpkg コマンドに --force-confdef オプションを指定して、パッケージがインストールされる際に必要なデフォルトの設定値を使用するように指定します。
  4. -o Dpkg::Options::="--force-confold" : dpkg コマンドに --force-confold オプションを指定して、既存のコンフィグファイルを保持するように指定します。
  5. full-upgrade : aptitude コマンドの full-upgrade オプションを指定して、すべてのパッケージを最新バージョンに更新します。
  6. | tee $upgraded_packages >/dev/null : 更新されたパッケージのリストを一時ファイルに保存します。パイプライン演算子 | を使用して、aptitude コマンドの出力を tee コマンドに送信し、同時に一時ファイルに書き込むように指定します。>/dev/null を追加することで、標準出力を無効化し、結果を表示しないようにします。

修正後のスクリプト全文

#!/bin/bash

# インストールされているパッケージの一覧を取得して別ファイルに出力します。
now1=$(date +%Y%m%d)
dpkg-query -W > installed_packages_$now1.txt

# aptitude updateを行います。
aptitude update

# updateの結果:
if aptitude search '~U' | grep -q '^i'; then
    # 対象パッケージ,変更前バージョン,変更後のバージョン を記入した日付付きのファイルを作成。
    now1=$(date +%Y%m%d)
    upgraded_packages=$(mktemp)

    # パッケージのキャッシュをクリアした上でパッケージアップグレードを実施。
    aptitude clean
    DEBIAN_FRONTEND=noninteractive aptitude -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade | tee $upgraded_packages >/dev/null

    # パッケージ一覧からの差分を別ファイルで作成。(実行日の日付を付与)
    new_packages=$(mktemp)
    dpkg-query -W > $new_packages
    diff -u installed_packages_$now1.txt $new_packages > package_diff_$now1.txt

   # 新しいパッケージ名を取得
   DIFF_FILE="package_diff_$now1.txt"
   NEW_PACKAGES=$(grep -E "^\+[^+]" $DIFF_FILE | awk '{print $1}' | cut -c 2-)

   # 変更されたパッケージの数と、新しいバージョンのパッケージ名のリストを表示
   UPDATED_PACKAGES=$(echo "$NEW_PACKAGES" | wc -l)
   echo "$UPDATED_PACKAGES 件のパッケージに変更がありました。以下のパッケージが更新されました:"
   echo "$NEW_PACKAGES"

    # checkrestartを実行して結果を取得
    now=$(date +%Y%m%d)
    checkrestart_output=$(checkrestart)

    # サービスを再起動する必要のあるプロセスを抽出してファイルに出力
    restart_services=$(echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | awk '{print $NF}' | sort -u)

    if [[ -n "$restart_services" ]]; then
        # ファイル名に日付を追加
        now2=$(date +%Y%m%d)
        filename="restart_services_$now2.txt"

        echo "以下のサービスを再起動してください:" >> "$filename"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep -v "restart$" >> "$filename"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep "restart$" >> "$filename"

        echo "以下のサービスを再起動してください:"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep -v "restart$"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep "restart$"


    else
        echo "再起動するサービスはありません"
    fi
fi

これでコンフィグを残すか否かのアップデートでも停止することなく動きましたが、肝心の

  • どのパッケージがコンフィグを残すか否か求められたか
  • その差分は何か

などが不明。なので、改善点はまだまだです。

ChatGPTによるシェルスクリプト。(外為レートの表示と記録)

概要

定額制のLightsailを利用しているとはいえ、ドルベースで請求されるので相場観は気になる数字です。

そこで、ドル円の相場をスクリプトベースで取得することにしました。

参考:

【Linux】ドル円為替情報をwgetコマンドで取得する
https://www.mtioutput.com/entry/fx-info-wget

前提

  • Ubuntu 20.04で動作を確認しています。
  • 参考先にも書いてありますが、不正アクセスと間違われないよう実行頻度などはお気をつけください。
  • また、相場観を知るためだけにこのスクリプトを作成したことを前もって強調いたします。

ChatGPTへのお伺い

以下のように訊いてみました。

以下を満たすシェルスクリプトを書いてください。

1. 以下のコマンドを実行する
wget -O - -U "" http://www.gaitameonline.com/rateaj/getrate 2> /dev/null

2. コマンド実行時の日時を取得する。

3.USDJPYを含む以下を抽出する。(以下は1のコマンド抜粋)
{"high":"132.86","open":"132.86","bid":"132.54","currencyPairCode":"USDJPY","ask":"132.55","low":"132.49"}

4. 以下のように改行して並び替える。この時、:以外の記号を取り除く。
currencyPairCode:USDJPY
open:132.86
high:132.86
bid:132.68
ask:132.69
low:132.50

4. 次のように言葉を変えて表示する。
yyyy/mm/dd hh:mm 現在のドル円相場は以下の通りです。

open:132.86
high:132.86
bid:132.68
ask:132.69
low:132.50

作成結果

そこからいくつかの質疑応答や機能追加、そして手動による修正をを繰り返しました。

最終的にできあがったのがこちらです。

  • fx_info.sh
#!/bin/bash

# fx_info.shは、外国為替相場の情報を取得し、現在のレートを表示するシェルスクリプトです。
# USD/JPYをデフォルトの通貨ペアとして使用しますが、他の通貨ペアにも簡単に変更できます。
# また、同じディレクトリに相場.csvを作成。相場の履歴を追うことも可能です。
# 参照するURLは外為オンラインの情報です。

#### 変数定義ここから #####
# 通貨ペアを変数化する。
# USDJPY=ドル円 
# EURUSD=ユーロドル
# など、以下のURLに沿ったものを指定
currency_pair="USDJPY"
#### 変数定義ここまで ####

# 1. コマンドを実行してデータを取得し、標準エラー出力を/dev/nullにリダイレクトする。
data=$(wget -O - -U "" http://www.gaitameonline.com/rateaj/getrate 2> /dev/null)

# 2. 現在日時を取得する。
date=$(date '+%Y/%m/%d')
time=$(date '+%H:%M')

# 3. 指定された通貨ペアの情報を取得する。
currency_data=$(echo "$data" | grep -o '{"high":"[0-9]*\.[0-9]*","open":"[0-9]*\.[0-9]*","bid":"[0-9]*\.[0-9]*","currencyPairCode":"'$currency_pair'","ask":"[0-9]*\.[0-9]*","low":"[0-9]*\.[0-9]*"}')

# 4. 必要な情報を取り出し、並び替える。
currencyPairCode=$(echo "$currency_data" | grep -o 'currencyPairCode":"'$currency_pair'"' | cut -d ':' -f 2 | tr -d '"')
open=$(echo "$currency_data" | grep -o 'open":"[0-9]*\.[0-9]*"' | cut -d ':' -f 2 | tr -d '"')
high=$(echo "$currency_data" | grep -o 'high":"[0-9]*\.[0-9]*"' | cut -d ':' -f 2 | tr -d '"')
bid=$(echo "$currency_data" | grep -o 'bid":"[0-9]*\.[0-9]*"' | cut -d ':' -f 2 | tr -d '"')
ask=$(echo "$currency_data" | grep -o 'ask":"[0-9]*\.[0-9]*"' | cut -d ':' -f 2 | tr -d '"')
low=$(echo "$currency_data" | grep -o 'low":"[0-9]*\.[0-9]*"' | cut -d ':' -f 2 | tr -d '"')

# 5. 結果を表示する。
echo "$date $time 現在の${currencyPairCode}相場は以下の通りです。"
echo "始値:$open"
echo "高値:$high"
echo "売値:$bid"
echo "買値:$ask"
echo "安値:$low"

## 以下はファイルに書き込むための処理。

# ファイル名を${currencyPairCode}.csvとする。
filename="${currencyPairCode}.csv"

# ファイルが存在しない場合は、ファイルにヘッダーを書き込む。
if [ ! -e "$filename" ]; then
  echo "実行日,実行時刻,相場,始値,高値,売値,買値,安値" >> "$filename"
fi

# ファイルにデータを追記する。
echo "${date},${time},${currencyPairCode},${open},${high},${bid},${ask},${low}" >> "$filename"

スクリプト作成後の処理

chmod +x fx_info.sh

スクリプト実行結果

  • スクリプト実行
./fx_info.sh
  • 実行結果
2023/03/30 13:41 現在のUSDJPY相場は以下の通りです。
始値:132.86
高値:132.86
売値:132.56
買値:132.57
安値:132.45
  • 作成されたファイル閲覧
cat USDJPY.csv
  • ファイル内容
実行日,実行時刻,相場,始値,高値,売値,買値,安値
2023/03/30,13:29,USDJPY,132.86,132.86,132.60,132.61,132.45
2023/03/30,13:31,USDJPY,132.86,132.86,132.60,132.61,132.45
2023/03/30,13:41,USDJPY,132.86,132.86,132.56,132.57,132.45

これで、ブラウザを開くことなく情報を表示することができるようになりました。

Redmine脆弱性対応。(4.2.x→4.2.10へのバージョンアップ)

これを行うきっかけ

こちらの記事:

https://blog.redmine.jp/articles/redmine-security-scanner/

で運用中のRedmineに既知の脆弱性がないかをチェックできるWebサービスの存在を知ったからでした。

で、現在のRedmineのURLを調べてみたら

E。

何度見てもEです。多少自信はあったので、この結果はその鼻っ柱を打ち砕くものでした。

そこで、現在運用中のRedmineのバージョンアップを図り脆弱性に対応します。

環境

  • Ubuntu 20.04 (AWS Lightsailで稼働中)
  • 動かしていたRedmine:4.2.9
  • Apache 2.4 / mod-passangerでRubyアプリを使用(Ruby 2.7系)
  • MySQL 8.0.3

作業に備えての前提

  • 本手順では「使用するDBの削除」を伴います。作業の際には慎重に行って下さい。
  • Webサービスを止める/何も入っていないRedmineが途中でできるため、ユーザアクセスができない状況が発生します。
  • また、筆者環境はfiles配下をクラウドストレージにマウントしています。手順は自身の環境に合わせてください。

さっくりとした手順

  1. スナップショットのバックアップ
  2. DBのバックアップ
  3. redmineのディレクトリを一度mvでリネームしてバックアップ。
  4. apache停止
  5. redmineのDBを消す。
  6. redmineのDBを新たに作る。(ユーザは全て権限があるので問題なし)
  7. apache再開
  8. ディレクトリを再作成し、新しい空のRedmineを作る。
  9. themesとpluginを再配置。filesのシンボリックリンクを貼り替える。
  10. themesとpluginを再配置した状態でDBマイグレーション。
  11. DBリストア。

データバックアップ

万一に備え、AWSからインスタンスのスナップショットを取得します。

mysqlによるDBバックアップ

mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql
# DB名やDBユーザは自信の環境に合わせます

データ退避

cd /var/lib
# Redmineが格納されているディレクトリの親ディレクトリに移動します

ls -ld redmine
# 退避対象のディレクトリがあることを確認します

sudo mv redmine redmine_$(date +%Y%m%d)

ls -ld redmine_$(date +%Y%m%d)

apache停止

ここでWebサービスを停止するのは、DBを削除するためです。

systemctl status apache2.service

sudo systemctl stop apache2.service

systemctl status apache2.service

DB削除

慎重に行って下さい。

sudo mysql -u root -p
show databases;
/* redmineのDBがあることを確認 */

drop database redmine;

show databases;
/* redmineのDBがないことを確認 */

CREATE DATABASE redmine character set utf8mb4;

show databases;
/* redmineのDBがあることを確認 */

exit

Redmine再インストール

ソースダウンロード

sudo mkdir /var/lib/redmine

sudo chown -R www-data:www-data /var/lib/redmine

sudo -u www-data svn co https://svn.redmine.org/redmine/branches/4.2-stable /var/lib/redmine
# 4.2系の最新安定版をダウンロードします

退避させたディレクトリからconfigファイルコピー

sudo cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/database.yml /var/lib/redmine/config/database.yml

cat /var/lib/redmine/config/database.yml
#中身確認

sudo cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/configuration.yml /var/lib/redmine/config/configuration.yml

cat /var/lib/redmine/config/configuration.yml
#中身確認

Redmineインストール

cd /var/lib/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

apache再開

systemctl status apache2.service

sudo systemctl start apache2.service

systemctl status apache2.service

再開後の仮パスワード作成

対象のRedmineにアクセスします。

IDとパスワードがadmin / admin に戻っている状態のため、仮パスワードを発行します。

退避したディレクトリからデータを再配置

cd /var/lib/redmine_$(date +%Y%m%d)/plugins

sudo cp -pir ./* /var/lib/redmine/plugins/
# プラグイン一式をコピーします

cd /var/lib/redmine_$(date +%Y%m%d)/public/themes

sudo cp -pir ./* /var/lib/redmine/public/themes/
# テーマ一式をコピーします

シンボリックリンク貼り替え

これは筆者の環境が

  • logディレクトリとfilesディレクトリを別の場所にリンクを張っているための措置です。
  • それ以外の場合は上述した /var/lib/redmine_$(date +%Y%m%d)からfilesやlogをコピーして下さい。
cd /var/lib/redmine

sudo rm -rf files

sudo rm -rf log

sudo ln -sf /mnt/wasabi/redmine/files files
# wasabiクラウドストレージを利用しています。

sudo chown -h www-data:www-data files

sudo ln -sf /var/log/redmine log
# ログは/var/log配下で一括管理しています。

sudo chown -h www-data:www-data log

データ再マイグレーション

プラグイン再マイグレーション

cd /var/lib/redmine

sudo -u www-data bundle install

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

apacheリスタート

systemctl status apache2.service

sudo systemctl restart apache2.service

systemctl status apache2.service

DBリストア

cd /hoge
# mysqldumpを行ったディレクトリ

mysql -h localhost -u redmine -p redmine < redmine_backup.$(date +%Y%m%d).sql
# パスワードはredmineインストール時に設定したDBユーザのものです

apacheリスタート

systemctl status apache2.service

sudo systemctl restart apache2.service

systemctl status apache2.service

動作確認

この状態でRedmineに管理者権限でログインします。手順通りなら

  • テーマ
  • 添付ファイル
  • プラグイン

などが正常に動いていると思います。

バージョンアップ後の診断

2023/03/18現在のRedmine4.2系の最新安定版:4.2.10がインストールされ、A+ と診断されました。

Page 25 of 33

Powered by WordPress & Theme by Anders Norén