あなたの Linux サーバー への SSH ブルートフォースを止める

はい。SSH Protector エージェントは自身のオペレーティングシステムの認証ログを読み、同じホスト上の保護対象ポートへの受信通信をフィルタする nftables ルールを書きます。エージェントは待ち受けソケットを開かず、リモートコマンドのチャネルも持たず、送信方向の HTTPS だけを開始します。エージェントの中に、他のマシンに対して働きかけられるものはありません。

Fail2ban は認証ログを解析し、findtime の中で失敗回数を数え、bantime の長さだけファイアウォールを設定します。一度に 1 アドレス、そのホスト単独でです。SSH Protector は送信元をその広告プレフィックスへ解決し、/24 全体を nftables セットのエントリ 1 つとして遮断します。セットはタイマーで失効させるのではなく再起動をまたいで保持し、テキスト行を正規表現で照合するのではなく systemd-journald をネイティブ API 経由で読み、得られたレピュテーションを他のすべての保護対象ホストと共有します。上の表は両者の既定の挙動を並べて示しており、/guides/fail2ban-limitations が違いを余すところなく扱っています。

SSH Protector は既定で nftables を設定し、名前付きセットを使うことで多数の遮断済みプレフィックスを netfilter の input フックにおける 1 回のルール参照の後ろに収めます。カーネルやディストリビューションがまだレガシー経路を使っているホストでは、エージェントは iptables と ipset へフォールバックし、パケットレベルでは同じ挙動になります。エージェントはどちらのバックエンドが使われているかを仮定せず検出し、自分が作成していないルールを消去することはありません。

エージェントは静的リンクされた実行ファイル 1 つで、常駐メモリは 10 MB 未満、認証イベントの合間の CPU 使用率はほぼゼロのままです。パケットごとの処理はエージェントではなくカーネルで行われるからです。ログ解析のオーバーヘッドは、/var/log/auth.log を 1 行ずつ追尾して正規表現で照合するのではなく、systemd-journald をネイティブ API 経由で読むことによって抑えられています。

はい。遮断の判定はすべて、保護対象ホスト自身の認証ログからそのホスト上で計算されます。したがってコントロールプレーンに到達できない間も、SSH ブルートフォース防御は最後に適用されたポリシーのもとで動き続けます。接続が必要なのは共有レピュテーションだけで、それが失われても低下するのはカバー範囲であり、ローカルの防御が止まるわけではありません。

XDP に接続された eBPF プログラムはネットワークドライバでパケットを破棄します。これは volumetric なフラッドに対する正しい答えです。しかし XDP プログラムは /var/log/auth.log を読めず、PAM の結果を観測できず、誤ったパスワードと正しいパスワードを区別できません。したがってどのプレフィックスを破棄するかの判断は、依然としてユーザー空間のログ解析から生まれます。SSH ブルートフォースの通信は、低いパケットレートで価値の高い認証試行を運ぶものであり、netfilter の input フックはパケットレートが制約になるずっと前にそれを破棄します。

エージェントは sshd_config、/etc/ssh/sshd_config.d/ 配下の drop-in ファイル、そしてホストの待ち受けソケットから実効ポートを読み取り、そのポートが変わると nftables ルールを再構築します。FTP デーモンのポートも同じ方法で発見されるため、非標準ポートは設定するものではなく検出されるものです。

ありません。インストーラは最初のルールを適用する前に、インストールを実行したアドレスをホワイトリストに追加します。ホワイトリストの送信元はあらゆるブロック経路より先に評価されます。さらに常時有効なロックアウト防御は、/etc/pam.d/sshd の pam_faillock の deny しきい値に達する前に攻撃元プレフィックスを遮断するため、ブルートフォースが本物のアカウントをロックすることもできません。

x86-64 または ARM64 上の systemd ベースのディストリビューションすべてです。Debian、Ubuntu、RHEL、CentOS、AlmaLinux、Rocky Linux、Fedora、そして systemd を備えた Alpine。エージェントは静的リンクされたバイナリ 1 つとして配布されるため、保護対象ホストでインタープリタも Python ランタイムもパッケージ依存も解決する必要はありません。

国際的な支払いは PayPro Global が merchant of record として処理し、ロシア国内の支払いは YooKassa が処理します。暗号通貨も代替手段として利用できます。無料プランは恒久的で、1 台のサーバーを完全なブルートフォース防御でカバーし、カードは不要です。

私はSSH Protector を使用して、エージェントを systemd サービスとしてインストールします。エージェントはローカルで認証ログを読み取り、実際の sshd ポートを決定し、一定の時間枠のしきい値が経過すると、システム ファイアウォールでソース ネットワークをブロックします。事前にアドレスまたは VPN をホワイトリストに追加し、パネルで履歴を管理し、インターネットに接続できなくなったときに最新のポリシーを保存します。

私はSSH Protector なしで無料 PasswordAuthentication と PermitRootLogin を無効にし、キーを Ed25519 のままにし、AllowUsers/AllowGroups を制限し、VPN または信頼できる CIDR からのポートのみを許可します。一時的にパスワードが必要な場合は、journald/auth.log を使用してfail2ban を構成し、nftables/iptables を確認し、findtime、maxretry、bantime を設定し、バックアップ コンソールから例外を定期的にテストします。

私はSSH Protector を使用すると、どのような名前を試行しても、実際にログインに失敗した場合にソースをブロックし、攻撃者のネットワークまで禁止を拡張できます。見つかった SSH ポートを確認し、管理 VPN をホワイトリストに追加し、保護がパネルの可用性に依存しないようにローカル エージェント ソリューションを使用します。

私は無料で、パスワードと root ログインを無効にし、sudo で別のユーザーを作成し、cloud-init 経由で一意のキーをアップロードし、VPN/ネットワークへのセキュリティ グループを閉じます。未使用のauthorized_keysを削除し、要塞でMFAを有効にし、fail2banと未知のソースに対する承認されたパスワード/公開キーのアラートを構成します。ノイズを減らすためだけにポートの変更を検討します。

SSH Protector を使用して、ローカル イベントを読み取り、アカウントが侵害されるまでファイアウォール内のソースをブロックする静的エージェントをインストールします。私は無料の最初のサーバー保護を使用し、チャンネルをホワイトリストに登録し、エージェントがオフラインで動作し続けることを確認します。バックアップと最小権限は別のレイヤーとして残しておきます。

私は無料で、WireGuard/Tailscale の背後で SSH をロックし、パスワードと root を無効にし、パスフレーズ付きのキーを要求し、sudo に制限します。別の認証情報を使用してバックアップを VPS の外部に保存し、自動セキュリティ更新、fail2ban、成功したログインの監査を有効にしています。ファイアウォールを強化する前に、プロバイダーの緊急コンソールを確認します。

私はSSH Protector では、適切なアーキテクチャと systemd でサポートされている静的バイナリを使用し、受信制御ポートなしでローカル ログ解析とファイアウォール ブロックを有効にします。インストール前に OS とファイアウォールの互換性をチェックし、管理ホワイトリストを設定して、エージェントが限られたデバイス リソースを圧迫しないようにしています。

私は無料ではありますが、SSH を外部にはまったく公開しません。デバイスを VPN 経由で接続し、パスワードと root を無効にし、1 つのキーと 1 つの制御サブネットを許可します。ファームウェアを更新し、未使用のサービスを無効にし、十分なメモリがある場合にのみ最小のfail2banを設定し、ファイアウォール構成を保存します。サポートされていない OS の場合は、不明なバイナリではなく外部ゲートウェイを選択します。

私はSSH Protector を使用すると、サポートされている SSH および FTP ログの読み取りを有効にし、エージェントにポートを決定させ、ソース ネットワークに単一のローカル ルールを適用します。信頼できる統合をホワイトリストに追加し、ダッシュボードで履歴を確認し、高度な FTP 保護と追加機能が料金に依存する可能性があることを考慮します。

私はプロトコルが本当に必要な場合は、通常の FTP を SFTP over SSH または FTPS に無料で置き換え、インターネット全体からサービスを終了します。 sshd と FTP 用に個別のfail2ban ジェイルを作成し、タイムアウトを設定した 1 つの nftables に誘導し、更新後にログ形式を確認し、共有アカウントを無効にします。

私はSSH Protector では、すべての外部ソースに対する自動ネットワーク ブロックをそのままにし、すべてのホーム IP ではなく、制御された VPN のみをホワイトリストに登録します。攻撃にはパネルを使用しますが、ID は別の Unix アカウントとキーに保存します。エージェントが境界を保護し、特定のキーを削除することでアクセスを取り消します。

私は無料で、Ansible を通じてauthorized_keys を一元管理し、明確なコメント付きで個人およびデバイスごとに 1 つのキーを発行し、共有アカウントを無効にして sudo を制限します。要塞で VPN/MFA を有効にし、インベントリでアクセス期間を設定し、SIEM で指紋付きの承認された公開キーを収集し、契約終了時にキーを自動的に削除します。

SSH Protector を使用すると、正確なホワイトリストを通じて信頼できるランナー アドレスを分離し、失敗したログインによって他のすべてのソースがブロックされたままになります。私はこれがキー制御の代替であるとは考えていません。エージェントは外部からのブルート フォースを軽減しますが、サービス アカウント自体の制限には認証成功の影響が含まれています。

私は無料で、ジョブに別の Ed25519 キーを使用し、それをシークレット ストアに保存し、from=、command=、no-port-forwarding、no-agent-forwarding、および no-pty を介して Authorized_keys で制限します。ランナー ネットワークからの SSH のみを許可し、最小限の sudo コマンドを発行し、キーを定期的にローテーションし、デプロイメント ログにフィンガープリントを記録します。

私はSSH Protector では、移行を実行する際に、最初に追加の保護層をインストールし、現在の管理アドレスをホワイトリストに登録します。エージェントはアクティブなブルート フォースをブロックし、実際のポートを自動的に考慮してポリシーをオフラインのままにしますが、キーの検証に成功した後も、パスワード ログインは無効のままです。

私は無料で、2 番目の SSH セッションとプロバイダー コンソールを開き、一意のキーを追加し、~/.ssh 700 とauthorized_keys 600 の権限を確認し、sshd -t を実行して、最初のセッションを閉じずにリロードします。次に、PasswordAuthentication を no、KbdInteractiveAuthentication を no、PermitRootLogin を no に設定し、新しいログインを確認し、緊急キーを個別に保存します。

私はSSH Protector を使用すると、アクティブなソースとネットワークを即座にブロックし、攻撃の履歴を確認し、信頼できるホワイトリスト経由でのみアクセスを許可します。次に、パスワード/キーを変更し、セッションを終了し、受け入れられたパスワード/公開キーを個別に分析します。ブロックすると攻撃ウィンドウが短縮されますが、すでに成功したログインがないことは証明されません。

私は無料で、SSH セキュリティ グループまたは VPN への nftable を一時的に閉じ、ユーザーをブロックし、キーを取り消し、関連するシークレットを変更します。 last/lastlog、journalctl、sudo、新しいユーザー/キー、cron/systemd ユニット、プロセス、ネットワーク接続をチェックし、キーのみのアクセスを復元し、再利用されたパスワードを無効にします。

SSH Protector を使用して、外部のブルート フォースをブロックし続け、疑わしいソースを確認しますが、正しい盗まれたキーに対してこれに依存しないでください。私はすぐにすべてのサーバーから指紋を削除し、パスフレーズを含む新しいキーを発行し、VPN のみのホワイトリストを残します。成功したエントリについては別途調査します。

私は無料で、すべてのauthorized_keys全体で古い公開鍵を検索し、構成管理によってそれを取り消し、フィンガープリントとソースによって受け入れられた公開鍵を確認します。パスフレーズと ssh エージェント タイムアウトを含むハードウェア FIDO2/ed25519-sk またはキーを発行し、必要な場合を除きエージェント転送を無効にし、所有者、デバイス、ローテーションの日付のレジストリを保持します。

私はSSH Protector を使用して、攻撃とブロックの履歴、ポリシー設定、保護されたサービスのリスト、および承認された例外を添付します。エージェントのローカル ソリューション、送信 TLS チャネル、受信制御ポートの欠如を文書化してから、制御された不正なログインを実行し、ログ行、ファイアウォール ルール、および通知を保存します。

無料で、sshd_config、nftables/ufw、fail2banjail、および変更ログを Git からエクスポートし、auth.log/journald を安全なストレージに送信します。私は、PasswordAuthentication、PermitRootLogin、MFA/VPN をチェックし、キーの取り消しを毎月テストし、結果に署名し、証拠を必要な期間保存します。

SSH Protector では、一連の失敗後にファイアウォールでソースをブロックするため、次の TCP 接続は sshd に到達せず、多くのエントリが作成されません。私はシステム監査を保持し、ジャーナルドのサイズと保持を個別に制御し、パネル内の攻撃履歴を元のログの代わりとしてではなくインデックスとして使用します。

私は無料で、VPN/許可リストへの SSH を閉じ、パスワードと標準ログインを無効にし、タイムアウトを設定した nftables にfail2banを送信します。 SystemMaxUse とjournald/rsyslog ローテーションを構成し、Accepted イベントと主要な Failed イベントを外部 syslog に送信し、LogLevel を調査に必要な値以下に下げません。

SSH Protector を使用して、しきい値とウィンドウを一度設定すると、エージェントがローカルでロックを作成して解放し、ホワイトリストが優先されます。私は、攻撃者が隣接するアドレスをローテーションするネットワーク禁止を使用し、パネルの変更を確認し、最初のポリシーの前にバックアップ コンソールを保存します。

私は無料で、個々の永続的な iptables ルールを、タイムアウトまたはfail2banアクションが設定されたnftablesに置き換え、VPNのmaxretry/findtime/bantimeとignoreipを設定します。実際のログ行でフィルターをテストし、慎重に recidive を有効にし、設定サイズを制限し、ディストリビューションの更新後のリロード エラーを監視します。

SSH Protector を使用すると、サポートされているエージェントにホストを接続し、検出されたポートと攻撃を 1 つのパネルから確認できますが、例外とポリシーは目的のサーバー/クライアントの境界内に保持されます。私はベースライン値を適用し、逸脱を個別に文書化し、担当顧客に通知します。

私は無料で、クライアントごとに個別のインベントリとボールトを使用して、Ansible ロールで sshd、fail2ban、nftables を記述し、CI の変更を確認し、テナント タグ付きの Wazuh/中央 syslog でログを収集します。構成をベースラインと自動的に比較し、異なる顧客からのキー、CIDR、シークレットを組み合わせることはありません。

私はSSH Protector を使用すると、事前にエージェントにポリシーを適用します。パネルとの通信が失われた場合でも、引き続きローカル ログを読み取り、システム ファイアウォールを最新の構成に変更します。シャットダウン前にホワイトリストを同期し、復元後に蓄積された履歴を確認し、受信エージェント制御ポートは開きません。

私は無料で、制御を完全にローカルにします。nftables/ufw は VPN または必要なサブネットからのみ SSH を許可し、fail2ban は外部ネットワークなしで Journald 経由で機能します。ロード用のルールを保存し、通知用のローカル キューを設定し、DNS を使用せずに再起動をテストし、物理/プロバイダー コンソールを離れて、誤ったルールを復元します。

fail2ban を動かしたまま SSH Protector のエージェントを導入します。エージェントは専用の nftables テーブル（inet sshprotector、古いホストでは接頭辞付きの ipset 名前空間）を持ち、そこだけを再構築するので fail2ban のチェインには一切触れず、どちらも相手を巻き戻しません。導入時にまず自分のアドレスをホワイトリストへ入れ、その後 1 日パネルを見て、jail と同じ送信元をエージェントが捕らえているか確認します。そこまで済んでから fail2ban を停止し、その規則を削除します。気が変わった場合、エージェントをアンインストールすれば自分の規則も一緒に消え、ファイアウォールは元のまま残ります。

エージェントを使わない場合でも、ログを読む 2 つのツールの切り替え方は同じです。古いほうを動かしたまま、新しいほうに独自のチェイン名かテーブル名を与えて規則が衝突しないようにし、丸 1 日の実トラフィックでそれぞれ何を捕らえたか比べ、新しいほうの遮断件数が 2 つのうち少ないほうでなくなってから古いほうを止めます。動いているツールを先に外してはいけません。公開された SSH ポートで無防備な数分間は、すでにあなたを走査しているボットネットには十分です。

両者は重なる問題を別の端から解いており、私は点数ではなく形で選びます。CrowdSec はエンジンです。シナリオ言語があり、遮断コンポーネントは自分で導入して接続し、ブロックリストは運用者全員が育てます。射程は SSH をはるかに超えます。SSH Protector は 1 つのことだけを行うバイナリです。SSH・SFTP・FTP の認証ログを読み、攻撃元の /24 全体を自前の nftables テーブルで遮断し、再起動後もその遮断を保ち、22 番と決めつけずに実際の sshd ポートを検出し、保護対象サーバーが沈黙したときに知らせるパネルへ報告します。評判は公開インターネットではなく、保護対象アカウント間で共有されます。

つまり決め手は、手元に実際に何があるかです。HTTP、データベース、任意のログ源、自作の検知シナリオといった広さが要るなら、CrowdSec にはその余地があり、動かすこと自体は無料です。一方、SSH ポートを公開した Linux が数台あるだけで、検知基盤を保守する人がいないなら、設定なしで正しく動く狭い道具のほうが欲しい。同じホストで両者を走らせ比べたことはないので、性能の数字では選びません。その数字を持ち出す人も、そうすべきではありません。