July 2006 - Test - lists.nanog.org

Re: Best practices inquiry: filtering 128/1
by Patrick W. Gilmore 10 Jul '06

10 Jul '06

On Jul 10, 2006, at 10:18 PM, Valdis.Kletnieks(a)vt.edu wrote: > On Mon, 10 Jul 2006 22:00:11 EDT, "Patrick W. Gilmore" said: >> >> On Jul 10, 2006, at 9:48 PM, WONG, Yuen-Fung wrote: >> >>> Sometimes earlier this year someone announced this 128/1 and caused >>> heavy loading to our routers to rebuild the CEF. >>> Would anyone filter out this route (and other similar routes such >>> as 0/1, 128/1, 0/2, 64/2, .... up to /4, for example) as bogus >>> routes? >> >> Would anyone not filter those routes? Why wouldn't you filter to /7? > > Every growing season, a new crop of network engineers falls fresh from > the tree, and must be picked up, polished, and clue imparted on the > way to market..... Well, then don't snip the most important clue in the post: > Actually, I take that back. Why wouldn't you just get a feed from > Cymru <http://www.cymru.com/Bogons/index.html> ?? :-) -- TTFN, patrick

1 0

Fridays are always good for shock headlines...
by Fergie 10 Jul '06

10 Jul '06

Nothing new here, but just an FYI -- I figured some of you might want to be aware new pressures being exerted in the CALEA arena. Via C|Net. [snip] The FBI has drafted sweeping legislation that would require Internet service providers to create wiretapping hubs for police surveillance and force makers of networking gear to build in backdoors for eavesdropping, CNET News.com has learned. [snip] More: http://news.com.com/2100-1028_3-6091942.html - ferg p.s. When did the FBI start drafting legislation? ;-) -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

4 4

Best practices inquiry: tracking SSH host keys
by Phillip Vandry 09 Jul '06

09 Jul '06

We all know that the weakest link of SSH is key management: if you do not confirm by a secure out of band channel that the public host key of the device you are connecting to is correct, then SSH's crypto will not help you. SSH implements neither a CA hierarchy (like X.509 certificates) nor a web of trust (like PGP) so you are left checking the validity of host keys yourself. Still, it's not so bad if you only connect to a small handful of well known servers. You will either have verified them all soon enough and not be bothered with it anymore, or system administrators will maintain a global known_hosts file that lists all the correct ones. But it's quite different when you manage a network of hundreds or thousands of devices. I find myself connecting to devices I've never connected to before on a regular basis and being prompted to verify the public host keys they are offering up. This happens in the course of something else that I am doing and I don't necesarily have the time to check a host key. If I did have time, it's hard to check it anyway: the device is just one of a huge number of network elements of no special significance to me and I didn't install it and generate its key and I don't know who did. >From time to time I also get hit with warning messages from my SSH client about a changed host key and it's probably just that someone swapped out the router's hardware sometime since the last time I connected and a new key got generated. But I'm not sure. Worst of all, my problem is repeated for every user because each user is working with their own private ssh_known_hosts database into which they accept host keys. A possible solution is: - Maintain a global known_hosts file. Make everyone who installs a new router or turns up SSH on an existing one contribute to it. Install it as the global (in /etc/) known_hosts file on all the ssh clients you can. Pro: The work to accept a new host key is done one, and it's done by the person who installed the router, who is in the best position to confirm that no man in the middle attack is taking place. Con: You need to make sure updates to this file are authentic (its benefit is lost if untrusted people are allowed to contribute), and you need to be sure it gets installed on the ssh clients people use to connect to the network elements. Con: If a host key changes but it is found to be benign (such as the scenario I describe above), users can't do much about it until the global file is corrected and redeployed (complicated openssh options which users will generally not know to bypass the problem notwithstanding). I'm looking for information on best practices that are in use to tackle this problem. What solutions are working for you? Thanks -Phil

10 15

Re: NANOG Spam?
by William Allen Simpson 09 Jul '06

09 Jul '06

Christian Seitz <chris(a)in-berlin.de> wrote: > In article <44AC3493.6010705(a)gmail.com> you wrote: > >> oarwind.info. >> AS | IP | Registry | AS Name >> 6724 | 81.169.143.178 | ripencc | STRATO Strato AG > > How did you resolve this? Is there something wrong with > my DNS or did you make a mistake resolving the adress? > > oarwind.info A 218.22.43.22 > > inetnum: 218.22.0.0 - 218.23.255.255 > netname: CHINANET-AH > country: CN > descr: CHINANET Anhui province network > descr: Data Communication Division > descr: China Telecom > admin-c: CH93-AP > tech-c: AT318-AP > status: ALLOCATED PORTABLE > mnt-by: APNIC-HM > mnt-lower: MAINT-CHINANET-AH > changed: hm-changed(a)apnic.net 20060322 > source: APNIC > At the time of resolution 3 days ago, multiple persons on this list resolved it to Strato.de. h613092.serverkompetenz.net (81.169.143.178) Apparently, it has since moved to China. That's the kind of thing that happens while you took a long weekend. Are you in a position to quarantine the German server? Or otherwise aid in investigating the problem? Such as getting German law enforcement to confiscate the server as compromised and containing personal identity theft?

1 1

Re: NANOG Spam?
by Gregory Hicks 09 Jul '06

09 Jul '06

> Subject: NANOG Spam? > Date: Wed, 5 Jul 2006 12:56:19 -0500 > From: "Joe Johnson" <joe(a)sendjoeanemail.com> > To: <nanog(a)merit.edu> > > > Am I the only one to get this email? Headers say merit.edu sent it. I > have NANOG whitelisted, though, so it came to my mailbox. > [...snip spam...] No, I got it as well but Postini caught it for me. So I hadn't seen it... Just a "joe-job" though. The headers are forged. See the IP address in thi FIRST "Received-by:" header. Came from Spain. [...snip later headers...] Received: from trapdoor.merit.edu (unknown [84.232.124.32]) by trapdoor.merit.edu (Postfix) with SMTP id AD0CF91265 for <nanog(a)trapdoor.merit.edu>; Wed, 5 Jul 2006 13:39:15 -0400 (EDT) From: "nanog(a)enterzone.net" <nanog(a)enterzone.net> To: nanog(a)trapdoor.merit.edu Content-type: text/html; Charset=Windows-1251 ------------------------------- % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html % Information related to '84.232.124.0 - 84.232.125.255' inetnum: 84.232.124.0 - 84.232.125.255 netname: TELELEPE-NET descr: Television Por Cable descr: Hermanos Ponce Garcia S.L. descr: Local TV and ISP Provider country: es admin-c: GPP18-RIPE tech-c: GPP18-RIPE status: ASSIGNED PA mnt-by: SERVIHOSTING-MNT source: RIPE changed: ripe(a)servihosting.es 20060126 person: Gregorio Ponce Pozuelo address: C/Niña, 31 address: 21440 Lepe (Huelva) SPAIN phone: +34 959645086 fax-no: +34 959158409 e-mail: cablehnosponcegarcia(a)hotmail.com nic-hdl: GPP18-RIPE notify: ripe(a)servihosting.es mnt-by: SERVIHOSTING-MNT changed: ripe(a)servihosting.es 20060126 source: RIPE % Information related to '84.232.0.0/17AS29119' route: 84.232.0.0/17 descr: ServiHosting Networks S.L. descr: First Allocation remarks: ********************************************** remarks: | For ABUSE/SPAM/SCANS issues | remarks: | send mail to abuse(a)servihosting.es | remarks: | or Fax at number +34.966982510 | remarks: ********************************************** origin: AS29119 mnt-by: SERVIHOSTING-MNT notify: m.tecles(a)servihosting.es changed: ripe(a)servihosting.es 20060113 source: RIPE Regards, Gregory Hicks --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 9B1 San Jose, CA 95134 I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." - Benjamin Franklin "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

19 25

Fwd: (RADIATOR) OSC hosts RadiusExpert Wiki
by Hugh Irvine 09 Jul '06

09 Jul '06

Hello Everyone - For those of you who may be interested in RADIUS and/or DIAMETER. regards Hugh > > Open System Consultants (OSC) has established a free resource for > the RADIUS > user community to collect and share information about configuring and > implementing RADIUS protocol devices and software. > > RadiusExpert:Community Portal at > http://www.open.com.au/wiki/index.php/Main_Page will become the > repository > for all the information that often resides only in the heads of system > administrators who manage and maintain the security access and > authentication requirements of their networks. > > We welcome contributions about such topics as configuring various > RADIUS > devices, load balancing with RADIUS servers and wireless > authentication tips > from our very active user community. > > If you can contribute any information on any RADIUS topic to the > benefit of > the entire community, please feel free. > > For more information about the Wiki, please contact me or go to: > > http://www.open.com.au/press_complete.html > > Best regards, > Nicola Wassell > Open System Consultants > 9 Bulbul Place, Currumbin Waters QLD 4223 Australia http:// > www.open.com.au > Phone +61 7 5598 7474 Fax +61 7 5598 7070 > -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows, MacOS X. Includes support for reliable RADIUS transport (RadSec), and DIAMETER translation agent. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. - CATool: Private Certificate Authority for Unix and Unix-like systems.

1 0

Copper thefts in california
by Sean Donelan 09 Jul '06

09 Jul '06

In addition to the traditional backhoe threat, as the price of copper increased so has the threat of people stealing telephone trunk cables containing copper wire. http://www.dailybulletin.com/news/ci_4021500 Since Jan. 1, there have been 148 reports of copper wire theft in San Bernardino County, said sheriff's spokeswoman Jodi Miller. [...] Per pound, the metal has risen in price from about 70 cents in July 2001 to $3.60 this month, according to Kitco Inc., an international retailer of precious metals. [...] Anyone with information on the Verizon theft may call the Verizon Security Control Center, 1-800-997-3287. For the AT&T thefts, people may call security at (213) 633-2558 or (213) 633-2405. People with information on copper thefts may also contact their local law enforcement agencies.

5 4

CFP: DA Workshop - ISOI
by Gadi Evron 09 Jul '06

09 Jul '06

This is a call for papers for a DA Workshop (ISOTF/TISF DA). Its name is: Internet Security Operations and Intelligence Workshop or ISOI for short. DA stands for Drone Armies (botnets), which is the main subject of this workshop. I apologize for those who get this message multiple times. Introduction ------------ This workshop is for the purpose of bringing together members of the DA and MWP operational communities and share information, as well as plan our future operations. It is open to other operational communities as specified below. Among the attendees are: Professionals from ISPs, Anti Viruses, Anti Spam, CERTs, Law Enfrocement, Academia, etc. coming together to work on the most recent technology, intelligence and operations being done online today for the security of the Internet. This ISOI DA Workshop is being hosted by Cisco Systems, Inc., whom we would like to thank at this time. CFP --- The call for papers is open to the public. The main subject of interest is botnets. Secondary subjects are Denial of Service attacks and phishing. Submission is simple, email me directly with your topic and some data to back it up by July 23rd. Scope: ------ This year's workshop will be mainly on the subject of botnets. Secondary subjects include Denial of Service attacks and phishing. This workshop will provide with the usual benefits such as lectures and networking, but mostly we will discuss the latest occurrences, technology and intelligence and our future plans, as well as coordination and information sharing between other operational and research communities. Cooperation with law enforcement will also be covered. Details: -------- Date: Thursday, August 10, 2006 When: 9:30 a.m. - 5:00 p.m. Location: Cisco Systems, Inc. Building C 150 Tasman Drive San Jose, CA 95134 Attending Remotely: ------------------- A phone conference bridge and web conference will be available to share presentations for remote attendees. Intended Audience: ------------------ Hands-on people and decision makers. Attendance: ----------- The workshop is organized by the DA and MWP communities with the much appreciated help of Cisco Systems, Inc., and is closed to members of the following communities: DA, MWP (and sister communities such as routesec), OARC, NSP-SEC. FIRST and the honey-net project. If you are not a member and would like to attend, feel free to send a request. We would be happy to learn of your interest. The workshop is closed to reporters. Please verify your arrival by August 1st, space is limited. Costs: ------ Attendance is free. -- Gadi Evron, ISOI/DA Coordinator, ge(a)linuxbox.org.

3 4

NANOG 38: Call for Presentations - Oct 8-10 2006 - St. Louis, MO
by Steve Feldman 08 Jul '06

08 Jul '06

The North American Network Operators' Group (NANOG) will hold its 38th meeting October 8-10, 2006, in St. Louis, Missouri. The meeting will be co-hosted by Savvis and Washington University in St. Louis. This will be NANOG's fifth joint meeting with ARIN, the American Registry for Internet Numbers. NANOG will meet from Sunday to Tuesday, and ARIN from Wednesday to Friday, October 11-13. NANOG registration will open in August. NANOG conferences provide a forum for information exchange among network operators, engineers, and researchers. Meetings are held three times each year, and include panels, presentations, tutorial sessions, and BOFs. NANOG solicits presentations highlighting issues relating to technology already deployed or soon to be deployed in the Internet. The NANOG community is invited to attend and participate in this forum, which offers numerous opportunities to share ideas, explore research and development, and interact with leaders in this important field of network operations. Vendors are encouraged to work with operators to present deployment experiences with the vendor's products and interoperability. General Session =============== The community is invited to develop panel sessions or present talks on topics relevant to the NANOG community, including: Network Operations Present-day operational case studies Everyday life in the NOC and tools of interest Exchange point technologies and implementation Peering/colocation coordination issues Content provider issues Security attacks/mitigation, tools, and analysis State of OAM tools for IP and MPLS networks Disaster recovery and planning Deployment Experience Mergers and their impact on interconnected networks Alternative and emerging last-mile technologies (metro/rural, broadband, radio, optical, etc.) VoIP deployment, architecture, peering, and interconnect Anycast IPTV Large-scale wireless Fiber and wavelength use by enterprises Research, Policy, and New Technology Approaches to securing the global routing system (e.g., s*BGP and/or other tools) Routing system scalability Capacity planning standards and tools Inter-provider MPLS/QoS/PCE RIR policy (e.g., implications of HD ratio) Active standards organizations and areas of interest IPv6: economics, deployments, and adoption rates Approaches to IPv6 scalability, e.g., Shim6 Panels ====== Panel selection will be based on the importance, originality, focus and timeliness of the topic; expertise of proposed panelists; as well as the potential for informative and controversial discussion. The panel leader should provide an abstract describing the panel theme, list of panelists, and an outline of how the panel will be organized. After acceptance, the panel leader will be given the option to invite panel authors to submit their presentations to the NANOG Program Committee for review. Until then authors should not submit their individual presentations for the panel. Lightning Talks =============== A lightning talk is a very short presentation or speech by any attendee on any topic relevant to the NANOG audience. These are limited to ten minutes; this will be strictly enforced. If you have a topic that's timely, interesting, or even a crackpot idea you want to share, we encourage you to consider presenting it. Signups for lightning talks will be accepted during the NANOG meeting. Research Forum ============== Researchers are invited to present short (10-minute) summaries of their work for operator feedback. Topics include routing, network performance, statistical measurement and analysis, and protocol development and implementation. Studies presented may be works in progress. Researchers from academia, government, and industry are encouraged to present. Tutorials ========= Proposals are also invited for tutorial sessions from the introductory through advanced level on all related topics, including: Disaster Recovery Planning Troubleshooting BGP Best Practices for Determining Traffic Matrices Options for Blackhole and Discard Routing BGP/MPLS Layer 3 VPNs How to Present ============== Submit presentation information and an abstract online at: http://www.nanogpc.org Once you have done this, the you will receive instructions for submitting your draft slides. See http://www.nanog.org/presentations.html for complete submission guidelines. All submissions must include: Author's name(s) Preferred contact email address Submission category (General Session, Panel, Tutorial, Research Forum) Presentation title Abstract Slides (attachment or URL), in PDF (preferred) or Powerpoint format You may intead submit the presentation information and draft slides in email to nanog-support(a)nanog.org. The deadline for proposals is Thursday, August 3, 2006. A limited number of slots may be available after that date for topics that are exceptionally timely, important, or critical to the operation of the Internet. Submissions will be reviewed by the NANOG Program Committee, and presenters will be notified of acceptance by August 14. Final drafts of presentation slides are due for review on September 22, and final versions for posting are due on October 1.

1 0

Interesting voip theft of service - anybody got a more technical skinny on this?
by Suresh Ramasubramanian 08 Jul '06

08 Jul '06

http://www.networkingpipeline.com/shared/article/printablePipelineArticle.j… June 08, 2006 The Inside Story of A Million-Dollar VoIP Scam A Miami man allegedly defrauded Internet voice providers to the tune of $1 million, with a sophisticated hacking scheme. Here's the inside story of exactly how he did it. By Preston Gralla Networking Pipeline The $1 million scheme by a Miami man to allegedly defraud VoIP providers, and sell long-distance calls surreptitiously through their networks, was a surprisingly easy technical feat, and should give pause to providers and enterprises alike about how insecure voice services have become in a world where all calls will eventually be routed over IP networks. Federal prosecutors charge that Edwin Andres Pena of Miami hacked into the networks of Internet telephone providers and fraudulently sold more than 10 million minutes of VoIP calls. Pena allegedly sold $1 million of phone service to his customers at extremely reduced rates. But rather than buy long-distance minutes from existing providers to provide the service, he instead hacked into the networks of VoIP providers, and provided the minutes for free. Here's how he did it. Starting with a "Brute Force" Attack The basic service that Pena provided is not uncommon. Telecommunications brokers often buy long-distance minutes from carriers -- especially VoIP carriers -- and then re-sell those minutes directly to customers. They make money by marking up the services they buy from carriers. Pena sold minutes to customers, but rather than buy the minutes, he instead decided to hack into the Internet phone company networks, and route calls over those networks surreptitiously, say prosecutors. So he had to pay virtually no costs for providing phone service. The first step in the scheme required that Pena find the special prefixes that Internet phone companies use to identify calls that are allowed to be routed over their networks. Prosecutors say that Pena did this with a "brute force" attack, by "slamming" Internet phone networks with thousands of test calls, using many different variants of prefixes. When a call was able to get through to one of the Internet phone service networks, Pena knew that he had the proper prefix for that network. Once he had the proper prefixes, he turned to someone else for help with the scam, say prosecutors. He contacted Robert Moore of Spokane, Washington, they say, who runs the site moorer-software.com. The site includes links to hacker sites and to hacker tools. Moore, say prosecutors, immediately set to looking for vulnerable ports in "unsuspecting companies and other entities in the United States and around the world." He wasn't looking for Internet phone service ports, but instead for open, vulnerable ports and routers in private companies. When he found vulnerable ports, he would also hack into the network to get administrator names and passwords. The scope of the scanning was massive, say prosecutors, who claim that he performed six million scans of AT&T's worldwide network alone from June to October of 2005. Pena allegedly sent the IP addresses of the open ports and routers to Pena, and also sent the network administrator names and passwords. Hacking the Routers With the IP addresses and network administrator names and passwords in hand, say prosecutors, Pena reprogrammed the routers to allow the routers to handle VoIP calls, and to disguise the true source of the traffic. Prosecutors say that one of the networks Pena hijacked in this way was a Rye Brook, NY hedge fund company. In other instances, say prosecutors, Pena and Moore rented servers under false names, including "David Hauster" and "Jake Hamilton" and used those rented servers to handle his customers' voice traffic. Completing the Scam The last step of the scam was relatively easy. Pena first routed his customer's calls to the Rye Book hedge fund company network via the routers he had hacked, say prosecutors. In other instances, he routed them through the rented servers, they added Using his access to the routers, he then sent the calls from the hedge fund company, or his rented servers, to Internet phone service providers, according to prosecutors. They say that he routed the calls to 15 separate Internet phone service providers, including one based in Newark, NJ. The provider wasn't named in the charges, but Net2Phone, a large Internet phone service provider, is located in Newark. Pena allegedly appended the access codes to the calls, so that the Internet phone providers would believe they were legitimate calls. The calls went through with no problems, and were completed over the Internet phone provider networks. The Internet phone service providers, though, have been left holding the bag, because they had to pay $300,000 for routing the calls to other carriers. The scope of the scam was massive. According to prosecutors, in a single three-week period, 500,000 calls were routed through the Newark Internet phone service provider, and were made to look as if they came from the Rye Brook Hedge fund. The Bottom Line The bottom line in all this? It should be a wake-up call not just to Internet phone service providers, but to network administrators as well. This scam couldn't have been accomplished without there being enterprise network security holes -- and these holes may get bigger as voice is increasingly routed over enterprise IP networks.

1 0