Re: Internet SYN Flooding, spoofing attacks

On Tue, Feb 15, 2000 at 10:22:46AM -0700, Vernon Schryver wrote:
> > From: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
> > ...
> > Well.. as soon as somebody presents us with "the real solution", we'll start
> > implementing.  In the meantime, filtering is the best we know how to do.
> > ...
> I really wish "we" actually knew how to filter.
> Just as I feared when the news broke, I'm seeing more paths where neither
> traceroute nor ping work, apparently because some of "us" are so expert
> that we turn off all of ICMP, and never mind intermittent blackholes from
> Path MTU Discovery or diagnosing routing or other mere technical problems.
        But some of us turn off ICMP except for ICMP_FRAG_NEEDED and keep
MTU discovery alive while cutting off the ICMP food fights and script
kiddie probes that seem to be endemic in our current mess.

        You betcha traceroute and ping are broken (figuratively and
literally).  Just as broken as I can make them.  You don't need to be
tracerouting or pinging into my network and that's my choice to make.
I can break them without breaking MTU discovery.  You want to diagnose
routing or other technical problems, why aren't you contacting me?

        You cut off ICMP_ECHOREPLY and all but a tightly restricted set
of UDP and you have just starved these DDoS zombies of the vast majority
of their communications facility.  TCP is much easier to trace, if they
fall back to that (I don't see how TFN2K could - it utilizes a blind
forward-only non-responding channel).  Blocking spoofed packets won't
do nearly as good a job since a lot of the packets aren't spoofed.  Doesn't
help at all in some examples I have some first hand experience with.

        Edge filtering and spoof protection would have been absolutely no
help for one site I was help with forensics after TFN2K.  They were a
source of ICMP_ECHOREPLY packets in one of the storms.  We STILL
haven't located the zombie amongst the hundreds of potential Windows
boxes (we already cleared the single Solaris and single RedHat box on
the subnet and TFN2K is known to run on Windows).

        No spoofed packets crossed router boundries.  The TFN2K command
sequence was executed well before anyone noticed any bandwidth anomolies,
so there's no track back to the master.  (Who would have noticed 20
ICMP_ECHOREPLY packets that merely didn't correspond to any internal
request?)  The slaves shut down after two hours and before the admins
realized that the smurf was being generated internally.  They did find a
bug in a router blocking of directed broadcasts.  That red-herring slowed
them down, thinking it was externally generated.  No trace back of the
smurf triggers back to the zombie (having that MAC address would do wonders)
was caught since it quiet before they started sniffing the network.

        They broke it's back by blocking ICMP_ECHO and ICMP_ECHOREPLY
(fortunately, this attack was not using one of the UDP options).

        I have not heard if any of the TFN scanners have turned up
anything yet.  TFN2K zombies are a real bummer since it can lay dormant
on a network until triggered and they don't reply back to the master.
These guys are on a machine by machine, file by file snark hunt looking
for files that could be any one of a number of names on systems that are
all different anyways.  Don't you know they're having fun?

        The attackers are gaining in sophistication.  We are begining to
see effort at "covert channels" for communications.  The tricks of
communicating via ICMP_ECHOREPLY packets with commands in the payload
and sending blobs of forward only commands with no reverse channel
responses are just examples.  How long before they start sneaking past
those defenses by sending ICMP_UNREACHABLE/ICMP_FRAG_NEEDED with
a command data payload?

        They don't have to resort to spoofing to pull off a lot of this.
Long command time delays, covert channels, and unidirection command
direction can make it just as difficult to track down as spoofing.

        Diagnostics are fine.  Performance is fine.  Diagnostics and/or
performance at the expense of security and/or robustness is not.

> Vernon Schryver    vjs(_at_)rhyolite(_dot_)com
        Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw(_at_)WittsEnd(_dot_)com
  (The Mad Wizard)      |  (770) 331-2437   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!