|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: SYN floods - possible solution? (fwd)
With source, and reasonable knowledge of the kernel, this would be easy
enough to do on any unix. Avi's already explained what needs to be done,
and you don't need a special box.
But to protect other machines, you'd have to put a filter machine in front
of them. This sounds like a workable solution to me, for those who can cope
with the technical or financial demands (which *might* not be so high).
There's no protocol issue to prevent this. You can tag held SYNs any way
you like; you're not limited to using parts of the packet. But even if
you did, it would still be fine.
If your attacker were on a T1, and *if* his router and your can handle the
packet-forwarding load, you could see perhaps 4000 pps theoretical max.
In real life I'd be surprised to see half that many, and that would be a
*real* flood. 30sec. timeout means 60k slots in a hash table of SYNs, each
taking up 12 bytes for the data. Your total memory used is maybe 1MB if you
figure the hash just right. You might also do better if you used a tree
keyed on the source IP. For free, you can protect any number of hosts, not
just one.
But... I still don't believe that this is a good global solution. Most ISPs
can't cope with this. The clue level I've been seeing among many of the
ISP "engineers" and "systems administrators" who have called in the last
few days to ask for help ("is your problem happening to me too???") is
astonishingly low. :-(
I also have no clue what I'd choose to implement this on. It *could* be
done in a unix kernel but that's probably a really *bad* choice. I'm sure
plenty of people out there know some good possibilities, though.
/a
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?
>
> Michael Dillon - ISP & Internet Consulting
> Memra Software Inc. - Fax: +1-604-546-3049
> http://www.memra.com - E-mail: [email protected]
>
> ---------- Forwarded message ----------
> Date: Fri, 13 Sep 1996 01:36:54 -0400 (EDT)
> From: "Roderick Murchison, Jr." <[email protected]>
> To: firewall-[email protected]
> Cc: [email protected]
> Subject: Re: SYN floods - possible solution?
>
> On Thu, 12 Sep 1996, Blast wrote:
> > This problem has kept me awake more than coffee. :-)
>
> Ditto... I just woke up *again* with a kludgy but potential defense...
> sorry if this is totally out of whack, but I'm really beat!
>
> 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.
>
> Some moderate tracking and aging methods could be employed to
> intelligently quick drop sources we know are recently offline, and lessen
> the amount of echo requests we send out.
>
> Could this be a potential defense? If so, what products would be best
> suited to implement this?
>
> hope this helps,
> -r
>
> Roderick Murchison, Jr. [email protected]
> Newbridge Networks, Inc. office: (703) 708-5930
> Product Manager - VIVID ACS fax: (703) 708-5937
> Herndon, VA 22070-5241 http://www.vivid.newbridge.com
>
>
>
>
- - - - - - - - - - - - - - - - -
|