Raspberry Pi (Linux) on リタイア放浪記

DKIMおよびDMARC導入

Fri, 05 Jun 2026 07:00:00 +0900

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

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

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

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

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

sudo apt update
sudo apt install opendkim opendkim-tools

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

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

Wed, 06 May 2026 09:00:00 +0900

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

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

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       |
+----------------+   +----------------+

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

正規サイトとハニーポット切り替え詳細

Fri, 10 Apr 2026 06:00:00 +0900

4月2日より、「深淵迎賓館仕様変更」、「シュレディンガーのサーバー」
の内容にてサーバー公開を行っているが、その後 iptables の改良を重ね、構成がほぼFIXしたため、その内容を覚書として記す。

●本構成の振り分けイメージ

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

上記の振り分けを、PREROUTINGチェインに集約した。
現在はPREROUTINGを確認するだけで、流入トラフィックの性質がほぼ把握できる状態となっている。

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1       44  2492 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:smtp match-set firehol_level3 src to:192.168.1.2:25
2        0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:smtp match-set firehol_level2 src to:192.168.1.2:25
3        5   228 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:smtp match-set firehol_level1 src to:192.168.1.2:25
4        2   120 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:smtp match-set gcloud src to:192.168.1.2:25
5        0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:smtp match-set other_block src to:192.168.1.2:25
6      126  6626 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:http match-set firehol_level3 src to:192.168.1.2:80
7       50  2592 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:http match-set firehol_level2 src to:192.168.1.2:80
8       12   580 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:http match-set firehol_level1 src to:192.168.1.2:80
9        2   100 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:http match-set gcloud src to:192.168.1.2:80
10       0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:http match-set other_block src to:192.168.1.2:80
11     255 13436 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:https match-set firehol_level3 src to:192.168.1.2:443
12      15   784 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:https match-set firehol_level2 src to:192.168.1.2:443
13      17   920 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:https match-set firehol_level1 src to:192.168.1.2:443
14       4   200 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:https match-set gcloud src to:192.168.1.2:443
15       0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:https match-set other_block src to:192.168.1.2:443
16      13   760 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:ssh match-set jpnet src to:192.168.1.1:22
17       1    60 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:smtp match-set jpnet src to:192.168.1.1:25
18       0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:smtp match-set searchengines src to:192.168.1.1:25
19       1    40 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:http match-set jpnet src to:192.168.1.1:80
20       3   180 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:http match-set searchengines src to:192.168.1.1:80
21      16   988 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:https match-set jpnet src to:192.168.1.1:443
22     176  9872 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:https match-set searchengines src to:192.168.1.1:443
23       0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:submission match-set jpnet src to:192.168.1.1:587
24       1    60 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:imaps match-set jpnet src to:192.168.1.1:993
25       7   356 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:smtp to:192.168.1.2:25
26     150  7602 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:http to:192.168.1.2:80
27     305 18288 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:https to:192.168.1.2:443
28       8   480 DNAT       tcp  --  ppp0   any     anywhere             anywhere             tcp dpt:2222 match-set jpnet src to:192.168.1.2:22

・firehol_level1～3 : FireHOLで公開されているブラックリストIPからのアクセスを Honeypot（192.168.1.2）へ振り分け
・jpnet : 日本国内からのアクセスを Main Server（192.168.1.1）へ振り分け
・searchengines : 主要サーチエンジンからのアクセスを Main Server（192.168.1.1）へ振り分け
・gcloud : スパムアクセスの多い Google Cloud からのアクセスを Honeypot（192.168.1.2）へ振り分け
・other_block : その他、不審と判断したアクセス（主に国内）を Honeypot（192.168.1.2）へ振り分け

Hugoへ移行しての所感

Sun, 01 Feb 2026 06:03:57 +0900

当サイトのブログをHugoへ移行して10日ほど経過し、テーマも最終の形態に落ち着いてきた。
サイトの使い勝手や見た目もblogn時代と比べ無駄を排除した上でかなり向上した。
特にphpの処理が無いため、記事数の多いweblogでも瞬時に表示される。
以前、weblogを記事数2935で公開していた時は、表示されるまでに2秒近くかかっていた。

もう一点、運用面で大きいのは精神的な負担が減ったことだ。
phpやDB、CMSの脆弱性を気にする必要がなく、壊れないものを淡々と置いておく感覚に近い。
個人ブログとしては、これが一番のメリットかもしれない。

また、Raspberry Pi上での運用という点でも、Hugoの相性は非常に良い。
ビルドは別環境で行い、サーバー側は単なる静的ファイル置き場として振る舞うだけなので、CPU負荷やメモリ使用量をほとんど気にしなくて済む。

Hugoへ移行して気になる点といえば、やはり投稿時の手間と、サーバー側ディスクの負担増である。
記事一点を追加する度にブログ全体をビルドして全ファイル差し替えとなるため、例えば本ブログ（retiredlog）の場合、下記ディスク占有容量である5.3Mバイト以上の書き換えが必要となる。
これは、記事数が増えればそれに伴い増加していく。

・retiredlog
記事数 88
pagefind 1.3Mバイト
ディスク占有容量 5.3Mバイト

もっとも、ディスク容量については記事数が数千規模になっても数百MB程度で収まる見込みであり、現実的には大きな問題にはならないだろう。
むしろ速度と単純さを優先した結果として、納得して受け入れている。

なお、写真やファイルについては、転送容量とディスク書き込み負担軽減のため、毎回全ファイルを転送する訳ではなく、サーバー側で別途ファイル専用ディレクトリーを用意して、下記(files)のようにシンボリックリンクを張っている。

/mnt/data/sky/retiredlog
合計 352
drwxr-xr-x 11 pi pi 4096 1月 29 06:51 .
drwxr-xr-x 14 pi pi 4096 1月 26 20:03 ..
-rw-r–r– 1 pi pi 8863 1月 31 15:23 404.html
-rw-r–r– 1 pi pi 111 1月 18 07:19 apple-touch-icon.png
drwxr-xr-x 2 pi pi 4096 1月 20 20:22 archives
drwxr-xr-x 8 pi pi 4096 1月 18 07:49 categories
drwxr-xr-x 2 pi pi 4096 1月 24 07:35 css
-rw-r–r– 1 pi pi 16958 10月 11 15:24 favicon.ico
lrwxrwxrwx 1 pi pi 41 1月 26 13:18 files -> /mnt/data/sky/blog_data/retiredlog/files/
drwxr-xr-x 2 pi pi 4096 1月 18 07:49 img
-rw-r–r– 1 pi pi 44360 1月 31 15:23 index.html
-rw-r–r– 1 pi pi 213825 1月 31 15:23 index.xml
drwxr-xr-x 2 pi pi 4096 1月 18 07:49 js
drwxr-xr-x 20 pi pi 4096 1月 30 13:38 page
drwxr-xr-x 4 pi pi 4096 1月 31 14:38 pagefind
drwxr-xr-x 89 pi pi 4096 1月 30 14:59 posts
-rw-r–r– 1 pi pi 12890 1月 31 15:23 sitemap.xml
drwxr-xr-x 3 pi pi 4096 1月 24 07:35 tags

Hugoテーマ Mainroad 改善

Sun, 25 Jan 2026 13:18:47 +0900

今日は朝から冷え込んで、路面にはうっすらと雪が積もっている。
こんな日は外に出ず、暖かい部屋でゆっくり過ごすに限る。

暇な日曜日の時間つぶしとして、このブログのHugoテーマ「Mainroad」の改善に着手した。
デザインは気に入っているが、一点だけ不便を感じていた「個別記事ページでの前後ナビゲーション」を追加することにする。

以下、自分用の備忘録を兼ねたカスタマイズ手順だ。

個別記事に「過去記事・未来記事」ボタンを追加

Mainroadの layouts/_default/single.html を編集し、記事のヘッダー部分にナビゲーションを配置した。
blogn時代のように、記事の冒頭で前後の流れを確認できるようにしている。

<nav class="post-nav flex">
    {{ with .PrevInSection }}
    <div class="post-nav__item post-nav__item--prev">
        <a class="post-nav__link" href="{{ .RelPermalink }}" rel="prev">
            <span class="post-nav__caption">≪&nbsp;過去の記事</span>
            <p class="post-nav__post-title">{{ .Title }}</p>
        </a>
    </div>
    {{ end }}
    {{ with .NextInSection }}
    <div class="post-nav__item post-nav__item--next">
        <a class="post-nav__link" href="{{ .RelPermalink }}" rel="next">
            <span class="post-nav__caption">新しい記事&nbsp;≫</span>
            <p class="post-nav__post-title">{{ .Title }}</p>
        </a>
    </div>
    {{ end }}
</nav>

メタ情報の整理（日付とカテゴリー）

境界線が二重にならないよう、テーマ標準の post_meta.html を活かしつつ、hugo.toml で表示を制御。
これで日付とカテゴリーがスッキリ一行に収まった。

[Params]
post_meta = [“date”, “categories”]

トップページへ戻るボタン追加

Sat, 24 Jan 2026 06:57:10 +0900

早起きは暇の元(笑)
土日は相変わらず暇だし・・・ということで、またhugoネタ。

分割ビューやアーカイブリストなど、順次下の方を閲覧したところでトップページに戻る場合、上にスクロールしてサイトタイトルをクリックする必要があった。
これはかなり不便なので、フッターに「トップページへ戻る」ボタン追加。

下記はその忘備録。
1). layouts\partials\footer.html

<footer class="footer">
	<div class="container footer__container flex">
		{{ partial "footer_links.html" . }}
		<div class="footer__copyright">
			&copy; {{ now.Format "2006" }} {{ .Site.Params.copyright | default .Site.Title }}.
			<span class="footer__copyright-credits">{{ T "footer_credits" | safeHTML }}</span>
		</div>
		/* 以下を追加 */
		<div class="footer-home-nav">
			<a href="/" class="home-button">トップページへ戻る</a>
		</div>
		
	</div>
</footer>

2). static\css\custom.css

以下を末尾に追加

/* ===== Home Button Style ===== */
.footer-home-nav {
  text-align: center;      /* 中央寄せ */
  margin: 5px 0 5px;     /* 上下に余白をとる */
  padding: 0px;
}

.home-button {
  display: inline-block !important;
  background-color: #333 !important; /* ボタンの色（白ベースなら赤 #e22d30 もおすすめ） */
  color: #ffffff !important;         /* 文字色（白） */
  padding: 10px 20px !important;    /* 押しやすいように大きめに */
  text-decoration: none !important;  /* 下線を消す */
  border-radius: 50px !important;    /* 角を丸くしてボタンらしく */
  font-weight: bold !important;
  font-size: 1.1rem !important;
  box-shadow: 0 4px 6px rgba(0,0,0,0.2); /* 少し浮かせて「押せる感」を出す */
  transition: transform 0.2s, background-color 0.2s;
}

.home-button:hover {
  background-color: #7aa2ff !important; /* ホバー時は青系に */
  transform: translateY(-2px);           /* 軽く浮き上がる演出 */
  color: #ffffff !important;
}

Mainroad ダークモードセットアップ

Thu, 22 Jan 2026 16:48:53 +0900

以前、blognでブログを運用していた頃も、最終的には背景がブラックのダークモードで落ち着いていた。
Hugo + Mainroad に移行後はホワイトベースがデフォルトだったが、やはり自分にはダーク系の方がしっくりくる。

今日は株取引の日でもあるのだが、相場を眺めていると、たまに阿保らしくなってくる（笑）

そこで今日は、相場チェックはそこそこにして、AIに相談しながら Mainroad のダークモード化をセットアップしてみた。

変更点は custom.css のみ。
テーマ本体には一切手を入れていない。

下記はその具体内容

● サイトをダーク系配色にする場合の custom.css 追記分
/static/css/custom.css

/* ===== Mainroad Dark Base ===== */
html, body, .container, .wrapper, .main, .sidebar, .post, .widget {
  background: #202020 !important;
  color: #d6d6d6 !important;
}

/* サイトタイトル・本文 */
.logo a, p, li {
  color: #d6d6d6 !important;
}

/* 見出し */
h1, h2, h3, h4, h5, h6 {
  color: #e6e6e6 !important;
}

/* リンク */
a {
  color: #7aa2ff !important;
}

a:hover {
  color: #a5c0ff !important;
}

/* ウィジェットタイトル下のライン：少し暗くして馴染ませる */
.widget__title {
  border-bottom: 2px solid #444 !important; /* #cccから変更 */
}

/* コードブロック：背景を少しだけ明るくして認識しやすくする */
pre, code {
  background: #2b2b2b !important; /* 全体背景より少し明るいグレー */
  color: #e6e6e6 !important;
  padding: 0.2em 0.4em;
  border-radius: 3px;
}

/* ===== Header & Titles ===== */

.header, .header * {
  color: #ADDFB3 !important;
}

.header svg {
  fill: currentColor;
}

.post__title, .post__title a {
  color: #90D7EC !important;
}

/* ===== Search Widget (Final Optimized) ===== */
/* 1. 検索フォーム全体の枠組み */
.widget-search__form {
  display: flex !important;
  background: #202020 !important;
  align-items: stretch !important;
  border: none !important;
}

/* 2. 入力欄（テキストボックス） */
.widget-search__field {
  flex-grow: 1 !important;
  background: #2b2b2b !important;
  color: #d6d6d6 !important;
  border: 1px solid #444 !important;
  border-radius: 4px 0 0 4px !important;
  padding: 10px !important;
  outline: none;
}

/* プレースホルダー（Search...の文字） */
.widget-search__field::placeholder {
  color: #888 !important;
}

/* 3. 検索ボタン */
.widget-search__submit {
  display: flex !important;
  align-items: center !important;
  justify-content: center !important;
  width: 60px !important;       /* 幅をスリムに固定 */
  min-width: 40px !important;
  padding: 0 !important;
  flex-shrink: 0 !important;
  background-color: #444 !important;
  fill: #ffffff !important;
  color: #ffffff !important;
  border: none !important;
  border-radius: 0 4px 4px 0 !important;
  margin-left: -1px !important;
  cursor: pointer;
  transition: background-color 0.2s;
}

/* 4. マウスを乗せた時の反応 */
.widget-search__submit:hover {
  background-color: #7aa2ff !important;
}

hugo + Mainroad でのブログ再構築内容（覚え書き）

Wed, 21 Jan 2026 07:31:48 +0900

Raspberry Pi 上のサーバーで処理するには重すぎるなど制約が多いため、Windows 版 Hugo を使用し、Windows 上でビルドする方法を採用した。

Hugo の静的サイトでは、記事を 1 件追加するたびにサイト全体をビルドし、サーバーへ同期コピーする必要がある。
一見手間に思えるが、リソースの限られた Raspberry Pi を前提とすれば、合理的な運用方法だと思われる。

ただし、記事の追加がやや面倒になるため、更新頻度は自然と下がるはず。
もっとも、つぶやきのような無駄な投稿が減ると考えれば、それはそれで良いのかもしれない（笑）。

以下、覚え書き。

Windows版　hugo

https://github.com/gohugoio/hugo/releases/hugo_extended_0.154.5_windows-amd64.zip

テーマ Mainbord

Linux機で下記
git clone https://github.com/Vimux/Mainroad.git ./mainroad

hugoサイト追加ファイル

① layouts\partials\post_meta.html

{{- $root := . -}}
{{- with .Param "post_meta" -}}
	{{- range $field := . -}}
		{{- $p := printf "post_meta/%s.html" $field -}}
		{{- partial $p $root -}}
	{{- end -}}
{{- end -}}

{{ with .Date }}
  <time datetime="{{ .Format "2006-01-02" }}">
    {{ .Format "2006-01-02" }}
  </time>
{{ end }}

② アーカイブリスト表示関連

Hugoへの移行記録

Sun, 18 Jan 2026 07:54:09 +0900

移行のきっかけ

長年使ってきた PHPスクリプトであるBlogn+ がOSのアップデートと共に動作しなくなってしまった・・・

PHP8に対応したブログスクリプトなども検討したが、今後の手間やセキュリティー向上のためPHPは削除し、流行りの「静的サイトジェネレーター（Hugo）」を選択。

苦闘したポイント

テーマ選び: 最初はAnankeを試したが、記事リストが出ず苦戦。最終的にアーカイブ機能に強い「Mainroad」へ。

hugo.tomlの呪文: Hugoのバージョンアップによる仕様変更や、サイドバーが表示されない「Warning」との戦い。

画像表示の壁: サブディレクトリ運用（/retiredlog/）特有のパス問題や、Markdown内の生HTMLを表示するための unsafe = true 設定など、一つずつパズルを解くような作業だった。

Hugo移行後のメリット

圧倒的な速さ: ラズパイ 2Bとは思えないほどページが瞬時に開く。

メンテナンスフリー: PHPもDBも不要なので、ハッキングの心配やアップデートの不安がゼロに。

運用スタイル: Windows側でビルドしてラズパイへ転送。大きな画像はラズパイ側で直接管理して効率化。

結び

記事を一件追加するごとにビルドが必要な「不便さ」はあるが、それ以上に「一生壊れない安心感」を手に入れた。

記事数が3000近い、更新停止した「海辺の放浪記」についても移植していこうと思う。

PPPoEマルチセッションとRaspberry Piの役割整理

Mon, 12 Jan 2026 09:55:48 +0900

― 余ったB+を「使わない」という選択 ―

祭日で相場も動かず暇なので、現在の自宅ネットワーク構成を整理しておく。

昨日まで、B+のサブルーター配下に攻撃やスキャンのLOGを集めるサーバーを置いてたけど、あほらしくなって廃止した(笑)
その関係で機器の役割を整理。

■ PPPoEマルチセッションの意義

PPPoEマルチセッションは、目的がはっきりしている場合にのみ意味がある。

・回線の論理分離
・実験・検証用トラフィックの隔離
・監視や観測時の挙動切り分け

単に「2セッション張れるから張る」では無意味だが、静かに分離するという思想には非常に相性が良い。

■ サブルーターとしてのRaspberry Pi B+

昨日まで、サブルーターには Raspberry Pi B+ を使用していた。

・上下とも実効22Mbps程度
・PPPoEマルチセッション配下

性能的には低いが、普段の用途では体感的な不足はない。

■ Pi2Bは「余剰」ではなく「予備」

一方、Pi2Bは LIVA-Z ルーターの完全な予備機として、

・等価設定
・定期メンテナンスのみ
・通常は電源OFF

という状態で維持していた。
このPi2Bは、出番が無い＝価値が無いではない。
むしろ、出番が無い状態を維持できている → 主系が安定している証拠である。

■ ではサブルーターはPi2Bの方が合理的では？

結論としては YES。

・サブルーターをPi2Bに変更
・B+は2台余る

という構成の方が、全体として無駄が少ない。

理由は単純で、

・サブルーターは「忘れていられる方が良い」
・Pi2Bの方がかなり余裕があり、100MbpsのVDSLサービス下ではボトルネックにならない。
・消費電力はB+と同等（軽負荷時2W程度）
・B+は予備や実験機として割り切れる

というわけで、今日からPi2Bの予備ルーターをB+のサブルーターと置き換え、メンテしながら継続使用することにした。

■ 余ったB+をどうするか

答えは拍子抜けするほど単純。

・何もしない
・電源を入れない
・役割を与えない
・ノイズを増やさない

1台は非常用の保険、もう1台は実験用、あるいは完全放置。
「余ったから使う」という発想は、設計を劣化させる原因になる。

■LIVA-Z（主系）とPi2B（サブ系）での役割の分離

主系のWebサーバー等をWAN側からチェックする様な場合や、単に気分転換に、クライアントからDOSコマンドでルーターやDNSサーバーを切り替えて使用。
あるいは、主系ルーターのアップデート時に主系をpoffして、デフォルトルートにサブ系ルーターを充ててアップデート。

■ サブルーターのもう一つの役割

―「一般ユーザー」を装った自己アクセス―

実はサブルーターには、もう一つ明確な用途がある。
それは、メインサイトに実アクセスが無い状態でも、一般ユーザーと同じ経路・条件で自分自身がアクセスすることである。

■ なぜ自分でアクセスするのか

静かなるインフラと、出番のない予備機

Wed, 07 Jan 2026 05:11:31 +0900

ルーターとして運用している LIVA-Z の傍らに、予備機として Raspberry Pi 2B を据えている。
設定も済ませ、いつでも切り替えられる状態だ。

しかし、ふと思う。
「この予備機に、本当に出番は来るのだろうか？」そもそも、これを用意した意味はあったのか。
そう考えて LIVA-Z の構成と運用状況を冷静に見つめ直すと、疑問の矛先は意外な方向へと向かっていった。

●LIVA-Z の寿命感：現実的な見積もり

小型PCを長期間運用するうえで、「結局、何年もつのか？」という問いは避けて通れない。
感情や期待値を排し、スペックと用途から冷静に寿命を見積もると、LIVA-Z は驚くほど長生きしやすい条件を満たしている。

ファンレス構造：可動部ゼロ。
物理故障のリスクが極めて低い。

低TDP（Atom / Celeron系）：熱ストレスが小さく、基板へのダメージが蓄積しにくい。

用途（ルーター／軽サーバー）： CPUもメモリも酷使せず、常に低負荷。

この条件なら、10年超えは余裕で射程圏内、15年生存も決して珍しくない。

実際、産業用PCや店舗用端末、組み込みLinux機といった「壊れないこと」を最優先に設計された同系統のハードウェアは、15?20年と稼働し続ける例がザラにある。

●本当の「故障ポイント」はどこか

もし LIVA-Z が先に死ぬとしたら、その原因は本体ではない可能性が高い。

電源周り： ACアダプタの劣化やDCジャックの接触不良。

ストレージ： eMMCの寿命（ただし、リードオンリー + OverlayFsでの運用なので負荷は極小）。

電解コンデンサ：低発熱環境下では劣化が非常に遅い。

結論として、「本体より先に、外付け要素が逝く」のが現実的なシナリオだ。

●「何年もつか？」への正直な答え

今の低負荷（ほぼアイドル状態）での運用を前提とするなら、予測はこうなる。

あと5年：余裕。

あと10年：普通にあり得る。

あと15年：条件次第だが否定できない。

しかし、ここでより重要な事実が浮かび上がる。

●先に来るのは「故障」ではない

多くの場合、ハードウェアの物理的な限界よりも先に訪れるのはこれだ。

「ハードが壊れる」よりも「興味が完全に消える」方が圧倒的に早い。

技術的な好奇心が他へ移るか、ネットワーク環境の規格そのものが変わるか。
そのスピードに比べれば、LIVA-Z の物理寿命はあまりに長い。

●完成されたインフラの皮肉

現状を整理すると、皮肉なほどに美しい構図が見えてくる。

LIVA-Z：沈黙を守り続ける、本命の主役。

Pi 2B：出番を待ち続ける予備役（おそらく、永遠に呼ばれない）。

この「予備機に出番がない」という状態こそ、インフラとしては理想的だ。
正常運転が続いている何よりの証拠なのだから。

●結論：Pi 2B という「お守り」の価値

無駄が無駄を呼ぶ

Sat, 03 Jan 2026 16:28:40 +0900

暇だから、シングルコアのラズパイB＋をPPPoEマルチセッションでルーターにして、クライアントPCからスループットを測定した。
100Mbpsのサービスではボトルネックにはなるが、十分使えるレベル。

クライアントからこのルーターにデフォルトルートを切り替えて使う意味は無いので、配下にDNATで攻撃LOG収集用のサーバーでもぶら下げるかな・・・それにしても暇だな(笑)

自宅ネットワークの入り口が二つになったが、意味あるのか？(笑)

一応VPNサーバーも載せてる。
firehol level1～3のipsetも問題なく載せられた。
Pi2Bと比べると、起動時間はかなり長い。

午後も暇だから攻撃収集用サーバーを組むか(笑)

B+がもう一台余っており、今後使うことはないんで、無駄な攻撃収集用サーバーとして無駄に活用するか・・・これぞ、無駄が無駄を呼ぶ典型パターン(笑)

というわけで、正規サーバーのSDカードをベースにB+で攻撃収集用サーバーをセットアップした・・・
それにしても暇な一日であった(笑)

正規サーバーは国内限定にしており、殆どアクセスが無くつまらないんで、暇に任せて用意した・・・
このようなスキャンや、その他攻撃を眺めるのが趣味なのか？(笑)

163.5.148.15 - - [03/Jan/2026:14:52:11 +0900] “GET /workspace/drupal/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 497 “-” “libredtail-http”
163.5.148.15 - - [03/Jan/2026:14:52:12 +0900] “GET /panel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 497 “-” “libredtail-http”
163.5.148.15 - - [03/Jan/2026:14:52:12 +0900] “GET /public/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 497 “-” “libredtail-http”
163.5.148.15 - - [03/Jan/2026:14:52:13 +0900] “GET /apps/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 497 “-” “libredtail-http”

別室のデスクの下にあるスペースに、メインサーバーと並べて配置。
無駄が無駄を呼ぶ構成の完成(笑)
メインサーバーは冷却効率を上げるためにアルミ板の上に置いてあるのが面白い。

Predictable namingを無効化するメモ

Fri, 02 Jan 2026 13:57:06 +0900

ヘッドレスでラズパイのSDカードを使いまわす場合、Predictable Network Interface Namesの命名ルールが邪魔になるので、無効化する。

① predictable naming を無効化

sudo nano /boot/cmdline.txt

1行の末尾に追記（改行しない）：

net.ifnames=0 biosdevname=0

② オンボードLANを eth0 に固定する udev ルール作成（必須ではない）

sudo nano /etc/udev/rules.d/70-onboard-eth.rules

中身（Pi 2 / 3 / B+ 共通）

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS==“smsc95xx”, NAME=“eth0”

③ /etc/network/interfacesを編集

オンボードNICのデバイス名をeth0に変更

④ SDカード移植後、machine-id を再生成

rm -f /etc/machine-id
systemd-machine-id-setup

●machine-idを直接生成して書き込む場合

・例として、別システムの /mnt/media/ にシステムディスクをマウントして書き込む場合
cat /proc/sys/kernel/random/uuid | tr -d ‘-’ | sudo tee /mnt/media/etc/machine-id

⑤ まとめ（実務視点）

・/etc が書ければ今回の作業は全部できる
・/boot は初回だけ
・SD 移植後は /etc だけ触れば復旧可能
・ヘッドレス運用でも詰まない

LIVA-Z故障後を見据えたルーター代替検討

Thu, 01 Jan 2026 09:34:23 +0900

2016年4月頃からは、本サーバーのみならずルーターもRaspberry Pi 2B（以下 Pi2B）で運用していたが、偶然見つけたNICが二式実装されている小型PC、LIVA-Zを衝動買い(笑)
2020年10月に、LIVA-Z をルーターとして入れ替えで導入し、すでに5年以上が経過している。

overlayfs を使ってシステムディスクを読み取り専用化しているため、ストレージ寿命の不安は小さいが、一般的にこの手の小型PCは電源周りが先に逝くことが多い。

負荷が低い用途なので、トータルで10年程度は持ちそうではあるものの、「いつかは壊れる」という前提で、次の置き換え候補を考えておくのは無駄ではない。

現状はRaspberry Pi によるWi-Fi AP付 PPPoEルーターの構成にある記事の構成となっているが、暇な年末年始の時間を使い、現在LIVA-Z で運用しているルーター構成をほぼそのまま移植してみた。

●移植した構成

・iptables / ipset を用いたフィルタリング
・各種スクリプト類（更新・定期処理含む）
・常時稼働前提の最低限構成

LIVA-Z 側と極力差が出ないようにし、「置き換えたらどうなるか」をそのまま再現する形にしている。

●処理能力の差は明確

まず感じたのは、純粋な処理能力の差。

特に、

・ipset のアップデート所要時間
・大量ルールを一気に適用する場面

では、LIVA-Z の方が明らかに速い。

この点については ARM SoC の Pi2B が劣るのは当然で、性能面では割り切りが必要になる。

●それでも問題にならない理由

一方で、実運用において重要なスループットに関しては、結果は意外だった。

100Mbps クラスのサービス環境下では、Pi2B でも LIVA-Z と体感上ほとんど差がない

回線速度がボトルネックになる以上、ルーター側のCPU パワーは余剰になりがちだ。
USB NIC を追加した Pi2B でも、スループット面で不満を感じる場面はなかった。

●Pi2Bを代替候補として見る理由

Pi2B をあらためて「LIVA-Z の代替」として見ると、以下の点が大きい。

・低コスト

本体も周辺部品も安価で、壊れても精神的ダメージが少ない。

・構造がシンプル

電解コンデンサレスのボード構成で、経年劣化要因が少ない。

・バックアップと復旧が容易

SDカードを丸ごとバックアップしておけば、故障時も即リカバリ可能。

この復旧性の高さは、小型PCにはない安心感がある。

結論：LIVA-Zが止まったら、素直にPiで行く

処理能力では LIVA-Z に及ばないものの、100Mbps 環境でのルーター用途に限れば Pi2B でも十分現実的だという結論になった。

Pi2Bが10年連続稼働

Wed, 31 Dec 2025 08:11:59 +0900

2016年1月から常時稼働している Raspberry Pi 2 Model Bで構成したサーバー、以後一度も停止させることなく現在に至る。

気がつけば、早くも連続稼働10年。
しかも本体だけでなく、電源アダプタ（Chicony W12-010N3A）も同一個体のままだ。

ラズパイは「安価な実験用ボード」というイメージが強いが、この実機の稼働実績を見る限り、少なくとも Pi2B はその枠を大きく超えている。

では、なぜここまでもっているのか。
改めて条件を整理してみる。

●電解コンデンサレスという設計

Pi2B のボード上には、いわゆる寿命部品である電解コンデンサが存在しない。

・液漏れ
・容量抜け
・経年劣化

といった、時間で確実に進行する要素がない。
これは長期稼働において決定的に大きい。

ボード故障の多くは電源周りから始まるが、その最大要因がそもそも存在しない設計というのは強い。

●発熱が少なく、温度サイクルが穏やか

Pi2B（Cortex-A7 ×4）は性能こそ控えめだが、

・常時フルクロック
・サーマルスロットリングなし
・ファンレスでも温度が安定

という特性を持つ。

結果として、

・急激な温度変化がない
・半導体へのストレスが小さい

「性能を削ってでも安定を取った」世代と言える。

●連続稼働という“優しい使い方”

電源の ON / OFF を繰り返さないことも大きい。
電子機器にとって最も負担がかかるのは、

・電源投入時
・温度が一気に変化する瞬間

この Pi2B は、

・落とさない
・再起動しない
・常に同じ環境（空調のない部屋なので、それなりの温度変化はある）で動き続けている

という、機器にとって理想的な条件に置かれている。

●負荷をかけない用途

用途は軽量なサーバーで、

・CPU負荷は低い
・I/Oも控えめ
・書き込みは最小限（システムディスクは読み取り専用）

無理をさせていない。
これは「10年持たせる」運用としては正解だったと思う。

●電源品質がすべてを左右する

意外に思われるかもしれないが、10年無事に動いている最大の要因は電源かもしれない。

・定格に余裕のあるACアダプタ
・発熱しない配置
・抜き差しをほとんどしない

電源が安定している限り、Pi2B 本体は驚くほど粘る。

●現時点での結論

・Pi2B 本体：異常なし
・電源：10年経過でも兆候なし
・SDカード：消耗品だが交換可能

Webサーバーアクセス制限を更に強化

Fri, 19 Dec 2025 05:48:41 +0900

これまで、googlebotを許可するためにAS15169を許可していた。

Googlebot (AS15169)

echo “? - Fetching Googlebot ranges (AS15169)…”

whoisの出力を直接一時ファイルにリダイレクト

timeout 60 whois -h whois.radb.net -- ‘-i origin AS15169’
| grep -Eo ‘([0-9]{1,3}.){3}[0-9]{1,3}/[0-9]+’ » “$TMP_IPLIST” || true

これだと、下記のようにbc.googleusercontent.comからのスキャンを通してしまう・・・

162.15.169.34.bc.googleusercontent.com - - [18/Dec/2025:16:27:32 +0900] “GET //wp-includes/wlwmanifest.xml HTTP/1.1” 404 501 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4240.193 Safari/537.36”
162.15.169.34.bc.googleusercontent.com - - [18/Dec/2025:16:27:32 +0900] “GET //xmlrpc.php?rsd HTTP/1.1” 404 500 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4240.193 Safari/537.36”
162.15.169.34.bc.googleusercontent.com - - [18/Dec/2025:16:27:32 +0900] “GET / HTTP/1.1” 200 897 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4240.193 Safari/537.36”

MyDNS×Certbot(DNS-01)でSSL証明書を全自動更新

Wed, 17 Dec 2025 14:08:43 +0900

■ はじめに：なぜDNS-01認証なのか
通常、Certbotでよく使われるのは80番ポートを利用した http-01 認証（ACMEチャレンジ）だが、本環境ではセキュリティ対策として 80番ポートおよび443番ポートへのアクセスを国内限定に絞っている。

Let’s Encryptの認証サーバーは海外からもアクセスしてくるため、この制限下では通常のWeb認証が通らない。
そこで、ポート開放状況に左右されずに証明書を発行・更新できる DNS-01チャレンジを採用した。

また、ハニーポット（迷い込み用サイト）運用において、あえて正規ドメイン（sky.0t0.jp）用の証明書をハニーポット側にセットすることで、アクセス者に「ドメイン不一致の警告」を見せ、意図的に隙があるように演出している。
この正規証明書の更新プロセスを自動化した際の記録。

■ 1. 構築環境と課題
・対象ドメイン: sky.0t0.jp, deepsky.0t0.jp

・手法: Certbotの manual モード＋ MyDNS DirectEdit（PHPスクリプト）

・直面した課題: certbot renew を実行すると、設定ファイル (.conf) に dns と記述していても、なぜかhttp-01 認証（Web 経由のチャレンジ）を試行してしまい、更新に失敗する。

■ 2. なぜ設定ファイルの記述だけでは不十分なのか
検証の結果、Certbotの仕様による以下の挙動が原因であることが判明した。

・設定ファイルの限界: /etc/letsencrypt/renewal/xxx.conf 内に preferred_challenges = dns と書いても、コマンドライン引数で明示的に上書きしない限り http-01 認証が実行されてしまう。
Certbot 1.12.0 では、renew 実行時に認証方式が明示されていない場合、manual 認証であっても http-01 が選択される挙動が確認された。
renewal 設定ファイル内の preferred_challenges = dns だけでは、この挙動を抑止できないケースがある。

・解決策: challenge 選択の曖昧さを回避するため、実行コマンド側に直接オプションを付与する必要がある。

■ 3. 運用のポイント：certbot.timer に頼らない自動化
certbot.timer はディストリビューション標準の ExecStart 設定で certbot renew を実行するため、
認証方式を上書きするオプションを注入できない。
そのため、上述した「履歴優先」の仕様によって http-01 に戻ってしまい、DNS-01認証が動かない。

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

Sat, 13 Dec 2025 05:40:04 +0900

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

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

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

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

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

Thu, 11 Dec 2025 14:21:48 +0900

今回は、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 + 必要最小限の許可” に徹しているため、無駄がない構成です。

iptables のアクセス制限を緩和

Tue, 09 Dec 2025 06:21:18 +0900

先日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)

FireHOL Level3 導入

Mon, 08 Dec 2025 05:53:31 +0900

ルーターでのDNAT構成において、FORWARDチェインでのルールを一部変更。

FireHOL Level1・Level2 だけでは、中国系からの SMTP SPAM が一部漏れてくる為、これまで中国全域（CN zone）を丸ごと DROP していました。

しかし、メールサーバ側で zen.spamhaus による強力なフィルタリングが効くため、国単位（CN zone）の大味なブロックは必ずしも必要ではない状況になっていた。

そこで、IP国家ブロックではなく、より精度の高い “悪性アドレス集合ベースの防御” に切り替える方針へ変更。

変更点

CN zone（中国 IP 全域 DROP）を廃止

代わりに FireHOL Level3 を追加

FireHOL Level3 は、既知のスパム・ボットネット・脆弱性スキャンなど
“より積極的に悪性と判定されているアドレス” を対象に含むため、
国家単位のブロックよりも必要十分で副作用の少ないブロックを実現できます。

現行のフィルタ構成（説明付き）

以下は現在の iptables ルールセットに、解説を付加したものです。

■ INPUT チェーン（WAN→自サーバの防御）
Chain INPUT (policy DROP)

→ 基本は DROP。必要な通信だけを例外許可する「ホワイトリスト方式」。

1 ACCEPT RELATED,ESTABLISHED

既存の通信の戻りはすべて許可（最重要ルール）。
接続中の HTTP/HTTPS や SSH の応答を止めないため。

2 ACCEPT all br0

LAN 内（192.168.1.x）からのアクセスは完全許可。
管理用のローカル接続を遮断しないようにするため。

3 DROP firehol_level1

外部からの新規接続で、FireHOL Level 1（悪性度高）に該当するホストを遮断。
→ 基本のマルウェア・スパム送信元の大半を撃退。

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

Sat, 06 Dec 2025 06:15:14 +0900

半年近く続いている不審なアクセスについて、現在のところ原因は特定できていないものの、個人的には以前の人間関係や環境が影響している可能性も否定できないと感じている。

ただし、技術的には海外クラウドやスキャナーによる通常の自動アクセスである可能性も高く、どちらとも断定はできない。
とはいえ、同じパターンが長期にわたって続くことや、アクセスの時間帯・性質に一定の特徴があることから、単なる一般的なトラフィック以上の何かを感じてしまうのも正直なところだ。

この数か月、アクセス動向を観察するために、あえて設定を変えて反応を見てきたが、期待したような建設的な兆候は得られず、むしろ予測しづらい動きが多かった。
また、海外アクセスを数日間だけ開放した際には、20年以上続けているブログ「海辺の放浪記」の古い記事まで一気に取得される動きがあり、さすがに気味の悪さを感じた。

そこで今回、海外からの不審な接続を減らす目的で、ルーター側のDNATや iptables/ipset ルールを大幅に見直し、より厳格なアクセス制御に切り替えた。

① ブラックリスト → 国別ブロックが先頭
2 DROP firehol_level1　（FireHOLで公開されているIPブラックリスト）
3 DROP firehol_level2　（FireHOLで公開されているIPブラックリスト）
4 DROP cn_block　　（中国全域）
5 DROP other_block　（その他、しつこく不審アクセスがあったネットワーク）

→ 海外 AWS/GCP/中国/その他が最初に落ちる。

② LAN → WAN を許可
12 ACCEPT br0→ppp0 192.168.1.0/24 → ANY

→ 家庭内のPCやスマホの外向き通信は全部通る。

③ WAN → LAN（サーバー）を「国内限定」許可
13 SSH (22) 国内
15 HTTP (80) 国内
16 HTTP (80) サーチボット
17 HTTPS (443) 国内
18 HTTPS (443) サーチボット

やはり中国・・・

Sat, 29 Nov 2025 06:49:36 +0900

FireHOL Level 1-> FireHOL Level 2 の順にDROP条件を追加していったが、やはりSPAMメールのアクセスが漏れてくるので、結局中国全域のDROPを追加。

中国は野良サーバーの排除を行わないと、国として信頼できないですよ！(笑)

ここまでやれば、殆どSPAMメールのアクセスが漏れてくることは無いが、全ての攻撃を消すことは不可能。

順序　ipset　　　　　　　　説明
1　　　firehol_level1　　　広範囲かつ静的な脅威をブロック
2　　　firehol_level2　　　最新かつ動的な脅威をブロック
3　　　cn_block　　　　　　中国全域をブロック
4　　　other_block　　　　その他のブロックリスト

システムリブートでのiptables/ipset自動復旧

Sun, 02 Nov 2025 06:30:34 +0900

停電や再起動のあと、PPPoEが自動接続されてもiptablesがデフォルトのままではセキュリティレベルが低い状態でサーバが公開されます。

そこで、リブート時にipsetによる制限などを自動復旧する内容を実装しました。

overlayfs環境などで設定復元を安定させるには工夫が必要です。

そこで、PPPoE確立後に自動でiptables/ipsetを初期化し、ブート後一度だけ外部リストをDL更新する構成を組みました。
結果として、停電やリブートが起きても、何もしなくても通信制御が完全に復元されます。

?? 背景

PPPoEは起動時に自動接続されるよう設定済み（/etc/network/interfaces）

iptables・ipsetの設定は /mnt/data/sh/restore_japan_only.sh にまとめてある

外部サイトから更新リストをDLする重い処理（update_ipset.sh）は再接続のたびに実行したくない

/etc/ppp/ip-up.d/ は overlayfsで直接編集できない

解決策の方針

/etc/ppp/ip-up.d/ にラッパースクリプトを1本だけ置く

まず軽量な restore_japan_only.sh を即実行して通信ルールを復元

ブート後の最初の接続時だけ update_ipset.sh をバックグラウンドで走らせる

/run/update_ipset_done で再実行を防止（再起動時に自動リセット）

実際のスクリプト

/etc/ppp/ip-up.d/99boot_update_ipset

#!/bin/bash

Run restore_japan_only.sh immediately and update_ipset.sh only once after boot

FLAG_FILE="/run/update_ipset_done"
LOGFILE="/var/log/update_ipset.log"

echo “$(date ‘+%Y-%m-%d %H:%M:%S’) [ip-up] PPPoE connected” » “$LOGFILE”

軽量な初期化スクリプト（iptables/ipsetの空構築）

echo “Running restore_japan_only.sh…” » “$LOGFILE”
bash /mnt/data/sh/restore_japan_only.sh » “$LOGFILE” 2>&1

ブート後初回のみ、ipset更新処理をバックグラウンドで実行

if [ ! -f “$FLAG_FILE” ]; then
echo “First PPPoE connection detected ? running update_ipset.sh…” » “$LOGFILE”
/mnt/data/sh/update_ipset.sh » “$LOGFILE” 2>&1 &
touch “$FLAG_FILE”
else
echo “update_ipset.sh already executed, skipping.” » “$LOGFILE”
fi

Spamhaus DROPリストを利用した ipset によるスパム対策

Thu, 02 Oct 2025 05:43:17 +0900

不眠症による早起きで、暇なんでまとめた(笑)

●はじめに

サーバをインターネットに公開していると、常に海外からの不正アクセスやスパムメールの試行が行われています。
特に SMTP (port25) はボットネットや踏み台サーバからの接続が多く、メールサーバ管理者にとって大きな負担となります。

そこで有効なのが Spamhaus の DROP/EDROP リストを活用したフィルタリングです。
このリストは「正規用途が一切ない、完全に不正利用されているネットレンジ」だけを収録しており、誤判定のリスクが極めて低いのが特徴です。

これを ipset に取り込み、iptables と組み合わせることで効率的にスパム元を遮断できます。

MTAのDB参照にて拒否することを併用しますが、LOGが汚れがちになるのでリストに登録分はあらかじめルーターやホストでDROPする内容です。

●ipset と Spamhaus DROP リスト

・iptables はルールが多くなると管理や処理が重くなる
・ipset を使うと「大量のIPレンジ」を一つの集合として扱えるため、効率的なフィルタリングが可能
・Spamhaus DROPリストは数千?数万の不正レンジを提供しており、これを ipset にまとめるのが最適

●実装手順

ipset作成

sudo ipset create spamhaus_drop hash:net family inet hashsize 1024 maxelem 65536

自動取得スクリプト作成

/usr/local/bin/update_spamhaus_ipset.sh

#!/bin/bash
IPSET_NAME=“spamhaus_drop”

ipsetが存在しない場合は作成

if ! ipset list -n | grep -q “^${IPSET_NAME}$”; then
ipset create ${IPSET_NAME} hash:net family inet hashsize 1024 maxelem 65536
fi

443ポートを塞いだまま Let’s Encrypt 更新

Fri, 05 Sep 2025 06:08:59 +0900

ここ最近、ストーカーのような海外アクセスが多く、
サーバーの 443 ポートを「日本＋検索ボット限定」に絞り込んでいました。

ところが、思わぬ副作用が。
Let’s Encrypt（certbot）で証明書を更新しようとしたところ、

Timeout during connect (likely firewall problem)

というエラー。
原因は認証サーバーが海外から 443 にアクセスしてくるのに、こちらで塞いでいたため。

試行錯誤の記録

preferred-challenges = http を設定してみた
→ でも /.well-known/acme-challenge/ が https にリダイレクトされてしまうため、やはり失敗。

ログに outbound1.letsencrypt.org のアクセスを発見！
→ これで「確かに来ているのに 301 リダイレクトされてる」ことが判明。

RewriteCond で acme-challenge を例外扱いに修正

RewriteEngine On

Let’s Encrypt 用は例外

RewriteCond %{REQUEST_URI} ^/.well-known/acme-challenge/ [NC]
RewriteRule ^ - [L]

それ以外は HTTPS 強制 & 正規ドメイン以外拒否

RewriteCond %{HTTP_HOST} !^(www.|pacific.)?sky.0t0.jp$ [NC,OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ %{REQUEST_URI} [R=301,L]