WebアプリケーションファイアウォールはOSIレイヤー7のみを保護しますか？
アプリケーションレイヤー7を保護しているWebアプリケーションファイアウォール（WAF）は、 The Open Systems Interconnection（OSI）モデル の他のレイヤーも保護していますか？
アーキテクチャ上の必要性のため、Webアプリケーションファイアウォール（WAF）は他のレイヤーでの攻撃からも保護します。ただし、これらの保護は主に付随的なものであり、包括的ではありません。これをいくつかの例で説明しましょう：
プレゼンテーションレイヤー-保護対象のアプリケーションがTLSを使用するとします。その場合、WAFデバイスは、アプリケーションデータを復号化してアプリケーションファイアウォールロジックを適用するために、定義上、クライアントTLS接続を終了する必要があります*。
これが実際に意味することは、潜在的な攻撃者がターゲット（アプリケーション）ホストのTLSスタックと相互作用することは決してないということです。そして、バックエンドは任意の数のアプリケーションフレームワークのいずれかを実行している可能性がありますが、そのすべてに独自の癖のある独自のTLS実装がありますが、WAFは通常、TLSが適切であることを理解する人によって構築および販売されます。 （私の経験では、F5は必要に応じてTLSを更新するのにかなり優れています）。
したがって、WAFは実際には（セールスブレットとしてではなくても）プレゼンテーションレイヤーで保護を提供します。
Session Layer-WAFは多くの場合、セッションエンドポイントデータを使用してゲームをプレイしている人々を検出および防止するために、独自のトラッキングCookieを挿入します。これは、WAFがバックエンドで[任意の]アプリケーションを保護する必要があるためですが、[[ランダム（任意）]アプリケーションの場合、妥当なセッション保護なしで作成されたと想定している」という事実をうまく補完します。
トランスポート層-TLSと同様に、TCPはWAFで終了するため、アプリケーションサーバーがクライアントと直接対話することを免除されます。手動で調整されたパケットへの微調整は、重複するフラグメント、状態違反ゲームは、アプリケーションサーバーではなくWAFに違反します。WAFはそれらをより適切に処理できますか？言うのは難しいですが、攻撃者は依然として目標を達成できません。
ネットワークレイヤー-ここでも、アプリケーションサーバーへの接続を終了して新しい接続を開くことにより、WAFはアプリケーションサーバーをIPレイヤー攻撃から隔離します...たとえば、外部（クライアント）内部（サーバー）3WHSを開始する前に3ウェイハンドシェイク（3WHS）が完了しているため、シンフラッドが軽減されます。
これらの保護は一般に付随的であり、設計されていません。 WAFメーカーは、CheckPointなどのステートフルインスペクション機能をWAFに組み込んでいません。彼らは、内部接続を開く前に、有効なステートフル外部接続を待つだけです。 WAFは、アプリケーションサーバーと同じようにOpenSSL TLSスタックを使用する可能性があり、どちらも同じ問題に対して脆弱です...しかし、WAFは、攻撃者が取得したいアプリケーションの有用なデータから削除された1つのステップです。 。
*ここで使用している定義は、「現代のTLSは、トラフィックを復号化するパッシブリスナーの機能を削除する一時的なキー暗号を好むので、今日のTLSを使用するものはすべて、復号化するために終了する必要があると想定します。」