過去に何度かBOTなどを避けるためのアクセス制御を導入していたが、結果どれも微妙だった。しかしどうにかしたい、そうだ、nginxは高機能なのでできるんじゃないか？と思って実践してみたログ。
User-AgentはGEOIP2と何も関係ないが、ついでにやったので書いている。
| Env | Ver(apt上) | 備考 |
|---|---|---|
| nginx | 1.24.0-2ubuntu7.13 | nginx -vではnginx/1.24.0 (Ubuntu) |
| nginx-common | 1.24.0-2ubuntu7.13 | |
| libnginx-mod-stream | 1.24.0-2ubuntu7.13 | |
| libnginx-mod-http-geoip2 | 1:3.4-5build2 |
インストールされていたnginxが1.26.1-2~jammyで、libnginx-mod-http-geoip2との互換性がなかったためダウングレードすることにした。
まず次のコマンドで整合性を確認した。コマンド自体はGPT-5.5が作ってくれたものであるが、こうすることでダウングレードを許可した上での互換性チェックができるようだ。
コマンドの実行結果としては既に追加されているコンポーネント、ダウングレードされるコンポーネント、新たに追加されるコンポーネントの一覧が出てくる。
# ngx_http_geoip2_module.soが存在しないことを確認。既にある場合は本項の工程は飛ばせると思う
ls -la /usr/lib/nginx/modules
sudo apt install -s --allow-downgrades \
nginx=1.24.0-2ubuntu7.13 \
nginx-common=1.24.0-2ubuntu7.13 \
libnginx-mod-stream=1.24.0-2ubuntu7.13 \
libnginx-mod-http-geoip2
上記の構成でインストールできることが分かったので-sを外してnginx本体をダウングレードし、他をインストールする。
sudo apt install --allow-downgrades \
nginx=1.24.0-2ubuntu7.13 \
nginx-common=1.24.0-2ubuntu7.13 \
libnginx-mod-stream=1.24.0-2ubuntu7.13 \
libnginx-mod-http-geoip2
# ngx_http_geoip2_module.soが増えていることを確認
ls -la /usr/lib/nginx/modules
ngx_http_geoip2_module.so
MMDBなら何でも行けると思うので、Matomoで使ってる無料の奴を使う。理想的にはCRONで定期取得するのがいいと思うが、面倒なので今回はやってない。
sudo mkdir -p /usr/share/GeoIP
sudo wget https://download.db-ip.com/free/dbip-country-lite-2026-06.mmdb.gz -O /usr/share/GeoIP/dbip-country-lite.gz
gunzip /usr/share/GeoIP/dbip-country-lite.gz
/etc/nginx/nginx.confに以下の設定を追記すると、$geoip2_で始まる変数にMMDBの中身が入るようになる。
load_module modules/ngx_http_geoip2_module.so;
http {
...
geoip2 /usr/share/GeoIP/dbip-country-lite {
auto_reload 24h;
$geoip2_metadata_country_build metadata build_epoch;
$geoip2_country_code country iso_code;
$geoip2_country_name country names en;
}
...
JSONログにキーを追加してやればよい。
http {
...
log_format main_json escape=json
'{'
...
'"country_code":"$geoip2_country_code"'
'}';
nginxのmap構文を使って判定用の元ネタを作る。
左側は~で始めると正規表現扱いになり、~*とすると大文字小文字の違いを無視してくれるようになるらしい。
http {
# headlesschromeを2にしてるのは、これはちょっと毛色が違うと思ったため、便宜上分類分けしている。
# 但し現時点でこの値を特別扱いしておらず、1と等価なので無駄ではある。
map $http_user_agent $deny_ua {
default 0;
"~*meta-externalagent" 1;
"~*baidu" 1;
"~*headlesschrome" 2;
"" 1;
}
map $geoip2_country_code $deny_ca {
default 0;
"CN" 1;
"BR" 1;
"IN" 1;
}
# nginxのif文にはandやorに相当する演算子がないのでmapで合成しておく
map "$deny_ua:$deny_ca" $deny_client {
default 1;
"0:0" 0;
}
....
}
雰囲気で読んでいるが構文の意味合いはこうだと思う。KeyValueで並べていくと入力値（$input_variable）のKey（input_value）に対するValue（output_value）が出力値（$output_variable）に入るのだと思う。
map $input_variable $output_variable {
default <default_value>; # デフォルト値
input_value output_value;
...
}
vhostに撒くように/etc/nginx/snippets/deny_client.confのようなsnippetsを作る。
前述のmapで判定をまとめているのでif文一つで制御できるようになっている。
if ($deny_client = 1) {
return 403;
}
反映したいvhostの設定にsnippetsを撒いていく。
server {
...
include snippets/deny_client.conf;
...
こんな感じで検証して弾かれてれることを確認した。国コードはどうにもならないが原理上問題ないはずなので大丈夫だろう。
curl -H "User-Agent:meta-externalagent/1.1" https://lycolia.info
あとは念のために国コードが出ているかどうかをnginxのログを見て出ていたらOK。
今回のアクセス制御の導入にあたり、運用面で課題のあるAnubisを回避しつつ、大量に存在するCGIにラッパーCGIを嚙ますなどの対応を回避できたのはよかった。
nginxは何とも高性能だ。そして自宅サーバーに全部乗せしたおかげで、レンタルサーバーでは決して手が届かないことができるのが良いと思った。
しかしググってもGEOIP無印の情報ばかりで、GEOIP2の情報が全然なかったので地味にハマってしまった。こういう時LLMに情報を漁ってもらうと取っ掛かりが得られて突破口を見つけられたりするので便利だと感じる。
パッケージを見ていて気になったことは元のコードは保守されてないにもかかわらず、ディストリごとにコードが保守されているように見えたことだ。
今回導入したのはlibnginx-mod-http-geoip2だが、これは元を辿ればDebianのlibnginx-mod-http-geoip2のようで、更に元を辿るとleev/ngx_http_geoip2_module: Nginx GeoIP2 moduleに行きつく。
何故ならDebianのリポジトリがGitHubより新しく、READMEの中身が同じだからだ。設定方法もまるっきり同じに見える。
GitHubのリポジトリは2年以上放置されており「Support nginx 1.23.0」で時が止まっているが、Ubuntuでは「Rebuild against new nginx 1.30.1.」とあるため、だいぶ新しいところまでサポートが進んでいる。
よく考えるとパッケージのバージョンに-ubuntuみたいなのがついているのも良くあることなので、もしかしたらディストリごとにこういったアプリケーションを保守していたりするのだろうか？
そういえばPHPなんかも本家がサポート切れててもUbuntuではサポート内とか聞いたことがある。動作サポートなのかセキュリティサポートなのか、何のサポート課なのかまでは知らないが、星の数ほどあるパッケージをディストリごとに保守しているとしたら、これは凄いことだなと思ったし、他人が書いた得体のしれないパッケージをどう保守しているのかも気になった。
Linuxの世界は興味深い…。
ダウングレードしても基本的に影響はないと思うが、元のバージョンに上げようとするとUbuntuそのもののバージョンアップが必要なことを知った。
しかし24.04.04 LTSから26.04への安全なアップグレードはまだ提供されていないようなのでいったん断念した。26.04.01が出ると上げられるようになるらしく、現状はお試し版みたいな感じらしい。
よくあるx.00は安定板だけど不具合がある、x.01で真の安定板になるみたいな話はUbuntuにもあるんだなと思った。
nginxのバーチャルホストを増やしたり減らしたりしていて未定義のドメインにアクセスしたとき、最も若い設定ファイルに飛ばされることに気づいた。
これだと未定義のバーチャルホストを叩いたときに変なところに飛んでいくので、エラーにするようにした。
git.lycolia.infoの設定をnginxから削除し、DNSにレコードが残っている状態でhttps://git.lycolia.infoを叩くと他の特定のドメインでホストしているサイトに飛ばされる状態になっていた。
例えば/etc/nginx/conf.d/access-analizer.confがあるとした場合、未定義の任意のドメイン名を叩くと、この設定ファイルで定義した場所が表示される状態だった。リダイレクトなどはなく、URLそのままで表示される感じ。
/etc/nginx/conf.d/ddefault.confなど、適当に設定ファイルを作って次の設定を記述すると対処できる。
server {
listen 80 default_server;
listen 443 ssl default_server;
listen [::]:80 default_server;
listen [::]:443 ssl default_server;
ssl_reject_handshake on;
return 444;
}
default_serverと書くと、未定義のホストに対するアクセスがすべてここに吸収される。
server_name ""にしておくとIP直打ちのアクセスもトラップできるらしいが、手元で確認した感じは、あってもなくても機能するように見えたので付けていない。
ssl_reject_handshake onにしておくことで、未定義のホストに対してHTTPSでアクセスしてきたときに、ハンドシェイクをせず突き返す事ができるようだ。わずかではあるもののサーバーの負荷やネットワークのトラフィックが抑えられそうだ。
以下のようにlistenの443にsslをつけなくても同じように動いたが、違いはよく分かっていない。
server {
listen 80 default_server;
listen 443 default_server;
listen [::]:80 default_server;
listen [::]:443 default_server;
ssl_reject_handshake on;
return 444;
}
余談がうちのサーバーは外向きに80番ポートを開けていないので、80に対して制御を入れているのはもっぱらローカル用だ。開発環境を増減させてる時に変なところに繋がると面倒なので入れている。
この設定をしたことで次のようなHTTP要求をすべてエラーで返せるようになった。
curl -H "Host:hoge.lycolia.info" "https://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]"
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 unrecognized name
curl "https://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]"
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 unrecognized name
curl -H "Host:hoge.lycolia.info" "https://180.33.219.150"
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 unrecognized name
curl "https://180.33.219.150"
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 unrecognized name
但しhttpスキーマにして443ポートに投げるとHTMLが返ってくるようだった。まぁ別にいいかと思ったが、サーバーのバージョンが出てると微妙な気がしたのでserver_tokens off;を/etc/nginx/nginx.confに足しておいた。記事で明かしているとはいえ、悪意のあるBOTが機械的に叩いてきたときに見られると余りよくない。
curl -H "Host:hoge.lycolia.info" "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]:443"
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.24.0 (Ubuntu)</center>
</body>
</html>
curl "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]:443"
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.24.0 (Ubuntu)</center>
</body>
</html>
curl -H "Host:hoge.lycolia.info" "http://180.33.219.150:443"
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>
curl "http://180.33.219.150:443"
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>
おまけで80番を叩いて見たらそもそも繋がらなかった。ルーターで塞いでるのでnginxに届いていない。
curl -H "Host:hoge.lycolia.info" "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]"
curl: (7) Failed to connect to 2400:4153:8f01:c800:c14b:3f7a:2b54:353a port 80 after 4 ms: 接続が拒絶されました
curl "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]"
curl: (7) Failed to connect to 2400:4153:8f01:c800:c14b:3f7a:2b54:353a port 80 after 8 ms: 接続が拒絶されました
curl -H "Host:hoge.lycolia.info" "http://180.33.219.150"
curl: (7) Failed to connect to 180.33.219.150 port 80 after 7 ms: 接続が拒絶されました
curl "http://180.33.219.150"
curl: (7) Failed to connect to 180.33.219.150 port 80 after 6 ms: 接続が拒絶されました
HTTPステータスコードに444なんてあったっけ？と思ったらnginxの特殊コードの様で、このコードが指定されるとnginxはレスポンスを返さず、その場でTCPコネクションを切るらしい。
前述のdefault_serverのマニュアルを読み返すと軽く触れられていることに気がついたのでドキュメントを漁ったら根拠が出てきた。
公式ドキュメントのreturnに以下のようにあるため、コネクションを閉じ何も返さないという事は間違いなさそうだ。
Stops processing and returns the specified to a client. The non-standard code 444 closes a connection without sending a response header. code
GitHubではWebUIからPRのマージやファイル編集をしたときにコミットに署名がつくが、これをForgejoでもやる方法。
基本は公式にあるInstance Commit Signingの通り。
ssh-keygen -t ED25519 -f forgejo
ssh-keygen -y -f forgejo > forgejo.pub
sudo mv forgejo* /etc/forgejo
sudo chown git:git /etc/forgejo/forgejo
sudo chown git:git /etc/forgejo/forgejo.pub
/etc/forgejo/app.iniに設定を足す
[repository.signing]
FORMAT = ssh
SIGNING_KEY = /etc/forgejo/forgejo.pub
SIGNING_NAME = "Example Git Instance"
SIGNING_EMAIL = "noreply@git.example.com"
INITIAL_COMMIT = pubkey
WIKI = pubkey
CRUD_ACTIONS = pubkey
MERGES = pubkey
sudo systemctl restart forgejo.service
| 対応前 | 対応後 |
|---|---|
 |
 |
コミットに署名がつき、自分のアイコンが出るようになった。
但しGitHubとは違い、Forgejoが署名したことが分かる見た目になっている。
実はGitHubでもWebUIからの修正にはGitHubの鍵で署名が行われているのだが、GitHubではUI上その区別がない。Forgejo はその区別があるため、より明確な表示になったといえる。
コミット履歴のアイコンにForgejoがいるのが気に食わなかったので、自分のアイコンで上書きできてよかった。これで履歴の気味悪さを忘れてWebUIから気軽に治せる。
署名なしコミットは文字やアイコンが大きく、行も広くなるため、表示がしっくりこなかったので丁度よくなった。
MSYS2のGitって遅いよな～とつぶやいていたら公式から早くする方法があるよと紹介されたので、その時にやったこと。
この手順は私個人の環境に深く紐づいている。
| Env | Ver |
|---|---|
| MSYS2 | msys2-x86_64-20260322 |
@echo off
-set MSYSTEM=MSYS
+set MSYSTEM=UCRT64
set MSYS2_PATH_TYPE=inherit
set CHERE_INVOKING=1
C:\env\msys64\usr\bin\zsh.exe -l %*
pacman -Syu
pacman -Syu
pacman -S git
pacman -S mingw-w64-ucrt-x86_64-git
Windows側に入ってるGit for windowsも消していい気がしてきた。まぁそもそもGit作業は今のところUbuntu実機で行っている関係もあり、滅多に使わないのだが…。ただVSCodeでパスフレーズ付きのカギを扱うときにはあった方が良さそうだし、コミット用にはあった方が良さそうな気もする。
しかし過去情報の断面を残したいがために、出来るだけ過去記事の状態を保っているが、MECEでなくなりすぎていて大変なので、そろそろWiki的な何かを作った方がいい気がしてきた。
絶対に次にフルセットアップするときにこの状態に戻せない気がしている。
ところでMSYS2公式から助言をもらえたのはFediverseをやっていたお陰な気がするので、これはとても良い出来事だったと思う。
実行環境的にMSYSはCygwinでUCRT64はWindowsネイティブで速そうなので実行環境はMSYSTEMよりUCRT64のがいいのかなとか思った。
PHP-FPMとかの設定がvhostに散らばってて一元化したかったけど/etc/nginx/nginx.confにlocationディレクティブを書くと構造上エラーになるため、再利用可能なモジュールと切り出し各vhostの設定から呼び出して解決したログ。
PHP-FPMを設定する例
/etc/nginx/snippetsに適当な名前で.confを作る
/etc/nginx/snippets/php-fpm.conflocation ~ ^.+\.php$ {
fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param HTTPS on;
fastcgi_param SERVER_PORT 443;
}
読み込みたいvhostの.confから参照する
server {
listen [::]:443 ssl;
server_name hoge.example.com;
# ワイルドカード証明の設定も外出ししておくと共通化できて便利
include snippets/cert.conf;
client_max_body_size 100M;
root /var/www/hoge;
index index.php;
location / {
index index.php;
try_files $uri $uri/ =404;
}
include snippets/php-fpm.conf;
}