SYN spoofing

Mailman List Mirror (Read Only)
1

In message <Pine.LNX.4.10.9907281242140.18497-100000@anime.net>, Dan Hollis wr
ites:

Perhaps if you were to NAME these networks, they may be shamed into doing
something about the problem.

Anyone for a weekly 'bogons transit list'?

The problem being, that you would need to know where these packets
originated, and if you knew that, you could probably get the problem
fixed in the first place. Lack of a soci-technological solution
for interprovider backtracing limits the utility of this, and
since you can't really pin point the 10 ten bogon transit providers
you don't have much ability to shame people into fixing their stuff.

Then again, they should be ashamed to begin with for passing RFC1918
traffic, let alone loopback space.

You would think so. But somehow these packets still show up.

-Dan

--- jerry@fc.net
Freeside/ Insync Internet, Inc.| 512-458-9810 | http://www.fc.net
#include <sys/machine/wit/fortune.h>

2

In message <Pine.LNX.4.10.9907281242140.18497-100000@anime.net>, Dan Hollis wr
ites:
>Anyone for a weekly 'bogons transit list'?
The problem being, that you would need to know where these packets
originated, and if you knew that, you could probably get the problem
fixed in the first place.

You really think so? Some of us have tried to persuade the 'big names' to
filter completely bogus source addresses, and were blown off.

Lack of a soci-technological solution for interprovider backtracing
limits the utility of this, and since you can't really pin point the 10
ten bogon transit providers you don't have much ability to shame people
into fixing their stuff.

You can at least conclusively show who is transporting the
invalid-source-address-packets to the endpoint. That is, conclusively show
that the next-to-last-hop isnt properly filtering.

-Dan