☰

数回の試行後、接続要求がSYN_SENTでハングする

tag-icon • tag-icon networking ssh
数回の試行後、接続要求がSYN_SENTでハングする

オフィスを移転し、新しい場所に LAN/WAN インフラストラクチャを構築しました。

サーバー (LAN ではなくクラウド内) への SSH 接続を開始すると、最初の 3 ～ 4 回のリクエストは短い間隔 (5 秒以内に 4 回の呼び出しなど) で正常に動作しますが、それ以降の接続は SYN_SENT ステータスでハングします。それ以降のリクエストはすべて、タイムアウトと思われるまで SYN_SENT でハングします。その後、数回は再び動作します。

サーバーには変更が加えられておらず、さまざまなローカル クライアントがこのように動作します。したがって、違いは 2 つのエンドポイントではなく、IT インフラストラクチャにあると考えられます。

この動作にはどのような説明が考えられますか? 修正方法はどこで探せばいいですか?

私たちはリセットする必要があった Zyxel ZyWall ファイアウォールを使用していますが、このファイアウォールにはこの動作を説明できるフィルターがあるのでしょうか?

答え1

サーバーの iptables ルールには、「anti ssh bruteforce」ルール チェーンがあり、これは「recent」モジュールを使用して、1 分以内に 4 回の試行が行われた後に接続を切断します。このルールにはチェーン内の例外がありINPUT、フェイス IP からのすべての ssh を許可します。移動すると、フェイス IP が変更され、ルールを調整する必要がありました。参考までに、これが私がこれを実行した方法です。

すべてのiptablesルールを一覧表示する

# iptables -L --line-numbers

チェーン内の accept ルールに注意してくださいINPUT。これは、(以前の) フェイス IP アドレスからのすべての ssh 接続を受け入れるように設定されており、チェーン内で数回試行した後に ssh 接続をドロップするアンチブルートフォース ルールも設定されていますSSH_CHECK。

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
...
14   ACCEPT     tcp  --  old.myISP.com      anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num  target     prot opt source               destination
...
3    DROP       all  --  anywhere             anywhere            recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source

ルールを編集する/etc/iptables.rules

変化

-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT

に

-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT

ここで、111.222.33.44 は新しいフェイス IP です。適応されたルールを読み取ります。

 # iptables-restore < /etc/iptables.rules

関連情報