(As this group helps my feeble undertanding!! - Thanx :-))
Actually I don't think Firewall-1 would do this, based upon my
experience with it...I made an erroneous assumption that the
SYN's were a secondary packet during a connection....
There is code regarding SYN and ACK and the order in which they
must come in, so there maybe some secondary protection against
repeated attacks.
As I build upon my (still) pathetic knowledge of TCP/IP internals,
I now see that this presents a *nearly* insurmountable problem.
Firewall-1 may be able to be tweaked to handle the problem, but...
If this is the original packet, and a service is specified that
is allowed (say http), there seems almost no way to protect against
this attack except to validate the incoming address before starting
the connection. SYN attacks that ask to attach to invalid services can
indeed be blocked by most products/shareware, I would believe, but against
valid services, I would believe this is a still-to-be-solved programming
issue.
On 13 Sep 1996, Ryan Russell/SYBASE wrote:
> The main problem is that the atacks just mimic
> a normal start of a connection. There is no
> good way (that I can think of) for any sort of
> firewall or proxy to tell the difference. About the
> only thing one might be able to do (as is being
> discussed currently) is hold the request until
> you get a valid ACK.
>
> Firewall-1 would probably do this out of the box, and
> may do it well. It's about the same as implementing the
> same thing onthe actual inside host, but may be much
> quicker as the work is already done.
>
> The only thing is, I don't know off-hand if
> Firewall-1 will keep the SYN from being sent
> to the inside host until it gets the ACK or not..
> I also don't know how hard it would be to tweak.
>
> There is at least one Checkpoint support person on
> the list.... any comments?
>
>
> Ryan
>
> ---------- Previous Message ----------
> To: murchiso
> cc: firewalls
> From: Daniel.Blander @ ACSacs.Com ("Daniel J Blander - Sr. Systems Engineer for
> ACS") @ smtp
> Date: 09/13/96 12:39:53 AM
> Subject: Re: SYN floods - possible solution?
>
>
> Granted that I am no underlying code expert, but can not Firewall-1's
> code be tweeked to do this? Since it handles all packets before it hits
> the actual ports, these checks can be input...and the code and header to the
> compile are open to "hack"...
>
> On Fri, 13 Sep 1996, Roderick Murchison, Jr. wrote:
>
> > Date: Fri, 13 Sep 1996 01:36:54 -0400 (EDT)
> > From: Roderick Murchison, Jr. <murchiso @
vivid .
newbridge .
com>
> > To: firewall-1 @
applicom .
co .
il
> > Cc: firewalls @
GreatCircle .
COM
> > 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. murchiso @
vivid .
newbridge .
com
> > Newbridge Networks, Inc. office: (703) 708-5930
> > Product Manager - VIVID ACS fax: (703) 708-5937
> > Herndon, VA 22070-5241 http://www.vivid.newbridge.com
> >
> >
> >
> >
> >
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Daniel Blander =8^)
> Sr. Systems Engineer Applied Computer Solutions
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Phone: (714) 842.7800 Fax: (714) 842.8299
> Email: Daniel .
Blander @
acsacs .
com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> The Official Applied Computer Solutions Home Page
> and Tech Tip of the Week:
> http://www.acsacs.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Blander =8^)
Sr. Systems Engineer Applied Computer Solutions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phone: (714) 842.7800 Fax: (714) 842.8299
Email: Daniel .
Blander @
acsacs .
com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Official Applied Computer Solutions Home Page
and Tech Tip of the Week:
http://www.acsacs.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
