crontabで毎分実行されるスクリプトがあります。
スクリプトは、システムログをスキャンしてサーバーにログインしようとするたびに、dovecot、exim、またはsshに失敗したIPを取得し、ipsetに追加してIPを永久にブロックします。
問題は、このスクリプトが1分ごとに実行され、攻撃者のIPを取得してipsetに追加することをうまく実行しますが、システムを攻撃しようとする同じIPのログエントリがまだあることです。
つまり。それでは、誰かがシステムを攻撃しようとしているとしましょう。 1分以内にスクリプトが実行され、3回以上のパスワードエラーを持つすべてのIPを取得してIPsetに追加します。それにもかかわらず、まだサイトに無差別の代入を試みる数時間のIPログがあり、接続が中断されません。
私の仮説は次のとおりです。 ipsetはテーブルにIPを追加することで機能し、次にIPがサーバーに到達するとIPがブロックされますが、そのIPが攻撃しようとしているサーバーにすでに接続されている場合は接続されません。落ちた。これは正しいですか？それでは、進行中の接続を中断する方法はありますか？
注：履歴の場合：iptablesにブロックという名前のipsetを追加するために使用したコマンドは次のとおりです。
iptables -A INPUT -p tcp --dport XX -m set --set blocking src -j DROP
ここで、XXはブロックしたいポートです。
ベストアンサー1
iptables -Aに追加する終わり接続済み（長い形式-Aはです--append）。iptables -A INPUT -p tcp --dport XX -j ACCEPTルールが上から下に実行されたときに最初に一致するため、妨害するルールが上の近くにある可能性があります。
この問題を解決する2つの明確な方法があります。
サービスの承認ルールの前に呼び出される別のブロックチェーンを使用します。ブロックチェーンへのジャンプが適切に規制されれば、これらすべてのルールが必要でなければテストされないため、これが私が使用する方法です。どのブロックチェーンに追加したいのかを把握する必要があります。もう1つの利点は、必要に応じて、
iptables -F smtp-blocksポート25の各ブロックを手動で見つけて削除するよりもはるかに簡単です。 （セットを使用しているという事実は、この問題を多少緩和することができます。私はルールセットなどについてはよくわかりません。）セットを使用して実行できます。 )変える
iptables -Aそしてiptables -I。-I一番上（または指定されている場合はインデックスの前）に挿入を使用すると、サービスがルールを受け入れる前にブロックルールが実行されます。
私の仮説は次のとおりです。 ipsetはテーブルにIPを追加することで機能し、次にIPがサーバーに到達するとIPがブロックされますが、そのIPが攻撃しようとしているサーバーにすでに接続されている場合は接続されません。落ちた。これは正しいですか？それでは、進行中の接続を中断する方法はありますか？
ルールによって異なります。 TCPプロトコルルールがSYNパケットでのみ一致することを指定した場合（--syn）接続が開始されたときにのみ一致しますが、デフォルトはすべてのパケットと一致することです。 UDP には接続開始の概念はありません。道同様の目的で。つまり、明示的に何も指定しないときちんと配置したら新しく追加されたルールは、次の受信パケットと一致し、関連するルールに従って処理されます。ルールに従い、リモート-j DROPパーティの観点から見ると、ネットワークケーブルを抜いたばかりのものとほぼ同じです。