タグ: Ubuntu Page 8 of 15

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アドレスを指定しているなら、そこからのアクセスができないことを確認。

今後の対応

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

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

曜日を判別するmot_d。(Ubuntuシェルスクリプト)

概要

サーバにターミナル経由でログインした際に表示されるメッセージ、motd(Message of the Day)。

「特定の日時・曜日をを判別して、その条件を満たしたときにメッセージを表示することはできないか?」

ということでシェルスクリプトを書いてみました。

動作を確認した環境

  • Ubuntu 20.04

スクリプト内容

  • /etc/update-motd.d/02-Friday_Check(または既存のupdate-motdに追記します)

※管理者権限で追記する必要があります。

#!/bin/bash

# 現在の言語ロケールを保存します。
original_locale=$(locale | grep "LANG=" | cut -d= -f2)

# ロケールを英語に修正します。
export LANG="en_US.UTF-8"

# ロサンゼルス(カリフォルニア)の曜日を調べます。
day_of_week=$(TZ="America/Los_Angeles" date +"%A")

# 金曜日だった場合のみメッセージを表示します。
if [ "$day_of_week" == "Friday" ]; then
    echo "Today is Friday in California."
fi

# 元の言語ロケールに戻します。
export LANG="$original_locale"

追記後、

sudo chmod +x /etc/update-motd.d/02-Friday_Check

として、実行権限を付与してください。(既存スクリプトに追記する場合はその限りではありません)

スクリプトの動き

サーバにログインした際に

  1. 現在の言語ロケールを保存します。
  2. 言語ロケールを英語に修正します。(曜日の変数をFridayに固定しているため)
  3. タイムゾーンをチェックして、カリフォルニアで金曜日かどうかを判別します。
  4. PST(太平洋標準時)/PDT(太平洋夏時間)で金曜日の時間帯に
  5. Today is Friday in California. を表示します。
  6. 最後に、保存された言語ロケールへと戻します。

まとめ

今回は単に文字列を判別するだけ。ですが、月末時の処理や保守更新などの応用が利きそうです。

Ubuntuでプロンプトの挙動を変更(ちょいハマり-1-)。

ちょっとハマっていること

LinuxのCUI操作で、

  1. プロンプトの内容を「ユーザ名@ホスト名 カレントディレクトリ」に変更する。
  2. 一般ユーザの場合はプロンプトを緑にして\&で表記。
  3. rootに昇格した場合はプロンプトを赤にして#で表記。

という挙動にしています。

RockyLinuxの場合:OK

以下の内容を /etc/bashrc に組み込めばOKでした。

if [ "$PS1" ]; then
  if [ "$(id -u)" -eq 0 ]; then # rootユーザの場合
    PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
  else # 一般ユーザの場合
    PS1='\[\e[0;32m\][\u@\H \W]\$\[\e[0m\] '
  fi
fi

Ubuntuの場合:NG

ところが、Ubuntu系は

  1. 上記の設定を/etc/bash.bashrcに追記してもプロンプトの動きが想定通りとならない。
  2. source /etc/bash.bashrcと実行すると、設定が反映される。

これは相当面倒です。ログイン時に別のスクリプトか何かでこれを実行すればいいのでしょうが、新しいユーザを作成した場合など不都合が生じます。

Ubuntuでのワークアラウンド

取り急ぎ、当初の目的である「一般ユーザと特権ユーザでプロンプトの色や記号を変える」を優先させます。

ログインユーザ(一般ユーザ)の設定ファイル

  • ~.bashrc

末尾に以下を追記します。

# 一般ユーザ向けのプロンプト設定
if [ "$PS1" ]; then
  if [ "$(id -u)" -eq 0 ]; then # rootユーザの場合
    PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
  else # 一般ユーザの場合
    PS1='\[\e[0;32m\][\u@\H \W]\$\[\e[0m\] '
  fi
fi

rootの設定ファイル

  • /root/.bashrc

末尾に以下を追記します。

# rootユーザ向けのプロンプト設定
if [ "$PS1" ]; then
  PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
fi

これで当面の問題は回避できましたが、根本的な解決には至らず。

もう少し調査が必要です。

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

以上で設定は完了です。

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の帯域や処理速度に依拠します。過信は禁物です。

Nextcloud 画像認識「Recognize」の自動タグ付けが行われない問題の解決。(occ 実行)

Ubuntu 20.04に新規インストールすることになったNextcloud。

各種設定を済ませ、アプリの動作を確認中に「Recognize(画像自動認識・タグ付けツール)で以下の警告が出ていました。また、自動タグ付けも行われていなかったので、問題の解決を行います。

参考にしたURL

https://help.nextcloud.com/t/machine-learning-models-still-need-to-be-downloaded/151566

さっくりとした手順

  1. Nextcloudの格納ディレクトリに移動します。
  2. Nextcloudのコマンドラインツール(occ)を実行します。
  3. 動作を確認します。

Nextcloudがインストールされているサーバにターミナルでログインします。

任意のクライアントを用います。

格納ディレクトリに移動します。

# 例
cd /var/www/html/nextcloud

# 筆者環境
cd /home/www-data/nextcloud

コマンドラインツールを実行します。

sudo -u www-data php occ recognize:download-models
# 環境によって時間がかかります

sudo -u www-data php occ recognize:recrawl

動作確認を行います。

Nextcloudに管理者でログインし、管理メニュー>Recognizeから以下の通り、警告が消えていることを確認します。

ダッシュボード>アクティビティから、以下の通り、画像のタグ付けが行われていることを確認します。

(表示まで最大15分程かかります)

Nextcloudのインストール後の対応:ログローテーションの設定

Nextcloudは多層的なWebアプリスイートであるため、ログがたちまち肥大化します。

そのため、設定後、ログローテーションの設定を行います。

動作確認環境

  • Ubuntu 20.04
  • Nextcloud 27.02
  • Apache2.4経由で稼働
  • PHP 8.1

さっくりとした手順

  1. logrotate.dにファイルを追加します。
  2. 動作を確認します。
  3. logrotateサービスを再起動します。

ファイルの追加

以下の通り、ファイルを追加します。【】内は設定したログファイルの格納ディレクトリにしてください。

cat <<- __EOF__ | sudo tee -a /etc/logrotate.d/nextcloud
【/var/log/nextcloud/】*.log {
    daily
    dateext
    dateformat -%Y%m%d
    rotate 10
    missingok
    notifempty
    su www-data www-data
    create 640 www-data www-data
    sharedscripts
    compress
    delaycompress
        postrotate
                if invoke-rc.d apache2 status > /dev/null 2>&1; then \
                    invoke-rc.d apache2 reload > /dev/null 2>&1; \
                fi;
        endscript
}
__EOF__
それぞれの内容
  1. /var/log/nextcloud/*.log: /var/log/nextcloud/ ディレクトリ内の全ての .log ファイルを対象にしてログローテーションが行われます。
  2. daily: 日ごとにログをローテートします。
  3. dateext: ログファイル名に日付が追加されます。
  4. dateformat -%Y%m%d: 日付のフォーマットが "年4桁月2桁日2桁" の形式で指定されます。
  5. rotate 10: ログファイルは10世代まで保持され、古いファイルは削除されます。
  6. missingok: ログファイルが存在しない場合でもエラーを出さずに処理を続行します。
  7. notifempty: ログファイルが空の場合、ローテーションを行わずにスキップします。
  8. su www-data www-data: ローテーション操作時にログファイルの所有者とグループを www-data ユーザーに変更します。
  9. create 640 www-data www-data: 新しいログファイルが作成される際、所有者 www-data とグループ www-data、パーミッション 640 で作成されます。
  10. sharedscripts: ローテーションの前後に prerotate および postrotate セクション内のコマンドを共有します。
  11. compress および delaycompress: ローテート後にログファイルを圧縮し、以前のファイルを圧縮しないようにします。
  12. postrotate: ローテーションが完了した後、Apache2サーバーが起動している場合にApache2をリロードします。

設定確認

sudo logrotate -v /etc/logrotate.d/nextcloud

エラーがないことを確認します。

設定反映

sudo systemctl restart logrotate.service

これで設定は完了です。後日、アクセスログが圧縮されていることを確認します。

すぐ確認したい場合は

sudo logrotate -f /etc/logrotate.d/nextcloud

で、強制的にローテートさせます。

Nextcloudのインストール後の対応:cron設定

Nextcloudのインストール後の設定で概要でのセキュリティチェックがパスしましたが、

管理>基本設定で

最終ジョブ実行は %s です。何か問題が発生しています。

と出ていますので、これの設定を行います。

動作を確認した環境

  • Ubuntu 20.04
  • Apache 2.4系
  • PHP8.1
  • Nextcloud 27.0.2

さっくりとした手順

  1. Nextcloud上で設定を変えます。
  2. 一度Cronを走らせます。
  3. Cron設定を行います。
  4. 動作を確認します。

Nextcloud設定変更

  1. Nextcloud>管理>基本設定に進みます。
  2. バックグラウンドジョブをCronに設定します。

Cron作動

NextcloudがインストールされたサーバにSSHログインし、以下を実行します。

sudo -u www-data /usr/bin/php /var/www/html/nextcloud/cron.php

# 自分がnextcloudをインストールした環境に合わせます。
# 筆者環境
# sudo -u www-data /usr/bin/php /home/www-data/nextcloud/cron.php

Cron実行確認

  1. Nextcloud>管理>基本設定に進みます。
  2. 以下のように「最終ジョブ実行は○分前です」が表示されることを確認します。

Cronログ設定

Ubuntu 20.04の初期設定はcronログの出力が無効になっているので、修正します。

cd /etc/rsyslog.d

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

diff -u 50-default.conf /path/to/backup/50-default.conf.$(date +%Y%m%d)
# 差分がないことでバックアップされていることを確認します。
  • ファイル修正

教義・信仰に合わせたエディタで以下を修正します。

  • 修正前
#cron.*                         /var/log/cron.log
  • 修正後
cron.*                         /var/log/cron.log
  • 設定反映
sudo systemctl restart rsyslog.service

Cron登録

  • crontab起動
sudo -u www-data crontab -e
  • 追記内容
*/5 * * * * /usr/bin/php -f /var/www/nextcloud/cron.php
# 自分の環境に合わせます。
# 筆者環境
# */5 * * * * /usr/bin/php -f /home/www-data/nextcloud/cron.php
  • Cron登録確認
tail -50 /var/log/cron.log
  • BEGIN EDIT (www-data)
  • REPLACE EDIT (www-data)
  • END EDIT (www-data)

と表示されていれば、Cron登録は確認されています。

  • メール設定
  • config.phpの設定
  • メモリキャッシュの設定
  • redis-serverの組み込み
  • cron設定

が終われば、一応、初期準備は済んだと思います。

Page 8 of 15

Powered by WordPress & Theme by Anders Norén