from what I read in the IOS Security Configuration Guide, I understand the general concept of TCP interception, however I still don't get the complete picture:
Assume a machine being under DDoS Attack by SYN-Flooding, so TCP Intercept starts to answer to the spoofed SYN-requests. Since this uses cpu and memory on the firewall, the DDoS is now against the firewall instead of the server.
The CG states that there is a limit of 1100 connections, after that the oldest embryonic connection gets dropped (which is tunable, both number and mode).
Doesn't this mean that a proper TCP-SYN-request (which is still embryonic) may be dropped due to a large number of bogus SYN-requests ? Even when drop mode is set to random ?
1100 embryonic connections (default value) seems to be a number of embryonic connections that can be reached under real-life conditions - or am I wrong here ?
Firstly you are correct in saying that TCP intercept effectively moves the DDoS attack from the server to the firewall. However this is a good thing because the firewall is better placed to deal with the embryonic conections. A server will consume large amounts of resources dealing with this and won't release them quickly, locking up your server.
All ligitimate connections will only stay in an embryonic state for a very short time (3 packet exchange) and so under normal circumstances you will never get anywhere near 1100 conections.
By the same rational when the firewall reaches the 1100 limit and starts agging out the oldest connections these are likely to be the DDoS connections as they are never completed. ligitimate connections will have been setup and completed (hopefully).
I agree that it is a good idea to redirect a DDos to a firewall, since then the attack may block one path to the server, but it stays responsive to connections from an internal network or different IP ont the same machine.
However, I wonder what happens when you have for example a T1 connection between two offices and use that for your WAN connection too. An the ASA protecting your DMZ gets bombed by DDoS.
The DDos will eat up bandwidth, so legitimate traffic will get some negative impact. I wonder if this has sideeffects on the speed of the TCP 3-way handshake and what the best countermeasure would be. QoS comes to mind.
Regarding the ASA, how does it handle the embryonic connections ? I assume they are NOT put into any sort of state table to preserve memory and cpu. But is there a danger of DDoSing an ASA if you reach the 1100 embryonic connections limit ?
I wonder how much memory is used by 1. a state table entry or 2. an embryonic connection entry. This would allow to calculate maximum values based on the underlying hardware. Any idea where I can find these numbers ?
Thanks in advance and yes, you already helped me :)
"Regarding the ASA, how does it handle the embryonic connections ? I assume they are NOT put into any sort of state table to preserve memory and cpu. But is there a danger of DDoSing an ASA if you reach the 1100 embryonic connections limit ?"
No, with the TCP Intercept feature, as soon as the optional embryonic connection limit is reached, and until the embryonic connection count falls below this threshold, every SYN bound for the affected server is intercepted. For each SYN, a PIX firewall responds on behalf of the server with an empty SYN/ACK segment. The firewall retains pertinent state informatiion. drops the packet, and waits for the client's acknowledgment. If the ACK is recieved, a copy of the client's SYN segment is sent to the server, and a TCP three-way handshake completes and the connection resumes as normal. If the client does not respond during any part of the connection phase, the firewall retransmits the necessary segment.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...