ポートスキャン時にポート20と53をソースポートとして使用する方が良いのはなぜですか？
サーバーがDMZステートレスファイアウォールの内側にある場合、ポートスキャンを実行するときにポート20と53をソースポートとして使用することをお勧めします。なぜこれが良いアイデアなのですか？ファイアウォールはFTPおよびDNSデータをフィルタリングしない可能性が高いと思いますか？
あなたは正しく推測しました。
the Nmap Reference Guide によると：
--source-port <portnumber>; -g <portnumber>（なりすまし元ポート番号）驚くべき一般的な誤設定の1つは、送信元ポート番号のみに基づいてトラフィックを信頼することです。これがどのように行われるかを理解するのは簡単です。管理者は光沢のある新しいファイアウォールをセットアップしますが、アプリケーションが機能しなくなった恩知らずのユーザーからの苦情でいっぱいになります。特に、外部サーバーからのUDP DNS応答がネットワークに入力できなくなるため、DNSが壊れる可能性があります。 FTPも一般的な例です。アクティブなFTP転送では、リモートサーバーはクライアントへの接続を確立して、要求されたファイルを転送しようとします。
これらの問題に対する安全なソリューションは、多くの場合、アプリケーションレベルのプロキシまたはプロトコル解析ファイアウォールモジュールの形で存在します。残念ながら、より簡単で安全でない解決策もあります。 DNS応答がポート53から、アクティブFTPがポート20から送信されることに注意してください。多くの管理者は、これらのポートからの着信トラフィックを単に許可するという罠に陥っています。多くの場合、攻撃者はそのようなファイアウォールの穴に気づいて悪用することはないと想定しています。他の場合では、管理者は、より安全なソリューションを実装できるようになるまで、これを短期的な一時的措置と見なします。その後、セキュリティのアップグレードを忘れます。
この罠に陥るのは、働き過ぎのネットワーク管理者だけではありません。多数の製品がこれらの安全でないルールを備えて出荷されています。マイクロソフトでさえ罪を犯している。 Windows 2000およびWindowsに付属のIPsecフィルターXPには、すべてのTCPまたはポート88（Kerberos）からのUDPトラフィック）を許可する暗黙のルールが含まれています。） -既知のケースでは、2.1.25までのバージョンのゾーンアラームパーソナルファイアウォールで、ソースポート53（DNS）または67（DHCP）を使用した着信UDPパケットが許可されていました。
Seclists.orgの2005年の回答 は、以前のバージョンのリファレンスガイドからの引用を提供します。
--source_port <portnumber>スキャンで使用される送信元ポート番号を設定します。 多くの単純なファイアウォールとパケットフィルターのインストールでは、ルールセットで例外が発生し、DNS（53）またはFTP-DATA（20）パケットが通過して接続を確立できるようになります。侵入者はソースポートを変更することでFTPまたはDNSになりすますことができるため、ファイアウォールのセキュリティ上の利点を完全に覆します。明らかに、UDPスキャンの場合、最初に53を試行し、TCPスキャンは53の前に20を試行する必要があります。これは単なる要求であることに注意してください。nmapは、可能な場合にのみそれを受け入れます。たとえば、TCP ISNで1つのホスト：ポートから1つのホスト：ポートにすべてをサンプリングすることはできないため、このオプションを使用した場合でも、nmapはソースポートを変更します。これは、短いが覚えにくい
-gオプション。