address spoofing

Fri Apr 23 05:44:00 UTC 1999

In message <m10aUqK-0008G4C at rip.psg.com>, Randy Bush writes:
>
>everybody seems to be focussed on the 1918 space packets and the
>explanations seem half reasonable.  as Daniel Senie <dts at senie.com> said,
>the rules of the road say i should not be seeing packets from 1918 space.
>i.e. at best these come from broken places.

Perhaps because no one really wants to consider the implications of
the second set.

>but the uglier symptoms are packets from my own address space
>
>    deny ip 147.28.0.0 0.0.255.255 any (6 matches)
>
>the loopback network
>
>    deny ip 127.0.0.0 0.255.255.255 any (375 matches)

While it is possible to come up with examples such as end sites
randomly picking IP addresses and using those, and originating those packets
onto the Internet, most of these packets I've ever seen have been scanning
or probing or active attacks.

Sadly these attacks would be impossible to trace as there exists
no real time communication system between Nocs where "security" issues
are addressed.  I can understand some of the political reasons why
companies would prefer there NOCs not be able to address "security" issues.
And I can understand why an end user reporting the problem has difficulty
in reporting problems to networks that they aren't a customer of.
I can't for the life of me understand why companies with clue
and companies with tons of money, and companies without either, typical
only have one "security" person who happens to be out, and even if paged
won't get back before the attack goes away, then gives you the lame answer
"I don't see anything now", as if you made it up.

The only possible conclusion I feel comfortable with, aside from none,
is that these issues are not significant from an operational perspective
and security must be handled at the end sites.

My gut feeling is that we don't see nearlly as many amplifier attacks
in the last six months as we did in the six previous.  (Thank CAR?)
Primarily because these were severe enough to cause operational issues.
The same could perhaps be said of mail relaying, which I don't see nearly
as many operational issues from now as I did a year ago.  (Hasn't much
affected levels of junk email I receive tho.)

If there is a real impact of random bogon packets, I don't see much
solution other than real time tracing, as source ingress filtering
is only marginally effective in preventing them (or URFP verfication).

>and attempts on 111 and 2049
>
>    deny udp any any eq sunrpc (9 matches)
>    deny tcp any any eq 2049 (494 matches)
>
>randy

I've got customers that actually use these, so I couldn't filter those
without problems, although probably the customer could work around those
peices of software...

--- jerry at fc.net
Insync Internet, Inc.          | Freeside Communications, Inc.
5555 San Felipe, Suite 700     | PO BOX 80315 Austin, Tx 78708
713-407-7000                   | 512-458-9810 
http://www.insync.net          | http://www.fc.net