[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewalls-gc
Subject:    Re: IP Filters?
From:       Travis Hassloch <travish () dejanews ! com>
Date:       1997-07-04 11:41:11
[Download RAW message or body]

In message <3.0.1.32.19970704091416.006dc930@lint.cisco.com>, Paul Ferguson writ
es:
>What these two attacks share are that they have been known to
>be launched by attackers using bogus source addresses, addresses
>which are not found in the global routing system. TCP SYN attacks
>which use this methodology can be thwarted using a TCP 'intercept',
>a TCP proxy which will not complete the TCP three-way handshake
>unless the originator of the TCP connection is reachable in the
>routing table.

Linux claims to have a "fix" for SYN attacks; standard patches
reduce the problem but don't "fix" it and run the risk of
penalizing high-latency connections (false positives as it were).
Some have even considered using AI techniques for picking
connections in the queue to expire.  Can anyone comment on this?

The only "fix" I can think of would be putting the burden of
maintaining state on the originator, perhaps by passing some
token back in the SA (2nd) packet and having the client repeat
this in the 3rd packet.  Not sure if there is room for this
anywhere, and if so what kind of compatibility issues there
would be.
You have the disadvantage of not being able to list all sockets
in the syn-received state but being able to do that would imply
sensitivity to the attack wouldn't it?

This has probably been covered before by protocol experts; if so,
point me/us at the archive and let's not rehash it.

>This has the unfortunate
>side-effect of not only affecting the initial target, but also
>an unwary third-party to whom the bogus addresses used actually
>belong.

This actually seems likely since the SYN flooders are likely
just to pick pseudorandom 32-bit numbers (if not picking 0.0.0.0).

>The same holds true for UDP flooding, however, there is no
>effective mechanism to proxy UDP since it is connectionless.

It doesn't keep connection state in the packet like TCP does,
but that doesn't mean a gateway can't.  Besides, if you
rely on what the TCP flags say you're opening yourself
up to passive port scans (i.e. scans based on packets with ACK
set).

>Of course, ICMP traffic can be blocked altogether using
>traffic filters, and is usually a pretty smart idea to
>do so at the border router.

But if you aren't using application-level proxies which
can receive ICMPs, you can't get unreachables back, right?
That might be annoying.
If I remember right, ICMPs are a little trickier to handle
than standard TCP replies as some (for example, host unreach)
can come from IPs other than the destination.
Would it be useful to allow ICMPs relating to established
connections from the first-hop just used for that connection?

Another useful thing might be to check for ACKs corresponding
to data which hasn't been sent (recently), indicating
a possible TCP session-hijack.  Interestingly, Joncheray
doesn't mention this in his paper.  I have heard Bellovin
might have an RFC on this, but I haven't looked for it.

>Note: ingress traffic filtering is a concept of filtering
>traffic leaving your administrative domain so that only
>traffic which is announced via routing (e.g BGP) is allowed
>to exit your routing domain. This does nothing to protect
>you from an attack, but it does disallow downstream users
>from launching attacks using nonexistent source addresses.

Is this the multi-network equivalent of blocking outgoing
packets which don't appear from being part of your internal
network?

Disclaimer: I don't claim to be a protocol expert, and I should
probably have verified some of these assumptions, but my books
are at home.  Be nice :)
--
Travis Hassloch / travish@dejanews.com / http://www.dejanews.com
Deja News System Administration Group  / "When news breaks... we fix it."

[prev in list] [next in list] [prev in thread] [next in thread]