新規VPSを最初の1時間で堅牢化

1時間オンラインになっているサーバーでjournalctl -u sshを見ると、最初はその量に驚かされます。しかし驚く必要はありません。あなたが目にしているのは、いわばインターネットの背景放射です。学術目的のものも、商用のものも、犯罪目的のものも含む一握りのスキャン活動が、IPv4アドレス空間全体を絶え間なく列挙し、その結果を認証情報推測ボットに渡しているのです。あなたのアドレスに到達したのは、それが番号順に存在しているからにすぎず、あなたが何をしようと数時間後にはまた到達されます。

これは問題の姿を、扱いやすい形に変えてくれます。あなたが対峙しているのは、あなたを狙って選び、状況に応じて適応してくる敵ではなく、決まった手札しか持たないスクリプトです――root、admin、ubuntu、test、git、oracle、postgres、そして情報漏洩で流出したデータに現れた2万個のパスワードです。それには忍耐も創造性もなく、一度で応答しないマシンへの関心もありません。パスワード認証を無効にしても、この攻撃者の動きが遅くなるわけではありません。盤面からまるごと排除されるのです。

知っておく価値のある点が二つあります。第一に、IPv6ははるかに静かです。/64を総当たりで走査することはできないからです――しかし、AAAAレコードが公開されたり、あなたのマシンのアドレスがメールヘッダーや証明書透明性ログに現れたりした瞬間、その静けさは終わります。IPv6を隠れ場所だと考えては絶対にいけません。小さな干し草の山だと考えてください。第二に、IPv4アドレスには過去があります。あなたより前にそのアドレスを使っていたテナントがおり、そのテナントがメールサーバーをずさんに運用していたり、ブロックリストに載るような何かをホストしていたりすれば、その評判が薄れるまであなたが引き継ぐことになります。メールが重要であれば、それを使い始める前に定番のブロックリストでそのアドレスを確認してください――5分の確認作業で、2週間のメール到達率トラブルシューティングを避けられます。

小規模サーバーが実際に侵害される経緯のほぼすべては、次の二つのどちらかから始まります。推測されうるパスワード、または、稼働しているべきではないのに待ち受けていたサービスです。それぞれに対応する対策がPasswordAuthentication noと、デフォルトポリシーがdropであるファイアウォールです。地味ではありますが、二つ合わせて15分で終わり、このページの他のすべての対策を合わせたものよりも価値があります。

その理由は統計的なものというより構造的なものです。どちらもデフォルトで閉じている――つまり、失敗する方向が安全側に倒れています。鍵認証のみのsshdは、どれだけ試行が届こうとも総当たり攻撃を受けません。パスワードを受け入れるコードパスがそもそも存在しないからです。デフォルト拒否のファイアウォールは、まだインストールしていないサービス――3か月後に追加してlocalhostへのバインドを忘れるであろうデータベースも含めて――を守ってくれます。堅牢化チェックリストのそれ以外の項目はすべて、悪いものの列挙にすぎません。無効にすべき個別の項目のリストであり、その網羅性はリストの出来次第でしかありません。

もし一つの節だけ読んでタブを閉じるつもりなら、この節を読み、下記のステップ2から5までを実行してください。それだけでもこの1時間は十分に報われます。残りは本当に役立つものではありますが、あくまで本当に副次的なものです。

Debian 13とUbuntu 24.04では、/etc/ssh/sshd_configの冒頭にInclude /etc/ssh/sshd_config.d/*.confという行があり、クラウドイメージはそのディレクトリ内に、すでにPasswordAuthenticationを設定済みのファイル――通常は50-cloud-init.conf――を同梱しています。メインファイルを編集して自分のディレクティブを末尾に追記するのは自然に感じられますが、その結果できあがる設定は、書いてあるとおりには動作しません。

このルールこそ、sshdについてほぼ全員を驚かせる唯一の事実です。各キーワードについて、最初に得られた値が勝つのです。これは、あなたがこれまで使ってきたほとんどすべての設定マージの仕組みとは正反対です。Includeはメインファイルの冒頭近くにあるため、ドロップインはsshd_config本体より先に読み込まれます――そして複数のドロップインの間ではアルファベット順が決め手になります。10-hardening.confという名前のファイルは50-cloud-init.confに勝ちます。60-hardening.confという名前のファイルはそれに負け、しかも黙って負けます。再起動が成功したと報告してきても、そこからこれを知ることはできません。

だからこそ、書いたばかりのファイルを決して信用してはいけません。デーモン自身に、実際に何を読み込んだのかを尋ねてください。

sshd -t                 # syntax check — silence means valid
sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractive|allowusers|port) '

sshd -Tは、すべてのインクルード、上書き、デフォルトが解決された後の実効設定を出力します。その出力がpasswordauthentication yesと示しているなら、ディスク上のどのファイルが何を主張していようと、パスワード認証は有効になっています。それ以外のものは検証としてカウントされません。

二つ目の落とし穴も同じ系統のものです。Ubuntu 24.04はソケットアクティベーションを通じてsshdを起動します。ssh.socketが待ち受けポートを所有しており、sshd_config内のPortは完全に無視されます。systemctl is-enabled ssh.socketで確認してください。有効になっていて別のポートを使いたい場合は、sshd_configではなくsystemctl edit ssh.socketとListenStream=のオーバーライドで変更してください。sshd_configでは、設定は正しく見えるのに何の効果もありません。

この件については正直になりましょう。インターネットの側は正直ではないからです。sshdをポート2222や47000に移しても、腕の立つ攻撃者を止めることはまったくできません。1台のホストに対するTCPフルスキャンは数秒で終わり、サービスはバナーで自ら名乗り、あなたを名指しで狙うと決めた相手なら、コーヒーを飲み終える前に見つけ出します。

実際に得られるのは、認証ログをおよそ95%削減できることであり、これには本物の価値があります。ざっと目を通すだけのログと、実際に読むログとの違いを生むからです。埋もれた信号より、見える信号のほうが優れています。何かを監視しているなら、静かなauth.logは異常を可視化する最も安上がりな方法です。

コストは小さいものの実在し、だからこそ私たちはこれを「推奨」ではなく「任意」と呼んでいます。8か月後に戻ってきたとき、そのポート番号を忘れているでしょう。1024番より上の非標準ポートは、原理上、sshdが待ち受けていない瞬間があれば、権限を持たないプロセスに奪われる可能性があります。クライアント側ネットワークの制限的なアウトバウンドファイアウォールは変わったポートをブロックするため、オフィスやホテルから自分のサーバーに接続できないことがときどき起こります。そしてソケットアクティベーションされたシステムでは、前節で述べた正しい場所で変更しなければなりません。ログを静かに保ちたいならやってください。ただし、それをやったからといって安全になったと感じてはいけませんし、鍵認証のみにする代わりにこれをやることは絶対にやめてください。

何をブロックするかを列挙するファイアウォールは、単なる書類整理です。何を許可するかを列挙するファイアウォールこそが、セキュリティ制御です。この違いがすべてを決めます。来月インストールするサービスも、金曜日に開けたままのデバッグ用ポートも、勝手に自分を公開してしまったコンテナも、カバーできるのは後者だけだからです。

当社のプラットフォームには二つの層があり、それぞれ独立しています。エッジフィルターは任意で、パネルからサーバーごとに設定し、ハイパーバイザー上で強制されるため、ブロックされたトラフィックはそもそもゲストに届きません――カーネルがサイクルを費やす前に適用したいレイヤー4のルールや、作業中に侵害されたゲストへの到達を防ぎたい場合に有用です。ゲストファイアウォールは完全にあなたのものです。nftables、iptables、pfなど、あなたのイメージが同梱しているものを使います。私たちがこれに触れることは一切ありません。マシンが重要であれば両方を使ってください。少なくとも後者は常に使ってください。

ステップ5のルールセットのうち二点は説明が必要です。コピー&ペーストされたルールセットの多くが、ここを間違えているからです。ICMPをすべてdropしないでください。一見すっきりして見えますが、これはパスMTUディスカバリーを壊します。その結果生じるのは最悪の部類のバグです。小さなリクエストは通るのに、大きなレスポンスはハングし、ログのどこにもファイアウォールのことなど出てこないのです。少なくともdestination-unreachable、time-exceeded、parameter-problemは許可してください。リストを把握していない限り、ICMPv6をタイプ別にフィルタリングしないでください。IPv6は近隣探索とルーター広告をICMPv6に依存しています。広範にブロックすると、IPv6の接続性は、あたかもルーティングの問題であるかのような形で失われます。単一ホスト上ですべてのICMPv6を許可するのは妥当な妥協であり、以下のルールセットもまさにそうしています。

flush rulesetを実行する前に一つ警告があります。Dockerがインストールされている場合、この行はDockerが書き込んだNATおよびfilterルールを削除してしまい、systemctl restart dockerでそれらを復元するまでコンテナのネットワークが機能しなくなります。まずルールセットを読み込み、次にDockerを再起動し、コンテナのポートを一つでも公開する前に、次の節を読んでください。

マシンに、実際に何を待ち受けているか尋ねてください。インストールしたつもりのものではなく、今この瞬間にバインドされているものです。

ss -tulpn | grep -vE '127\.0\.0\.1|\[::1\]'

このフィルターを通り抜けて残るものはすべて、マシン自身以外のどこかから到達可能です。標準イメージでよく見つかるのは、111番のrpcbind（あなたが動かしているものは何も必要としません）、ベースインストールの残骸であるexim4のリスナー、そしてループバック上では無害だが、そうでなければオープンリゾルバになってしまうsystemd-resolvedのスタブです。危険なものは後からやって来ます。あなたが意図的にインストールしたソフトウェアと共にです。チュートリアルがlisten_addressesを編集しろと書いていたせいで0.0.0.0:5432で待ち受けるPostgreSQL、その歴史の大半でデフォルトのパスワードがなかったせいでパスワードなしのRedis、Elasticsearchのノード、Prometheusのエクスポーター、Jupyterノートブックなどです。これらのどれもが、実際の侵害の第一歩となった実績を何度も持っています。

ここに、注意深い人ほど引っかかる落とし穴があります。Dockerはあなたのファイアウォールに許可を求めません。-p 5432:5432と書くと、DockerはnatテーブルのPREROUTINGチェーンにDNATルールを挿入します。これはカーネルが、あなたのinputチェーンがパケットを目にする前に評価するものです。そのトラフィックはその後コンテナへ転送されます。あなたのデフォルト拒否のinputポリシーは一切参照されず、ufw statusはそのポートを閉じていると表示し、そしてデータベースは公開インターネット上に存在することになります。これはDockerの仕様として文書化された挙動であり、10年前からこの通りであり、これによって膨大な数のデータベースが露出してきました。

対処法は一言で済み、身につける価値のある習慣です。

# wrong — reachable from the entire internet, whatever your firewall says
docker run -p 5432:5432 postgres

# right — bound to loopback, reachable only through an SSH tunnel or a proxy
docker run -p 127.0.0.1:5432:5432 postgres

最後に、外部の視点を得てください。サーバー自身からのポートスキャンは、カーネルがどう考えているかを教えてくれるにすぎません。別の場所からのスキャンこそが、世界からどう見えているかを教えてくれます。そして重要なのはその数字だけです。マシンからではなく、あなたのノートパソコンからnmap -Pn -p- <your-ip>を実行し、その結果を、あなたが想定していたリストと比較してください。

小規模サーバーが侵害される原因となる窓は、ゼロデイではありません。CVEが実際に動くPoCとともに公開されてから、あなたがたまたま次にログインするまでの4週間です。攻撃ツールは新しいリモート脆弱性を数日で取り込みますが、「そのうち」パッチを当てるつもりのマシンは、その間ずっと露出したままです。そして、誠実な運用者なら誰でも、その「その間」が実際にはどれほど長いかを知っています。

自動アップデートへの反対理由は「壊れることへの恐れ」であり、これは真剣に受け止める価値があります――そのうえで、範囲を絞り込む価値もあります。自動化の対象は、ディストリビューションのセキュリティ枠に限定してください。ここではメンテナーが、新しい上流リリースを出すのではなく、パッケージ済みのバージョンに修正をバックポートしています。Debianのopensslに対するセキュリティアップデートは、あなたがすでに動かしているのと同じバージョンにパッチを当てたビルドです。それによって挙動が変わるリスクは、リモートの穴を1か月放置するリスクに比べればはるかに小さなものです。機能アップグレードは、本来そうあるべき通り、手動のままにしておいてください。

人々が省略しがちなのが再起動です。ディスク上でパッチが当たったlibsslは、起動時に古いものをマップ済みのプロセスには何の効果もありませんし、カーネルの更新も、それで実際に起動し直すまでは何の効果もありません。あなたが選んだ時間帯での無人再起動を受け入れるか、あるいはneedrestartをインストールして、削除済みのライブラリを参照したまま動いているサービスを教えてもらうか、どちらかを実行してください――ただし、どちらか一方は必ず実行してください。uptimeが340日を示している状態で「自動アップデートは有効です」と言うのは、心地よい幻想にすぎず、私たちが最もよく目にするものでもあります。

fail2banはログを読み、あるアドレスからの失敗が繰り返されているのに気づくと、しばらくの間そのアドレスをbanします。CrowdSecも同じことをしたうえで、その判定を参加者のネットワーク全体で共有するため、よそで悪さをしたアドレスが、あなたのところに到達する前にブロックできます。どちらも優れたソフトウェアです。しかしどちらも、鍵認証のみのSSHサーバー上では、多くの人が思っているような働きはしません。

PasswordAuthenticationがnoになっていれば、SSHへの総当たり攻撃は成功しえません。「成功しにくい」のではなく、成功するコードパスがそもそも存在しないのです。したがって、5回失敗した後にアドレスをbanしても、何かを防ぐわけではありません。ログの量とごくわずかなCPUを削減するだけです。それは実在するメリットではありますが、セキュリティ上のメリットではありませんし、その代償もタダではありません。誤ったログを監視するように書かれた粗悪なjailは、攻撃者を締め出した以上に、多くの管理者を自分自身のサーバーから締め出してきました。

これらのツールが本当に力を発揮するのは、もう一段上の層――あなたが実際に外部公開しているサービスです。ログインフォーム、WordPressの管理画面、レート制限のあるAPI、SMTP AUTHを使うメールサーバーなどです。これらは実際にパスワードを受け付けますし、実際に総当たり攻撃が可能であり、banリストはまさに正しい対策です。したがって、私たちの結論は狭く具体的です。SSH用のjailは省略してください。CrowdSecかfail2banは、パスワード入力欄を持つものの前に置いてください。そしてどちらを選ぶにせよ、まず自分の管理用アドレスをホワイトリストに入れてください――ignoreipが存在するのは、そうしなければ、良くない理由で記憶に残ることになる、まさにそんな晩のためです。

予防とは、1時間でできることです。検知とは、その1時間で足りていたかどうかを教えてくれるものです。凝ったものである必要はなく、単一のサーバーであれば、三つの安上がりな仕組みでほとんどの範囲をカバーできます。

ログを保持する。多くのイメージでは、ジャーナルは/run上にあり、再起動すると消えてしまいます。つまり、インシデントの記録は、その直後の再起動で消え去るということです。/var/log/journalを作成することは一行で済む対策であり、この節の中で最も価値の高いものです。

ログインを知らせてもらう。/etc/ssh/sshrcに、セッション開始のたびにloggerを実行する一行を加えても、コストはかからず、sshd自体の雑多な出力とは別に、すっきりとしてgrepしやすい記録が得られます。ただし一つ注意点があります。ユーザーが~/.ssh/rcを持っている場合、sshdは/etc/ssh/sshrcの代わりにそちらを実行するため、まさにカスタムのdotfileを持っていそうなアカウントに限って、システム全体向けのファイルがスキップされてしまいます。迂回されないフックが必要な場合は、代わりにpam_execを使ってください。

初日にファイルシステムがどんな状態だったかを把握しておく。AIDEはバイナリ、ライブラリ、unitファイルのハッシュを記録し、それ以降の変更点を報告します。ここには根本的でありながら見過ごされがちな落とし穴があります。監視対象のマシン自身にデータベースを保存していると、そのマシンを侵害した者がデータベースを再生成でき、以後チェックは永遠に「変更なし」と報告し続けることになります。データベースをそのマシンの外にコピーするか、少なくともそのハッシュを別の場所に記録しておけば、このツールは20分をかける価値のあるものになります。そのまま放置すれば、それは単なる気休めです。

ここには単独で述べる価値のある一般原則があります。信用できないログとは、侵害されたマシン上にあるログのことです。本当に頼りにするつもりのもの――ジャーナル、整合性データベース、バックアップ――は、同じ攻撃者が制御していないどこかに、その控えを持つべきです。別の法域にあるもう一台の小さなサーバーは、これに対する正当な答えであり、5ドル程度のものでも十分です。

ここまで述べてきたことはすべて境界防御の作業であり、施錠された玄関ドアを金庫と取り違えないためにも、その境界線を正確に理解しておく価値があります。

稼働中のマシン上のデータは保護しません。堅牢化されたカーネルも閉じたファイアウォールも、ハイパーバイザーへのアクセス権を持つ者や、マシンが稼働している間のRAMの中身には関係がありません。サーバーの電源が切られているとき、押収されたとき、あるいは廃棄されたときのディスクが懸念であれば、それはディスク暗号化の領分であり、失敗の仕方も異なる別の手順です――LUKSでVPSディスクを暗号化するを参照してください。

あなたを匿名にはしません。サーバーは完璧に堅牢化されていても、WHOISレコード、使い回したSSH鍵、アナリティクスのタグ、ホップなしで自宅から接続するSSHクライアント、あるいは二つの身元を結びつけてしまう証明書を通じて、それでも所有者が誰であるかを漏らすことがあります。Moneroで支払っておきながら自分自身のアドレスからログインすれば、その支払いは無意味になります。この失敗モードには専用のページがあります――匿名性を失わせるミスです。

あなたのアプリケーションを直しはしません。SQLインジェクション、認証なしの管理エンドポイント、バックドア入りの依存パッケージは、あなたのsshd設定など気にも留めません。きちんと運用されているサーバーが侵害される経緯の大半は、あなたが自分で書くか導入するかしたサービスのために、意図的に、わざわざ開けたポートを通ってやって来ます。

バックアップではありません。ランサムウェア、変数が空だったrm -rf、失敗したアップグレードは、すべて同じ結末を迎えます。控えを取り、別の場所に置き、必要になる前に一度はそこから復元しておいてください――別のホストへの移行を乗り切れるものにするのと同じ規律が、最悪の火曜日も乗り切れるものにしてくれます。

これらはどれも、この1時間をやる意味がないという主張ではありません。この1時間が何を買ってくれたのかを正確に把握しておくべきだという主張です。