[11226] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Simple DOS attack on FW-1

daemon@ATHENA.MIT.EDU (James Burns)
Tue Aug 3 02:29:50 1999

Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id:  <00e401bedbbb$2156da60$a2f1dad1@ipivot.com>
Date:         Sat, 31 Jul 1999 18:13:55 -0700
Reply-To: James Burns <jburns@IPIVOT.COM>
From: James Burns <jburns@IPIVOT.COM>
X-To:         bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM

 > Sure this is the case if you have a rule set that has something like.
Let
> in a packet that is bound to some address range.
> If I have a rule set that is host based, allowing only a few specific IP
> address's in the DoS attack is limited?
>
> Increasing the size of the connections allowed in the table may only
reduce
> the possibility of the attack.  Why not increase the number such that it
is
> greater than what your bandwidth can handle (advocated by firewall people
> here).
>
> r1ccard0
>
> Richard Scott
> (I.S.) E-Commerce Team
> * Best Buy World Headquarters
> 7075 Flying Cloud Drive
> Eden Prairie, MN 55344 USA
>
> This '|' is not a pipe

Even if you have a few specific IPs, if they can be found, they can be
spoofed since there is no sequence number checking. I guess your security
then depends on how hard the trusted IPs are to guess. (Probably a bad idea)
In regards to increasing the connection table to a number greater the your
bandwidth can handle, well, first I'm not sure that that's a meaningful
statement. The maximum number of connections for a given bandwidth depends
on what's going on in those connections. However, the faked connections are
only 1 packet and I don't think that you could expand the table enough to
hold even 56k bps of faked packets.

-James

home help back first fref pref prev next nref lref last post