First, a SYN flood defined:
From Denial of service: Fighting back, Network World, 09/02/02.Quote:
A type of denial of service attack in which a large number of TCP SYN packets (the first packet in a TCP/IP connection), usually with spoofed source IP addresses, are sent to a target.
The target system replies with the corresponding ACK packets and waits for the final packet of the TCP/IP three-way handshake. Because the source IP address of the initial packet was spoofed, the target never will receive the final packet, leaving it to hold TCP/IP sessions open until they time out.
A SYN flood causes so many TCP/IP open sessions that the system becomes overwhelmed and cannot handle any more network traffic.
Now that my one obligatory cut-n-paste is out of the way. Let's talk about stopping it.
If you are running Foundry switches, this is a simple one line entry. It can be configured globaly, or on a per-port basis.
That line is:
ip tcp burst-normal xxx burst-max yyy lockup zzz
Where xxx is defined as the 'normal' amount of SYNs you expect to see per second, yyy is the maximum amount of SYN packets (in burst) per second and zzz is defined as the number of seconds that you want to stop receiveing SYN packets on that port for.
So ip tcp burst-normal 100 burst-max 300 lockup 600 tells your switch that if it exceeds 100 SYN packets per second, to drop all excess TCP SYNs If it exceeds 300 SYNs per second, all SYN packets will be dropped on that port for the duration of the lockup value.
Very effective, but potentially very damaging too. If you yourself can't send SYNs through the port, the denial of service attack has been at least partially sucessful.
With Cisco equipment, the tools are a bit more granular, but much more complicated.
First you have to create an extended IP access list. That list syntax is:
access-list access-list-number {deny | permit} tcp any destination destination-wildcard The reason we are filtering on any for the source, is because we don't know who is going to be SYN flooding us.
If you don't understand the syntax of ACL's, there are lots of tutorials on them. The scope of ACL's is beyond the scope of this tutorial here.
After the ACL is created, you have to turn a feature known as tcp intecept on. That is done with this command:
ip tcp intercept list access-list-number
Next we have to set the intercept mode. We have two choices here. The default is intercept, where your cisco device will actually behave like a proxy. It will recieve the SYN, send its' own SYN/ACK, and if it recieves an ACK, will then pass the data on to the protected host or network. The other option is watch mode, where it will allow the SYNs to go to the host or network, but the cisco device 'keeps an eye on' the connection until it becomes fully established. If the connection fails to become established in a certain amount of time (the default is 30 seconds, but can be configured with the ip tcp intercept watch-timeout command) Then the cisco device sends a reset to the host, clearing the embryonic TCP connection.
Now, if your Cisco device thinks there is an attack in progress, it starts to guard a little more zealously. If 1100 partial connections exist, or if the number of partial connections in one minute exceeds 1100, the device will start closing the oldest connections. It will then also reduce the retransmission time-out value to .5 seconds, effectively cutting in half the amount of time that hosts spend trying to communicate with each other.
If you really feel like getting crazy, you can change the mode from 'drop oldest' to 'drop random' connection. This is done with the ip tcp intercept drop-mode random command. And, as you might expect, all the timers et cetera can be tweaked to your specifications with variations of the ip tcp intercept command. I won't go into all of them here because Cisco gives you that lovely ability to type in a question mark at the CLI. Trust me, they're all self-explanatory.
So if you accept the default times, and default (intercept) mode, your configuration would likely look like this:
ip tcp intercept list 121
!
access-list 121 permit tcp any 172.16.1.0 0.0.0.255
Which would cause the intercept feature to be enabled for all TCP servers/hosts on the 172.16.1.0/24 network.
Since some SYN traffic will still be allowed to pass, this is often times a preferable solution to the Foundry method as it should at least give things like critical web servers some ability to communicate while tossing the DDOS packets. That's the hope at least.
