nanog mailing list archives
Re: address spoofing
From: Jeremy Porter <jerry () freeside fc net>
Date: Fri, 23 Apr 1999 00:44:00 -0500
In message <m10aUqK-0008G4C () 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 () 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 () 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
Current thread:
- address spoofing Randy Bush (Apr 22)
- Re: address spoofing Gary E. Miller (Apr 22)
- Re: address spoofing Jared Mauch (Apr 22)
- Re: address spoofing Randy Bush (Apr 22)
- Re: address spoofing Tim Finkenstadt (Apr 22)
- Re: address spoofing Jeremy Porter (Apr 22)
- Re: address spoofing John Leong (Apr 23)
- Re: address spoofing John Leong (Apr 23)
- Re: address spoofing Simon Leinen (Apr 27)
- Re: address spoofing Jared Mauch (Apr 22)
- Re: address spoofing Gary E. Miller (Apr 22)
- Re: address spoofing Daniel Senie (Apr 22)
- Re: address spoofing Forrest W. Christian (Apr 23)
- Re: address spoofing Andrew Brown (Apr 23)
- Re: address spoofing Forrest W. Christian (Apr 23)
- Re: address spoofing sthaug (Apr 23)
- Re: address spoofing John Leong (Apr 23)
- Re: address spoofing Daniel Senie (Apr 23)