SSHポート22を完全に閉じた理由と、代わりに使っている方法
I close SSH port 22 (and what I use instead)
SSHのポート22をインターネットに晒さないための方法として、fwknopによるSingle Packet Authorization（SPA）を紹介。鍵認証やfail2banだけでは不十分で、ポートを完全に閉じてスキャナーに何も見せないようにする。SPAは暗号化・署名されたUDPパケットを送ることで、一時的にファイアウォールのルールを挿入し、SSHポートを開く。パケットは使い捨てでリプレイ攻撃も防げる。Ansibleでのサーバー設定、クライアント設定、SSHやAnsibleへの組み込み方、Tailscaleを併用した冗長化まで解説。
これは隠蔽によるセキュリティではありません。ポートは巧妙な番号の背後に隠されているのではなく、本当に閉じているのです。
HNでの議論
103- teddyh
ポートノッキングや、インターネットサービスの前に置くその他の特注のミドルウェアは愚かだ。これはケルクホフスの原理¹に違反する。システムにアクセスするためにユーザーが知る必要がある秘密のビットを増やしたいなら、パスワードの長さや暗号鍵のサイズを増やせ。ログのサイズ（または「ノイズ」）を管理可能にしたいなら、ログレベルを調整しろ。
通常のサービスの前に何かを追加すると、それが非標準であるためアクセスも複雑になる。IPベースのサービスへの安全なアクセスというすべてのニーズを満たす標準的な解決策が欲しいなら、IPsecを使えばそれで終わりだ。
1. <https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_pr...>
（この古い投稿から翻案：<https://news.ycombinator.com/item?id=39898061>）
- kazinator
私がやっていることは笑ってしまうほど簡単だ。
1. 侵入試行に関するログをすべて無効にする。
2. 「root」のような一般的なユーザー名を持たない。
例えば、どこからでもパスワードだけでrootとしてログインできるようにしたいとする。これは賢明な考えだ。証明書を使えない状況でアクセスが必要になるかもしれない。
「roto-rooter」など、頭に浮かんだ別の名前をでっち上げる。それをUID 0の別名としてパスワードファイルにインストールする（「root」エントリより後に現れるようにすること！）。シャドウファイルも編集し、別名のエントリが複製されていることを確認する。
そしてsshdの設定ファイルで、AllowUsersを使って許可するユーザーのホワイトリストを指定する。ここで「AllowUsers rotorooter」と指定すれば、認証できるユーザーIDはそれだけになり、passwd/shadowを介してUID 0にマッピングされる。リモートアクセスしたい他のアカウントも追加し、それらが一般的にプローブされる領域に該当する場合や、標的型攻撃者があなたについての知識から推測できるような名前の場合は、同様のエイリアスを与える。
攻撃者はユーザーID空間をまったくプローブしない。彼らはroot、admin、database、www-dataなどの一般的なユーザーIDのパスワード空間のプローブに専念している。あなたのシステムがそれらのIDをサポートしていなければ、彼らは何かをクラックする軌道に乗っていない。あなたのrotorooterパスワードが「g0d」でも、彼らがrootしか試さないなら、侵入はできない。
- ggm
このような方式は、ピーター・グットマンによって標準化の過程にある。彼は自分のやっていることを理解している。この発言に文脈を与えると、彼はニュージーランドの暗号学者であり、以前にも標準化に携わったことがある。つまり、彼は暗号、リスク、標準化プロセスに関する知識を持ってこのモデルを推進している。
- fedpost
これは実際に攻撃面を実質的に減らしているのだろうか？私たちは実戦で鍛えられたサービスを、ファイアウォールルールを操作できるランダムなものに置き換えているのだ。
- usernametaken29
なぜこれが以前に言及されなかったのか分からないが、ファイアウォールを使えばいいのでは？HetznerやScalewayのような仮想ボックスを使っているなら、ルーターレベルでIPまたは範囲を指定できる。これにより、実質的に公衆への露出がなくなる。Scalewayには安価なVPNブリッジもある。だから、望まなければパブリックインターネット経由で接続する必要はまったくない…これ以上に安全な方法はほとんどない。
- happosai
私はSSHサーバーをIPv6専用でリッスンするようにした。以来、ログは非常に静かだ。
最初のイテレーションでは、letsencrypt証明書が公開されるとすぐに、少数の攻撃者によってIPv6がスキャンされた。2回目のイテレーションでは、/64から別のIPv6アドレスを選び、ssh.example.comがそれを指すようにした。これは、攻撃者がサブドメインを推測し始めるまで機能するはずだ…
- figmert
本当の解決策は、PangolinやTailscale（またはHeadscale）のようなものを使うことだ。アクセスをはるかに細かく制御でき、SSHを公開する必要がまったくなくなる。一時的にも。
- akshayrajeshwar
> OpenSSHにゼロデイが発生したら…
現実的に言って、fwknopはOpenSSHよりも脆弱性が発生する可能性が高い。最後のリリースは2年前で、READMEは12年前のものだ。時間が教えてくれるだろう。