ノードを建てた。動き始めた。
だが、まだ門は開いている。
森に庵を結ぶハンターは、寝る前に必ず戸締まりをする。森は静かだが、優しいわけではない。
公開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(物理的なファイル) |
公開鍵認証に切り替えると、攻撃者は「正しい秘密鍵」を持っていない限り、いくら試行しても入れない。これだけで侵入リスクは桁違いに下がる。
やったこと ─ 段階的に締めていく
セキュリティ強化は、慎重に段階を踏む必要がある。なぜなら、急いで全部を一度に締めると、自分自身が締め出される(ロックアウト)からだ。実際の流れは、こうだった。
ed25519 という鍵を作る
PCで秘密鍵と公開鍵のペアを生成する。ed25519 は現代の暗号方式で、強度と速度のバランスが良い。鍵自体にもパスフレーズを設定すれば、PCを誰かに盗まれても鍵が無防備にはならない(二重ロック)。
公開鍵だけをサーバーに渡す
公開鍵は名前の通り公開してもよい鍵。サーバーの ~/.ssh/authorized_keys というファイルに追記する。秘密鍵は絶対にサーバーには置かない。秘密鍵を持つのは、あなたのPCとモバイル(Termius)だけだ。
鍵で入れることを確認する ─ 必ず
ここが一番大事なステップだ。パスワード認証を切る前に、鍵での接続が確実に成功することを確認する。しかも、PCとTermiusの両方で。鍵を持つ場所が二つあれば、片方を失っても入れる。
このステップを飛ばしてパスワードを切ると、もし鍵設定にミスがあった場合、誰もサーバーに入れなくなる。VPS のコントロールパネルからのコンソールアクセスでなんとか復旧することになるが、それは「うまくいかなかった時の話」であって、避けられるなら避けたい。
パスワード認証を無効化する
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に入れなくなっていたかもしれない。
先を急がない人ほど、結果として早くゴールに着く。
fail2ban で自動門番を雇う
万一、何らかの方法で攻撃が継続するパターンが現れた場合(鍵総当たりという理論上の攻撃は存在する)、一定回数の失敗で自動的にIPをBANする仕組みを入れる。これが fail2ban だ。
設定は単純:「10分以内に3回失敗したら、1時間BAN」。
そして冒頭で書いた通り、設置した数時間後には既に1件のBANが記録されていた。これは fail2ban が機能しているという証拠であり、同時に「世界には常にドアを叩こうとする者がいる」という現実の証拠でもある。
内側の宝物庫にも鍵を ─ .env の権限
サーバーに入った後でも、すべてのファイルが誰でも読めるわけではない。CAWノードの .env ファイルには、バリデーターの秘密鍵、RPCのAPIキー、データベース認証など、最も重要な情報が書かれている。
権限を 600 に設定する。これは「オーナー(自分)だけが読み書きできる」という意味だ。万一、別のユーザーがサーバーに存在しても、.env は読めない。
外の城門だけでなく、内側の宝物庫にも鍵をかけておく。
鍵を二つの場所に持つということ
今日の作業で大事にしたことの一つが、鍵を持つ場所を二つに分散させることだった。
開発・運用のメイン環境
移動中や緊急時の確認用
どちらかを失っても、もう一方からノードに入れる。これは保険でもあり、利便性でもある。
ただし、これは「秘密鍵を二つの場所にコピーする」ということでもある。つまり、どちらか一方でも盗まれれば、ノードが侵害される。だからこそ、鍵自体にパスフレーズを付けた。鍵が盗まれてもパスフレーズを知らなければ使えない。
セキュリティは常に「便利さ」と「強さ」のトレードオフだ。完璧を求めれば不便になり、不便さを避ければ穴ができる。自分が許容できる範囲で、できるだけ強くすることが、現実的な落としどころになる。
城門は固めた。だが、見張りは続く
今日やったことを並べると、こうなる。
- パスワード認証を無効化
- ed25519 鍵認証(パスフレーズ付き)に切り替え
- fail2ban で自動BAN体制を構築
- PC・モバイル両方からの接続経路を確保
- .env の権限を 600 に締める
これで、ありふれた攻撃のほとんどは弾ける。残るのは:
- 鍵そのものの紛失や盗難
- パスフレーズの漏洩
- もっと洗練された標的型攻撃(小規模ノードに来る可能性は低い)
つまり「自分の管理ミスでしか侵害されない状態」まで持っていけた。
それでも、これで終わりではない。城門を固めても、見張りは続けなければならない。
- 定期的に
fail2ban-client status sshdで BAN状況を確認する - OS のセキュリティアップデートを当て続ける
lastコマンドで最近のログイン履歴をチェックする- 不審なプロセスがないか時々確認する
ノードを建てるとは、自分の城を持つこと。そして城を持つということは、それを守り続ける責任を負うことでもある。
だが、扉の鍵はかけた。今夜は、少しだけよく眠れる。






