カテゴリー: PC Page 23 of 51

Torの出口ノードリストからのWebアクセスを遮断する設定。(Mod_Securityとの連携)

こちらの記事の続きとなります。

Torの出口ノードリストを抽出するスクリプトと、既に稼働済みの不審なIPアドレスをブロックするスクリプトを連携させます。

前提

こちらにあるように、

  • Mod_Security導入済み
  • エラー検知時にブロックする設定をバーチャルサイトに設定済み

となります。

また、先日の記事である、

  • Tor出口ノードリストを抽出スクリプトがCron化されているものとします。

スクリプト

  • negativelist.sh
#!/bin/bash

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

# シェルスクリプトから抽出したTorの出口ノードリストを指定
tor_list_dir="/path/to/directory"  # tor_list.txtのディレクトリを指定
tor_list_file="sorted_ip_addresses$(date +%Y%m%d).txt"

# 除外するIPアドレスをファイルで指定
# 自分のNWなど、偽陽性を防ぐために記載したアドレスのリストです。
exclude_ips_file="/path/to/directory/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 -u > "$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 -u > "$log_dir/suspicious_ip_all.txt"
chown www-data:www-data "$log_dir/suspicious_ip_all.txt"

# 新たにリストに書き起こすと同時にTorの出口ノードリストを読み込んで重複を排除し、negativelist.txtに追加します。
cat "$log_dir/suspicious_ip_all.txt" "$tor_list_dir/$tor_list_file" | sort -u > /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

あとはこちらをroot権限でCron登録。

設定後の動き

以下のように動きます。

  1. 指定のログファイルからエラーとなったIPアドレスのみを抽出します。
  2. 全てのIPアドレスを統合し、重複を排除してsuspicous_ip_all.txtとして抽出します。
  3. suspicous_ip_all.txtとtor_list_fileを統合し、negativelist.txtとして作成します。(これらのIPアドレスからのアクセスに対しては全て403を返します)
  4. negativelist.txtから除外IPアドレスを取り除きます。
  5. Webサービスを再起動します。

ひとまず、WAFとの連携ができました。

IPアドレス抽出スクリプト。(Torの出口リスト)

必要があったので、スクリプトを書きました。

スクリプトの動き

  1. 公開されているTor出口リストをダウンロード。
  2. IPアドレスのみを抽出。
  3. 重複を排除してソート。

スクリプト内容

  • tor_exit_hodes.sh
#!/bin/bash

# 出口ノードリストのURL
TOR_EXIT_LIST_URL="https://check.torproject.org/exit-addresses"

# ダウンロード先ファイル名
OUTPUT_FILE="exit_nodes.$(date +%Y%m%d).txt"

# curlを使用してリストをダウンロード
curl -o "$OUTPUT_FILE" "$TOR_EXIT_LIST_URL" 

##curl -o "$OUTPUT_FILE" "$TOR_EXIT_LIST_URL" >/dev/null 2>&1
##cron処理などを行う場合はこちらを使います。

# ダウンロードが成功したかどうかを確認
if [ $? -eq 0 ]; then
  echo "Tor出口ノードリストをダウンロードしました。ファイル: $OUTPUT_FILE"
else
  echo "ダウンロード中にエラーが発生しました。"
  exit 1
fi

# IPアドレスのみを抽出し、ソートして出力
awk '/^ExitAddress/ {print $2}' "$OUTPUT_FILE" | sort | uniq | tee sorted_ip_addresses$(date +%Y%m%d).txt 

##awk '/^ExitAddress/ {print $2}' "$OUTPUT_FILE" | sort | uniq > sorted_ip_addresses$(date +%Y%m%d).txt >/dev/null 2>&1
##cron処理などを行う場合はこちらを使います。

これで、IPアドレスのみが抽出されますので、apache/nginxやFiwawall/WAFとの連携が容易になります。

今後の動き

  1. Cron化
  2. Mod_Securityとの連携

などやっていきます。

Redmineプラグイン:knowledgebaseでのリンクの張り方。

概要

Redmineプラグイン『knowledgebase』に書いた記事を他のチケットで参照したいときはままあります。

そんなときに使えるTIPSです。

Wiki Macro

https://github.com/alexbevi/redmine_knowledgebase

githubのレポジトリにリンクの張り方が書かれていました。

特記事項

  • <article_id>は http(s)://redmineのドメイン/プロジェクト識別子/knowledgebase/articles の後に書かれている数字です。
    • この数字は全プロジェクトで一意の数字が割り当てられるので、他プロジェクトで書かれたナレッジを参照できます。
    • そのプロジェクトへの閲覧権限がない場合はその限りではありません。
  • <category_id>は http(s)://redmineのドメイン/プロジェクト識別子/categories/ の後に書かれている数字です。
    • articleと同様、全プロジェクトで一意の数字が割り当てられます。
  • <>は外して、数字のみを入力します。

マクロ一覧

  • {{article(<article_id>)}}
    • 「kb#:記事名」でリンクをレンダリングします。(例:kb#1:障害手順書)
  • {{kb(<article_id>)}}
  • {{article_id(<article_id>)}}
    • 「kb#」 でリンクをレンダリングします。 (例: kb#1)
  • {{category(<category_id>)}}
    • 「カテゴリー名」でリンクをレンダリングします。

使用した例

https://atelier.reisalin.com/projects/ryza3

こちらの「概要」のように、「実績一覧」にナレッジベースの記事のリンクがあるという状態。

これで、連携を取りやすくなりました。

Ubuntu 20.04にphp-fpmを導入。

事情があったのでLAMPサーバにphp-fpmをインストールする機会があったのでメモ書きです。

動作を確認した環境

  • Ubuntu 20.04
  • php8.1
  • Apache 2.4

さっくりとした手順

  1. 必要パッケージをインストールします。
  2. apacheモジュールの調整を行います。
  3. php-fpmの設定ファイルの編集を行います。
  4. サービスの有効化を行います。

php-fpmをインストールします。

  • パッケージインストール
sudo aptitude install php-fpm
  • apacheモジュールの調整
sudo a2enconf php8.1-fpm

sudo a2dismod php8.1

sudo a2dismod mpm_prefork

sudo a2enmod mpm_event

# php-fpmと関連サービスを有効化します

sudo systemctl restart apache2

php-fpmの設定ファイルを編集します。

  • 設定ファイルバックアップ
sudo cp -pi /etc/php/8.1/fpm/php.ini /path/to/backup/php.ini.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。

diff -u /etc/php/8.1/fpm/php.ini /path/to/backup/php.ini.$(date +%Y%m%d)
# 差分がないことでバックアップを確認します。

次のファイルを教義・信仰に沿ったエディタで編集します。

  • /etc/php/8.1/fpm/php.ini
max_execution_time = 180

memory_limit = 512M

post_max_size = 200M

upload_max_filesize = 200M
# 環境に沿って合わせてください。

設定を反映します。

sudo systemctl restart php8.1-fpm

sudo systemctl enable php8.1-fpm

以上で設定は完了です。

6周目の記録。(Redmineの関連チケットのリンク)

ここにきて、ゲーム『ライザのアトリエ3』の

等をRedmineのチケットとして管理した異議が出てきました。

6周目の課題「ノーマルクエストの記録」

今回はノーマルクエストがどのタイミングで発生し、どこで受諾できるかを書いています。

ここで役立つのが、Redmineに標準で備わっている「関連するチケット」機能。

このように、「関連している」チケットに、発行済みの見聞録やらランドマークへのチケット番号を記載して追加するだけ。

こうすることで、ランドマーク(あるいはその周辺)で発生するクエスト/入手できる見聞録などを可視化。後の集会の効率化を図ります。しかも、どちらか片方に「関連している」を貼れば、もう片方へはしなくていいのも利点です。

Linuxサーバでの失敗と切り戻しと心構え。

当サイトに残しているLinuxの設定について。

多くのケースで

sudo cp -pi /etc/apache/sites-available/hoge.example.conf /path/to/backup/hoge.example.conf.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。

diff -u /etc/apache/sites-available/hoge.example.conf /path/to/backup/hoge.example.conf.$(date +%Y%m%d)
# バックアップが保存されたか、差分がないことで確認します。

と、バックアップを取っています。その重要性を書こうとしましたが、ChatGPTの方がうまく説明してくれるのではと思いプロンプトを叩いてみると、物の見事に答えてくれました。

設定変更作業を行う際に設定ファイルをバックアップし、失敗した場合にバックアップファイルから切り戻すことは非常に重要です。以下にその重要性をいくつか説明します:

  1. システムの安全性と信頼性の確保:
    サーバーの設定ファイルに誤った変更を加えると、サーバーの正常な動作に影響を及ぼす可能性があります。バックアップを取らない場合、問題が発生したときに元の状態に戻す手段がなくなり、システムの安全性と信頼性が損なわれる可能性が高まります。
  2. トラブルシューティングの助け:
    設定変更による問題が発生した場合、バックアップファイルを使用して元の設定に戻すことで、問題を解決する手助けとなります。バックアップがない場合、問題の特定や修正が難しく、システムの停止時間が延長される可能性があります。
  3. 変更履歴の記録:
    バックアップファイルを保存することにより、設定変更の履歴を確認できます。特定の変更が問題を引き起こす場合、どの変更が原因かを特定しやすくなります。これにより、同じ問題が将来的に再発するのを防ぐのに役立ちます。
  4. 開発とテストのサポート:
    バックアップファイルは、新しい機能や設定変更をテストする際にも役立ちます。変更前の設定ファイルを使用して、新しい設定が期待どおりに機能するかどうかを確認できます。
  5. バージョン管理とチーム協力:
    プロジェクトが複数の開発者や管理者によって共同管理される場合、バックアップファイルを使用することで、異なるバージョンの設定ファイルを比較し、変更を調整するのに役立ちます。

バックアップを取る際には、タイムスタンプを含む有効なファイル名を使用し、適切な場所に保存することをお勧めします。また、定期的にバックアップを更新し、システムの変更が行われるたびに新しいバックアップを作成することが重要です。バックアップと適切な設定管理は、システムの安全性と信頼性を確保するために欠かせないプラクティスです。

この事態が発生したので、設定ファイルを切り戻す際の心構え的なことを書いていきます。

エラーの事象を確認します。

  1. 本来とは意図しない動きが発生した。
  2. サイトそのものが見られなくなった。

など、設定変更時にはトラブルはつきものです。その際、まず、すぐ修正しようとせず

「今起きている現象は何か」

を記録しておきます。

  • システムログ
  • スクリーンショット
  • 概要

何でも構いません。「今の現象をありのまま記録する」が重要です。

切り戻しを実施します。

ある程度の記録が発生した後、「元の状態に戻す(切り戻し)」を行います。

冒頭の「hoge.example.conf」設定ファイルの変更中に不具合が発生した場合の切り戻し手順を示します。

  • 問題を起こした設定ファイルをコピーする

この作業は原因追及のために必要です。

sudo cp -pi /etc/apache/sites-available/hoge.example.conf /path/to/backup/ERROR_hoge.example.conf.$(date +%Y%m%d)
# バックアップしたファイルとは別の名前にしておきます。
  • 切り戻しを実施する

cp バックアップファイル 元のファイル

の順番を間違えると二次災害を生みます。

sudo cp -pi /path/to/backup/hoge.example.conf.$(date +%Y%m%d) /etc/apache/sites-available/hoge.example.conf 
  • サービスを再起動する

ここではWebサービス(apache)の再起動を行います。

sudo systemctl restart apache2.service

sudo systemctl status apache2.service
# サービス稼働を確認します。

修正前の状態であることを確認します。

証明書の更新作業だったら、「有効期限が延びていないこと」など、明確な指標があると楽です。

失敗を悔やむより

  1. どんな失敗があったかを記録する
  2. 元の状態に戻す
  3. その後で原因を考える
  4. 原因をフィードバックする

の方が、自分にとっても利用者にとっても建設的です。

Steam保存場所の変更とNextcloudの連携。

Steamが稼働しているPCの保存領域を少し減らすため、スクリーンショットの保存場所を変更しました。

Steamツールバーから「表示→スクリーンショット」へと進みます。

ゲーム中タブから「スクリーンショットの非圧縮コピーを保存する」を有効にします。

非圧縮スクリーンショットフォルダーをNextcloudの共有フォルダーに変更します。

後はゲームを立ち上げてスクリーンショットを撮影するだけ。
Nextcloudの画像ファイルに勝手に登録してくれます。

登録日時やシステムタグも登録するので便利です。

Piwigo, Webからのアップデート。

Webでのフォトアルバムアプリ、Piwigo。

https://hideout.reisalin.com/

WordPressやNewxtcloudと同じようにWeb画面上でアップデートができました。

管理者アカウントでログインし、管理>ダッシュボードにアクセスします。

「新しいバージョンのPiwigoが利用可能です」とでるのでこちらをクリック。

アップグレードをクリックします。

しばらく待ちます。

「アップデート完了」のメッセージが出たら作業は完了です。

GrowiのDB格納先を変更。(mongod.conf編集)

GrowiのDB保存先を、冗長性を持たせたディスクに移設したときのメモです。

動作を確認した環境

  • Ubuntu 20.04
  • MongoDB v4.4.13
  • Growi 6.1.14

さっくりとした手順

  1. MongoDBサービスを停止します。
  2. DBの格納ディレクトリを作成します。
  3. MongoDBの設定ファイルを編集します。
  4. MongoDBサービスを再開します。
  5. 格納ディレクトリが変わったことを確認します。

MongoDBの停止

これは確実に行ってください。でないと、作業中にDBが書き換えられ不具合が発生する可能性があります。
(共有Wikiであればなおさらです)

sudo systemctl stop mongodb

systemctl status mongodb
# inactive(dead)を確認します

新規格納ディレクトリの作成

sudo mkdir /home/mongodb
# 任意の保存ディレクトリを作成します

sudo chown -R mongodb:mongodb /home/mongodb

ls -ld /home/mongodb
# ディレクトリの所有者がmongodbであることを確認します

既存データのコピー

  • ディレクトリ移動
cd /var/lib/mongodb && pwd

ll
# .wtで終わるファイルがあることを確認します
  • ファイルコピー
sudo cp -pir * /home/mongodb
# 先ほど作成したディレクトリにコピーします
  • ファイルコピー確認
cd /home/mongodb && pwd

ll
# コピーしたファイル一式があることを確認します

設定ファイル修正

  • 設定ファイルのバックアップ取得
sudo cp -pi /etc/mongod.conf /path/to/backup/mongod.conf.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。

diff -u /etc/mongod.conf /path/to/backup/mongod.conf.$(date +%Y%m%d)
# バックアップが保存されたか、差分がないことで確認します。
  • 設定ファイル編集

/etc/mongod.conf を教義・信仰に沿ったエディタで修正します。

  • 編集内容
  dbPath: /home/mongodb
  • 差分内容
-  dbPath: /var/lib/mongodb
+  dbPath: /home/mongodb

設定反映 (MongoDB再開)

sudo systemctl start mongod.service

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

設定反映確認

  • ブラウザでの確認
  1. MongoDBを利用しているアプリ(Growi)にアクセスします。
  2. 正常にアクセスできて、Wikiの閲覧や編集、作成ができることを確認します。
  • サーバでの確認
cd /home/mongodb && pwd

ls -lart
# .wtファイルの更新時刻がブラウザで編集した時と同じであることを確認します。

cd /var/lib/mongodb && pwd

ls -lart
# .wtファイルの更新時刻が操作前と同じことを確認します。

事後作業(必要に応じて)

問題なく稼働することが確認されたら、元の保存ファイルを削除(退避)させます。

NFSマウントによるサーバディレクトリのマウント。

予備で使っているUbuntuサーバ。ディスク容量が余っているのでバックアップサーバとして用いてみました。

前提

  • サーバA(メイン)とサーバB(バックアップ)が同一NW上につながっている。
  • 両方ともサーバはUbuntu。
  • サーバBの/home/backupディレクトリをバックアップとして用いる。

さっくりとした手順

  1. サーバBでNFSサーバをインストールします。
  2. サーバBでサーバAの許可設定を行います。
  3. サーバAでサーバBのディスクをマウントします。
  4. 再起動時、自動マウントできるように設定します。

NFSサーバインストール (サーバB)

sudo aptitude update
sudo aptitude install nfs-kernel-server

NFSサーバアクセス許可設定 (サーバB)

教義・信仰に沿ったエディタで以下のファイルを編集・追記します。

  • 編集するファイル
/etc/exports
  • 追記する内容
/home/backup <サーバAのIPアドレス>(rw,sync,no_root_squash,no_subtree_check)

NFSサーバの設定反映

sudo systemctl restart nfs-kernel-server

NFSクライアントのインストール(サーバA)

sudo aptitude update
sudo aptitude install nfs-common

マウントするディレクトリの作成(サーバA)

sudo mkdir /mnt/backup

サーバのマウント確認(サーバA)

  • NFSマウント
sudo mount <サーバBのIPアドレス>:/home/backup /mnt/backup
  • マウント確認
df -h
# サーバBのIPアドレス:/home/backup  と見えていれば成功です
  • ファイルの読み書きを行えるか確認
sudo mkdir test

sudo chown -R hoge:hoge test
# hogeは任意のユーザ名を指定します

cd test

touch test.txt

ls test.txt
# ファイルが表示されることを確認します

rm test.txt
ls test.txt
# ファイルが表示されないことを確認します
  • マウント解除
cd
#/mnt/backupにいるとマウント解除できません

sudo umount /mnt/backup
  • マウント解除確認
df -h
# サーバBのIPアドレス:/home/backup が消えていればマウント解除できています

fstab編集(サーバA)

サーバAを再起動しても自動的にサーバBのディレクトリをマウントできるようにします。

教義・信仰に沿ったエディタで以下のファイルを編集・追記します。

  • 編集するファイル
/etc/fstab
  • 追記する内容
<サーバBのIPアドレス>:/backup /mnt/backup nfs rw,sync 0 0

自動マウント確認(サーバA)

※サーバの再起動を行うので、作業時は注意してください。

sudo reboot
df -h
# サーバBのIPアドレス:/home/backup  と見えていれば成功です

rsyncやlsyncと違って、あたかもそのディスクがサーバ上にあるかのように扱えるのがポイントです。

もちろん、NW越しにデータの読み書きをするので、速度はNWの帯域や処理速度に依拠します。過信は禁物です。

Page 23 of 51

Powered by WordPress & Theme by Anders Norén