ufwとfail2banの前段に、vpsが備えているファイアウォールを挟ませることで、サーバの負荷を抑えます。
ネットワーク管理＞ファイアーウォールをクリック。
右上の「ファイアウォールの作成」をクリック。
を設定します。これは基本的なWebサーバ用の設定なので、許可したいポートが他にあればそれに合わせます。
設定後、インスタンスへの適用→作成したインスタンスを選び、設定を保存します。
固定IPを持っていれば、SSHのIPアドレスを指定することで、それ以外のIPをシャットアウト可能です。
場合に必要な措置となる、NW保護を行います。
sudo ufw limit proto tcp from any to any port 22sudo ufw allow 80/tcpsudo ufw allow 443/tcpsudo ufw enableCommand may disrupt existing ssh connections. Proceed with operation (y|n)?はyで続けます。
sudo ufw status以下を確認します。
状態: アクティブ
To Action From
-- ------ ----
22/tcp LIMIT Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
22/tcp (v6) LIMIT Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6) 別ウィンドウで新たなSSH接続を行い、通信できるかを確認します。
sudo reboot再起動後、SSH接続ができることを確認します。
sudo ufw status上記、許可された設定が有効になっていることを確認します。
sudo aptitude update && sudo aptitude install fail2bansystemctl status fail2ban.service active(running)を確認します。
教義と進行に沿ったエディタを用いて/etc/fail2ban/jail.localを管理者権限で編集します。
[ufw]
enabled=true
filter=ufw.aggressive
action=iptables-allports
logpath=/var/log/ufw.log
maxretry=1
bantime=-1
ignoreip = 127.0.0.0/8 ::1
# ignoreipは任意の(ある程度アクセス元が判明しているIPアドレス)を指定ください。スペース区切りで複数指定できます。
[sshd]
enabled=true
filter=sshd
mode=normal
port=22
protocol=tcp
logpath=/var/log/auth.log
maxretry=3
bantime=-1
ignoreip = 127.0.0.0/8 ::1
# ignoreipは任意の(ある程度アクセス元が判明しているIPアドレス)を指定ください。スペース区切りで複数指定できます。sudo tee /etc/fail2ban/filter.d/ufw.aggressive.conf > /dev/null << 'EOF'
[Definition]
failregex = [UFW BLOCK].+SRC=<HOST> DST
ignoreregex =
EOFsudo systemctl restart fail2ban.servicesystemctl status fail2ban.service active(running)を確認します。
sudo cat /var/log/fail2ban.logこの時点で、
2024-09-01 17:14:26,476 fail2ban.filter [1720]: INFO [ufw] Found xxx.xxx.xxx.xxx - 2024-09-01 17:14:26
2024-09-01 17:14:26,623 fail2ban.actions [1720]: NOTICE [ufw] Ban xxx.xxx.xxx.xxx
2024-09-01 17:14:44,198 fail2ban.filter [1720]: INFO [ufw] Found yyy.yyy.yyy.yyy - 2024-09-01 17:14:44
2024-09-01 17:14:44,647 fail2ban.actions [1720]: NOTICE [ufw] Ban yyy.yyy.yyy.yyyと、fail2banが不審なアクセスを弾いています。
sudo fail2ban-client status ufw設定して10分も経たないうちに100ほどのIPアドレスがブロックされていました。
vpsを利用して立ち上げたUbuntu 24.04。
まずは2024年7月に発生した脆弱性に対応させます。
openssl version -aOpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)
built on: Fri Aug 9 02:33:21 2024 UTC
platform: debian-amd64
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -fzero-call-used-regs=used-gpr -DOPENSSL_TLS_SECURITY_LEVEL=2 -Wa,--noexecstack -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/openssl-uVxJzP/openssl-3.0.13=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/openssl-uVxJzP/openssl-3.0.13=/usr/src/openssl-3.0.13-0ubuntu3.3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=3
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0x9fb82203478bfffd:0x0ssh -VOpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13 30 Jan 2024脆弱性に対応していないバージョンだったので、まずはここから対応します。
※脆弱性対応のため、切り戻しは一切考慮しません。※
localectlSystem Locale: LANG=C.UTF-8
VC Keymap: (unset)
X11 Layout: us
X11 Model: pc105localectl list-localesC.UTF-8
en_US.UTF-8→ 日本語がないので、追加することから確認します。
sudo aptitude install language-pack-jalocalectl list-localesC.UTF-8
en_US.UTF-8
ja_JP.UTF-8追加を確認しました。
sudo localectl set-locale LANG=ja_JP.UTF-8これで各種メッセージが日本語で表示されるようになります。
sudo apt install aptitudeパッケージ管理はこちらが好みなので先にインストールします。
sudo aptitude install build-essential zlib1g-dev libssl-dev libpam0g-dev libselinux1-dev libkrb5-dev checkinstall zlib1g-dev gitソースコードからコンパイルしてインストールするため、この作業は全て管理者権限で実行します。
sudo su -cd /hoge && pwd任意のディレクトリ名を指定します。
git clone https://github.com/openssl/openssl -b openssl-3.3.12024/09/01現在の最新版を指定します。
cd openssl && pwd./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared zlibConfiguring OpenSSL version 3.3.1 for target linux-x86_64
Using os-specific seed configuration
Created configdata.pm
Running configdata.pm
Created Makefile.in
Created Makefile
Created include/openssl/configuration.h
**********************************************************************
*** ***
*** OpenSSL has been successfully configured ***
*** ***
*** If you encounter a problem while building, please open an ***
*** issue on GitHub <https://github.com/openssl/openssl/issues> ***
*** and include the output from the following command: ***
*** ***
*** perl configdata.pm --dump ***
*** ***
*** (If you are new to OpenSSL, you might want to consult the ***
*** 'Troubleshooting' section in the INSTALL.md file first) ***
*** ***
**********************************************************************make時間がかかります。状況を時々見ながら待ちます。
make testこれも時間がかかります。
make installcat <<- __EOF__ | tee -a /etc/ld.so.conf.d/openssl-3.3.1.conf
/usr/local/ssl/lib64
__EOF__ldconfig -vmv /usr/bin/c_rehash /path/to/backup/c_rehash.$(date +%Y%m%d)mv /usr/bin/openssl /path/to/backup/openssl.$(date +%Y%m%d)それぞれ、任意のディレクトリを指定します。
sudo sed -i 's|^PATH=.*|#&\nPATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/local/ssl/bin"|' /etc/environmentsource /etc/environmentecho $PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/local/ssl/bin と表示されるのを確認します。
openssl version -aOpenSSL 3.3.1 4 Jun 2024 (Library: OpenSSL 3.3.1 4 Jun 2024)
built on: Sun Sep 1 05:14:25 2024 UTC
platform: linux-x86_64
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG
OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/ssl/lib64/engines-3"
MODULESDIR: "/usr/local/ssl/lib64/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0x9fb82203478bfffd:0x0これで、バージョンが3.0.1から3.3.1に変わります。
その後のシステムアップグレードでパスなどが変わるのを防ぎます。
sudo apt-mark hold opensslsudo aptitude hold opensslreboot再起動すると同時に、rootから抜けます。
むしろここからが本番。CVE-2024-6378の致命的な脆弱性の対応を行います。
sudo mkdir /var/lib/sshd && sudo chmod -R 700 /var/lib/sshd/ && sudo chown -R root:sys /var/lib/sshd/cd /hoge && pwd任意のディレクトリを指定します。
wget -c http://mirror.exonetric.net/pub/OpenBSD/OpenSSH/portable/openssh-9.8p1.tar.gztar -xvzf openssh-9.8p1.tar.gzcd openssh && pwdwhich openssl/usr/local/ssl/bin/opensslを確認
本手順でSSLのバージョンアップを行った場合の環境となります。
./configure --with-kerberos5 --with-md5-passwords --with-pam --with-selinux --with-privsep-path=/var/lib/sshd/ --sysconfdir=/etc/ssh --with-ssl-dir=/usr/local/ssl--with-ssl-dir=/usr/local/sslは、opensslがあるディレクトリを指定します。
makesudo make installターミナルクライアントソフトは開いたまま、新たなウィンドウで開き、ログインできることを確認します。
ssh -VOpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024これで、SSH接続の脆弱性に対応。一番の危険は去りました。
Ubuntu 20.o4サーバのEOLが近づいてきたため、現時点でのUbuntu最新版LTSサーバのvpsを立ち上げたときの記録です。
https://web.arena.ne.jp/indigo
今回は国産vpsを選定です。
が選定理由です。
申し込みそのものは
で、アカウント作成後は
こんな形のダッシュボードができました。
ここからUbuntuサーバを立ち上げていくのですが、罠が待っていました。
上記ダッシュボードから
で鍵を作成後、
で、Ubuntu 24.04インスタンスを作成するとログインできません。
過去にもこういう事例があったので、それに沿って対応します。
これと同じく、
(SSH-1アルゴリズムによるRSA認証が無効化されます)
に引っかかるので、
回りくどい方法を採りました。
sudo su -パスワードは設定されていないので空エンターです。
adduser hogehogeは任意のユーザー名です。その後、パスワードなどを設定していきます。
usermod -G sudo hogehogeは自分が作成したユーザー名です。
su - hogewhoami作成したユーザー名であることを確認します。
sudo su -パスワード入力後、作成したユーザーがrootに昇格できることを確認します。
exit && whoami作成したユーザーであることを確認します。
ssh-keygen -t ed25519鍵の格納場所は初期値(/home/hoge/.ssh)なので空エンターです。特別な運用がない限りはパスワードを設定します。
cd .ssh && pwd/home/hoge/.sshにいることを確認します。
ls -lの2つを確認します。
cat id_ed25519cat id_ed25519.pubとした上で内容をコピーし、ローカル環境に貼り付けて保管します。この、秘密鍵と公開鍵はサーバセキュリティの生命線です。管理と保管は厳密に行ってください。
rm id_ed25519サーバにアクセスするための秘密鍵がサーバ上にあっては意味がありません。「ローカルに秘密鍵があることを再確認した上で」秘密鍵を削除します。
mv id_ed25519.pub authorized_keyschmod 600 authorized_keys公開鍵の名前をauthorized_keysに変更して、所有者のみがアクセスできるようにします。
ターミナルクライアントソフトで
を用いてアクセスできることを確認します。
Ubuntu 20.04から24.04まで上げるので、二段階に上げます。
また、OSの再インストールなので、休憩時間を一切挟まず、一気通貫で行ってください。
sudo su -ここから全てroot権限で設定します。
apt update && apt upgrade && apt autoremoveパッケージを最新版にして不要パッケージを削除します。途中で不要パッケージを消すかを求められるので[y]で消去します。
reboot再起動を行います。
sudo su -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-releaseDISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"となっていればまずはアップグレード完了です。
sudo su -do-release-upgrade途中のプロンプトはほぼ同じなので割愛。再起動後、
cat /etc/lsb-releaseDISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.1 LTS"にて成功です。
WebARENAのコンソールで作成された初期ユーザーはパスワードがない状態なので、無効化します。
sudo su -cd /home/ubuntu/.sshmv authorized_keys ../以上、仕様によって「すぐに立ち上げ」というわけには行きませんでしたが、クラウドでUbuntu24.04サーバを立ち上げることができました。
RedmineのViewCustomizeはいじりがいがあるプラグインです。
今回もまたちょっとした要望に応えるユースケースとなりました。
攻略情報をRedmineのチケットとして載せています。
https://atelier.reisalin.com/projects/ryza3/issues/gantt
この、「アトリエ-全般」やチケットNo.が視認性を悪くしているので、これの表示を変えます。
具体的には
トラッカー名-チケット番号-チケットの件名
を、
チケットの件名-トラッカー名-チケット番号
に変える形です。
※ 参考：Redmine View Customizeサンプルスクリプト:ガントチャートでトラッカー名・チケット番号を非表示にする
以下の通り設定します。
$(function() {
$('div.issue-subject span').each(function() {
var $this = $(this);
var issue_link = $this.find('a.issue');
var issue_number = issue_link.text().trim();
var issue_title = $this.clone().children().remove().end().text().trim();
var new_html = issue_title + ' ' + issue_number;
// 新しいHTMLを設定
$this.html(new_html);
// リンクを再設定
$this.wrapInner('<a href="' + issue_link.attr('href') + '"></a>');
});
});設定後、保存します。
上記の設定を行ったプロジェクトのガントチャートを確認します。
このように、並び順が変われば設定OKです。
バージョンアップしたNextcloudに、ある意味で待っていた機能が改善されました。
なぜか、今まで、
# で見出しタグを指定した後に文字を入力しようとすると日本語で文字が入力できないというかなり厳しい事象がありました。
そのため、Markdwonの文書の書き出しは
ぐらいしか手はありませんでしたですが、今回（かは不明ですが）のバージョンアップによって
このように、見出しの後にそのまま日本語入力ができます。
「オンラインで気兼ねなくメモを取れる」環境がほしかったので、これは大きな改善。
モバイルアプリなどを利用してのメモ書きの効率化も図れそうです。
Nextcloudのバージョンを29.05に上げたところ、以下のメッセージが出てきました。
One or more mimetype migrations are available. Occasionally new mimetypes are added to better handle certain file types. Migrating the mimetypes take a long time on larger instances so this is not done automatically during upgrades. Use the command
occ maintenance:repair --include-expensiveto perform the migrations.「1つ以上のMIMEタイプの移行が利用可能です。特定のファイルタイプをより適切に処理するために、新しいMIMEタイプが追加されることがあります。大規模なインスタンスではMIMEタイプの移行に時間がかかるため、アップグレード時に自動的には行われません。移行を実行するには、occ maintenance:repair --include-expensiveコマンドを使用してください。」
とあるので、この警告に対処していきます。
Nextcloudがインストールされているサーバにログインしての作業です。
cd /var/www/html/nextcloud && pwd自分の環境に合わせます。
sudo -u www-data php occ maintenance:repair --include-expensiveNextcloudの実行ユーザー(www-data)を付与した上でoccを実行します。
ですが、以下のエラーが出てきて問題は解決しませんでした。
WARNING: Failed to create filecache trigger (compatibility mode will be used): An exception occurred while executing a query: SQLSTATE[HY000]: General error: 1419 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)
- exiftool binary is configured: /var/www/html/nextcloud/apps/memories/bin-ext/exiftool-amd64-glibc
- go-vod binary is configured: /var/www/html/nextcloud/apps/memories/bin-ext/go-vod-amd64
- WARNING: ffmpeg binary could not be configured
そこで、このエラーメッセージで探したところ、そのものズバリのバグが報告されていました。
[Bug]: Warning: One or more mimetype migrations are available #47359
どうやら、RepairMimeTypes.phpファイルがver29.0.5を正しく読んでいないようです。
そこで、改めての対処です。
cd /hoge && pwd自分の環境に合わせます。
sudo cp -pi /var/www/html/nextcloud/lib/private/Repair/RepairMimeTypes.php /hoge/RepairMimeTypes.php.$(date +%Y%m%d)Nextcloudのルートディレクトリ (自分の環境に合わせます)から作業ディレクトリにコピーします。
wget https://raw.githubusercontent.com/nextcloud/server/stable29/lib/private/Repair/RepairMimeTypes.php -O RepairMimeTypes.php.fixedsudo -u www-data diff -u /var/www/html/nextcloud/lib/private/Repair/RepairMimeTypes.php RepairMimeTypes.php.fixed > RepairMimeTypes.patchcat RepairMimeTypes.patch--- /var/www/html/nextcloud/lib/private/Repair/RepairMimeTypes.php 2024-08-20 17:56:22.000000000 +0900
+++ RepairMimeTypes.php.fixed 2024-08-26 14:14:11.568462741 +0900
@@ -424,7 +424,7 @@
$out->info('Fixed ReStructured Text mime type');
}
- if (version_compare($mimeTypeVersion, '30.0.0.0', '<') && $this->introduceExcalidrawType()) {
+ if (version_compare($mimeTypeVersion, '29.0.5.0', '<') && $this->introduceExcalidrawType()) {
$out->info('Fixed Excalidraw mime type');
}差分（プラスマイナス）が2行のみを確認します。
sudo patch -d /var/www/html/nextcloud/lib/private/Repair < /hoge/RepairMimeTypes.patch /hogeはパッチを作成したディレクトリをフルパスで指定します。
sudo -u diff -u /hoge/RepairMimeTypes.php.$(date +%Y%m%d) /var/www/html/nextcloud/lib/private/Repair以下のような差分を確認します。
- if (version_compare($mimeTypeVersion, '30.0.0.0', '<') && $this->introduceExcalidrawType()) {
+ if (version_compare($mimeTypeVersion, '29.0.5.0', '<') && $this->introduceExcalidrawType()) {ls -l /var/www/html/nextcloud/lib/private/Repair/RepairMimeTypes.php念のため、パッチを当てても所有者が変わっていない(www-data)ことを確認します。
cd /var/www/html/nextcloud && pwd自分の環境に合わせます。
sudo -u www-data php occ maintenance:repair --include-expensive今度は通ります。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
「やらかしてしまった」メモです。
aws lightsailで動かしているUbuntu20.04サーバにアクセスできない事象が発生しました。
Webサイトはもちろん、sshにもつながりません。
awsの管理画面にログインしてリソース状況を確認したら、CPUがバースト。いわゆる暴走状態なのでこの状態を止めます。
「停止」→「起動」を選択。（再起動では完全に暴走が止まりませんでした）
それから程なくしてssh接続ができるまでは回復。ですが、
netstat -lntpを実行してもWebサービスがリッスンしていません。
systemctl status apache2.serviceでサービスは動いていることを確認。状態を確認できたところで原因を特定します。
バーストが発生しているサーバで、ufwの作業をしていました。これ以外に設定は特にやっていないので、ほぼおおそらくこれが問題だろうと判断。
取り急ぎ、
sudo ufw disableを行い
サイトが見られることを確認しました。判断するに
等でバースト、暴走したと考えられます。
不審なアクセスを無計画に弾いていたことが徒になった形です。
ufwが原因だと特定したものの、サーバ内のFWが有効化されていないのは危険です。そこで、以下のようにして設定を強制リセットしました。
sudo ufw --force resetsudo ufw limit proto tcp from any to any port 22sudo ufw allow 80/tcpsudo ufw allow 443/tcpsudo ufw enablesudo ufw status状態: アクティブ
To Action From
-- ------ ----
22/tcp LIMIT Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere を確認しました。
を確認し、対処完了です。
「FWをいじるだけだから、特に作業履歴をやらなくてもいいだろう」という慢心から起きたものでした。
個人で運営しているサーバだったことに救われた形です。
また、この程度の作業ということで、システム全体のバックアップを取らなかったことも冷や水でした。
といった基本的な運用の管理への意識を改める自戒の出来事でした。
DoS/DDoS対策ができるモジュールをApacheに導入したときのメモです。
まずはサーバにターミナルログインするところから始めます。
sudo aptitude install libapache2-mod-evasiveこのとき、postfixが依存関係でインストールされる場合があります。メール機能が使えない（AWS等で送信が制限されているなど）は、途中の設定で「何もしない」を選択します。
これは、www-dataがufwを実行する場合の処理です。権限昇格の危険性を承知した上で、慎重に作業を行ってください。
sudo cp -pi /etc/sudoers /path/to/backup/directory/sudoers.$(date +%Y%m%d)任意のバックアップディレクトリを指定します。
sudo diff -u /path/to/backup/directory/sudoers.$(date +%Y%m%d) /etc/sudoers差分がないことを確認します。
echo 'www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw' | sudo tee -a /etc/sudoerssudo diff -u /path/to/backup/directory/sudoers.$(date +%Y%m%d) /etc/sudoers以下の差分を確認します。
+www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufwsudo cp -pi /etc/apache2/mods-available/evasive.conf /path/to/backup/directory/evasive.conf.$(date +%Y%m%d)sudo diff -u /path/to/backup/directory/evasive.conf.$(date +%Y%m%d) /etc/apache2/mods-available/evasive.conf差分がないことを確認します。
/etc/apache2/mods-available/evasive.conf DOSHashTableSize 3097
DOSPageCount 100
DOSSiteCount 100
#かなり緩く設定して、後で狭めていった方が偽陽性を防げます。
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
#DOSEmailNotify you@yourdomain.com
#メール通知を行わないため、ここを省いています
DOSSystemCommand "sudo ufw deny proto tcp from %s to any port 80,443"
# 検証時に自分のサイトがブロックされるのを防ぐため、ポートは80/443に絞っています
DOSLogDir "/var/log/mod_evasive"
DOSWhitelist 127.0.0.1
DOSWhitelist xx.xx.xx.xx
# 対象外としたいIPアドレス（自分の環境など）参考：Apache の DoS攻撃対策モジュール mod_evasive
sudo diff -u /path/to/backup/directory/evasive.conf.$(date +%Y%m%d) /etc/apache2/mods-available/evasive.conf- #DOSHashTableSize 3097
- #DOSPageCount 2
- #DOSSiteCount 50
- #DOSPageInterval 1
- #DOSSiteInterval 1
- #DOSBlockingPeriod 10
+ DOSHashTableSize 3097
+ DOSPageCount 100
+ DOSSiteCount 100
+ DOSPageInterval 1
+ DOSSiteInterval 1
+ DOSBlockingPeriod 10
#DOSEmailNotify you@yourdomain.com
- #DOSSystemCommand "su - someuser -c '/sbin/... %s ...'"
- #DOSLogDir "/var/log/mod_evasive"
+ DOSSystemCommand "sudo ufw deny proto tcp from %s to any port 80,443"
+ DOSLogDir "/var/log/mod_evasive"
+ DOSWhitelist 127.0.0.1
+ DOSWhitelist xx.xx.xx.xx
</IfModule>sudo apache2ctl configtestSyntax OKを確認します。
sudo systemctl restart apache2.serviceこれで、不審なアクセスが大量にあったときにufwで弾く体制が整いました。
4月の中頃から弁当を本格的に作り始め、5月24日から弁当を作った日は
を欠かさず行っていました。
そんなアルバムが8月6日に全て埋まりました。
この記録で分かったことは
「卵焼きに関するメモが非常に多い」です。
ことも相まって、日々のおかずに欠かせません。
次はもっと多く綴じることができるアルバムで記録を続け、見映えや味のフィードバックを続けていこうと思います。
Powered by WordPress & Theme by Anders Norén