SSH ブルートフォース攻撃の実際の姿

平たく言えば、これは何か

SSH ブルートフォース攻撃はあなたを狙ってはいません。量産品としての作業です。誰かがボットネットを借り、IP レンジを食わせ、ポート 22 で応答するすべてにログインを試させる。ユーザー名の一覧は短く退屈です——root、admin、ubuntu、test、git、oracle、postgres、そして今年たまたま流行しているサービスアカウント。

これを回し続けているのは経済です。Linux マシン上のシェルは金になります——マイニングに、プロキシに、そのマシンが届く範囲すべてへの足がかりに——そして 1 回の試行はほぼ無料です。新しいサーバーを公開 IP に置けば、最初の探索はたいてい 1 時間以内に届き、1 週間後には 1 日数千件の失敗が当たり前になります。

重要なのは量です。人間があなたのパスワードを推測するのは逸話ですが、入れ替わるアドレスから月に 10 万回の試行は背景条件であり、前者を想定した防御は後者に何もしません。

実際に何を試みているのか

同じログの中に 3 つの異なる振る舞いが現れ、それぞれ対応が違います。

root へのログイン試行は最も騒がしく、最も危険が少ないものです。正しく設定されたサーバーなら PermitRootLogin は no か prohibit-password だからです。1 日数千件あるということは、ボットがまだ root は使えないと気づいていないということ——気づくことは決してありません。尋ね続けても何のコストもかからないからです。

次に来るのがユーザー名の列挙です。よくあるアカウント名を順に試し、実在するものを探す。現代の OpenSSH では、かつてこれを確実にしていた応答時間の差はおおむね解消されていますが、ボットはそれでも試し、当たれば狙いが定まります。

実際に成功するのはクレデンシャルスタッフィングです。他人の漏洩から得たユーザー名とパスワードの組を、あなたのサーバーに対して再生する。洪水ではなく少数の試行に見え、そして開発者の誰かがパスワードを使い回していれば成功します。レート制限では捕まりません。制限すべきレートが存在しないからです。

SSH にあって他のプロトコルにないもの

SSH には、多くの公開サービスが持たない逃げ道があります。公開鍵認証です。パスワード認証を完全に切れば、推測攻撃という分類は難しくなるのではなく、不可能になります。推測すべきパスワードが存在しないからです。

これは本当に利用可能な最強の一手であり、実行できるなら本記事の残りはすべて二次的です。専用のガイドがあります。

ただしトラフィックが止まるわけではありません。ボットはあなたの設定を知らないので、接続を続け、パスワードを提示し続け、拒否され続けます。1 回ごとに TCP 接続、sshd のフォーク、ログ 1 行、CPU のひとかけらを消費し、認証ログは相変わらず必要な出来事を失うほど速く回ります。鍵のみは риск ではなく——リスクを取り除きます。負荷は取り除きません。

レート制限だけでは足りない理由

定番の最初の答えは fail2ban で、それは妥当です。どのディストリビューションのリポジトリにもあり、実際に機能します。防御のすべてを託す前に、その限界を知っておく価値があります。

遮断するのは単一アドレスです。ボットネットはレンジ内を巡回します。203.0.113.47 を遮断すれば、1 時間後に .48 が始まります。/24 を遮断すればその一巡を一度で終わらせられますが、fail2ban は標準ではそれをしません。

遮断は期限切れになります。既定値は分単位で、同じボットネットが今夜また来ます。長く設定できますが、状態はメモリとファイルにあり、どちらも作り直しには耐えません。

他の誰からも学びません。各サーバーが各攻撃者を独立にゼロから発見し、その代価として毎回最初の N 回を受け止めます。

そして静かに壊れます。ディストリビューションのアップグレード後に一致しなくなった正規表現、パッケージ更新で無効になった jail、再起動後に戻ってこなかったサービス——どれも自ら知らせず、故障は平穏とまったく同じ見た目をしています。

実際にトラフィックを減らすもの

量を変えるものは 1 つだけです。送信元と話すことを拒むこと。それ以外はすべて送信元と交渉しています。

つまり、失敗のストリームを監視し、送信元がしきい値を超えたら、sshd が何かを費やす前にファイアウォールで破棄すること。持ちこたえる防御と漏れる防御を分けるのは 3 つの性質です：

• アドレスではなくサブネットを遮断する。攻撃トラフィックはホスティングのレンジから来ており、隣接アドレスは同じ事業者のものです。正規の利用者がスキャナーと同じ /24 を共有することはまずありません。
• 恒久的に遮断し、再起動を越えて残す。規則は nftables に置かれ、起動時に復元される必要があります。デーモンのメモリの中ではなく。
• 何かを有効にする前に、まず自分をホワイトリストに入れる。これが失敗する最も一般的な形は、SSH でしか到達できないサーバーから自分のアドレスを締め出してしまう管理者です。

仕組みを自分で保守せずに済ませる

SSH Protector はそのロジックをエージェントとしてまとめたものです。あなたが読むのと同じ journald や auth.log のストリームを読み、判断はローカルで行い——だからネットワークが落ちても動き続け——遮断したすべてのレンジを含む 1 つの統合 nftables セットを維持します。

インストール時には、22 を前提とせず sshd の設定から実際の SSH ポートを検出し、何かを遮断する前に、あなたが接続しているアドレスをホワイトリストに登録します。

ひとりでは作れない部分が共有されたレピュテーションです。他の利用者を攻撃したアドレスは、あなたに届く前にすでに遮断されているので、最初の N 回を受け止めることがありません。1 台は永年無料なので、記事ではなく自分のマシン上の実際の攻撃ストリームを見て、証拠に基づいて判断するには十分です。