Raspberry Pi (Linux)

リッスンポートによるLOGの分離

去年7月から続くしつこい付きまといアクセスが終息に向かっている為、7月1日より正規サイトへの国内限定制限を解除している。

解除時の記事はこちら。
野良アクセス観測再開!?

制限解除以前は、正規サイト(Main Server)については国内ネットワークからのアクセスと主要サーチエンジンのクローラのみを通し、それ以外はすべて Others に振り分け、アクセスログも分離していた。
また、Others 側のコンテンツは正規サイト(Main Server)とは全く異なる内容としていた。

●過去の振り分けイメージ

Internet
   |
   v
+----------------------------+
|        Router              |
|     iptables / NAT         |
+----------------------------+
   |                      |
   |                      |
 Normal                 Suspicious
 / Allowed              / Unknown
   |                      |
   v                      v
+----------------+   +----------------+
| 192.168.1.1:80 |   |192.168.1.1:9080|
| 192.168.1.1:443|   |192.168.1.1:9443|
| Main Server    |   | Others         |
+----------------+   +----------------+

7月1日以降は、すべてのアクセスを正規サイト(Main Server)側へ通し、Others への振り分けを廃止したため、Others 側の構成は役目を終えていた。

何か活用できないか検討した結果、国内ネットワークからのアクセスのみを正規サイト(Main Server)へ通し、それ以外のWebアクセスはすべて Others 側へ振り分けることで、アクセスログを分離する目的に利用することにした。
Others 側の公開ディレクトリには、正規サイト(Main Server)のディレクトリへのシンボリックリンクを作成し、両者で同一のコンテンツを公開している。
サーチエンジンのクローラも Others 側へ振り分けられるが、コンテンツは正規サイトと完全に同一であるため、実用上の問題はない。

iptables構成

●PREROUTINGチェイン
PREROUTINGチェインにて、Main Server と Others への振り分けを完結させる。

Cloudflare から復帰(笑)

ほんの3日前に、本ブログを含む公開ブログ類をCloudflare移設したばかりだが・・・

Cloudflare の場合、詳細なアクセスログが取れず、3日で我慢の限界を迎えた(笑)

そこで、本ブログ(リタイア放浪記)のみ、自宅サーバー上に戻した。

Cloudflare の方はミラーとして残し、並行して更新する。

海辺の放浪記は更新終了しているし、そもそも元職場がらみと思われるつきまといぐらいしかアクセスが無いので、Cloudflare 上に放置。

●リタイア放浪記
https://sky.0t0.jp/retiredlog/ : メイン
https://retiredlog.pages.dev/ : ミラー

●海辺の放浪記
https://sky.0t0.jp/weblog/ : 旧URL(移設済)
https://seasideblue.pages.dev/ : メイン

結局、SEOより「自前」を優先(笑)

公開ブログ類をCloudflareに移設

自宅サーバーのベースである Raspberry Pi 2B が連続稼働10年を超え、寿命が近い可能性がある。

また、去年7月から続く嫌がらせのようなつきまといアクセスも収まらず、国内限定許可としていることもあって、ほとんどアクセスが無い状態が続いている。

そこで、スパムアクセスを自動排除してくれるという Cloudflare に公開ブログ類を移設することにした。

移設内容は下記の通り。

●リタイア放浪記
https://sky.0t0.jp/retiredlog/

https://retiredlog.pages.dev/

●海辺の放浪記
https://sky.0t0.jp/weblog/

https://seasideblue.pages.dev/

Hugo の静的サイトなので、手元でビルドして単一の ZIPアーカイブにまとめ、アップロードするだけでサーバー側が自動デプロイしてくれる。
呆気にとられるほど簡単だ。

ドメインは独自ドメインも使えるが、維持費用を避けるため、無償の pages.dev サブドメインのままでいく。
そもそもほとんどアクセスが無いのだから、これで十分だ(笑)

DDNS の自宅サーバーより Cloudflare の CDN 配信のほうが、SEO 的にも有利になるのではないかと期待している。

DKIMおよびDMARC導入

これまで長らくSPFのみでメールサーバーを運用してきたが、最近になってYahooメールなど一部のメールサービスで到達性に不安を感じる場面が増えてきた。
そこで、送信ドメイン認証を強化するため、DKIMおよびDMARCを追加導入することにした。

これにより、SPF・DKIM・DMARCの主要なメール認証方式が揃い、なりすまし対策やメールの信頼性向上が期待できる。

以下、その導入手順を備忘録としてまとめておく。

  1. 必要なパッケージのインストール

まず、OpenDKIM本体と鍵生成ツールをインストールします。

sudo apt update
sudo apt install opendkim opendkim-tools

  1. OpenDKIMの設定

/etc/opendkim.conf の編集
設定ファイルを開き、以下の項目を変更または追記します。
今回は確実でパーミッション問題の起きない TCPソケット(ポート8891) でSendmailと通信させます。

● ログ出力の設定
Syslog yes
SyslogSuccess yes

● 動作モード(s = 署名、v = 検証)
Mode sv

● 鍵やドメインのマッピング設定
KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
ExternalIgnoreList refile:/etc/opendkim/TrustedHosts
InternalHosts refile:/etc/opendkim/TrustedHosts

● Sendmailと通信するためのTCPソケット設定
Socket inet:8891@localhost

関連ファイルの作成

設定用のディレクトリを作成。

sudo mkdir -p /etc/opendkim/keys

① /etc/opendkim/TrustedHosts の作成

信頼する送信元(自分自身)を指定。

127.0.0.1
localhost
::1
sky.0t0.jp

② /etc/opendkim/KeyTable の作成

使用する鍵のセレクタ名(今回は dkim260605)と、ドメイン、秘密鍵のパスを紐付け。

dkim260605._domainkey.sky.0t0.jp sky.0t0.jp:dkim260605:/etc/opendkim/keys/sky.0t0.jp/dkim260605.private

ハニーポット切り替え合理化

海外からのアクセスは、その大半が攻撃やスキャンであるため、ハニーポットへ振り分けるという方針を基本としている。
これまで、主要サーチエンジン以外の海外アクセスについては、下記のように別ホストへ転送していた。

●これまでの振り分けイメージ

Internet
   |
   v
+----------------------------+
|        Router              |
|     iptables / NAT         |
+----------------------------+
   |                      |
   |                      |
 Normal                 Suspicious
 / Allowed              / Unknown
   |                      |
   v                      v
+----------------+   +----------------+
| 192.168.1.1    |   | 192.168.1.2    |
| Main Server    |   | Honeypot       |
+----------------+   +----------------+

従来は、Web以外のプロトコルも含めて転送可能とするため、ハニーポットを別ホストとして分離していた。
しかし最近では、対象をWebアクセスのみに限定しているため、この構成を見直した。
その結果、別ホストを維持するメリットが薄れたため、Apacheのリッスンポートを追加し、単一ホスト上のバーチャルホスト構成でハニーポットを実現する方式へ変更した。

●新しい振り分けイメージ

Internet
   |
   v
+----------------------------+
|        Router              |
|     iptables / NAT         |
+----------------------------+
   |                      |
   |                      |
 Normal                 Suspicious
 / Allowed              / Unknown
   |                      |
   v                      v
+----------------+   +----------------+
| 192.168.1.1:80 |   |192.168.1.1:9080|
| 192.168.1.1:443|   |192.168.1.1:9443|
| Main Server    |   | Honeypot       |
+----------------+   +----------------+

この構成により、物理・仮想ホストの分離を廃しつつ、ポート単位で役割を分離するシンプルな設計となる。
また、ログ管理や証明書運用も一元化できるため、運用負荷の低減にも寄与する。