- NANOG - lists.nanog.org

Re: BCP38 tester?
by Peter Baldridge 01 Apr '13

01 Apr '13

I can assume that If you are spoofing packets, resetting passwords on cpe and replacing the box would be trivial. So it's questionable how useful this is. It seems like it just adds cost to for customers that can't spoof a packet to save their lives. On Mar 31, 2013 6:37 PM, "Jason Lixfeld" <jason(a)lixfeld.ca> wrote: On 2013-03-31, at 10:48 AM, Jay Ashworth <jra(a)baylink.com> wrote: > Is there a program which users can run on an end-site workstation which > would test whether they are being some link which is doing BCP38, or some > related type of source-address ingress filtering? > > I'm hoping for something that could be downloaded by users and run, and > try to forge a few packets to somewhere useful, which could be logged > somehow in conjunction with some unforged packets containing a traceroute, > so we could build up a database of leaky networks. > > On a related topic, while I know GRC Research's Steve Gibson is a bit of > a polarizing personality, he does have a fairly sizable consumer audience, > and might be a great distribution venue for such a thing. > > Or, perhaps, is there someone on here from Ookla? > > Patrick? Could Akamai be persuaded to take an interest in this as a > research project? >From my perspective, 99% of end-users probably don't understand (or care) that their provider might be responsible for initiating or precipitating a DDoS attacks, period. Most network operators are probably either too inexperienced to understand or too lazy to care. I believe that most everyone has a CPE of some sort, whether their service is resi or commercial. So, what about shifting the focus to the CPE manufacturers? They bend to technology and/or market pressures by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to their respective products in to satisfy technology limitations or security concerns or whatever. Why can't they help the cause by implementing some sort of RFC'ified BCP38 thing?

5 5

GlobalCrossing looking glass problem
by Eduardo Schoedler 01 Apr '13

01 Apr '13

Hi all, Someone is getting access to the GlobalCrossing the looking glass? # telnet route-server.gblx.net Trying 67.17.81.28... telnet: connect to address 67.17.81.28: Connection refused Thanks. -- Eduardo Schoedler

2 1

Re: Open Resolver Problems
by Brian Dickson 01 Apr '13

01 Apr '13

For filtering to/from "client-only" networks, here's the filtering rules (in pseudo-code, convert to appropriate code for whatever devices you operate), for DNS. The objective here is: - prevent spoofed-source DNS reflection attacks from your customers, from leaving your network - prevent your customers' open DNS servers (regardless of what they are) from being used in reflection attacks - permit normal DNS usage by clients, regardless of whether they are talking to an external DNS resolver, or doing their own local resolution (e.g. local DNS resolver on a host, or SOHO router) from client: permit source=client-subnet dest=any port=53 proto=TCP (TCP only works if reaches "established", i.e. spoofing is irrelevant, but we stop spoofed SYN here) permit source=client-subnet dest=any port=53 proto=UDP QR=0 (first/highest bit of 3rd octet of DNS packet payload of UDP) deny port=53 (regardless of source/dest - either spoofed source, or QR=1, if reached this rule) to client: permit dest=any source=any port=53 proto=TCP permit dest=any source=any port=53 QR=1 (first/highest bit of 3rd octet of DNS packet payload of UDP) deny port=53 proto=UDP (QR=0 which is what we want to avoid) (We don't have to check dest==client-subnet, since routing handles this requirement) If you have "eyeball" networks, please apply liberally. Brian

1 0

AS1239 & AS701 IP Transit sales folks
by Jason Lixfeld 01 Apr '13

01 Apr '13

If there are any IP Transit sales folks[1] listening form Sprint or Verizon, please drop me a line off-list. Thanks. [1] No resellers, please.

1 0

Tier 2 ingress filtering
by Jay Ashworth 01 Apr '13

01 Apr '13

In the current BCP38/DDoS discussions, I've seen a lot of people suggesting that it's practical to do ingress filtering at places other than the edge. My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week. The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic... which is not fraudulent, and has a valid engineering reason to exist and appear on their incoming interface. Fixing that will require the construction of an entirely new tracking system at the Tier 2, which is not really the case for the Tier 3 edge carrier, as I see it - you generally just turn unicast-rpf on for everyone's port, unless you have a signed waiver in your file cabinet, in which case you turn it off. Am I missing something? Or is the overarching problem large enough that people are willing to throw the baby out with the bathwater? Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

12 23

Dropping connectivity for Cyberbunker?
by Joseph Chin 31 Mar '13

31 Mar '13

This article talks about convincing direct peers and transit providers to stop Net connectivity to the culprit http://www.darkreading.com/blog/240151931/who-supplies-cyberbunker.html Would it not be easier if a majority of the ISPs simply filter BGP prefixes containing the aforementioned ASes in the paths? Maybe many of you are already quietly doing it? This probably won't stop the baddies from spoofing source addresses for attacks, but it will make Cyberbunker economically unviable as no one will be able to reach assets hosted on their IP addresses. They have proven beyond a reasonable doubt that they have no intention to behave as civilized Netizens. So why should the rest of us continue to play nice? Does anyone see a problem with this action?

1 0

[Q] Any detailed enterprise WAN QoS design/config for MPLS services, f/various ISPs?
by Stefan 31 Mar '13

31 Mar '13

Been looking for Verizon and AT&T AVPN MPLS, specifically. Pointers highly appreciated, as the nanog archive does not seem to have searchable items ref such. Cisco docs have some info, but I am mostly looking for tried and proven configs with the specifics that Verizon and AT&T offer. Traditional AT&T (e.g.) means involve the likes of (for main DC): policy-map <GENERAL NAME> description <ISP> CoS Profile <nb code> <nb>% RT (nb1/nb2/nb3) class <0> priority percent <nb> class <1> set dscp af21 bandwidth <nb1> class C<2> set dscp af31 bandwidth <nb2> policy-map <3> class <4> set dscp af21 class <5> set dscp af31 class <6> priority percent <nb> policy-map <NAME> class class-default shape average <nb> service-policy <GENERAL NAME> ... interface GigabitEthernet2/0/0.x ... ip pim sparse-mode service-policy output <3> ... or the likes (can't even tell if I consistently sanitized the info, but you get the point) I am interested in main hub/DC + remotes - docs, preferably. TIA, ***Stefan

1 0

CIO Mag on the Spanhaus attack
by Jay Ashworth 31 Mar '13

31 Mar '13

Mentions ODRP, doesn't mention BCP38. http://www.cio.com/article/730882/Spamhaus_Attacks_Expose_Huge_Open_DNS_Ser… Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

1 0

So how big was it *really*?
by Valdis Kletnieks 30 Mar '13

30 Mar '13

So we all have heard the breathless news reports of how the recent urinating contest between Spamhaus and a butthurt ISP was the "biggest in history". Where would you guys put it, if measured as "percent of total worldwide available Internet bandwidth/resources"? My gut feeling is that by that metric, it didn't even make the top 20. Think back to the Morris worm, or Blaster/Nachi/etc - *nobody* had any free bandwidth when those happened. And even if you restrict the discussion to intentional targeted attacks, I'm sure we've had worse (Smurf, anybody? :)

9 9

BGP hijack of Spamhaus?
by Nicolai 30 Mar '13

30 Mar '13

Hi all, Regarding the Spamhaus DDoS attack, there's a Cisco article [0] detailing its chronology, which cites greenhost.nl [1] claiming a BGP hijack by AS34109 (CB3ROB). Here, a /32 was announced (and accepted...) for 0.ns.spamhaus.org, and the fraudulent server returned 127.0.0.2 for *all* DNSBL queries, with the intent to undermine confidence in Spamhaus. Are there any confirmations of this claim? This needs to be investigated and proven/disproven. Nicolai 0. http://blogs.cisco.com/security/chronology-of-a-ddos-spamhaus/ 1. https://greenhost.nl/2013/03/21/spam-not-spam-tracking-hijacked-spamhaus-ip/

2 2