アクセス制御リスト-プロトコルをブロックするのではなくポートをブロックする理由
セキュリティ+試験の勉強をしています。 ACLはポートやプロトコル全体をブロックするように設計できることを学びました。私が読んでいる本は例を述べています：
「HTTPトラフィックをブロックする場合は、ポート80でトラフィックをブロックするルールを作成できます」
これは理にかなっています。通常、HTTPはポート80経由で送信されます。しかし、なぜプロトコル番号でHTTPプロトコルをブロックするのではなく、このようにブロックするのですか？
HTTPのプロトコル番号が見つからないため、一部の情報が不足していると確信しています。
プロトコル番号をブロックするのではなく、ポートをブロックする利点は何ですか？ポート番号をブロックするのではなく、プロトコルをブロックすることの利点は何ですか？
ありがとうございました！
ポートのブロックは安価です。これは、OSIレイヤー4までの検査のみを行うシンプルなステートレスファイアウォールで実行できます。また、最初のパケットですでに実行できます。つまり、TCPハンドシェイクでもデータはまだ転送されていません。
実際に話されているアプリケーションプロトコルによるブロッキングは、ペイロードを分析する必要があります（レイヤー7）。これは、最初に、分析のために十分なペイロードを収集する必要があることを意味します。つまり、TCPハンドシェイクですでにブロックすることはできません。次に、最初のいくつかに基づいて見つけるための信頼できるヒューリスティックが必要です。これはプロトコルの種類です。サーバーが最初にデータを送信するプロトコル（SMTP、IMAP、FTPなど）がいくつかあります。この場合、ファイアウォールはサーバーへの接続を許可する以外に選択肢がありません。プロトコルを分析するための最初のデータ最初に接続を許可すると、望ましくない副作用が生じる可能性があります。
ペイロードがある場合でも、これが実際にどのプロトコルであるかは必ずしも明確ではありません。 TLSを使用するプロトコル（HTTPS、POP3S、IMAPSなど）はいくつかあり、多くの場合、初期のTLS ClientHelloに基づいて、TLS接続内でどのようなプロトコルが話されるかを決定することはできません。
要約すると、これは安くて早く行うことができるので、これが信頼できる限り、ポートでブロックすることが最善でしょう。さらに、実際に話されているプロトコルが許可されている場合、ブロックされていないポートのアプリケーション層を分析できます。
しかし、プロトコル番号でHTTPプロトコルをブロックするのではなく、なぜこの方法でブロックするのでしょうか。
HTTPのプロトコル番号はありません。そして、「プロトコル」には実際には複数の意味があります。レイヤー5..7には「アプリケーションプロトコル」があります。つまり、HTTP、SMTPなどです。そして、レイヤ4に「トランスポートプロトコル」があります。つまり、UDP、TCPなどです。これらのトランスポートプロトコルには、実際にはIPヘッダーで使用される番号があります。つまり、UDPの場合は17、TCPなどの場合は6です。 。しかし、あらゆる種類のTCPまたはUDPをブロックすると、ブロックし過ぎるため、トランスポートプロトコルに基づくブロックはあまり意味がありません。