tracing spoofing (Was Re: Ping flood? Whats the point?)

[dr () DURSEC COM (Dragos Ruiu)]

On Wed, 02 Feb 2000, Don wrote:
> Well, I experienced the same problem myself once. Since the number of
> IP's is too large, it can't be possible for the flooder too "own" them
> all.
> My conclusion was that it are spoofed IP's comming from one or several
> hosts. Because all IP's are random and spoofed it will not be possible
> to trace them.
> It's most likely the flooder is trying to flood you down so that it's
> impossible for the target host to do anything.
>
> I have seen several programms capable of doing this, one of them is
> "trinnoo flood network" or something like this. It opperates by running
> client software on computers which can be triggered by a server and then
> the flooding begins.
>
> As far as I know there's nothing you can do to trace the flooder...
> (could it be possible to trace via ARP stuff?)

No, but it should be trivial to use snort, nfr, dragon or any of your other
fave forensic tools all the way to tcpdump to check to see if your network
is -sending- spoofed traffic.  This may not mean much when you are
talking about a small server at home or in an university, but if you run
an isp or a hosting shop, it should be a pretty rudimentary and
inexpensive pseudo-mandatory precaution to buy some probes and
configure them to scan through the source addresses on your network
or server farm and detect anytime your machines or nastyer customers are
sending out spoofed network traffic.  This setup requires at least two
machines but it can then be used to WinPopUp, syslog, ring bells, set off
pagers, or my favorite... cheap imitation police flashers from mexico
wired to a serial port controlled relay, flashing at anytime your machines
start transmitting a lot of garbage.

The magic is to have two probes and sychronize their timebases.
Then you need to periodically grab those dump files and process.
In reality you do not need to capture anything more than the addresses
and timestamps but capturing the whole packet will let the process
be more conclusive.  The two probes need to be situated on either
side of a nice choke point, like say your main peering router and
its link to your server farm/dmz - firewalls also make nice spots.
By writing a query or a perl script  to do the equivalent of a
packet diff, sorting each packet by source address and
timestamp, you should be able to tell if the packet was outbound
or inbound into your network based on which probe saw
the packet first. If you see packets outbound out of your
address space that aren't in your address  space, then you
may be causing someone else to have network "issues." :-)
This may be of some use to make sure you haven't become a
nesting site for some trinoo or like infestation.

This concept can be scaled up with addtl. expense of more
probes to cover more complex and thorough spoofing identifiers.
If anyone is really interested in building this more sophisticated
function into their infrastructure, please feel free to contact us for
further info.

cheers,
--dr

--
dursec.com / kyx.net - we're from the future                            http://www.dursec.com
learn kanga-foo from masters: CanSecWest - April 19-21 Vancouver

Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, rain.forest.puppy/wiretrip.net,
          Theo DeRaadt/OpenBSD, Max Vision/whitehats.com, Fyodor/insecure.org