Nmapほとんどすべてのポートが開いていると報告
TCPポートスキャン、Nmapは、ほぼすべてのポートがマシンに対して開いていると報告します。
たとえばnmap -sS -PN -T4 target -p0-65535、20,000以上のポートが開いた状態で返されます。さらに調査すると、これらのポートのほとんどが開いていないか、フィルタリングされていません。
Nmapがポートが開いていると見なす原因は何ですか。これに対抗してより正確な結果を得ることができる別の種類のスキャンはありますか？
おそらく、適切に構成されたIDS/IPSアプライアンスを使用しています。
snort は、進行中のポートスキャンを sfPortscan フィルターで簡単に検出できます（-sSは、実際には「ポートスキャン進行中」のシグネチャです）。また、攻撃のロギングに加えて、 アクティブレスポンス を実行するように設定できます。これらの応答は、RSTを送信するだけの単純なものでも、「 react 」ルールのように豊富なものでもかまいません。 「反応」応答のデフォルトの動作は、HTTP 403 Forbiddenメッセージで応答することですが、必要な任意のデータを送信するように構成することもできます。反応動作もポート80リクエストに限定されません。 snortは応答を送信しますポート番号に関係なく。
この理論をテストするには、スキャンを実行しているのと同じマシンからターゲットのポートスキャンを実行しながら、そのターゲットの古いポートをブラウザーまたはnetcatで開いてみてください。非HTTPポートからHTTP 403 Forbidden応答を受け取った場合、それはおそらく何が起こっているのでしょう。
Nmapは応答を解釈しないと思います。ソケット接続が確立されたことが報告されるだけなので、オープンポートとして報告されます。ただし、推測するのではなく、nmapで--packet-traceオプションを設定して、実際に何が返っているのかを確認することもできます。
snortマニュアルはこちら を読むことができます。
いくつかのオプションがあります。私の最初の考えは、禁止された（ファイアウォールされた）ポートへのSYN/ACKパケットで応答している中間システムがあるかもしれないということでしょう。この場合、真に開いているポートを応答のTTLで区別できる場合があります。スキャンの XML出力 （-oXまたは-oA）を保存した場合、//port/state/@reason_ttl属性を確認できます。これは「ファイアウォーキング」の手法に似ています。ここでいくつかの関連情報を見つけることができます： nmap でのファイアウォーキング。
別の代替案は、 異なるスキャンタイプ を使用することです。 NmapのSYNスキャン（ルートとしてスキャンする場合の-sSまたはデフォルト）は、TCPオプション、MSS、およびウィンドウサイズによって検出できるため、IDS/IPSがそれに応答する可能性があります。代わりにTCP接続スキャン（-sT）を使用してみてください。他のスキャンタイプ（ACK、FIN、Maimonなど）を使用して、結果をフィルタリングできます。開いているポートを単独で表示することはありませんが、これらの「開いている」ポートの一部にファイアウォールとしてフラグを立てるか、少なくとも動作が異なることを示すことができます。ただし、これらは非常に顕著な「不良」パケットを送信し、最近のOSにはあまり存在しない動作に依存しているため、ここでは注意してください。
最後に、Nmapの サービスバージョン検出 （-sV）を使用して、「開いている」ポートの背後にあるサービスを識別できます。誤検知は単にタイムアウトするか、RSTを送信して接続を開いた直後に接続を閉じる可能性があります。これによりスキャン速度が大幅に低下しますが、正確であることが重要な場合があります。 --version-intensity 0から開始することをお勧めします。これは、バナーグラブを実行し、デフォルトではこれと最大8つの他のテストを実行するのではなく、スキャンされる特定のポートにタグ付けされたプローブを実行します。
サーバーが開くすべてのポートをシミュレートする難読化手法があり、理想的にはこれらのポートのほとんどで有効なサービス署名をシミュレートします。
Portspoof は、たとえば、このアプローチを実装し、8000を超えるサービス署名を処理します。
私にも同じことが起こりました。それはSnortが原因でした。 -fおよび--badsum nmapへの切り替えにより、IDS/IPSを回避できました。完全なコマンドは次のとおりです。
nmap -sS -p 1-65535 -f --badsum -vv -Pn -oA target_nmap target
私はあなたと同じ問題に直面しました。私の場合、IDS/IPSはすべてのポートに対してSYN、ACKを送信するため、nmapはすべてのポートが開いていると判断しました。
ただし、パケットは TCP仕様 に従って確認されない場合は再送信する必要がありますが、IDS/IPSは確認されなかったパケットを再送信しませんでした（TCP SYNスキャン）、.
したがって、wiresharkで再送信されたパケットを確認することで、開いているポートとアクセスできないポートを区別できました。 SYN、ACKが再送信された場合、ポートが開いていたことを意味します。
これに使用できるWiresharkフィルターは次のとおりです。
tcp.analysis.retransmission
ここで多くのことが起こっている可能性があります。
Johnは、snortまたは別のタイプのIDS/IPSがSynスキャンをキャッチする潜在的な落とし穴であると述べました。 -sSを-sTに切り替えて、別のポートをスキャンする前に待機する時間を指定してみてください-sfportscanが有効になっている場合は、時間駆動型です。 （出典：元Sourcefireの従業員）
その他の可能性には、ステートフルインスペクションファイアウォールが含まれます。あなたとスキャンターゲットの間にファイアウォール/ NAT /フィルタリングデバイスがある場合、ファイアウォールがSYN/ACKを返す場合がありますが、実際には実際のターゲットへのポートにアクセスできない場合があります。もう一度、-sTスキャンを試し、一度にスキャンするポートの数を調べます。
-sSや他のスキャンタイプではなく-sTを使用する場合の注意点は、サービスがポートでリッスンしていて、応答が返された場合、ログに記録される可能性が高いことです。この例として、任意のsshデーモンに-sTスキャンをスローし、後で/ var/log/secureを確認します。
過去にnmapでスキャンを急ぎすぎると、奇妙なことが起こりました。-T4は結局「積極的」と定義されています。スキャン速度を3にして、同じ結果が得られるかどうかを確認してください。
また、OSやnmapのバグ、またはある種の相互運用性の問題が発生している可能性もあります。別のシステムがある場合は、それを実行してみて、同じ結果が得られるかどうかを確認してください。
あなたのトラフィックを乱しているいくつかのファイアウォール技術があるかもしれません、あなたが方法で何かを取り除くことができるかどうか見てください。