Linux を実行している AWS サーバーがあります。マシン自体から を実行するとnetstat -lntp、いくつかのポートが開いていることが示されますが (予想どおり)、445 または 139 は表示されません。このマシンに Samba をセットアップしたことがないので、これは当然です。さらに、実行中のプロセスを一覧表示してsmbまたは をgrep するとsamba、実行中のものは何も表示されません。
サーバーのファイアウォール ルールを見ると、ポート 80 と 22 の受信トラフィックのみが許可されていることがわかります。すべてのポートのすべての宛先への送信トラフィックは許可されていますが、これは関係ないと思います。
問題は、ネットワークの外部から実行するとnmap、ポート 139 と 445 が閉じられていると表示されることです。これはなぜでしょうか。私の理解では、「閉じられている」とは、ファイアウォールがパケットをサーバーに通過させているが、ポートでリッスンしているものがないことを意味すると思います。なぜファイアウォールはトラフィックを通過させているのでしょうか。
答え1
私の理解では、「閉じている」とは、ファイアウォールがパケットをサーバーに通過させているが、ポートでリッスンしているものがないことを意味します。なぜファイアウォールはトラフィックを通過させているのでしょうか?
「Closed」は、nmap が TCP RST パケットを受信したことを意味します。これは、ポートで何もリッスンしていない場合に IP ホストが応答する方法です。
しかし、nmapはリセットパケットが実際のホストから来たのか、それともファイアウォールによる偽装途中で。(実際、多くのファイアウォールは、接続試行を黙って無視するのではなく、明示的に拒否するように設定されています。これにより、クライアント側での長いタイムアウトを回避できます。)
サーバーのファイアウォールが、
reject with tcp-resetまたは同様のものを使用している可能性があります。スキャンしているネットワークがから安全対策としてすべての送信 SMB 接続をブロックするように構成されており (たとえば、ワークステーションが悪意のあるサーバーに NTLM で通信するのを防ぐため)、'RST' を生成しています。
それは、ISPスキャン元の Web サイト、またはサーバーがホストされている ISP が、マルウェア (古い Conficker ワームなど) の拡散を防ぐために、WAN 経由の SMB 接続をブロックしています。
tcpdumpを使用してパケットを見ると、ミドルボックスによって偽装されたRSTは当然サーバーからは見えません（サーバーが送信していないため）。そして、そのようなパケットはかもしれないサーバーが生成する実際の応答とは TTL が著しく異なります。
特定の状態が表示されている理由を確認するために使用しますnmap --reason。 nmap は TCP RST が「閉じている」 (ホストが接続を受け入れなかったため) であると見なしますが、他のツールでは実際には「開いている」 (ファイアウォールがパケットの通過を許可したと見なす) と見なすことに注意してください。