web-dev-qa-db-ja.com

Iptablesを介してSSHブルートフォースをブロックする方法とその仕組み

iptablesに次のルールを追加して、最近一般的なsshブルートフォース攻撃を阻止する予定です。

-A INPUT -i eth0.103 -p tcp -m tcp --dport 4522 -m state --state NEW -m recent --set --name SSH --rsource    
-A INPUT -i eth0.103 -p tcp -m tcp --dport 4522 -m recent --rcheck --seconds 30 --hitcount 4 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset    
-A INPUT -i eth0.103 -p tcp -m tcp --dport 4522 -m recent --rcheck --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j LOG --log-prefix "SSH brute force "    
-A INPUT -i eth0.103 -p tcp -m tcp --dport 4522 -m recent --update --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset    
-A INPUT -i eth0.103 -p tcp -m tcp --dport 4522 -j ACCEPT

2番目、3番目、4番目のルールは、同じIPからの攻撃を30秒以内にログに記録してブロックする責任があることを理解しています。間隔。

ご質問

  1. ドキュメントに「システムログに一度ログを記録し、すぐに拒否して忘れる」と記載されている場合、忘れることはどういう意味ですか？
  2. 永遠にそれを忘れますか？
  3. Iptablesがチェックするブラックリストはありますか？
  4. IPが拒否されたが、1時間後に別の接続を試行した場合、そのIPからさらに3回試行されますか？
  5. その場合、iptablesにブラックリストカウントがない限り、これはブロックではなく攻撃を遅くしますか？
sshsecurityiptablesfirewall
4
fcukinyahoo

質問＃1：ドキュメントに「一度システムログに記録したら、すぐに拒否して忘れてください」と書かれている場合、忘れるとはどういう意味ですかそれについて？

メッセージがログに表示されるのは1回だけなので、ルールがトリガーされるたびにログがメッセージの連続ストリームで汚染されることはありません。

質問＃2：それを永遠に忘れますか？

いいえ、永遠ではありません。これらのメッセージがログに発生する頻度に関連する期間があります。

質問＃3：iptablesがチェックするブラックリストはありますか？

いいえ、iptablesが「チェック」するブラックリストはありません。それはあなたがそれを言うことだけをフィルタリングし、あなたがそれを通過させるようにあなたが言うことだけを許可するという意味でばかげています。

質問＃4：IPが拒否されたが、1時間後に別の接続を試行した場合、そのIPからさらに3回試行されますか？

これは、オーバーアーチタイムアウトが何であるかによって異なります。追加の試行が発生し、最初の試行から元のタイムアウトが経過していない場合、ログに追加のメッセージングや許可された接続がないはずです。ただし、そのタイムアウトが経過した場合は、これらの後続の試行に関する追加のメッセージが表示されます。

動作の詳細については、Iptableのrecentモジュールのドキュメントをご覧になることをお勧めします。

ポートスキャン

IPが「badguy」リストに残っている時間の長さは、次のようなルールの構造によって管理されます。

iptables -A INPUT -i $OUTS -m recent --name badguys --update --seconds 3600 -j DROP
iptables ...
 .
 .
 .
iptables -A INPUT  -t filter -i $OUTS -j DROP -m recent --set --name badguys

最初のルールは、着信パケットがすでに「badguy」リストにあるかどうかを確認します。もしそうなら、時計は--updateスイッチによって「リセット」され、悪者のIPは最大1時間（3600秒）このリストに残ります。その後の試行ごとに、この1時間のウィンドウがリセットされます。

注：このように構成されたルールでは、違反者は再び私たちと通信できるようにするために、1時間完全に沈黙してください

[〜＃〜] ssh [〜＃〜]

SSH接続の場合、戦術は少し異なります。 IPが "badguy"リストに追加されることに関連するタイムアウトは、まだ1時間であり、その1時間のウィンドウ内で再接続するたびにリセットされます。

SSHの場合、各--syn接続をカウントする必要があります。これはTCP SYNパケットであり、TCP 3ウェイハンドシェイクで発生します。これらをカウントすることにより、各接続試行を「追跡」できます。 30秒のウィンドウで2回以上私たちに接続し、私たちはあなたをドロップします。

「badguy」リストで継続的に接続を試みるこれらのIPを取得するために、5分ウィンドウ（300秒）内に6回接続しようとした場合に、それらを追加する別のルールを組み込むことができます。

対応するルールは次のとおりです-それらの順序は重要です！：

iptables -N BADGUY
iptables -t filter -I BADGUY -m recent --set --name badguys

iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --set
iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --rcheck --seconds 300 --hitcount 6 -j BADGUY
iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --rcheck --seconds  30 --hitcount 2 -j DROP

注：/proc/net/ipt_recentの下の「badguy」リストを確認できます。リストの名前がbadguys。のファイルがそこにあるはずです。

質問＃5：その場合、iptablesにブラックリストカウントがない限り、攻撃はブロックされていませんが、速度が低下していますか？

一般に、iptableの観点から接続の試行に対処するには3つの方法があることがわかると思います。

  1. 許容できることがわかっているトラフィックを許可する
  2. 許容できないことがわかっているトラフィックを許可しない
  3. 潜在的に不良である、速度が低下する、および/または無期限に、または「タイムアウト」期間の間拒否されるトラフィック。上記の動作が「タイムアウト」を使用して処理されている場合は、タイムアウトが経過した後に再度許可します。

＃3は、一般的にiptablesやファイアウォールの設定に伴う複雑さのほとんどです。インターネット上のトラフィックの大部分はまあまあですが、1つのIPがサーバーのポートXに接続しようとするという意味で、そのトラフィックが「強迫観念」の振る舞いを示すときが問題になるのです。

参考文献

5
slm