A few weeks ago, I logged into Panix (Public Access Internet), my Internet service provider, located a few blocks from my house, and this is the message of the day (MOTD) which welcomed me:
(Posted by Alexis Rosen) Sat, Sep 07 1996 -- 1:23 AM --------------------------------------------------------------------------- Friday evening, starting at around 5:45, all of Panix's main mail hosts were attacked from a site somewhere on the internet. I have been trying to deal with this problem ever since, and the attack is still happening at this time. ... This is probably the most deadly type of denial-of-service attack possible. ---------------------------------------------------------------------------
Panix came down, its three mailservers crumbling under a flood of malevolent IP packets, cresting at 150 per second, and 6,000 users experienced sporadic Internet access. Like a death-ray from outer space, someone was focusing the full might of a new weapon on an unsuspecting and defenseless target. Rosen, on his way out the door that Friday evening, couldn't believe what he was seeing, bemoaning the tenacity of the attack in his MOTD:
"We fully understand how terrible this is. The really scary part is that *no* site on the net is immune. No site can unilaterally do *Anything* to protect or defend itself against this sort of attack."
For a week the attack continued, shifting from one server to the next, and Rosen entered into an arms race with the anonymous attacker. Each time a solution seemed close, a new attack began. The core of Panix's business was at risk -- providing Internet access to its customers. What was going on here? Was this some new, frightening discovery? Had someone found a hidden vulnerability in the Net, one which no one was immune to, or ever would be? This was the logical conclusion. After all, no one had ever seen this kind of attack before, so it must have been new. Nothing could be further from the truth.
The technique, known as SYN Flooding, was documented by 1984, if not earlier, when Bill Cheswick and Steve Bellovin published their book Firewalls and Internet Security: Repelling the Wily Hacker. "We had a paragraph in the book about it, " Cheswick told me from his office at Bell Labs, "which we removed because we knew of no way to fix it. We're sorry about it now. We should have put it in."
When Cheswick heard about the SYN attack, he spoke with Rosen and was invited over. He rushed to Panix to watch the attack first-hand and offer whatever help he could. "I wanted to understand the attack more," he said, "I wanted to see the actual packets. I wanted to see how big they were. What they looked like, where they were coming from." What he saw confirmed his fears -- there was nothing he, or anyone, could do to stop it. Panix was at the mercy of their attacker.
if(!dport){
tsunami++; /* GOD save them... */
fprintf(stderr,"\nTSUNAMI!\n");
fprintf(stderr,"\nflooding port:");
}
/* Setup the sin struct with addressing information */
sin.sin_family=AF_INET; /* Internet address family */
sin.sin_port=sport; /* Source port */
sin.sin_addr.s_addr=dadd; /* Dest. address */
"This attack," daemon9 explains from his office somewhere in Northern California, "takes advantage of TCP by creating an unreachable IP address. So you send a connection request from an unreachable address and the server tries for 75 seconds to complete it. If you fill it up with 10, 15, 20 phony requests within 75 seconds it will eventually get flooded and crash." Daemon9 is one of three editors at Phrack Magazine, a so-called hacker magazine, and the latest issue, number 48, hit the Net on September 1st containing a detailed white paper by daemon9, along with "fully functional robust Linux sourcecode" exhuming the intricacies of SYN Flooding. Simultaneously, 2600, another hacker magazine published a piece on SYN Flooding. A week later the Panix attack began.
The attack inspired CERT to publish an advisory on the SYN attack. I asked a CERT spokesman if the advisory was referring to Phrack and 2600 when it stated "two 'underground magazines' have recently published code to conduct denial-of-service attacks," and he demurely refused to confirm this. Still, I pointed out, there appears to be a correlation between publication and attack. Grudgingly he agreed that there was a "correlation." "We've seen 15 SYN attacks in the last couple of weeks," he said. "I think that number is higher in the last 48 hours. It could be 18." SYN incidents reported to CERT used to be next to zero. Daemon9 found this lack of credit insulting, when I told him CERT refused to acknowledge his work by name. "There has never been a SYN flood advisory posted before," he said, "Of course this issue led to this. It would be ridiculous to allude otherwise."
(Posted by Alexis Rosen) Sun, Sep 08 1996 -- 6:58 AM --------------------------------------------------------------------------- Late Saturday evening, my temporary low-grade routing hack to protect our mail service was overcome and our mail servers were again inoperable due to the "SYN flood" attack.
The SYN Flood is particularly dastardly because it takes advantage of fundamental Internet architecture, which is built on two essential ingredients: trust and packets. When a client sends a request to a server on the Internet -- it could be Telnet, Web, FTP -- the client first sends a SYN message to the destination server, asking to open a connection between the two machines. The server then sends back a SYN-ACK message to acknowledge receipt of the request. It then waits 75 seconds for the client to acknowledge the SYN-ACK packet. Once acknowledgment is received the two computers start exchanging information. The SYN Flood exploits this protocol by not sending final confirmation of SYN-ACK, instead it sends more SYN messages to open a connection, which stack up in the server's memory until it runs out of memory and crashes, or gets so tied up that it can no longer accept other incoming connections. Either way, the result is denial of service. The victim is "flooded" into silence.
There is no easy way to trace the originating attack source because the SYN packets often contain "implausible," as CERT puts it, originating address information. This reflects the nature of the Internet's "store and forward" system, where packets are temporarily "stored" on computers then "forwarded" closer to their eventual destination. Retracing a packet's path was never an Internet priority because the network is based on trust. There was no reason, way back when, to build in a traceable system. People just trusted that nobody would do such naughty things as flood servers with bogus SYN packets. The solution then would seem to build tracing capabilities into future version of TCP/IP. That, as Cheswick explains, won't necessarily work either.
The server would still have to check where the incoming packet came from. If enough packets come in with invalid addresses, the time needed to check them could still shut down the system "Imagine that everything is encrypted and I need to validate incoming packets. I can still swamp the CPU doing the validation. It's harder. But it's possible," Cheswick says. "It becomes an arms race." He then gets a more elegant idea. "Or forget the CPU," he says, "just flood the T-1 link with garbage packets. Flooding is the final Internet problem. After we solve everything else, that will still be there. You can mitigate it, but you cannot make it go away."
(Posted by Alexis Rosen) Mon, Sep 09 1996 -- 11:43 AM --------------------------------------------------------------------------- We are now being attacked on our telnet ports. This means that people can't reach panix1, panix2, or panix3 from the internet. Our router is also being attacked. Our web server's web port is being attacked too.
Phrack and 2600 opened the Genie's bottle. It's a wonder that SYN Flooding didn't happen sooner. Now that it has, and no definitive solution is in sight, Cheswick and security experts like James Settle expect SYN Flooding to move from the hands of hackers looking to claim experience points into the realm of retribution (employees getting back at corporations), competition (shutting a competitor down with a flood), exploitation (blackmailing someone to keep you at bay), and simple information warfare (hostile groups -- national or otherwise -- flooding the Net-based sectors of another group or nation).
Settle, who spent 26 years with the FBI and in 1992 led the newly formed FBI Computer Crime Squad is now in private practice, leading teams of hackers hired to break into his client's computers, which they probe for vulnerabilities. "Generally," he explains, "the intruder community did not have an interest in causing [flooding] problems. In 1993 we saw a shift to the next thing which was breaking in to steal or make money. Now we are entering the next phase, which is shutting down networks. The big problem is that anyone can do this, from anywhere. How do we enforce this on a global network," Settle asks, "The answer is we cannot."
SYN Flooding is like real-life crime. There is no technology-based solution. Where data privacy can be solved by pure technology using encryption, making online data secure from theft, with close to 100% confidence, flooding is a social issue. As in offline life, someone could flood your phone with 500 bogus calls an hour, effectively shutting down your ability to get or make calls. SYN Flooding isn't too different from that. The attack on Panix marks a turning point for the Net, the moment where dormant fears, long known and kept quiet, crossed from fantasy to reality.
Daemon9 regrets that Panix got flooded. "I am sorry for Panix," he says, "I never intended for that to happen." So what's next for daemon9? "This was my first semi-official issue," he says, "People will look for something big in the next one, and to tell you the truth I am working on something similar."
(Posted by Alexis Rosen) Fri, Sep 13 1996 -- 5:12 PM --------------------------------------------------------------------------- I'd like to clarify some statements recently quoted in the press. We've been getting a lot of calls about this and I want to set people's minds at ease... to the extent possible. I said that it was possible that we could be forced out of business IF the attacks continued unabated since their inception. They did not, AND we have developed somewhat effective countermeasures. We are confident that we will survive this attack, but it will cost us dearly. And who is to say that there won't be another? That's why we have to have cooperation among all the service providers, to make these attacks impossible at the source.
MEME and its contents copyright by David S. Bennahum. Duplication for non-commerical use is permitted. Contact me if you have questions. Direct comments, bugs and so on to me at davidsol@panix.com.
