- NZNOG - lists.nznog.org

Virus Filtering by ISPs vs the need to receive security/abuse traffic
by Mark Foster 21 Jan '05

21 Jan '05

This is one that i've come across from time to time and often pondered myself - Obviously virus traffic can fluctuate up and down and become an annoyingly high percentage of an ISPs total mail load. Thus AV filtering which drops these messages is beneficial and can be provided as a benefit to customers, etc... So what happens to role accounts like, heaven forbid, abuse@ ? And for that matter, if the messages are dropped, is there any logged trace of the fact the message was sent in the first place? The reason I ask is that i've seen at least one ISP to whom i've reported viral infections to recently actually reject the report, because of the 'illegal file attatchment' (where the criteria used was the file extension... not even viral code within the attatchment)... So I had to manually copy/paste headers only to get my point across. The argument can be made that headers are all thats required, and that the actual payload isnt needed - but what if theres occaision where you want said payload? (To provide actual evidence of the infection, to identify what variant of the virus is infected, to help build filters ...?) Do ISPs out there regularly exclude their security team or at least build in means for one-off exceptions on an as-required basis? Do ISPs that drop viral (or suspected viral) traffic do anything to report said infection, or do they just drop the virus and pretend it never happened? (Doesn't actually fix the problem, does it...) Appreciate your thoughts. Mark.

4 5

I guess somebody needs a Beer.
by Simon Lyall 20 Jan '05

20 Jan '05

Sounds like a few people out there had a rough few days. I found this linked at the top of the paradise homepage. http://www2.paradise.net.nz/security_update/news.html Security Update Security issue - email and web hosting A small number of Paradise.net customers may have have experienced email delays and web-hosting problems on Thursday January 20th and Friday January 21st. Early Thursday morning some Paradise email was delayed. Our security people detected a security threat and disconnected a server to preserve the integrity of Paradise.net. This server will be reconnected shortly and backlogged email should be delivered this afternoon (Friday January 21). As part of our security precautions we also disconnected hardware which hosts Paradise web pages. We have been working round the clock to ensure the hardware can be reconnected with no risk to Paradise.net or Paradise users. We expect to restore web pages this evening. We know that an external party has attempted to interfere with Paradise.net. This attempt was picked up and immediate steps were taken to avoid any further impact on Paradise.net customers. Please accept our apologies for any inconvenience these very necessary steps have caused. Our approach, as always, is to take firm steps to preserve the security of Paradise.net and protect our customers. the team at Paradise.net -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

2 1

Mystery compound in beer fights cancer
by Andy Linton 20 Jan '05

20 Jan '05

Seems that research into this topic is warranted at NZNOG. http://www.newscientist.com/article.ns?id=dn6895

6 7

Notification of NZRR Database changes
by NZRR Database Notifications 20 Jan '05

20 Jan '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Fri, 21 Jan 2005 13:15:27 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0501211313160.7621(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW DELETED: route-set: AS9439:RS-ROUTES:AS23959 descr: Route set advertised to WIX by Catalyst-IT - AS23959 members: 202.49.159.0/24^24-29, 202.46.190.0/24^24-29, 202.20.6.0/24^24-29, 203.167.212.32/29, 203.167.247.160/29, 202.7.4.64/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: andrew(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040120 changed: rpsl-admin(a)nzix.net 20040628 source: NZRR

1 0

RE: [nznog] National BGP routing
by Gordon Smith 19 Jan '05

19 Jan '05

> Why are inconsistent AS-paths bad? Operationally, I mean. (I > hadn't had any operational mishaps in all my years at UUNET > because of inconsistent AS-paths, so I'm wondering if > something else causes an issue now?) > > Technically there is nothing wrong with them. As you > observed, it's simply an organisation multihoming using a > private ASN - hopefully their upstreams are stripping out the > private ASN before they propogate the originated prefixes > further. (Mind you, I find it rare for two ISPs to agree > which private ASN to use for a mutual customer to multihome - > often so much easier to obtain a real one.) > > And yes, people can quite easily use public ASNs. It's simply > a case of an APNIC member obtaining an ASN so their customer > can multihome. And that can't be too hard, right? > > philip > -- > Hi Philip, You're quite right. Technically, you can still be pass traffic to the client's endpoint, although the path selected may not be optimal. What can cause issues is if you then start creating routing policies on your route reflectors based on AS-path, especially if you don't have a direct peer with both of the providers that are carrying that customer's traffic. With multiple peering points, you can end up backhauling the traffic over your own links because the routing decisions passed via your IGP are no longer necessarily optimal e.g. I may wish to pass a 10Mbit stream from a Wellington customer to somewhere else in Wellington, via another provider, but the route reflectors see that destination as having a shorter AS path via Auckland. We don't have a destination AS that a metric can be applied to. We can of course apply different costs to the WAN links (and should have done), but the fine-grained control of traffic isn't achievable because the router can't be given much to go on. Policy routing and tagging is an option, but relies on the destination site, who is not necessarily a customer of ours, informing us of changes in their topology so our rules can be updated. APNIC have always been very good when it comes to getting ASN's; I've always found the justification of additional address space to be an ordeal though :-) In my opinion, it would be far more preferable if APNIC allocated an ASN when a customer was given an independent address assignment. After all, the reason that most want independantly allocated space is to multihome... Cheers, Gordon

3 2

National BGP routing
by Gordon Smith 18 Jan '05

18 Jan '05

I'm sure I can't be the only one that notices the BGP inconsistancies in their route tables.... Seeing the latest NZRR update prompted me to check the BGP tables again... We do not and will not accept route advertisements containing private AS numbers from our peers. The reason we don't is the same reason we don't route RFC1918 space externally... If a customer has their own address space and wants to multi-home, they should also have their own AS. Advertising up private AS numbers that should really remain within the network isn't a solution. Inconsistant AS-paths are bad enough, without creating additional problems... At least we're only seeing 5 class C's being advertised at the APE with inconsistant AS-paths at the moment. Perhaps BGP routing could be a topic for discussion at NZNOG 2005? Cheers, Gordon

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 18 Jan '05

18 Jan '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Wed, 19 Jan 2005 13:40:23 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0501191339480.4620(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS24226 descr: Route set advertised to AS9439 by Catalyst IT - AS24226 members: 202.46.190.0/24^24-29, 202.49.159.0/24^24-29, 202.20.6.0/24^24-29, 202.36.119.0/24^24-29, 210.48.47.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: david.zanetti(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS24226 descr: advertised to AS9439 by Catalyst IT - AS24226 members: 202.20.6.0/24^24-29, 202.36.119.0/24^24-29, 202.46.190.0/24^24-29, 202.49.159.0/24^24-29, 202.78.240.0/21^21-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: netadmin(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050119 source: NZRR --- PREVIOUS OBJECT: route: 202.20.6.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.zanetti(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route: 202.20.6.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: netadmin(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050119 source: NZRR --- PREVIOUS OBJECT: route: 202.36.119.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.zanetti(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route: 202.36.119.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: netadmin(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050119 source: NZRR --- PREVIOUS OBJECT: route: 202.46.190.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.zanetti(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route: 202.46.190.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: netadmin(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050119 source: NZRR --- PREVIOUS OBJECT: route: 202.49.159.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.zanetti(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route: 202.49.159.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: netadmin(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050119 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 18 Jan '05

18 Jan '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: rt(a)citylink.co.nz - Subject: [CityLink #1656] New Object for inclusion into the NZRR Route Registry (fwd) - Date: Wed, 19 Jan 2005 12:25:41 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0501191224520.4620(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64597 descr: advertised to AS9439 by Araneo - AS64597 members: 202.53.189.128/29, 210.48.101.64/27^27-29, 210.48.101.112/29, 210.48.109.224/27^27-29, 202.174.161.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: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041209 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64597 descr: advertised to AS9439 by Araneo - AS64597 members: 202.53.189.128/29, 210.48.101.64/27^27-29, 210.48.101.112/28^28-29, 210.48.109.224/27^27-29, 202.174.161.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: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041209 source: NZRR

1 0

Xtra in the SpamHaus SBL
by Peter Macaulay 17 Jan '05

17 Jan '05

I don't know if anyone from Xtra reads this list - trying to get through to anyone who has even an iota of understanding about this type of thing by phone appears to be almost impossible. Xtra has managed to get itself into the SBL realtime blocklist - http://www.spamhaus.org/sbl/sbl.lasso?query=SBL22816 It appears that someone objected to some promotional material sent out by the "House of Travel" travel agent group and has ended up blocking them; this means that one of Xtra's MX (mail exchanger) servers is now blocked by anyone who uses the SBL as a spam filter. If anyone knows anyone at Xtra who can do something about this, could you pass this message on? It's probably inconveniencing a reasonably large number of people. The NZNOG list would be a good place to post this too, I suppose, but I'm not a subscriber. Cheers! -- David -- ------------------ David Harris -+- Pegasus Mail ---------------------- Box 5451, Dunedin, New Zealand | e-mail: David.Harris(a)pmail.gen.nz Phone: +64 3 453-6880 | Fax: +64 3 453-6612 Phrase found in a Soviet Russian-English language guide: "Flying in the TU-114 I felt myself excellently." _______________________________________________ members-discuss mailing list members-discuss(a)internetnz.net.nz http://listserver.internetnz.net.nz/mailman/listinfo/members-discuss -- *Peter Macaulay* /Executive Director/ *InternetNZ */Direct +64 4 495 2113 Skype petermacaulay Mobile +64 21 488 485 /

6 5

(OT) Getting to NZNOG '05
by Jeremy Naylor 16 Jan '05

16 Jan '05

Hey guys, For people who want to know about how to get to the NZNOG '05 conference, you might want to catch the Overlander train that Tranz Scenic run. There's 2 every day (1 from Wellington - Auckland & 1 from Auckland - Wellington). You can get more info about these trains if you want to on Tranz Scenic's web site, at: http://www.tranzscenic.co.nz/services/overlander.aspx Hope this helps. Thanks, -- Jeremy Naylor p: +64 21 374 689 e: jeremy.naylor(a)r2.co.nz w: http://www.r2.co.nz/~jeremy w: http://e-living.wellington.net.nz -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004

3 2