web-dev-qa-db-ja.com

SYNフラッドではなく、SYN_RECVの接続数が多い場合、それはリフレクション攻撃ですか？

少なくとも数か月以来、netstat -t TCPポート22、80、および443がインターネットに公開されているWebサーバー上のコマンドは、多くの場合、SYN_RECV 状態：

$ netstat -nt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 128.1XX.XX.X:22         142.93.230.186:50603    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         104.248.89.196:36332    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         167.71.79.217:40430     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         142.93.235.90:36742     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.128.243.146:35451   SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.253.100:43994    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         188.166.91.16:42461     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         178.62.242.138:33381    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         142.93.235.90:57784     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        165.22.198.207:36181    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         68.183.11.83:63899      SYN_RECV
tcp        0      0 128.1XX.XX.X:22         104.248.93.253:41816    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         104.248.85.129:48833    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.62.207.43:59050     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         128.199.55.152:55891    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.205.23:52978     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         165.22.198.135:36668    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         165.22.203.65:65273     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         68.183.15.91:46722      SYN_RECV
tcp        0      0 128.1XX.XX.X:443        167.71.4.136:55194      SYN_RECV
tcp        0      0 128.1XX.XX.X:80         142.93.228.103:60458    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.253.100:52599    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         104.248.89.56:46283     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.250.235:43637    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        167.71.7.181:37556      SYN_RECV
tcp        0      0 128.1XX.XX.X:80         104.248.89.200:64128    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         142.93.139.213:38821    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        104.248.92.161:63004    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         68.183.15.91:46210      SYN_RECV
tcp        0      0 128.1XX.XX.X:443        104.248.92.138:39651    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         178.62.241.74:43953     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         142.93.224.74:42996     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        165.22.196.167:38597    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.128.254.3:36751     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         104.248.93.27:32904     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        167.71.78.255:60529     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         165.22.201.209:45397    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.62.207.205:39291    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         165.22.198.207:61967    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.234.81:39309     SYN_RECV
[---cut---]

最初に私が持っていたのはSYNフラッディング攻撃だったということですが、（a）サーバーは「攻撃」の影響をまったく受けていないようです（b）SYNレートはかなり低く、わずか2パケットを超えています/秒。（c）通常、そのサーバー（大学のネットワークでホストされている大学のラボのWebサーバー）と完全に異なるネットブロック（ホームサーバーを介して接続されている）にあるホームサーバーの両方で同じネットブロックから送信されるSYNパケットを観察します。パブリックダイナミックIPを使用した通常の住宅用ファイバー接続）、および（d）LinuxカーネルがSYNフラッドの可能性について準拠することはありません（TCP SYN Cookieが有効になっています）。

私が不思議に思っているのは、これらのSYNパケットの実際の目的が何であるかです。それらはネットワークの問題（不適切に設定されたファイアウォールまたは同様の問題）に起因するものではないようです。ほとんどの場合、データセンターのIPスペースから取得されます。IPスペースは1日ごとに変化します（Amazon EC2、Serverius、DigitalOceanなど）。場合によっては、1つから数個のIPである場合もあれば、数十ある場合もあります。 pingを実行すると、IPが応答する場合とそうでない場合があります。私は散発的にテストしただけですが、ポート80または443のIPで到達可能なWebサーバーを見つけることはほとんどありませんでした（これより多くのポートをスキャンしようとしたことはありません）。彼らは恐らく1時間バーストして来て、その後消えます。それらを自動的に検出して、「スケジュール」があるかどうかを確認するために1時間ごとのプロットを作成することはまだしていません。

これは偽造されたIP送信元アドレスを使用したある種の増幅攻撃である可能性もあると考えていました（受信した各SYNパケットは、サーバーがタイムアウトする前に最終的に5つのSYN ACKパケットを生成します）。しかし、それは（a）a通常のサーバーはRSTパケットで迅速に応答するため、それ以降のSYN ACKを停止します。（b）前述のように、これらのサーバーは、DDoS増幅攻撃に値する可能性のある公開Webサイトをホストしていないようです。

（偽装されている可能性がありますか？）送信元アドレスには、ほとんどPTRレコードがないか、一般的なものがありますが、場合によっては実際のホスト名が提供されます（たとえば、上記のリストでは、142.93.230.186はparimatchklub.comを提供し、明らかにロシアのスポーツ賭博サイトです）。 。サイトへの到達が非常に遅かったので、たぶんそれは確かに、見かけの送信元アドレスに対する何らかの形のリフレクション攻撃ですか？

他の誰かがすでにこれを観察しましたか？これらのパケットの実際の目的について何か説明はありますか？

networkingtcpattackssyn
3
Ale

それは、nmap Hostの発見のようなものによって残されたフットプリントのように見えます。 Nmapは、ホスト検出ツールおよびポートスキャナーです。

nmapのホスト検出フェーズは、icmp pingをブロックするサーバーを検出するために、synパケットをWebサーバーポートに送信できます。誰かがnmapを使用して、IP範囲（または0.0.0.0/0）のライブホストを検出していて、ホストにまったく関心がない可能性があります。

おそらく、SYNパケットとICMPパケットをパケットスニッフィングし、以下で説明するスキャンと比較することで、これを検出できます。 https://nmap.org/book/man-Host-discovery.html

また、より広いポートスキャンでフォローアップしているかどうかも確認できます。脆弱性がわかっている特定のポートを持つホストを探している可能性があります。

2
Fenster34

これらのパケットの実際の目的について何か説明はありますか？

netstatの出力は、サーバーがESTABLISH接続に失敗したことを示しています。これは、暫定的な接続の問題または偽装された（偽造された）IPソースエンドポイントである可能性があります—送信した応答が単にイニシエーターに到達しなかった（s）。

「なりすましバージョン」を選択した場合、少なくともサーバーが接続しているチャネルへの接続を追跡することをお勧めします。アップストリームではなく、LAN（実際のLANまたはVMネットワークなど）である可能性があります。

次に、それが上流である場合、懸念を彼らの懸念に転送するかもしれません [〜＃〜] noc [〜＃〜] （もちろん、サポートから始まります）。あなたの味方なら、それを片付けましょう。

1
poige

サーバーのセキュリティをバイパスするのはHTTP回避である可能性があります。 IPアドレスは悪意のあるホストである可能性があります。これは、ホストマルウェアに知られ、ボットネットアクティビティに参加する予算ホスティングプロバイダーであるためです。

1
Olaf V