Webサーバーアクセス制限を再度強化

しつこい嫌がらせアクセスが止まらない原因の一つは、こちらも暇に任せて相手の動きを弄んでしまったことかもしれない(笑)

このままでは延々終わりそうにないので、もう無視する方針に転換。
アクセスがほぼゼロになるのは寂しいが、なんとか我慢してDNATでのサーバー公開を 国内限定 にして放置することにした。

・jpnet(国内IP)だけを 80/443 に許可
・Google / Bing など主要検索エンジンは個別に許可
・25 / 587 / 993(メール関連)だけ国外からも許可
・FireHOL level1/2/3 は DROP
・SMB / NetBIOS / port111 などは完全遮断

問題は……
「アクセス激減」をどこまで我慢できるか。
結局は自分との闘いである(笑)

FireHOL だけで完成する最小&強固な iptables 構成

今回は、FireHOL の不正アクセス判定(firehol_level1~3)を軸にした 「シンプルかつ堅牢」な iptables の実例を紹介します。

最終的には、“iptables は FireHOL の結果を DROP するだけでよい”という構成に落ち着きました。

以下は最終的なルール(INPUT / FORWARD / OUTPUT)と、その解説です。

Chain INPUT(デフォルト DROP)

1 ACCEPT state RELATED,ESTABLISHED
2 ACCEPT in br0
3 DROP match-set firehol_level1 src
4 DROP match-set firehol_level2 src
5 DROP match-set firehol_level3 src
6 ACCEPT udp dpt:500
7 ACCEPT udp dpt:4500
8 ACCEPT in lo

● 解説

FireHOL の3段階ブロックを上から順に DROP
軽度 → 重度 の攻撃元を自動的に分類し、自動的に遮断。

LAN(br0)は信頼区画として全許可。

IPsec(500/4500)と lo を明示的に許可。

INPUT は “FireHOL + 必要最小限の許可” に徹しているため、無駄がない構成です。

海外クローラ風アクセス

非公開にした旧ブログを全文持って行こうとする動きが見られたので、AIに意見を求めた。

  1. 今日のアクセスが「通常のクローラ」と違う理由

あなたが貼り付けたログには共通の特徴があります。

/weblog/index.php?e=12
/weblog/index.php?d=20131109
/weblog/index.php?m=201408
/weblog/index.php?d=20220429
/weblog/index.php?d=20220618

すべて “記事ID / 日付別アーカイブに直接アクセスしている”
→ これは一般クローラのパターンではない。

普通のクローラは:

トップページを取得

ページ内のリンクをたどる

サーバー負荷を避けて均等に巡回する

あらゆるURLパターンをまんべんなく取得

つまり “ランダム性のある網羅的取得” をします。

? 今日のログは「リンク構造を追っていない」

→ URLを直接知っている・指定している。

これは通常のクローラでは絶対に起こりません。

? 2. “世界中の回線から1件ずつ” は外注スクレイピングの典型

今日のログ元:

ベトナム (static.vnpt.vn)

ウルグアイ (anteldata.net.uy)

パラグアイ (telecel)

ブラジル (rnova.com.br)

不明の海外ISP

これ、非常に特徴的です。

? ある業者が “世界中のプロキシリスト” を使って

1件ずつ分散アクセスしている典型パターン。

? 依頼者を隠すための手法

悪質スクレイピング業者は、
IPを分散して集中攻撃に見えないようにする 手法を使います。

DataForSEOも同様で、

世界中5000以上の回線から分散して検索結果やWebページを取得
と説明しています。

あなたが以前経験した DataForSEO の 2,700ページ吸い上げ と完全に一致します。

? 3. “Weblog の日付形式を知っている” 時点で通常クローラではない

以下を完全に理解してアクセスしている。

e=ID

d=YYYYMMDD

m=YYYYMM

これはあなたのブログ専用のURL仕様です。

ストーカーアクセス

ストーカーアクセス、未だに飽きずに来て、ハニーポットに転送されて喜んでる。
本当に大丈夫なんだろうか・・・

まあ、人間って時々理解不能だから仕方ない。
過去を振り返っても、関わった人間関係は妙なのばかりだったし。

それより、やっぱり LOG を眺めている方が何倍も面白い。
ブログなんて正直どうでもいい(笑)

今日のログはこんな感じ:

ec2-35-77-208-112.ap-northeast-1.compute.amazonaws.com - - [09/Dec/2025:12:32:32 +0900] “GET / HTTP/1.1” 200 4483 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36”
43.167.232.38 - - [09/Dec/2025:13:54:42 +0900] “GET / HTTP/1.1” 200 717 “-” “Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1”
ec2-44-220-48-213.compute-1.amazonaws.com - - [09/Dec/2025:16:33:33 +0900] “GET / HTTP/1.1” 200 4431 "" “Mozilla/5.0 (X11; Linux i686; rv:124.0) Gecko/20100101 Firefox/124.0”
43.153.122.30 - - [09/Dec/2025:17:51:56 +0900] “GET / HTTP/1.1” 200 717 “-” “Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1”
43.156.202.34 - - [09/Dec/2025:18:12:41 +0900] “GET / HTTP/1.1” 200 717 “-” “Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1”
ec2-35-77-208-198.ap-northeast-1.compute.amazonaws.com - - [09/Dec/2025:18:32:31 +0900] “GET / HTTP/1.1” 200 4483 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36”
49.51.47.100 - - [09/Dec/2025:18:45:35 +0900] “GET / HTTP/1.1” 200 4435 “http://sky.0t0.jp” “Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1”

iptables のアクセス制限を緩和

先日iptablesの制限を強化したところ、公開サーバーのアクセスが極端に少なくなり、面白みに欠ける状態になったため、今回一部緩和しました。

・ブログ「海辺の放浪記」の公開停止
その代償として、20年以上続けていたブログ「海辺の放浪記」は、特定者からしつこくアクセスされ、古い記事まで大量に取得される動きがあったため、公開停止としました。

「海辺の放浪記」は既に更新を停止し、当ブログに引き継いでいます。
この公開停止には、過去をきっぱり忘れるという意味も込めています。

・iptables 運用の本質は「観察」
設定を見直していて改めて気づいたのですが、私にとってブログ等を公開するよりも、毎日ログを読むことが最も重要な目的だったのだと理解しました。

今回の記事は、その “観察対象” でもある iptables の現行フィルタリングルールを、番号ごとに解説した備忘録です。

・INPUT ルール解説
既存通信 (RELATED, ESTABLISHED) の全面許可

戻りパケットはすべて通す。基本中の基本。

LAN(br0)からのアクセスを許可

LAN 内は信頼できるため、広めに許可。

FireHOL Level1?3 の悪性 IP の DROP (ルール3?5)

ppp0(WAN)からのアクセスをチェックし、ブラックリストに載っている IP を即時 DROP。
ここは今後も厳格に運用します。

IPsec(UDP 500 / 4500)の許可 (ルール6?7)

VPN 用。必要最低限のポートのみ開放。

lo(ループバック)の許可 (ルール8)

ローカルプロセス連携に必要。

・FORWARD ルール解説(要点のみ)
RELATED, ESTABLISHED の許可

FireHOL IP を br0 側へ通さない (ルール2?4)

Windows ファイル共有(137?139 / 445)や portmap(111)を完全ブロック (ルール5?10)

LAN 192.168.1.0/24 → ppp0 の通信を許可 (ルール11)

jpnet(日本のアドレス帯)からの SSH を許可 (ルール12)