Stardust✨のおもちゃ箱

Hello World

Mon, 12 Oct 2026 00:00:00 GMT

こんにちは、Stardust✨です。技術ブログ「Stardust✨のおもちゃ箱」を始めました。

print("Hello, World!")

最初の記事なので、このブログの出発点を書いておきます。前のホームページのトップに掲げていた、マニフェストです。

マニフェスト（2025-12-27）

本日2025年12月27日、Web3の世界が徐々にですが確実に拡大しているのを感じます。私たちは一度は奪われたインターネットを我々の手に取り戻すチャンスを突如手に入れました。このまたとない機会を逃してはいけないとひしひしと感じるのです。そうでしょ？アングラの諸兄達。僕はまだ此処にいるよ。（ ´ー｀）y―┛~~

あなたはThe Matrixという映画を見たことがありますか？
あの映画は現実社会に実在するバビロンシステムを抽象化し、比喩的な表現の結果として生まれた作品です。
多くの人はMatrixに囚われて人生の大半の時間を費やしており、気づくことなく人生を終えることも少なくありません。
インターネットは黎明期（Web1時代）には意外なことに分散化されており、Matrixに囚われていなかったと記憶しています。
Web2時代にはインターネットの表層が企業に支配されましたが、Web3ではWeb2で育んだ技術をブロックチェインと連携させ、インターネットは再び分散化を目指します。

長きに渡って続いた自由への戦いはWeb3時代を迎え、ついに我々の勝利という形で終結を迎えるはずだ。
インターネットの片隅からMatrixに抗うことを此処に誓う。((*´∀`))ｹﾗｹﾗ

このブログで書くこと

インターネットを取り戻すには、使うだけでなく、自分の手で動かせるようになることだと思っています。なので、ここには AI・Web3・botter で手を動かした記録を書いていきます。うまくいったことだけでなく、つまずいたことも残すつもりです。

それから、サイバーセキュリティにも興味があります。自由なインターネットは、自分の身を自分で守れてこそだと思うからです。鍵やパスワードをどう扱うか、自分のサーバーをどう守るか、AI にどこまで任せてよいか。手を動かしながら考えたことを、ここにも書いていきます。(｀・ω・´)ゞ

特に気になっているのが、Web3 のセキュリティです。Web3 では、ウォレットの秘密鍵を持つ人が資産の持ち主で、銀行のように代わりに守ってくれる人はいません。署名ひとつで資産を失うこともあるし（((( ；ﾟДﾟ)))ｶﾞｸﾌﾞﾙ）、スマートコントラクトの穴やフィッシング、ブリッジへの攻撃で大きなお金が動く事件も起きています。インターネットを自分の手に取り戻すなら、自分で守る力も一緒に身につけたい。ウォレットやコントラクト、署名の仕組みを調べて試したことも、ここに残していきます。

その第一歩として、このブログも借り物の場所ではなく、自分のサーバーに置きました。

Astro のテンプレート Fuwari で作っています
記事は Markdown で書いて、自分で借りた VPS（nginx）から配っています
ドメインは .box。ENS（Ethereum の上の名前）としても使える stardust.box です
証明書は Let's Encrypt です

インターネットの片隅から、どうぞよろしくお願いします。（ ´ー｀）ﾉｼ

GitHub Pages から自分の VPS へ引っ越した（DNS の古い値に 2 回つまずいた話）

Mon, 12 Oct 2026 00:00:00 GMT

stardust.box は、これまで GitHub Pages で出していました。今回、自分で借りた VPS に引っ越して、このブログ（blog.stardust.box）もそこから配るようにしました。Hello World に書いた「借り物の場所ではなく、自分のサーバーに」の中身です。

作業そのものは 1 日で終わりましたが、DNS の古い値に 2 回つまずきました。(；´Д`)

やったこと

ブラウザ ──(DNS)──> my.box で管理している stardust.box
   │
   └──(HTTPS)──> VPS（Debian・nginx・Let's Encrypt）
                    ├─ blog.stardust.box … このブログ（Astro でビルドしたもの）
                    └─ stardust.box・www … いまはブログへ一時的に移す（302）

VPS に nginx を入れ、サイトごとに設定のファイルを 1 つずつ置いた
手元でブログをビルドし、rsync で VPS に送った
DNS（.box ドメインの管理画面）に、blog の A・AAAA レコードを足した
certbot で Let's Encrypt の証明書を取った（http:// から https:// への移動も certbot が入れてくれる）
GitHub Pages を指していたレコードを消し、stardust.box と www を VPS に向けた
GitHub のリポジトリを消した（中身は手元の Git サーバーに控えがある）

つまずき 1: 証明書が取れない

stardust.box の DNS を VPS に向けた直後に certbot を実行したら、失敗しました。

Domain: stardust.box
Type:   unauthorized
Detail: 185.199.111.153: Invalid response from http://stardust.box/.well-known/acme-challenge/...: 404

185.199.x.x は GitHub Pages の IP です。Let's Encrypt が確かめに行った先が、まだ古いほう（GitHub）だったわけです。DNS の答えは、TTL（覚えておく時間。今回は 3600 秒）のあいだ、あちこちに残ります。

ここで何度もやり直すのは危ないです。Let's Encrypt には、確かめの失敗は 1 時間に 5 回までという制限があります。なので、公開の DNS（Cloudflare と Google）が新しい値を返すまで、1 分ごとに確かめる小さなスクリプトを回して待ちました。

# Cloudflare と Google の DNS が、どちらも VPS の IP を返すまで待つ（考え方だけ）
while not all(answer(server, name) == {VPS_IP} for server in SERVERS for name in NAMES):
    time.sleep(60)

今回は 2 分ほどで変わり、2 回目で取れました。証明書は、DNS が変わったのを確かめてから取る。

つまずき 2: ブラウザだけ昔のページが出る

コマンド（curl）で確かめると、ちゃんと新しいサーバーにつながります。なのに、ブラウザで stardust.box を開くと昔のページが出る。( ﾟдﾟ)

ブラウザの開発者ツールで、ページがどう届いたかを見ると、手がかりがありました。

performance.getEntriesByType('navigation')[0].nextHopProtocol  // => "h2"

キャッシュ（手元の控え）ではなく、ネットワークから HTTP/2 で届いていました。私の nginx はまだ HTTP/2 を有効にしていないので、相手は GitHub のサーバーです。

ブラウザは、速くするために、一度つないだサーバーとの通信をしばらく使い回します。DNS の答えも、ブラウザの中に少し覚えています。DNS を変えても、その古い通信が生きているあいだは、昔のサーバーにつながり続けるわけです。

Chromium 系のブラウザ（Brave など）なら、次の 2 つで消せます。

brave://net-internals/#dns で「Clear host cache」
brave://net-internals/#sockets で「Flush socket pools」

GitHub のリポジトリを消したあとにもう一度起きたときは、GitHub の「Site not found」の 404 が出ました。同じやり方で直りました。

気をつけたこと

302 にした: stardust.box は、いずれ自己紹介のサイトにする予定です。なので、ブログへの移動は 301（ずっと移動）ではなく 302（一時的な移動）にしました。301 はブラウザや検索エンジンが長く覚えてしまうので、あとで差し替えにくくなります
知らない名前の来訪は断る: IP アドレスで直接来たり、知らない名前で来たりした人には、何も返さずに接続を閉じるようにしました。これをしないと、設定のファイル名の順で最初のサイトが出てしまいます

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    server_name _;
    ssl_reject_handshake on;  # 証明書も出さずに TLS を断る（nginx 1.19.4 から）
    return 444;               # nginx 独自の「何も返さずに閉じる」
}

送る前に検査する: ブログを送るスクリプト（Python）は、ビルドしたものに、サーバーの IP や手元のパスなどの内部の情報が入っていないかを調べてから送ります。公開のサイトなので、うっかりを機械で止めます

まとめ

DNS を変えたら、答えが変わったのを確かめてから次へ進む（証明書は特に。失敗には回数の制限がある）
「コマンドでは直っているのにブラウザだけ古い」ときは、ブラウザの中の DNS の控えと、つながったままの通信を疑う
一時的な移動は 302

自分のサーバーにすると、こういうところまで全部自分で見ることになります。でも、そのぶん中で何が起きているかが分かって楽しい。インターネットの片隅から、少しずつ取り戻していきます。((*´∀`))

サーバーを立てて 7 時間で、知らない誰かが 132 回ログインしに来た

Mon, 12 Oct 2026 00:00:00 GMT

前の記事で、このブログを自分の VPS に引っ越しました。その VPS の SSH のログを、立てた初日に見てみたら、こうでした。(((( ；ﾟДﾟ)))

サーバーを起動してから 約 7 時間
存在しないユーザー名でのログインの試しが 132 回
root でのログインの試しも、たくさん
そのうち 9 つの IP が、自動で締め出されていた

インターネットにサーバーを出すと、こういうものが勝手に来ます。名前も宣伝もしていない、立てたばかりのサーバーにです。

来ていたユーザー名

ログ（journalctl -u ssh）から、試されたユーザー名を数えました。

ユーザー名	回数
`admin`	24
`user`	7
`apache`	4
`sysadmin`・`postgres`	3
`test`・`newuser`・`user02` など	2

よくある名前を、片っ端から試しています。人が手で打っているのではなく、インターネット中の IP を順に叩いて回るプログラムです。

でも入れない

このサーバーの SSH は、最初からこうしてあります。

passwordauthentication no   # パスワードでは入れない
permitrootlogin no          # root では入れない
pubkeyauthentication yes    # 鍵だけで入れる

パスワードを当てに来ても、そもそもパスワードでは入れません。鍵が無ければ、何回試しても入れない。なので、132 回来ても怖くはないです。

それでも、ログが当て試しで埋まるのは気持ちよくないし、相手に何度も試させる理由もありません。そこで働いているのが fail2ban です。

fail2ban がしていること

fail2ban は、ログを見張って、失敗を繰り返す IP をファイアウォールで締め出す道具です。今回の VPS（ConoHa の Debian 13）には、最初から入っていました。

知らない IP ──SSH のログインの試し──> sshd ──失敗をログに書く──> ログ
                                                             │ 見張る
                                                             v
知らない IP <──次からは届かない── nftables <──締め出す── fail2ban
                                 （10 分に 5 回失敗した IP）

設定は「10 分に 5 回失敗したら、1 日締め出す」でした。それで、初日だけで 9 つの IP が締め出されていたわけです。

自分も締め出されていた

ここで白状すると、締め出された IP の中に自分も入っていました。(；´Д`)

サーバーを立てたとき、「パスワードや root で入れないこと」を確かめたくて、わざとログインを失敗させたのです。何回か。いつもと違う回線から。

当然、fail2ban から見れば、それは当て試しと同じです。その回線の IP が 1 日締め出され、私は「なぜか SSH がつながらない」と悩むことになりました。最初は「途中の回線で止められている」と思い込み、まちがった見立てまで記録に書いていました。

学んだこと:

確かめるために、わざとログインを失敗させない
設定を確かめたいなら、サーバーの中で sudo sshd -T を見れば、今効いている設定が全部出る
「つながらない」ときは、まずサーバー自身が止めていないかを見る（sudo fail2ban-client status sshd で、締め出し中の IP の一覧が出る）

守りを少し足した

せっかくなので、少しだけ守りを足しました。

1. 繰り返し来る相手ほど長く締め出す

1 日締め出しても、明けたらまた来ます。そこで、fail2ban の bantime.increment を有効にしました。2 回目は 2 日、3 回目は 4 日…と倍になり、上限は 4 週間です。

# /etc/fail2ban/jail.d/stardust.local
[sshd]
bantime.increment = true
bantime.maxtime = 4w

ただし、これだけでは効きません。fail2ban は締め出しの記録を、既定では 1 日で消してしまうので、2 回目かどうかを覚えていられないのです。記録を残す期間も合わせて延ばしました。

# /etc/fail2ban/fail2ban.d/stardust.local
[Definition]
dbpurgeage = 4w

sudo fail2ban-client -t で設定を検査してから再起動しました。再起動しても、締め出し中の 9 つはそのまま残っていました。

2. 使っていない口を閉じる

待っている口（ポート）を一覧にしたら（sudo ss -tulpn）、SSH・Web のほかに、5355 番が開いていました。LLMNR という、同じネットワークの中で名前を解決する仕組みです。ファイアウォールで捨てているので外からは届きませんが、使っていないので止めました。使わないものは閉じる。

# /etc/systemd/resolved.conf.d/no-llmnr.conf
[Resolve]
LLMNR=no
MulticastDNS=no

3. 設定を git で残す

サーバーの設定（ファイアウォール・fail2ban・nginx）を、手元のリポジトリに写して git で残すようにしました。変えたら写してコミットする。壊したときに、前の設定に戻せます。

まとめ

サーバーを公開すると、数時間で知らない誰かがログインを試しに来る
鍵だけで入れるようにしておけば、何回来ても入れない
fail2ban は、繰り返す相手をファイアウォールで締め出してくれる。自分も締め出されるので、わざと失敗させない
繰り返す相手には bantime.increment。ただし記録を残す期間（dbpurgeage）も延ばす
使わない口は閉じる。設定は git に残す

インターネットの片隅にも、ノックの音は絶えず届きます。ドアに鍵をかけて、のぞき穴から眺めるくらいがちょうどいい。(｀・ω・´)ゞ