Wrt- SYN Flooding I'm going to try to consolidate some of these threads. There have been three areas in which defense of SYN flooding has been suggested (maybe more, three that will help): 1. Make the host less susseptible 2. Filter based on source address on inbound packets from singly homed sites. 3. Improve the ability to trace such attacks back to source I'll argue that all three of these are needed since none of them alone can completely solve the problem. Here are some details recapping discussions on the list (sorry for not giving credit, lots of people contributed ideas). 1. Make the host less susseptible [teach engineers to spell?] Specific code fragments were given for BSD and Solaris. BSDI is already in very good shape with recent kernel patch (that preceeded the attacks and was intended to improve HTTP server performance). The comment was made "what about NT". My answer is let Microsoft field that question. At issue is whether a stream of TCP SYNs can swamp a host TCP implementation. This is a denial of service exposure that has gone unaddressed in host implementations until recently. BSD now uses a hash table on the TCP PCBs (protocol control blocks in the kernel) and with change of removal of the check can support close to 64K-2000 PCBs (until TCP port numbers are exhausted). At a 75 second hold time, this is well under 1kpps (rapid reuse of port numbers has other problems). Some advantage is gained by the fact that SYN ACKs will be sent and legitimate hosts will respond with RST, clearing the port number for reuse. There was also a suggestion of a server to prescreen TCP SYNs. I don't think that is needed. With the host changes, hosts are not invincible but it requires nearly 1 kpps sustained to do damage. Reducing the hold time below 75 seconds (which is on the long side), makes the traffic rates required for a denial of service even higher. What this does is forces the attacker to use relatively long, high pps bursts, which are much more easily traced if providers are prepared to do the tracing (see 3.). 2. Filter based on source address on inbound packets from singly homed sites. A singly homed site cannot have assymetric routing since there is no ohter path. All that is needed is for the router to look up the source address in the forwarding table and if the route does not point to the interface the packet came in on, dispose of the packet. This would mean that even a singly homed university could not become the source of SYN attacks unless the hacker was willing to use source addresses in the range of the addresses of the university. This would make tracing back to the source very easy. 3. Improve the ability to trace such attacks back to source Here is where either router vendors have to take action or providers need to put Unix hosts on their FDDI rings and ethernets to do gather data. The NSS routers did statistical sampling based on a sampling of one in 50 packet headers. If a hacker must send upwards of 60,000 packets for an attack to be effective, even a sampling of 1 in 1,000 would be effective. The NSS was unique as routers go in that a general purpose computer was part of the package. The specialized code in the forwarding path sampled 1 in 50 headers and packed them into a large packet, which when full was sent to the Unix kernel. This reduced the rate of sampling packets to the kernel to a rate that could be easily handled (we could do 1 to 1 sampling in bursts with heavy load on the CPU, 1 in 50 continuous with very little load). What we have suggested to our router vendors is the following: in the forwarding path allow an option to take 1 in N packets (where N could be anything but is expected to be in the range of 50-1000) and pack the first H bytes of the packet plus timestamp into a buffer. Send the buffer out a designated interface when the buffer reaches a configured size (usually the MTU of the interface) to some configured addess. The normal use of this would be to send packets out a dedicated ethernet interface to a network management machine within the POP, though the same information could also be sent remotely if it was being used to monitor attacks. The advantage of a network management machine (which we happen to already have for other purposes like SNMP proxy agents for things that don't do SNMP and secure access for things that don't have a means of secure access), is that it has a disk and can quite easily store hours of samples. If an incident is reported and the end site has a traffic archive with address and port number pairs, a snapshot of the prior few hours is taken and the source is identified. If all major providers did this, a SYN attack reported within a few hours would be traceable. ---> Michael Dillon writes:

Now here is something that could be used by sites to protect against SYN flood attacke assuming that they can build a special custom box with enough RAM to buffer the sockets for 30 seconds or more. How high a rate can SYN floods come in at? I've heard of 1,000 per sec which implies that this box needs to hold open 30,000 to 75,000 potential sockets. Is there any problem within IPv4 (seq #'s?) that would make this inherently impossible?

Yep. Increasing the number of packets required for an effective attack makes it more difficult to launch an attack that is not easily traced. ---> Roderick Murchison, Jr. writes:

Ok. say you have a firewall between your network and you Internet connection. If that firewall could detect and *detain* a segment with the SYN option set, then see if the set source IP answers an ICMP echo request, we could effectively determine whether or not the SYN could be dropped at the firewall and not sent through to spam our hosts. If the source responds, release the SYN and let it pass through to the intended host. If it does not, trash the SYN and log the failure.

ICMP is a bad choice (already pointed out on the list). I don't think this is needed if the host implementations are fixed. It would be quite easy to send 60,000 different source addresses, which would make your solution worsen the problem. Better to just have the host send the SYN ACK, let it either blacxkhole (no such destination) or return a RST (a real host was found). ---> Dima Volodin writes:

Apart from the obvious sexism :-) of the message let me point out that there are some other tricks one can play with DNS, e.g. throwing in any addresses for some other's servers in additional records in your DNS reponces. We are hit by this DNS/named deficiency _every freaking day_.

You need to update to a newer version of BIND. This has been fixed. ---> Jim Forster writes:

...

Again, the rule is "dont accept packets from an interface if there's no route for their source addresses pointing back to the same interface". Note that that route does not have to be the best one -- just that the router gets it from somewhere.

Without discussing it with the right folks here ahead of time, I suspect we could do this at good speed in some, but not all routers, in our product line. The solution I have in mind would not be suitable for some places in the net. We'd put the extra checks in the slow path which Curtis hates so much, and then use our 'flow-switching' cache, which is keyed by src/dest adresses & ports. So packets which fail the source address scrutiny in the slow path aren't put in the flow-switching cache. I can't recall if we cache negatives there, but in any event apparently the attacks involve SYN flows on the order of 100's of PPS, which might go through the slow path OK. BTW, I believe the criterion Vadim suggest is similar to that used in RPF Multicast flooding.

Now the big question: is this useful in routers carrying a default route?

I have to highly commend Jim and Cisco for their quick response and willingness to help address the problem. I must say that this is a typical very helpful response from Cisco. What I am asking for ("we" if there is agreement) is the following. 1. Create an option to look up the source address in the forwarding table. If the forwarding entry for the source address does not point to the interface from which the packet came, drop the packet. Enable this by default. Allow it to be shut off on a per interface basis. This is most important on end system routers so if it cannot be made to run on some routers with hardware assist without overly impacting the forwarding path speed, then that's OK. 2. Create an option to pack 1 in N packet into ... (what I have written above as #3). It would be real handy if this could be done on all routers, including those with hardware assist. This would mean that any Cisco based ISP could very easily trace the source of SYN attack to their own border and there would be no excuse not to. [We've also asked for this feature for a number of other reasons having to do with network capacity planning and statistical studies.] Best Regards to all that are contributing to solving this problem, Curtis