インターネットに公開されているサーバーがあり、DDOS攻撃に対する保護を提供したいと思います。現在、fail2banおよび/またはsnortの使用を検討しています。私は彼らが彼らがどのように働くかについて異なるアプローチを持っていることを知っています。私の理解では、Fail2Banはログファイルを監視して侵入を判断し、snortは受信パッケージを監視します。
両方を使用する必要がありますか?そのうちの1つだけを使用するだけで十分ですか?ユニークな機能はありますが、他の機能はありませんか?私が抱えている懸念の1つは、パフォーマンスです。 snortは私たちのネットワークを遅くする可能性がありますか?
私があなたなら、fail2banから始めます。
どちらも適切に構成されていない場合、リソースを浪費する可能性がありますが、正規表現を使用する際の注意点は、より身近なものになると思います。
fail2banは、すぐに役立つようにするのが簡単です(少なくとも私の目には)。
悪意のあるソースを実際にブロックするように設定するのはsnortよりもはるかに簡単であり、snortログをスキャンして禁止するようにfail2banを構成できます。
どちらも実際にはDDoS自体から保護することはできないでしょうが、どちらもブロッキングモードと同等に、実際のアプリケーションサーバーとの相互作用を(事実上)回避することで、ネットワーク以外のリソースの枯渇を防ぐために使用できます。
Snortの問題の1つは、IPSモード(つまり、実際にトラフィックをブロックする))で動作させるのは簡単ではないということです-AFAIK、はるかに一般的なのは、IDSとして実行することです(つまり、悪意のあるトラフィックの検出)。
fail2banは、あなたが言うように、本質的にはログファイルの正規表現を実行し、それらのログから悪意のあるソースを抽出する単なるスクリプトです(たとえば、SSHログインの失敗、Webクライアントが4xxまたは5xxの応答を繰り返す、または既知の攻撃者プロファイルに関連付けられたユーザーエージェントを持つ) )。悪意のあるホストに関連するトラフィックをブロックするために、iptables(およびiptables上で実行されている可能性のあるもの(firewalld、shorewallなど)と統合します。これらのブロックは、単純なiptablesルールとして、またはiptablesルール+ ipsetとして実装される傾向があります。
snort(およびsuricata、およびその他のIDSen)は、潜在的に悪意のあるトラフィックを検出するために、トラフィックフローのさまざまな側面を実際に検査します。ドメイン固有の形式のルールを使用します。これにより、IPアドレス(および/またはホスト名/ドメイン)の照合、パケットの検査、再構築なども実行できます。 EmergingThreat's でかなり広く使用されているルールセット-snortの機能を理解するために、それら(の一部)を読み通すことができます。
1つの考慮事項は、fail2banは通常、箱から出してすぐに役立つということです。これは、snortには完全には当てはまりません。通常、イベントの量とアクション可能性のバランスをとるために、ルールを調整する必要があります(場合によっては独自のルールを追加する必要があります)。 。
個人的には、私がsnortでより良くなるのに時間を費やしている間、私のために働くセットアップは次のとおりです。
それはあなたにとってうまくいくかもしれないし、うまくいかないかもしれませんが、それはあなたがその内部に特に精通する必要なしにsnortからsome追加の保護を得るということを意味します。
ただし、snortルールは、正当な理由よりも少し警戒心が強いように見える可能性があります。つまり、どの脅威を指しているのか、アラートを理解/解釈する方法をある程度理解しておくことは、一般的に努力する価値があります。
Snortに慣れたら、まずそれを調整してから、直接処理できるようにするかどうかを検討します(たとえば、IPSモードにする)。
ちなみに、公開されているアセットの多くがWebベースである場合、WAFがどのように全体像の一部になるかを検討することをお勧めします。