- NZNOG - lists.nznog.org

Re: [nznog] DNS Cache Poisoning
by Spiro Harvey, Knossos Networks Ltd 28 Jul '08

28 Jul '08

> Once this had gone public CCIP should have engaged this forum. CCIP has > well defined procedures and processes in place when sharing information with > the National and International security communities and the "traditional" > critical infrastructure community. Outside of those communities the process Does "critical national infrastructure" (as quoted from your website) include all NZ ISPs, or just the big players? > Another suggestion is the > need for a closed mailing list for the NZ ISP community. Closed lists seem to serve two purposes: 1) making the members feel 1337; and 2) money spinners. And who would act as the "police" to ensure that all members are ISP representatives? Who would keep tabs on which members have changed jobs and thus require removal from the list? I see this as a way to introduce #2 as above. Then you give all members club cards or secret decoder rings and if the smaller ISPs have trouble coming up with the funds, they'll be excluded. Perhaps it's more pertinent to ask "What is the end goal?" Is it to keep the NZ ISP industry aware of all security issues? Or is it to create a secret club? It's likely that the undesirables already know of the vulnerabilities, and the media will find out anyway and put some dramatic spin on it to keep themselves employed. What about operators of private networks? Shouldn't they know about these issues to protect their networks from attack? In this scenario, one poisoned DNS cache on a company intranet could lead to an entire company's PCs being hijacked or infected, or whatever the poisoner decides will provide the maximum amusement. With your secret club proposal, these network operators would not be aware of the issues because they're not ISPs. I believe NZNOG is the perfect avenue for security vulnerability disclosure. -- Spiro Harvey Knossos Networks Ltd 021-295-1923 www.knossos.net.nz

1 0

Re: [nznog] DNS Cache Poisoning
by Nathan Ward 28 Jul '08

28 Jul '08

On 28/07/2008, at 11:28 PM, Paul McKitrick wrote: > Good Evening Everyone, > > I have to agree with Joe's post and I have also had a number of > other off > post emails reiterating the same message. > > Once this had gone public CCIP should have engaged this forum. CCIP > has > well defined procedures and processes in place when sharing > information with > the National and International security communities and the > "traditional" > critical infrastructure community. Outside of those communities the > process > is not as well defined and this event has highlighted this. What > this event > has also demonstrated is that the NZNOG community is dedicated to > protecting > New Zealand's networks and we just need to figure out how we can do > that > together, and part of that is ensuring the right information gets to > the > right people. > > One of the recent suggestions CCIP has received is the concept of > establishing an NSP-SEC group for New Zealand. Another suggestion > is the > need for a closed mailing list for the NZ ISP community. The > intention > would not be to replace the NZNOG mailing list but to have an > alternative > for when the community needed a closed and trusted mode of > communication. > CCIP would like to work with this community to investigate > establishing > something along these lines in New Zealand and to listen to your > thoughts > and suggestions on this topic as a number of you have been thinking > about > this for some time as well. I'm not sure I understand what benefit a closed list would have in this sort of scenario, to be honest. I can't imagine that CCIP, or anyone else, are going to have information about security problems like this before they are in the wild - there's just too many people involved globally for closed distribution to be truly closed. The NZ ISP community (or at least those who I imagine you'd put on such a closed list) is small enough that all those people have everyone else's contact details already, and any incident really only needs calls or emails to two or three other providers. A large benefit for most people who attend the NZNOG conferences is the ability to have a beer with their industry peers and set up those contacts[1]. The only thing I could imagine a list would be used for is discussion about technical issues where media, end users, and other generally non- technical people cannot read[2] - but that's not really a security list. -- Nathan Ward [1] This sentence doesn't really add much, but I'm bringing my post on topic :-) [2] Some have suggested that the presence of media, end users, etc. on NZNOG is a large factor in the lack of pure technical content. Some people talked about setting up an invite only list a few years ago, but it never got off the ground (or at least, if I did I wasn't invited ;-), largely because it was assumed that legal departments would have a problem with open technical discussion - even without media, end users, etc. listening in. -- Nathan Ward

2 1

DNS Cache Poisoning
by Paul McKitrick 27 Jul '08

27 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good Evening All, I thought it would be good to let you know that CCIP is aware of this vulnerability and has been working on it behind the scenes with the international community since May. In early July CCIP met with NZ Registry Services to discuss this issue and determine who the most appropriate audience for this information would be. Because of the sensitivity of this it was determined that the NZNOG mailing list would not be appropriate as it is an open forum with over 800 registered participants. It was agreed that the best method would be to send this out to the ISPANZ members. CCIP also issued an embargoed release to some of the larger ISP's prior to the public release. CCIP regularly work very closely with the international CERT community to coordinate on the dissemination of information such as this and we have been working a lot over the last few weeks to coordinate on this particular release. CCIP had the release prepared to send out the morning that it was made public. This was a report that had been prepared in conjunction with the international CERT community. While it may appear that CCIP or other CERTs reporting is just simply re-badged products from another country it has often has been worked on collaboratively prior to the release. This is to ensure that clear and consistent messages are being issued by all countries. CCIP is hosting an international meeting here later in the year where a key item on the agenda is this specific event. There will be a review of this collaborative effort and where it worked well and where there is room for improvement. CCIP has identified that in New Zealand there is a need for a stronger relationship between CCIP and the NZ ISP community and developing those relationships is going to be an ongoing process. If you have any details of vulnerable DNS servers in New Zealand please do not hesitate to send these through to incidents(a)ccip.govt.nz. There have been some already sent through today from members of this list and those have been or are being addressed by the relevant ISP's and thank you for sending those through. If you would like to introduce yourself to CCIP and/or to arrange a time to come in to meet with CCIP please feel free to contact CCIP at (info(a)ccip.govt.nz). Regards, Paul. - -- Paul McKitrick Business Manager Centre for Critical Infrastructure Protection P: (+64) 4 498 7654 F: (+64) 4 498 7655 E: paul.mckitrick(a)ccip.govt.nz W: www.ccip.govt.nz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBSIlzyDpQQM+EFUs7AQKLqwgAyfn/HPnxWW3MQvyt6nPHQJwkTIk8slpK 0SoclMnIoyX7HxJhjFF8z369Bfece1xg/3kUE4D2d693lVv1Aih6LUIf/BrprppF iJJmZCXbf3n3y2ZSLembf+vDj/Ff1/JYFECDKLsJNjDESTd2i2X6EgeZGMXeR41p cwKVUoyrmWbdmBcsxHkwAjy8KBwBBIBzBiwkW7tKd9Ed5RhoIlVrkmWgrJrdvMDf aF28UUUP2aYRisHrZJnTwkw1Z3ghFp12emNj2EMJons0ZLPKLhV1vt573eeyqFYH deQ6BbYNqpzvNrqVewSE07kBY2t8SDf3wFs8sI+VoPinAV8HGyvUvg== =NmEG -----END PGP SIGNATURE----- --- This e-mail contains official New Zealand Government information, which is intended for the use of addressees only. If you have received this e-mail in error, please notify the sender immediately and delete. You should not further disseminate, distribute or copy this e-mail in any way. ---

4 4

Christchurch 5756
by Stan Rivett 27 Jul '08

27 Jul '08

Hi Guys Has anyone fired up anything new or changed channels on Saturday around the Christchurch CBD? I've been running my South facing AP happilly on 5756 MHz for about 4 years and now all my clients on this AP are pretty much toast :( Cheers Stan Rivett ------------------ Netspeed Data Ltd PO Box 5691 Dunedin P: +64 3 481 7245 F: +64 3 481 7249 C: +64 21 323 841 Skype: stan-r ------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 24 Jul '08

24 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64595 descr: Route set advertised to AS9439 by Learning Media - AS64595 members: 210.55.244.160/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: gary(a)learningmedia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040702 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64595 descr: advertised to AS9439 by LearningMedia - AS64595 members: 203.167.252.112/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: terry.moore(a)learningmedia.co.nz notify: gary.jarvis(a)learningmedia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080725 source: NZRR ------------------------------------------------------------

1 0

Fwd: [apnic-talk] [Apnic-announce] AS number change could affect Internet routing from 1 January 2009
by Neil Fenemor 24 Jul '08

24 Jul '08

A bit of an FYI. It may be worth members approaching their respective vendors to find out what the timelines are around this. ---------- Forwarded message ---------- From: <secretariat(a)apnic.net> Date: 2008/7/25 Subject: [apnic-talk] [Apnic-announce] AS number change could affect Internet routing from 1 January 2009 To: apnic-announce(a)apnic.net ________________________________________________________________________ AS number change could affect Internet routing from 1 January 2009 ________________________________________________________________________ Manufacturers urged to upgrade routers and network management software to support the use of four-byte Autonomous System numbers by 1 January 2009. Regional Internet Registries (RIRs), including Asia Pacific Network Information Centre (APNIC), have warned that routers and network management software should be upgraded ahead of the increased distribution of four-byte (also known as 32-bit) Autonomous System (AS) numbers. AS numbers are a vital part of the Internet's core routing system, the Border Gateway Protocol (BGP). With existing two-byte AS numbers predicted to run out in early 2011, RIRs will issue four-byte AS numbers by default (unless otherwise specifically requested) beginning 1 January 2009, as the next phase of a transition from two- to four-byte numbers. Following a globally coordinated policy, RIRs began allocating four-byte AS numbers by request only in January 2007; January 2009 marks the transition to allocating four-byte AS numbers by default. Without timely support from vendors, network operators risk having routers and network administration systems that won't accept the expanded four-byte number format. As such, the RIRs urge operators to verify their vendors' routers will support four-byte AS numbers. Geoff Huston, Chief Scientist at APNIC, expressed severe concerns over failure to prepare for four-byte AS numbers: "AS numbers are often used to identify external relationships, set routing attributes, and manage traffic. Learning from our current experiences with IPv6 preparation issues, Internet engineers designed four-byte AS numbers to be backward compatible with much of the installed network infrastructure. But new entrants and networks that are expanding or merging will need new AS numbers and as of 1 January 2009 these will be, by default, four-byte AS numbers. If router software and support systems in critical parts of the Internet's infrastructure aren't upgraded by January, we'll encounter some significant network routing problems. We're extremely concerned that a lot of routers and network management software out there cannot and will not be able to recognize four-byte AS numbers". An Autonomous System (AS) is a collection of networks, or routers, administered as a group sharing a common set of routing policies, each defined with a unique number, or AS number. Massive Internet growth has depleted the existing pool of two-byte AS numbers (65,536 numbers in total). As a result, engineers have expanded the AS number space from two bytes to four-bytes, to include over 4 billion AS numbers. Some routers do not currently support the use of four-byte AS numbers. To help vendors understand what they need to do to provide four-byte AS number support and to help network operators find products that support four-byte AS numbers, APNIC has set up a special website at: http://wiki.icons.apnic.net/display/ASN/Home Yours sincerely ________________________________________________________________________ APNIC Secretariat Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61 7 3858 3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net ________________________________________________________________________ _______________________________________________ Apnic-announce mailing list Apnic-announce(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-announce _______________________________________________ apnic-talk mailing list apnic-talk(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk

1 0

IPv6 Technical Workshops - PCH / Cisco
by Keith Davidson 24 Jul '08

24 Jul '08

All, InternetNZ, in conjunction with REANNZ, Cisco, Packet Clearing House, NZRS, auDA and FX Networks, is offering IPv6 technical workshops in Christchurch and Auckland. This follows on from having already run this workshop in Wellington in August last year. The first 5 day programme will run in Christchurch from Saturday 30 August to Wednesday 3 September, and the second in Auckland from Monday 8 September to Friday 12 September. Attendence on each course is limited to 28 participants. Registration is on a first come, first served basis. Please see the attached document for details. More details are available at http://blog.internetnz.net.nz/wp-content/uploads/2008/07/2008-augsep-ipv6-w… To register email richard at internetnz.net.nz To keep this message list-compliant, please note InternetNZ will possibly provide beer to workshop participants. Cheers Keith Davidson Executive Director - InternetNZ

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Jul '08

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS65531 descr: Route set advertised to AS9439 by parliament - AS65531 members: 202.22.16.0/23^23-29, 202.22.18.0/24^24-29, 202.22.23.0/24^24-29, 202.22.30.0/24^24-29, 202.49.210.0/24^24-29, 202.49.213.0/24^24-29, 203.97.200.0/24^24-29, 203.97.232.80/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: john.howell(a)parliament.govt.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051102 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS65531 descr: advertised to AS9439 by Parliamentary Service - AS65531 members: 202.22.16.0/21^21-29, 202.49.208.0/21^21-29, 202.22.24.0/22^22-29, 202.22.28.0/23^23-29, 202.22.30.0/24^24-29, 203.97.232.80/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: John.Howell(a)parliament.govt.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Jul '08

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17705 descr: advertised to AS9560 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 210.7.46.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080411 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17705 descr: advertised to AS9560 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 140.200.248.0/22^22-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 203.174.26.0/24^24-29, 210.7.46.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Jul '08

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS17705 descr: advertised to AS9439 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 210.7.46.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080410 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS17705 descr: advertised to AS9439 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 140.200.248.0/22^22-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 203.174.26.0/24^24-29, 210.7.46.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0