----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
Hmmm ...
I know that you wanted to reply to you outside of this thread but since you are
simply telling the whole thread that I am saying something that is "simply not
true" ... may be you will believe RSA labs
Please point your browser to
http://www.rsasecurity.com/rsalabs/staff/ajuels/papers/clientpuzzles.pdf
and read about TCP Syn Flooding attacks and how the only way to protect against
them currently is to shut connections to legitimate users of the webserver at
that time as well. Now cutting off legitimate users basically equals losing
clients in my book.
Here is a little snipplet for you from this paper
<snip>
A number of mechanisms have been proposed to defend against the TCP SYN attack.
Most of these are based on one of the three different approaches: time-out,
random dropping, or "syncookies". The time-out approach discards a half opened
TCP connection after a short period of time if the ACK packet from the client
has not been received. While easy to implement in existing TCP servers, this
approach can be defeated by an attacker who sends the SYN packets at a rate fast
enough to fill the connection buffer. Moreover, a short timeout may be
problematic for legitimate users whose network connections have long latency. In
the random dropping approach, half-open connections are discarded at random when
the connection buffer reaches a certain percentage of its capacity. This
prevents a complete Denial of Service attack, since the server buffer is never
completely full. On the other hand, legitimate connections are as likely to be
discarded as those of the attacker, so substantial degradation in service may
result.
....
<snip>
Now SynCookies approach is a bit better but it is still not even w/o holes
specially if the attack is launched from the internal network.
I would be happy to work on taking your checkpoint firewall down, given the IP
address, mailing address, firewall type, internal IP for the webserver, a legal
document absolving me from any responsibility for the damage, a very good amount
of money and a reasonable time frame. Actually me and a few others would be
involved too. Care to throw some money at us.
Thanks
[EMAIL PROTECTED]
Bob Kimble wrote:
> ----------------------------------------------------------------
> BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
> WHEN YOU POST, include all relevant version numbers, log files,
> and configuration files. Don't make us guess your problem!!!
> ----------------------------------------------------------------
>
> <snip>
> Somebody said here that there network admin did not worry about it too much
> because there webserver was behind a firewall and all that. The fact of the
> matter is that it does not matter if your webserver is behind the firewall,
> you
> are still opening some port or some proxy way in so that your users request
> can
> get to the webserver. May be you opened port 80 on the firewall and direct
> all
> traffic coming in to port 80 to the internal (private) IP address of the
> webserver, it is still possible to get the half acknowledged TCP session
> going
> with the server.
> <snip>
>
> This is way off topic for the list, but I believe it's important to note
> that this is simply not accurate. Modern firewalls can prevent exactly this
> situation. They use several techniques to handle this attack. The August
> 2000 issue of PC magazine describes some products and how they work,
> starting on page 68.
>
> In the spirit of trying to avoid flooding this list with off topic messages,
> please respond directly to me at [EMAIL PROTECTED] Thanks.
>
> .... Bob Kimble
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search Archives:
> <http://www.mail-archive.com/java-apache-users%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search Archives:
<http://www.mail-archive.com/java-apache-users%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
