☰

驚くほど高い割合の「ボットネット」sshd ログイン失敗に対処するためのヒントはありますか?

tag-icon • tag-icon linux ssh ddos
驚くほど高い割合の「ボットネット」sshd ログイン失敗に対処するためのヒントはありますか?

2 つの新しい Debian 12 VPS を同時にセットアップしました。

1 つは正常に動作していましたが、もう 1 つは断続的に接続しているようでした。データセンターの接続の問題に違いないと思い、サポート チケットの半分まで書き進めましたが、さらに詳しく調べたところ、sshd の「MaxStartups」機能について知りました。開かれたがまだ認証されていない接続が一定数を超えると、sshd は意図的にそれ以上の接続を切断し始めます。これは私が見ていたものと一致しています。

正常に動作しているVPSでは、ログには悪意のある試みが約2分に1回記録されており、これは予想どおりです。問題のあるVPSでは、約1分に1回のようです。一秒ごと平均すると、デフォルトの LoginGraceTime が 2 分なので、ログインに苦労していた理由がよくわかります。私はすでにこれを 5 秒に短縮しており、開いている接続の数をなんとか制御できています。(両方の VPS は既に公開キー認証のみを受け入れるように構成されているため、悪意のある試みが成功する可能性はまったくありません。)

問題となっている IP への攻撃がいかに急速に行われているかに驚いています。攻撃はすべて異なるソース IP から行われているようです。明らかにボットネットであり、簡単にブロックできるものではありません。たとえば、fail2ban はソース IP で完全に機能するため、ここでは何もしないと思います。

この VPS にパブリック HTTP サーバーを設置する予定なので、すでに SSH 経由のボットネット攻撃のターゲットになっている場合、HTTP サーバーが開始する前に DDOS 攻撃を受けて破壊されてしまう可能性や、脆弱性を悪用するスキャンを行っている誰かまたは何かの注目を集めてしまう可能性も懸念しています。(2 分ごとに 1 回の試行しか発生していない他の VPS にメール サーバーを設置する予定ですが、どのプロトコルをより懸念すべきかわかりません。)

  • 悪意のある試みの割合はどのくらいにすべきか期待するランダムに選択された IPv4 アドレスに送信されるのですか?
  • これに対して何らかの行動を起こすべきでしょうか、それともただ我慢するべきでしょうか?
    • 私の VPS プロバイダーに、サーバーの IP を変更できるかどうか問い合わせてください。おそらく、私が運が悪かっただけで、このサーバーが他の誰かに対する DDOS 攻撃のターゲットになり、その人の IP が割り当て解除されて、その IP が私に割り当てられたのかもしれません。
    • いずれにせよ最終的にはパブリック HTTP サーバーを実行することになるにもかかわらず、SSH にアクセスできる別の VPS 以外からの SSH をブロックしますか? (HTTP を開く必要があるときに SSH をファイアウォールでブロックするのは少し無意味に思えます。また、これを行うと私にとっては多少不便です)
    • 失敗した試行のログ メッセージを黙らせるだけですか? (これを行うオプションがあると仮定します - まだ確認していません)
    • 悪意のある試行の頻度が高い場合に、より最適化された代替 SSH サーバー ソフトウェア パッケージを使用できますか? たとえば、sshd は認証の前に新しい接続ごとに新しいプロセスを作成しますが、これは不要なオーバーヘッドが大量にあるように思われます。理想的には、認証が成功するまで、消費するリソースをできるだけ少なくする必要があります。
    • ...他に何か提案はありますか?

答え1

ランダムに選択された IPv4 アドレスに向けられる悪意のある攻撃の割合はどの程度になると予想されますか?

インターネットのバックグラウンド ノイズ: 日常的かつ自動化された網羅的なスキャン (IPv4 アドレスを具体的にターゲットにするのではなく) により、インターネットの大部分が露出しているホストとサービスをスキャンします。プローブの連続ストリームにより、露出している sshd だけで 1 日あたり数百件のログイン/不正使用の試行が簡単に発生します (ただし、特定のプロバイダーの IP アドレス範囲が他の範囲よりもターゲットにされるため、その数は数十から数千に及ぶ可能性があります)。ソースはさまざまです。

  • 熱心なプロバイダ（安全でない/脆弱な/侵害されたシステムを運用している顧客に警告したり接続を切断したりするために脆弱性スキャナを実行している可能性があります）
  • 研究プロジェクト（例えばショーダンなど）と他の好奇心旺盛な人々
  • 悪意のある行為者（ボットネットを使用して調査を実行している可能性があります）
  • などなど。

これに対して何らかの行動を起こすべきでしょうか、それともただ我慢するべきでしょうか?

一般的に、サーバーとサービスをインターネットに公開する場合、インターネット全体からの接続、そして最も重要なのは不正使用（試行）を予想する必要があります。

サービスが公共サービスとして意図されていない場合それからインターネット全体に公開されるべきではありません。
可能な場合: ベスト プラクティスは、アクセス制御を適用することです。これにはいくつかの形式がありますが、一般的なのは、既知の IP アドレスや既知の IP アドレス範囲へのアクセスを制限することです。または、適切な IP アドレス範囲が正確にわからない場合は、有効なアクセス要件がまったくないと思われる範囲をブロックします。IP
アドレス (範囲) を地理的な場所に結び付けることは、100% の信頼性や完全性にはほど遠いですが、Geo-IP データを使用したアクセス リストはその点で非常に役立ちます。

アクセス制御は、セキュリティ グループやファイアウォール アプライアンスなどを使用してホストの外部で設定できます。その場合、サーバー自体はアクセス制御を維持するためのリソースを提供する必要がありません。

多くの場合、より柔軟ですが、ホスト自体のリソースも必要とするホストベースのアクセス制御 (ホストベースのファイアウォール (Linux の netfilter/iptables/nftables) など) やアプリケーション自体のアクセス制御) があります。これは、たとえば、異なるユーザーに異なる IP アドレス制限を設定する唯一の方法であることがよくあります。

サービスが意図されている場合公共サービスのためにたとえば、公開ウェブサイトのあるウェブサーバーなど、通常、アクセス制御は適用しませんなぜなら、本物のサイト訪問者はどこからでも歓迎されるからです。
多くの場合、このような公共サービスでは、どこからでもアクセスを許可するというアプローチをとりますが、悪意のある行為を検出し、悪意のある行為者が使用するIPアドレスを（一時的に）ブロックするのようなツールフェイル2バンそういったアプローチの一つであるIDSおよびIPSシステム別の。

例：たとえば私の故郷であるアムステルダムにある地元のレストランのテイクアウト注文ページとオンライン予約システムにアクセス制御リストを設定します。アムステルダムの IP アドレスのみにアクセスを許可するように設定することはないでしょう。おそらくそれは制限が厳しすぎるでしょうし、たとえば携帯電話を使ってサイトにアクセスしている正当な地元の訪問者を拒否することになります。
しかし一方で、ヨーロッパ以外で割り当てられていて使用中であることがわかっている IP アドレス範囲や、たとえばアフリカ、アジア太平洋、北米、南米の地域で使用さ
れている IP アドレス範囲をブロックすると、不正使用の試みの数が大幅に減少し、予約やテイクアウト注文の数に影響する可能性は低いでしょう。対照的に、同じ Web サーバー上の SSH アクセスのアクセス制御リストは、サイト管理者の静的 IP アドレス、オフィスのゲートウェイ、および/または静的 IP アドレスや VPN サーバーがない場合は ISP が使用する範囲に簡単に制限できます。

悪意のある試行の頻度が高い場合に、より最適化された代替 SSH サーバー ソフトウェア パッケージを使用できますか? たとえば、sshd は認証の前に新しい接続ごとに新しいプロセスを作成しますが、これは不要なオーバーヘッドがかなりあるように思えます。

実際のリソース要件とログイン試行の影響を過大評価していると思いますし、そう願っています。全体的な流れからすると、私が見た「通常」レベルの SSH 不正試行が露出した VPS システムで生成する負荷は、実際のアプリケーションの負荷に比べればごくわずかです。

HTTPがオープンである必要があるときにSSHをファイアウォールでダウンさせるのは、少し無意味に思えます

セキュリティに対する一般的なアプローチは最小権限の原則; ファイアウォール ルールでは次のように変換されます。

  • デフォルトですべてをブロックする
  • 必要なものだけを、必要な人にだけアクセスできるようにする

したがって、全世界ではなく一部の IP アドレスからの ssh アクセスのみを許可し、ポート 80 (プレーンを https にリダイレクトするため) とデフォルトの https ポート 443 へのアクセスを全世界に許可することは無意味ではありません。

答え2

これまで、ssh に対する slowloris タイプの攻撃は見たことがありません。ドキュメントを見ると、MaxStartups はこれらが同じクライアントからの攻撃であるかどうかを気にしていないようです (つまり、これを使用して DOS を助長する可能性があります)。私の最初の対応は (攻撃のパターンによって異なりますが)、iptables connlimit (クライアント IP ごとに接続を制限) を使用することです。

Fail2ban はほとんどの ssh 攻撃に対する明らかな解決策です (HTTP[S] トラフィックにも使用しました)。ただし、ipset を使用するように設定されていることを確認してください。

IP アドレスを変更しても、長期的には効果がない可能性があります。

私がアクセスできる別のVPS以外からのSSHをブロックする

はい、ジャンプボックスの使用はごく一般的な方法です。繰り返しますが、これは自分で行うことができます。ポート22にデフォルトのファイアウォールルールを設定し、ジャンプボックスをホワイトリストに登録するだけです。SSHには、使用を透過的にする組み込み機能もあります。

ssh -J [email protected] [email protected]

または、ssh_config でこれを設定して、次のようにすることもできますssh targethost.example.com。

Host jumpbox.example.com
   User: jumpuser
   IdentityFile: ~/.ssh/jumpuser.id_rsa

Host targethost.example.com
   User: user
   ProxyCommand: ssh -q -W %h:%p [email protected]:22 
   IdentityFile: ~/.ssh/user.id_rsa

失敗した試行のログ メッセージを黙らせるだけですか?

私はこれを推奨しません。不正アクセスを防ぐために適切な対策を講じている場合は、無視してもかまいません。

pepoluanが示唆しているように、非標準のポートとポートノッキングを使用することもできます（ちなみに後者はiptablesのみで実装knockdを使わなくても

答え3

私の提案:

  1. SSH ポートを 22 から別のポートに変更します。
  2. それでもボットがポートを見つけられる場合は、knockdポートノッキングを実装するようにサーバーをインストールして構成します。

答え4

パブリック IP 経由で SSH を公開すると、遅かれ早かれスキャンされ、VPS プロバイダーやネットワークに関係なく、脅威アクターが認証を試行することになります。

次のような Ansible プレイブックを使用して、SSH 構成を強化します。 https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/ssh_hardening

または、サーバー全体を強化するこのプレイブック: https://github.com/konstruktoid/ansible-role-hardening

また、fail2ban もお勧めします。Fail2Ban: 複数の認証エラーを引き起こすホストを禁止する Fail2Ban は、/var/log/auth.log などのログ ファイルをスキャンし、ログイン試行の失敗回数が多すぎる IP アドレスを禁止します。これは、システム ファイアウォール ルールを更新して、これらの IP アドレスからの新規接続を、設定可能な時間だけ拒否することで行われます。

または、VPS のネットワークへの VPN 接続を作成したり、OpenVPN (例) を使用して VPS 内に VPN サーバーを作成したり、VPN の背後に SSH を配置したりして、インターネットに公開しないようにすることもできます。

関連情報