AWSインスタンスを作成しているときに、自分のIPアドレスのみがサーバーにアクセスできるようにすることを選択しました。また、構成されたRSAキーがあります。この場合、サーバーにfail2banをインストールする必要がありますか?
その場合、fail2banは不要になると思います。
ハイパーバイザー(aws)ファイアウォールで管理サービスをインターネットに公開する必要がある場合にのみ、fail2banを使用します。あなたのケースでは、あなたのIPからのものを除くすべてのリクエストがドロップされています。
IPアドレスが変更された場合(静的でない場合)、awsセキュリティグループを更新する必要があります。
Fail2ban 潜在的に悪意のあるアクションがないかログファイルをスキャンし、そのような動作の発生元のIPアドレスを禁止します。通常、Fail2Banは、そのIPアドレスからの後続の(悪意のある)アクションが繰り返されないようにブロックするアクションを開始するために使用されます。
管理者としてロックアウトされないようにするには、通常、fail2banの IP-whitelist に独自の(管理)ネットワークアドレスを追加します。
サーバーまたはサービスが、そのホワイトリストに存在する同じIPアドレスまたはネットワーク、あるいはその両方からのアクセスのみを許可するようにファイアウォールで保護されている場合、fail2banは実際には何も実行しません。
Fail2banのAWSファイアウォールを使用する利点は、APIです。 APIを使用すると、多数のインスタンスのファイアウォールルールを一元的かつ自動的に管理できます。fail2banを使用すると、はるかに困難になります。
AWSのセキュリティポリシーのため、fail2banと言うすべての回答は不要です。事実上、別のファイアウォールです。ただし、それが失敗したり、設定が誤ったりすると、攻撃が発生する可能性があります。iptables/ firewalld/ufwとfail2banの組み合わせは完全に意味があり、階層化セキュリティは重要な戦術です。したがって、fail2banは(基本的なファイアウォール構成と共に)依然として良い考えです。
@timが述べたように、fail2ban(および他の種類の同様のツール)は、AWSセキュリティポリシーよりもきめ細かく提供できることを追加したいと思います。これは、プロトコルとIPアドレス範囲に制限されているようです。たとえば、攻撃的なスパイダーや、ログインしようとするボットをブロックできます。ネットワークレイヤーでのブロッキングは、WebサーバーやWebアプリケーション(Wordpressなど)レイヤーよりも効率的です。
私があなたの場合にfail2banを追加する唯一の理由は、サーバーに無制限に接続しようとする子供をドロップし、それが提供する応答を無制限に制限することです(サーバーが接続しようとしているユーザーに対してREJECT応答を生成する場合)。
これで、IPをホワイトリストに登録する正当な理由があるかもしれませんが、SSHでは、キーを非公開に保つ限り(ルートログインを無効にするのが最善です)、かなり安全です。また、パスワードと「ランダム」に生成された番号を使用して、sshで2要素認証を設定すること(たとえば、Google 2FAを使用)は非常に簡単です。 sshのIPをホワイトリストに登録することは、ある時点で実際的でなくなる場合があります。