We got hit again tonight. This time on seven different machines- three mail hosts, two news machines, our web site, and VTW's web site (we provide all service for VTW). I am simply amazed that anyone would attack VTW. Even the shmuck who's attacking us benefits from VTW's work. Why would anyone attack them? Anyway. Point is this: We can't take too much more of this, nor can our customers. I have yet to hear *anyone* come up with any ideas even remotely reasonable for how to deal with this situation, long term, except for the filtering that Avi, Perry, and I have been promoting these last few days. Whether or not existing equipment can handle the job is *IRRELEVANT*. If it won't, new equipment must be bought. The net won't survive without it. (And yes, I've been hearing "death of the net" predictions for longer than most readers of this list have been on the net. This could really be it.) /a
I must say that I agree about the SYN floods being a huge problem. A lot of our customers are getting "attacked" as well as possibly some of our machines. While I despise the "death of the net" phrase, I agree something must be done. But a few filters in a few core routers in a few small ISPs will have a null effect on the situation. Until this problem becomes gigantic enough that it affects large networks such as MCI, Sprint, UUNet, etc. I don't predict much will be done. So I presume the best we can hope for is that.. and this may sound a bit nasty.. that the bigger networks start getting attacked. That is the only way there will be a call to arms. Rob Exodus Communications Inc.
We got hit again tonight. This time on seven different machines- three mail hosts, two news machines, our web site, and VTW's web site (we provide all service for VTW).
I am simply amazed that anyone would attack VTW. Even the shmuck who's attacking us benefits from VTW's work. Why would anyone attack them?
Anyway. Point is this: We can't take too much more of this, nor can our customers. I have yet to hear *anyone* come up with any ideas even remotely reasonable for how to deal with this situation, long term, except for the filtering that Avi, Perry, and I have been promoting these last few days.
Whether or not existing equipment can handle the job is *IRRELEVANT*. If it won't, new equipment must be bought. The net won't survive without it.
(And yes, I've been hearing "death of the net" predictions for longer than most readers of this list have been on the net. This could really be it.)
/a
I don't know, but since nobody else seems to either, how about a router box that detects excessive SYN activity and then automatically blocks that ip address for awhile? I suppose it just means that the attacker has to vary the source address rapidly.
Anyway. Point is this: We can't take too much more of this, nor can our customers. I have yet to hear *anyone* come up with any ideas even remotely reasonable for how to deal with this situation, long term, except for the
I don't know, but since nobody else seems to either, how about a router box that detects excessive SYN activity and then automatically blocks that ip address for awhile? I suppose it just means that the attacker has to vary the source address rapidly.
Anyway. Point is this: We can't take too much more of this, nor can our customers. I have yet to hear *anyone* come up with any ideas even remotely reasonable for how to deal with this situation, long term, except for the
If they modulate the phasers we just need to modulate the sheilds. :-O If someone comes up with a good solution we will be glad to impliment it. -- /*Joseph T. Klein * Keep Cool, but Don't Freeze * NAP.NET, LLC * * phone +1 414 747-8747 * - Hellman's Mayonnaise * http://www.nap.net */
I don't know, but since nobody else seems to either, how about a router box that detects excessive SYN activity and then automatically blocks that ip address for awhile? I suppose it just means that the attacker has to vary the source address rapidly.
If they modulate the phasers we just need to modulate the sheilds. :-O
If someone comes up with a good solution we will be glad to impliment it. -- /*Joseph T. Klein * Keep Cool, but Don't Freeze * NAP.NET, LLC * * phone +1 414 747-8747 * - Hellman's Mayonnaise * http://www.nap.net */
Well, it's a good analogy (modulating the phasers). But they're *randomizing* the phasers... Avi
BTW. Some time ago (when we used PC based routers and had all sources) we discussed the same problem. One of the best solutions to prevent many kinds of hacker's weapons is to allow customer send packets with SRC address ONLY if this (SRC) address have routing via the same interface. This control is possible only for one-homed customer but is effective enougph to prevent TCP spoofing, many SYN, PING, UDP etc attacks and does allow ISP to determine the source of any internet attack.
reasonable for how to deal with this situation, long term, except for the
If they modulate the phasers we just need to modulate the sheilds. :-O But they always modulate phasers _BEFORE_ you modulate shields -:)
--- Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
If you can write a SYN flooder you can trivialy add the call to to generate a random source address.... IMHO this is not a win. Larry Plato
I don't know, but since nobody else seems to either, how about a router box that detects excessive SYN activity and then automatically blocks that ip address for awhile? I suppose it just means that the attacker has to vary the source address rapidly.
Anyway. Point is this: We can't take too much more of this, nor can our customers. I have yet to hear *anyone* come up with any ideas even remotely reasonable for how to deal with this situation, long term, except for the
On Wed, 11 Sep 1996, Alexis Rosen wrote:
Anyway. Point is this: We can't take too much more of this, nor can our customers. I have yet to hear *anyone* come up with any ideas even remotely reasonable for how to deal with this situation, long term, except for the filtering that Avi, Perry, and I have been promoting these last few days.
Whether or not existing equipment can handle the job is *IRRELEVANT*. If it won't, new equipment must be bought. The net won't survive without it.
Did you ever track down the source of the attacks? If not, why not? Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
On Wed, 11 Sep 1996, Alexis Rosen wrote:
Anyway. Point is this: We can't take too much more of this, nor can our customers. I have yet to hear *anyone* come up with any ideas even remotely reasonable for how to deal with this situation, long term, except for the filtering that Avi, Perry, and I have been promoting these last few days.
Whether or not existing equipment can handle the job is *IRRELEVANT*. If it won't, new equipment must be bought. The net won't survive without it.
Did you ever track down the source of the attacks? If not, why not?
Michael Dillon - ISP & Internet Consulting
Without saying too much, I think I can say tat the attacks did go on for hours a few times, but stopped before too much tracing could be done. Initially I thought Panix was being attacked by a random attacker; Voicenet in Philadelphia was attacked for almost a day on their mail ports, and another provider in Philly was attacked for 4-6 hours on news ports (pretty ineffective). But Panix has been attacked a few times now. I've actually got a kernel built for sun4c that is pretty good/resistant, but only to the attacks I can *think of*. I and panix are trying to get it working on sun4m. Bottom line, it would be good if everyone who could would filter incoming on customers or outgoing on borders. While you're at it, if your network is relatively simple (compared to, say, MCI's or UUNET's or Sprint's), you might want to filter incoming on borders at exchange points to prevent others from using you for transit. Avi
Anyway. Point is this: We can't take too much more of this, nor can our customers. I have yet to hear *anyone* come up with any ideas even remotely reasonable for how to deal with this situation, long term, except for the filtering that Avi, Perry, and I have been promoting these last few days.
If hardening all hosts against forged source address SYN attacks is not feasible then perhaps providing a hardened device in front of server farms is. How about something that spoofs the TCP connection setup, uses minimal resources for unconfirmed TCP connections and perhaps more aggressively times out these connections when under attack. Basically this firewall would not forward a SYN packet to a server from an unknown host until that host had properly ACKd a SYN ACK from the firewall. The resulting connection would require that the firewall adjust seq/ack numbers before forwarding the packets between the host and server as the pseudo random seq number used in the initial SYN ACK from the firewall to the host will be different from that proposed eventually by the server. And it makes sequence guessing attacks much harder as well. An idea? -Steve
Anyway. Point is this: We can't take too much more of this, nor can our customers. I have yet to hear *anyone* come up with any ideas even remotely reasonable for how to deal with this situation, long term, except for the filtering that Avi, Perry, and I have been promoting these last few days.
If hardening all hosts against forged source address SYN attacks is not feasible then perhaps providing a hardened device in front of server farms is. How about something that spoofs the TCP connection setup, uses minimal resources for unconfirmed TCP connections and perhaps more aggressively times out these connections when under attack. Basically this firewall would not forward a SYN packet to a server from an unknown host until that host had properly ACKd a SYN ACK from the firewall. The resulting connection would require that the firewall adjust seq/ack numbers before forwarding the packets between the host and server as the pseudo random seq number used in the initial SYN ACK from the firewall to the host will be different from that proposed eventually by the server. And it makes sequence guessing attacks much harder as well.
An idea?
I've been focusing on routing for the last year and not kernel hacking, but a better data structure (methinks for the whole kernel) for pending embryonic connections is required. Hacking algorithms is easy; kernel data structures hacking requires me to find my design & imp of the BSD os book.
-Steve
Avi
participants (9)
-
alex＠relcom.EU.net -
Alexis Rosen -
Avi Freedman -
jon＠branch.com -
Joseph T. Klein -
Larry J. Plato -
Michael Dillon -
Robert Bowman -
Steven L. Johnson