The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
How does the Layer 4 Traffic Monitor block traffic if it is only receiving mirrored traffic?
The Cisco Web Security Appliance (WSA) has a built-in Layer 4 Traffic Monitor (L4TM) service that can block suspicious sessions across all network ports (TCP/UDP 0-65535).
To be able to monitor or block these sessions traffic must be redirected to the WSA, either by using a TAP (Test Access Port) device, or by configuring a mirror port on network devices (SPAN ports on Cisco devices). L4TM in-line mode is not supported yet.
Even though traffic is only mirrored (copied) from the original sessions to the appliance, the WSA can still block suspicious traffic by either resting a TCP session or sending ICMP "host unreachable" messages for UDP sessions.
For TCP sessions
When the WSA L4TM receives a packet to or from a server and the traffic matches a Block Action, L4TM will send a TCP RST (reset) datagram to the client or server depending on the scenario. A TCP RST datagram is just a regular packet with the TCP RST flag set to 1.
The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user and goes to the CLOSED state.
There are two cases to consider (in both cases users/clients are behind a firewall):
First one is when the suspicious packet is coming from outside the firewall towards a client in the internal network. The RST will be sent to the server and in this case it will get to the firewall which will usually not forward the RST but it will terminate the session as it will believe the RST actually came from the client. In this case the source IP of the RST will be the spoofed IP of the client. The client will terminate the session.
A second case would be when the packet is coming from the client in the internal network and is going to an external server (outside the firewall). The RST is then sent to the Client and the RST source IP will be the server's spoofed IP.
For UDP sessions
A similar behavior is performed by WSA when the suspicious traffic is from a UDP session, but instead of sending TCP RST , the L4TM will send ICMP host unreachable messages (ICMP type 3 code 1) to either the client or the server. However , there's not IP spoofing in these cases as the ICMP message states that the host is unreachable so it can not be sending packets. Source IP in this case will be WSA's IP.
These RSTs and ICMP packets are sent from the WSA using the data routing table, via either M1, P1, or P2, depending on the deployment.