With existing technology, one option is a load balancing solution. The idea is that you can tolerate a larger number of packets overall, and continue to provide your users with service.
A stateful firewall is another choice, as mentioned earlier in this thread, because you are moving the load of handling the SYN floods out to another device that might be better designed to handle it.
Another option is litigation/legal action towards the ISP whose user(s) is/are perpetrating the attack. This is the only long-term solution, but is ineffective if the floods are coming from tribal flood networks or the like. In those cases, the flooders are unwitting broadband users who themselves aren't running any firewalls or antivirus software, and never patch their OS's. That statement describes about 90% of the market, unfortunately.
More technically, you can try the ICMP quench protocol. Dug Song's dsniff-2.3 toolsuite contains a tool, tcpnice, that sends ICMP source quench packets. Read section 11.11 of Stevens' TCP/IP Illustrated volume 1. Basically, you send a source quench to the router that's feeding the packets, and the source quench includes the IP header of the offending user. Stevens warns of some problems with using it, and that it could cause trouble for the router. In a sense, you are only pushing the problem out. In theory, this is supposed to automatically happen by your TCP/IP stack running out of buffers.
In the future, expect to see active networks have a dramatic result on routing infrastructure, supporting quality of service and reacting to IDIP incidents and taking action. Read more here: http://www.sds.lcs.mit.edu/darpa-activenet/ .
BTW, when you say "bogus SSL negotiations," some security protocols are designed to throw away the chaff early. With IPsec and IKE negotiation modes, a cookie is issued early, and negotiation will not proceed until the proper cookie is presented. The idea is that cookies are computationally easy to produce, and these safeguard the more computationally difficult parts of the negotiation.
According to Stallings, Cryptography and Network Security, a computational DoS condition with the SSL handshake is possible - a client hello can be easily generated/faked, and the work required of the server_hello is to generate a random number, and then possibly generate some prime numbers during the server_key_exchange and sign them. So yes, I can see computational DoS being a problem with SSL.
Russ
From: "Neil Humphreys" <[EMAIL PROTECTED]>
Lee, Yes I am worried about tcp syn attacks, AND bogus "time wasting" ssl negotiations - basically anything malicious that can happen to a "naked" listening socket. I didn't think there would be a satisfactory software solution .. just asked because there are some clever people out there...!!
cheers Neil
----- Original Message ----- From: "Lee Dilkie" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 19, 2003 8:46 PM Subject: RE: OpenSSL denial of service
> Depends on the attack itself?
>
> are you worried about syn flood type attacks, on the tcp port itself?
>
> or are you worried about ssl attacks that go through with ssl negotiation
> and simply strive to consume processing resources?
>
> the former has several solutions, including firewalls.
>
> the later is not as easy to protect yourself against. using honking big
h/w
> accelerators is one solution. I don't know of any s/w solutions.
>
> -lee
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of Neil Humphreys
> > Sent: Tuesday, August 19, 2003 2:24 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: OpenSSL denial of service
> >
> >
> > Shawn,
> >
> > Thanks for the response.
> >
> > It's a lovely thought, but it's not as simple as sticking in
> > a firewall I am
> > afraid .. that leaves
> > me open to attacks that can't be blocked by the firewall ..
> > such as attacks from inside the firewall, or attacks from
> > outside that use
> > the correct port and appear to come from a valid IP address (unless I
> > block tcp connections from the internet zone, which I cannot do).
> >
> > I was just wondering if anyone did anything to reduce the
> > impact of high
> > volume brute force attacks against the listening socket, that
> > cannot be
> > blocked in any trivial way (such as the firewall).
> >
> > I take it the answer's "no" then.
> >
> >
> > ----- Original Message -----
> > From: "Shawn P. Stanley" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, August 18, 2003 9:38 PM
> > Subject: Re: OpenSSL denial of service
> >
> >
> > > I use a firewall, myself.
> > >
> > > On 8/18/03 3:08 PM, "Neil Humphreys" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hi
> > > > Has anyone got any good examples / advice / tricks for
> > reducing the
> > impact of
> > > > denial-of-service attacks on an SSL listening socket?
> > > >
> > > > cheers
> > > > Neil
> > > >
> > >
> > >
> > >
> > ______________________________________________________________________
> > > OpenSSL Project
> http://www.openssl.org
> > User Support Mailing List [EMAIL PROTECTED]
> > Automated List Manager [EMAIL PROTECTED]
>
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
_________________________________________________________________
<b>MSN 8:</b> Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
