January 2009 - NANOG - lists.nanog.org

out-of-band access bandwidth
by wingying 29 Jan '09

29 Jan '09

Hi all, A quick question, what is the common bandwidth for out-of-band access? Thanks.

33 48

ISP Unbundling circuits
by itmailinglist 29 Jan '09

29 Jan '09

Hi everyone, Is it common for an ISP to install a lased line (circuit) and when the service ends, the service is not unbundled again but all the cabling is left where it is? I have even seen that a circuit is still active on there exchanges after years and no one at the ISP seems to care that they are wasting there own resources. Thanks and best regards, Alexander

8 7

-48VDC equipment recommendations
by Deepak Jain 29 Jan '09

29 Jan '09

Who does everyone like for -48VDC power systems nowadays (say in the 60A @48VDC and 600A@48VDC sizes). Something like you'd deploy in a POP or a 10-rack MMR with A&B. Management/no-management, not a big deal. Off-list is fine, and I'll be glad to summarize for the list. Thanks in advance, Deepak

3 2

NetFlow Research
by pmeaux MEAUX 29 Jan '09

29 Jan '09

I am doing some research at the University of Colorado on NetFlow and its potential to influence BGP routing policies. Are there any examples where review of NetFlow data has caused a change in a BGP routing policy? How often are these changes made and what would be the most common reasons for using NetFlow? Thanks Paul Meaux _________________________________________________________________ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_012009

1 0

Re: Tightened DNS security question re: DNS amplification attacks.
by aljuhani 28 Jan '09

28 Jan '09

Well the RBLs, in using dns queries, is another form of legal DDoS attacks, mainly when the suddenly cease to respond or re-configure to black-list the entire wold. One should just imagine the bandwidth consumption during a given time-frame, RBLs consume as oppose to volume of spam messages. ----- Original Message ----- From: "Frank Bulk" <frnkblk(a)iname.com> To: "'Paul Vixie'" <vixie(a)isc.org>; <nanog(a)merit.edu> Sent: Wednesday, January 28, 2009 18:02 Subject: RE: Tightened DNS security question re: DNS amplification attacks. | Pretty soon we need an RBL for DNS-oriented DDoS attacks. =) | | -----Original Message----- | From: Paul Vixie [mailto:vixie@isc.org] | Sent: Tuesday, January 27, 2009 9:21 PM | To: nanog(a)merit.edu | Subject: Re: Tightened DNS security question re: DNS amplification attacks. | | "Douglas C. Stephens" <stephens(a)ameslab.gov> writes: | | > ... | > I choose the latter, and that is why went to the effort of blocking this | > abusive traffic before it reaches my authoritative-only DNS servers. | | this is an odd implementation choice. the 1PPS query stream is still using | your line even with this defense in place. the 1PPS response stream and the | CPU cycles it takes to generate that stream isn't a burden on you (compared | to the 1PPS query stream that you can't stop anyway). so the only reason to | block these appears to be so that you don't participate in the attack, or in | other words to cut down the burden on the victim. with me so far? | | the burden on the victim isn't going to drop materially by what you did | since | hundreds of thousands of other servers are not going to block it. but if | the | victim is a recursive nameserver, then your blocking them will mean that | they | cannot access the zones you're authoritative for. so, no positive, but some | negative, for the only person in the whole equation who can be affected by | the blocking you're doing. | | i don't get it. with a cost:benefit matrix like that one, why is anybody | blocking this traffic? (i note with some alarm that ten years after i shot | it down, i still get queries to rbl.maps.vix.com, so the possibility that | the | blocks some folks might put in place to ...manage?... this attack will have | a | long term bad effect on our heirs and assigns. i know your perl script will | expire things 60 seconds after they stop spewing, but i fear that others are | blocking these in hardcode. | | (looking for ". IN NS" as the q-tuple pattern is not a solution, since the | bad guys can pretty trivially change the question they ask into one you're | willing to answer.) | | (REFUSED is nice because it's small, but the bad guys aren't lacking for | bots | to transmit spoofed packets from, they Do Not Need amplification, and all | forms of error rate limiting are also new attack vectors.) | | (is there a name-and-shame registry for networks that do/don't implement | BCP38? if not i guess i'll start one and hope that various auditors will use | google and notice me.) | -- | Paul Vixie | | | |

3 2

DNS DDoS
by Andrew Fried 28 Jan '09

28 Jan '09

Targeted victims, beginning 28-Jan-2009, as seen from my DNS server. GeoIP data for top two sites also below: +----------------+-------------+------------+ | host | count(host) | Percentage | +----------------+-------------+------------+ | 202.104.106.49 | 51 | 0.1109 | | 210.21.218.138 | 51 | 0.1109 | | 64.57.246.123 | 3561 | 7.7421 | | 64.57.246.146 | 29530 | 64.2026 | | 67.192.144.0 | 991 | 2.1546 | | 70.86.80.98 | 11276 | 24.5157 | | 76.9.16.171 | 535 | 1.1632 | +----------------+-------------+------------+ GeoIP Location Information for IP: 64.57.246.146 Located in: Suwanee, GA (US) Latitude: 34.0535 Longitude: -84.0659 Area Code: 770 Postal Code: 30024 ARIN information for: 64.57.246.146 DNS PTR Record: Registrar: arin ASN Number: AS20141 Country: US Ip Starting Block: 64.57.240.0 IP Ending Block: 64.57.255.255 IP Block Size: 4096 Date Registered: 20051012 Block Status: allocated BGP Peering Information for ASN20141: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 6983 | 64.57.246.146 | 64.57.240.0/20 | US | arin | 2005-10-12 | ITCDELTA - ITC^Deltacom 14745 | 64.57.246.146 | 64.57.240.0/20 | US | arin | 2005-10-12 | INTERNAP-BLOCK-4 - Internap Network Services Corporation GeoIP Location Information for IP: 70.86.80.98 Located in: Houston, TX (US) Latitude: 29.7523 Longitude: -95.3670 Area Code: 713 Postal Code: 77002 ARIN information for: 70.86.80.98 DNS PTR Record: 62.50.5646.static.theplanet.com. Registrar: arin ASN Number: AS21844 Country: US Ip Starting Block: 70.84.0.0 IP Ending Block: 70.87.255.255 IP Block Size: 262144 Date Registered: 20040729 Block Status: allocated BGP Peering Information for ASN21844: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 2914 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | NTT-COMMUNICATIONS-2914 - NTT America, Inc. 3356 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | LEVEL3 Level 3 Communications 3549 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | GBLX Global Crossing Ltd. 4565 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | MEGAPATH2-US - MegaPath Networks Inc. 6461 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | MFNX MFN - Metromedia Fiber Network -- Andrew Fried andrew.fried(a)gmail.com

2 1

google logo
by Antonio Querubin 28 Jan '09

28 Jan '09

Anyone else noticing Google's logo has been scrambled? Antonio Querubin whois: AQ7-ARIN

14 14

RE: Tightened DNS security question re: DNS amplification attacks. [SEC=UNCLASSIFIED]
by David Zielezna 28 Jan '09

28 Jan '09

I'm checking just with a mix of tcpdump/pcap, bind logs and p0f. A bit overboard, but logging is fun. I haven't checked any dark hosts to see whether the attack repeatedly sends queries to IPs which have never given an answer or indication of any kind of life. Your monitoring will probably determine this so let us know what behavior you find. DZ -----Original Message----- From: Steve Bertrand [mailto:steve@ibctech.ca] Sent: Wednesday, 28 January 2009 2:47 PM To: David Zielezna Cc: John Martinez; nanog(a)nanog.org Subject: Re: Tightened DNS security question re: DNS amplification attacks. [SEC=UNCLASSIFIED] Good work! How are you checking for this by hand? Would it be safe to assume that running tcpdump on a box in the following manner on a monitor port for a sizable portion of the network be ok (as opposed to the DNS servers themselves, as I don't have control over them all)? sniffer# tcpdump -n -i em5 dst port 53 | grep "NS? . (17)" 22:38:31.150114 IP 64.57.246.146.43581 > 208.70.106.58.53: 23685+ NS? . (17) We have a mix of DNS servers, some BIND and some DJBDNS, a BIND ACL won't work here. We also have single-homed clients that run accessible DNS servers that appear to be Windows based. ACL's outside of the BIND scope would be fantastic. For now, I'm following the above list, and blocking everything ingress that is not source port 53 from the IP to my network 53. Steve If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.

1 0

Contact at Eschelon/Integra to remove old swip
by Seth Mattinen 28 Jan '09

28 Jan '09

I've been trying unsuccessfully for years to get Eschelon/Integra to remove the swip for an old IP block. Last time I called some months ago I finally talked to someone who said they'd take care of it, but I looked today and it still says it's mine. The range in question is 66.224.163.0/24 and the T1 it was used with was disconnected years ago. If anyone can remove the swip or put me in touch with someone who can I'd appreciate it. ~Seth

2 2

APNIC offline
by manolo 27 Jan '09

27 Jan '09

All, Is anyone else seeing www.apnic.net offline? I have tried from two locations and the website does not respond. whois is working as expected though. Manolo

7 6