t_wの輪郭

『t_wの輪郭』とTwEgakuを動かしているサーバーの負荷が高くなって、アクセス不能になっている。

サーバーの負荷が高くなった原因は不明だ。nginxのログを見る限りでは、過剰なアクセスなどは生じていない。

しばらくサーバープログラムのログを見ながら様子見する。

は？やべぇ。攻撃来てるかも。攻撃戦だ。

nginxのログみたら、SQLっぽいクエリで検索めっちゃされてる。
nginxでIPをはじくようにした。
IPをBANしたら、一旦攻撃は止んだ。

攻撃の対策どうしよう、fail2banのnginx-403-404は設定してるけど、サイト内検索を連打されるとこれ効かないんだよな。
WAF入れるのが手っ取り早いんだろうけど、勉強にならないし、お金かかるしで、もうちょっとほかの手段を検討したい。

①fail2banでSQLインジェクションを検知してBANする
②nginxで高頻度の検索を検知してBANする
あたりかしら

設定するのめんどくせー
ちゃんと設定できてるか検証するのもめんどくせー

①検証用の被攻撃サーバーと攻撃用サーバーを立ててそこで対策が有効かを検証
②本番環境に反映したら攻撃用サーバーから攻撃してみて、ちゃんと対策されているか検証

って感じで進めるとお行儀が良さそう。
めんどくせー
本番環境でペペぺって設定して、自宅のPCから実際攻撃して検証したい。そして自宅のPCから本番環境にアクセスできなくなるワナ。

こういうのって制定された手順とかあるんかな。ありそう。先に調べよう。

そもそもサイト内検索が大変重たいという問題も解決したい。
自作の検索機能がDBにインデックス張ってないわ、title LIKE %hogehoge% OR body_text LIKE %hogehoge%とかやって全文検索走るわでイケてない。
DBにちゃんとインデックス張ればいいんだろうけど、PostgreSQLの日本語のインデックスって、PGroonga入れたり、pg_bigm入れたりで、これまた検証サーバー立てないと怖いのよね。
めんどくせー。

　『t_wの輪郭』にUser-Agentが下記のアクセスがちょいちょい来ていた。Date last visitedが乱れてちょっと気になる程度の頻度。

• Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36

　内部リンクが無いはずの所にアクセスしており、足跡が妙なため、nginxのログを見たら、なぜか律儀にrobot.txtにアクセスしている。

　熱心な読者が来てくれているとぬか喜びしてしまった。

　しかしまあ、輩と書いてしまったが、User-Agent以外はお行儀が良い。

2022年10月10日

なんか『t_wの輪郭』のアクセス数が急増している。アクセス数が2倍ぐらい。DoSか？

nginxのログをみる感じでは、MJ12bot（MJ12bot/v1.4.8） と DotBot（DotBot/1.2） が結構アクセスしてきている。

SemrushBotと同様に、robot.txtで拒否して終わり！明日になったら結果を見る。

User-agent: SemrushBot
User-agent: dotbot
User-agent: MJ12bot
Disallow: /

2022年10月13日

アクセス数が激減していることを確認した。nginxのログでも、MJ12bot と DotBotのアクセスが無くなっている。

2022年5月9日

全部記録すると、容量がすごいことになりそう。

nginxのログがあるのだから、わざわざ全部を記録する必要はなくて、「いつアクセスされたか」

「どこにアクセスしたか」「どれだけアクセスがあったか」が記録されていれば良さそう。
→後からアクセス数の集計方法を変えたいとかなった時に困りそう。

2022年5月2日

Google Analyticsを入れていれば十分だろうか。
nginxのログを見ればよい？

2022年5月8日

nginxのログを可視化するためにGoAccessを使用した。
関係ない人がログを見れないようにするために、GoAccessを参照するページにはBasic認証を設定した。
これでクロールされている度合いなんかも見ることができる。でもあまり詳細な所（何時どれだけクロールされたか）などは分からない。

zcat /var/log/nginx/access.log.*.gz | goaccess /var/log/nginx/access.log --log-format=COMBINED