ノードを建てた。動き始めた。
だが、まだ門は開いている。

森に庵を結ぶハンターは、寝る前に必ず戸締まりをする。森は静かだが、優しいわけではない。

公開IPを持ったサーバーも同じだ。動き始めた瞬間から、世界中の誰でもそのドアを叩くことができる。そして、実際に叩いてくる存在がいる ─ 何百回、何千回と、ひっきりなしに。

この記事は、そのドアを固める話だ。

攻撃は本当に来ているのか

これは杞憂ではない。理屈ではなく、数字で示せる。

2台目のノード tencawffee.com にセキュリティ強化を行った当日 ─ 具体的には fail2ban という防御ツールをインストールしてから数時間後 ─ 既に1件のIPアドレスがBANされていた。

|- Currently banned: 1
|- Total banned:     1
|- Banned IP list:   45.148.10.151

私が何か特別に攻撃を受けやすい設定をしていたわけではない。公開された22番ポート(SSH)を持つすべてのサーバーは、常時こうした自動探査にさらされている。新しく建てたVPSは、IPが世界に認知された瞬間からスキャン対象になる。

放っておけば、辞書攻撃や弱いパスワードで侵入される可能性は必ずある。だから、ノードを建てたら次にやるべきは「城門を固めること」だ。

パスワードと鍵 ─ 認証の二つの方法

サーバーに入る方法には、大きく分けて二つある。

パスワード認証は、文字通り「合言葉」だ。あなたが正しい合言葉を知っていれば入れる。便利だが、欠点がある ─ 攻撃者も、何度でも合言葉を試せる。世界中から、毎秒のように。

公開鍵認証は、もっと面白い仕組みだ。あなたは「秘密鍵」というデジタル鍵を自分のPCに保管し、それとペアになる「公開鍵」をサーバー側に置いておく。サーバーは公開鍵を使って暗号パズルを出題し、対応する秘密鍵だけがそれを解ける。秘密鍵そのものはネットワークを流れない。

パスワード認証 公開鍵認証
仕組み 「合言葉」を毎回送る 「鍵を持っていること」を証明する
攻撃耐性 何度でも試せる 鍵がないと事実上開けない
鍵の所在 あなたの記憶 あなたのPC(物理的なファイル)

公開鍵認証に切り替えると、攻撃者は「正しい秘密鍵」を持っていない限り、いくら試行しても入れない。これだけで侵入リスクは桁違いに下がる。

やったこと ─ 段階的に締めていく

セキュリティ強化は、慎重に段階を踏む必要がある。なぜなら、急いで全部を一度に締めると、自分自身が締め出される(ロックアウト)からだ。実際の流れは、こうだった。

1

ed25519 という鍵を作る

PCで秘密鍵と公開鍵のペアを生成する。ed25519 は現代の暗号方式で、強度と速度のバランスが良い。鍵自体にもパスフレーズを設定すれば、PCを誰かに盗まれても鍵が無防備にはならない(二重ロック)。

2

公開鍵だけをサーバーに渡す

公開鍵は名前の通り公開してもよい鍵。サーバーの ~/.ssh/authorized_keys というファイルに追記する。秘密鍵は絶対にサーバーには置かない。秘密鍵を持つのは、あなたのPCとモバイル(Termius)だけだ。

3

鍵で入れることを確認する ─ 必ず

ここが一番大事なステップだ。パスワード認証を切る前に、鍵での接続が確実に成功することを確認する。しかも、PCとTermiusの両方で。鍵を持つ場所が二つあれば、片方を失っても入れる。

重要
このステップを飛ばしてパスワードを切ると、もし鍵設定にミスがあった場合、誰もサーバーに入れなくなる。VPS のコントロールパネルからのコンソールアクセスでなんとか復旧することになるが、それは「うまくいかなかった時の話」であって、避けられるなら避けたい。

4

パスワード認証を無効化する

sshd の設定ファイルを編集し、PasswordAuthentication no に変更する。

実は今日、この設定で私はタイポをした ─ PasswordAuthenticatios(最後の s が余分)と打ってしまった。

/etc/ssh/sshd_config: line 78: Bad configuration option: PasswordAuthenticatios
/etc/ssh/sshd_config: terminating, 1 bad configuration options

幸い、設定変更を反映する前に sshd -t で構文チェックをしていたので、すぐに気づけた。もしチェックを飛ばして反映していたら、SSHサービスが壊れ、自分自身もVPSに入れなくなっていたかもしれない。

慎重さとは、面倒くさい確認を一つ一つ積み重ねることだ。
先を急がない人ほど、結果として早くゴールに着く。

5

fail2ban で自動門番を雇う

万一、何らかの方法で攻撃が継続するパターンが現れた場合(鍵総当たりという理論上の攻撃は存在する)、一定回数の失敗で自動的にIPをBANする仕組みを入れる。これが fail2ban だ。

設定は単純:「10分以内に3回失敗したら、1時間BAN」。

そして冒頭で書いた通り、設置した数時間後には既に1件のBANが記録されていた。これは fail2ban が機能しているという証拠であり、同時に「世界には常にドアを叩こうとする者がいる」という現実の証拠でもある。

6

内側の宝物庫にも鍵を ─ .env の権限

サーバーに入った後でも、すべてのファイルが誰でも読めるわけではない。CAWノードの .env ファイルには、バリデーターの秘密鍵、RPCのAPIキー、データベース認証など、最も重要な情報が書かれている。

権限を 600 に設定する。これは「オーナー(自分)だけが読み書きできる」という意味だ。万一、別のユーザーがサーバーに存在しても、.env は読めない。

外の城門だけでなく、内側の宝物庫にも鍵をかけておく。

鍵を二つの場所に持つということ

今日の作業で大事にしたことの一つが、鍵を持つ場所を二つに分散させることだった。

💻PC(Windows)
開発・運用のメイン環境
📱スマホ(Termius)
移動中や緊急時の確認用

どちらかを失っても、もう一方からノードに入れる。これは保険でもあり、利便性でもある。

ただし、これは「秘密鍵を二つの場所にコピーする」ということでもある。つまり、どちらか一方でも盗まれれば、ノードが侵害される。だからこそ、鍵自体にパスフレーズを付けた。鍵が盗まれてもパスフレーズを知らなければ使えない。

セキュリティは常に「便利さ」と「強さ」のトレードオフだ。完璧を求めれば不便になり、不便さを避ければ穴ができる。自分が許容できる範囲で、できるだけ強くすることが、現実的な落としどころになる。

城門は固めた。だが、見張りは続く

今日やったことを並べると、こうなる。

  • パスワード認証を無効化
  • ed25519 鍵認証(パスフレーズ付き)に切り替え
  • fail2ban で自動BAN体制を構築
  • PC・モバイル両方からの接続経路を確保
  • .env の権限を 600 に締める

これで、ありふれた攻撃のほとんどは弾ける。残るのは:

  • 鍵そのものの紛失や盗難
  • パスフレーズの漏洩
  • もっと洗練された標的型攻撃(小規模ノードに来る可能性は低い)

つまり「自分の管理ミスでしか侵害されない状態」まで持っていけた。

それでも、これで終わりではない。城門を固めても、見張りは続けなければならない。

  • 定期的に fail2ban-client status sshd で BAN状況を確認する
  • OS のセキュリティアップデートを当て続ける
  • last コマンドで最近のログイン履歴をチェックする
  • 不審なプロセスがないか時々確認する

ノードを建てるとは、自分の城を持つこと。そして城を持つということは、それを守り続ける責任を負うことでもある。

もし日々の見張りの中で、見慣れないエラーや「直すべきトラブル」に出くわしたら ── 同期が進まない、登録されない、他から接続できないといった具体的な症状については、別記事『闇の中で躓いた時 ─ ノード構築トラブルシューティング』が修理手順の地図になります。
明日からも、森の音に耳を澄ます日々が続く。
だが、扉の鍵はかけた。今夜は、少しだけよく眠れる。