- NZNOG - lists.nznog.org

Net4u - Stealing bandwidth etc.
by Liz Quilty 24 Mar '03

24 Mar '03

I worked for Sahil when he first started out. I left within 6 months because he didnt know anything about what the hell he was doing and kept fucking things up majorly. He was 15 at the time. I know of several other 'employees' whom did work and also did not get paid. His servers were rediculasly insecure and badley configured most of the time and he often made friends of other ISP's and tried getting customer databases. He would intentionally poach Users. Good that it has cought up with him ;] Liz

1 0

Re: Welcome to the "Nznog" mailing list
by Ste Taylor 24 Mar '03

24 Mar '03

the real url for the mp3 is here, do not distribute the non-offical copy http://ruediger.koeln.ccc.de/nz/Sahil_Explaining_All.mp3 Thank you Mr Lucas http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile.

1 0

Net4u - Stealing bandwidth etc.
by David Clarke 24 Mar '03

24 Mar '03

> It may have been an open web proxy only, not capable of > abusing SMTP or IRC. Quote from the Herald article: "He goes on to say that Net4U services, including his dial-up and server co-location customers, his "home link" and his "KaZaA" ... were all operated with stolen bandwidth for a "six-month" period." That reference to KaZaA would intimate that it wasn't merely web. Of course we possibly shouldn't believe the word of someone who'd stoop to stealing bandwidth. -- David Clarke Tech :wq #include <disclaimer.h>

4 3

Re: [nznog] Net4u - Stealing bandwidth etc.
by rye a 24 Mar '03

24 Mar '03

a staff member from net4u was bragging on irc the other day about the jetstream bandwidth issue. what they are doing is authenticating jetstream starter users (fastip) as jetstream users (fastipdirect). I think this is most likely a screwup on telecom/net4u's behalf.. perhaps their account manager set it up this way for a reason? perhaps net4u ask for jetstream ports instead of jetstream starter? either way guys, word of advice.. if your ripping people off.. dont go bragging about it on irc. I believe the staff member in question was only 14 years old. What possible use could he have been? He was also in the news recently, related to the captain bob spam fiasco.. cheers __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com

3 3

net4u staff spammer
by rye a 24 Mar '03

24 Mar '03

http://www.nzherald.co.nz/storydisplay.cfm?thesection=technology&thesubsect… The latter of the guys mentioned in the above story i believe works at net4u. He is the helpdesk manager. __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com

1 0

Net4u - Stealing bandwidth etc.
by Simon Lyall 24 Mar '03

24 Mar '03

Looks like the herald is breaking all the interesting stories lately: http://tinyurl.com/82j8 I can understand Callplus having problems since they have been struggling with inexperienced staff for a few months (although 6 months is before the most recent resignations) but I'm not sure how the Jetstream/Jetstart thing would have worked. I've yet to see Telecom lose money when people get Jetstream relms confused. -- Simon Lyall. | Newsmaster | Work: simon.lyall(a)ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon(a)darkmere.gen.nz Ihug Ltd, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz

6 6

Re: [nznog] Net4u - Stealing bandwidth etc.
by rye a 24 Mar '03

24 Mar '03

Its still very shocking that ISP's in new zealand would do this to each other.. I understand its a very tight market.. but still.. Are other isp's doing similar things? ha, i doubt anyone would admit it.. but i'd assume so.. Lets have a nationwide net4u boycot! ----- Original Message ----- From: "Matthew Poole" <matt(a)p00le.net> To: "Craig Spiers" <craig(a)concept.net.nz> Cc: <nznog(a)list.waikato.ac.nz> Sent: Tuesday, March 25, 2003 9:39 AM Subject: Re: [nznog] Net4u - Stealing bandwidth etc. > > > yea, you can imagine how many spammers would have found that proxy, and used > > it.. surely someone at attica/callplus got notification that it was open.. > > > Not while I was there. I've been gone three-and-a-half months now, > so it's quite possible they got told since then. > > > Spammers find open proxy's in a matter of hours these days.. perhaps staff > > recieved the notifications, but didnt give a dam? > > > Or they weren't able to figure out what the warning meant and ignored > it? > An open proxy would definitely have been brought to my attention as > all security issues came across my desk, and I never saw any such > notification. > > Not to mention that someone would've bitched if we'd been > blacklisted and while that did happen it was by a couple of companies > as a serious over-reaction to dodgy activity by customers. > -- > Matthew Poole > Auckland, NZ > > http://www.p00le.net > > "Three pills a day keeps the voices at bay" > Matthew Poole > > __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com

1 0

Heads up for anyone using SpamCop
by Aaron Nielsen 24 Mar '03

24 Mar '03

One of InternetNZ's servers is currently listed in SpamCop. Looks like a server in the UK processed a couple of the DNC's emails sent out to registrants :0 Aaron

1 0

RE: [nznog] "Captain Bob" and "^god"
by Stephen Andrew 22 Mar '03

22 Mar '03

----Original Message---- From: Juha Saarinen [mailto:juha(a)saarinen.org] Sent: Friday, 21 March 2003 10:36 AM To: Simon Lyall; nznog(a)list.waikato.ac.nz Subject: Re: [nznog] "Captain Bob" and "^god" [snip] > "The overheads are minimal. Captain Bob pays about $300 a month to > maintain his server. He runs a Jetstart account ($65) to connect to > his server which in turn connects to a high-capacity pipe out to the > web." > > Out to the Web? Not to mail servers? A lot of SPAM is now going through misconfigured proxy servers using the CONNECT method. Apparently open mail relays don't cut it any more. -- Andrew This email with any attachments is confidential and may be subject to legal privilege. If it is not intended for you please reply immediately, destroy it and do not copy, disclose or use it in any way.

5 4

"Captain Bob" and "^god"
by Juha Saarinen 21 Mar '03

21 Mar '03

http://tinyurl.com/7ut8 So that's what kids use their Jetstart connections for... ? -- Juha Saarinen

13 17

"Captain Bob" and "^god"
by Liz Quilty 21 Mar '03

21 Mar '03

Do something like mac addresses? so you can identify a computer rather than the person? make them log into a wan or something even? Liz Sure, that'd be a great method - wouldn't stop them completely though as they could always establish a new account under a false or someone elses name. Edward ----- Original Message ----- From: "Robert McDonald" <rob(a)nzpages.net> To: "Eon" <Eon(a)sli.net.nz>; "Stephen Judd" <nznog(a)vital.org.nz> Cc: <nznog(a)list.waikato.ac.nz> Sent: Friday, March 21, 2003 7:51 PM Subject: Re: [nznog] "Captain Bob" and "^god" IANAL (uses new catch phrase) Why not supply ALL the customers details (or as much as known) in a (forced to lower case) MD5SUM. Generaly they would not use the same username. If the telcos suplying DSL/other would take advice from the ISPs that the particular user was troublesome or breached a commonly agreed to T&C they would get their delivery method (what ever it may be) terminated. Having for instance your DSL line choped of, even for a month or two, would have a huge impact. IMHO, Rob On Fri, 21 Mar 2003 19:38, Eon wrote: > Why not MD5SUM the name of the user? Provide that to a list and any users > with the same MD5 > are not given service? Protects the privacy of people and sticks it to > those that Spam. I may not be the > best of internet users but even I agreee that spamers need to be stopped. > > Eon. -- -------------- Robert McDonald NZPages.Net Web Services Ph: 021 1770061 ICQ: 86984875 http://www.nzpages.net _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

key signing party at Uniforum
by Joe Abley 21 Mar '03

21 Mar '03

If I was to organise a PGP key signing party at the NZNOG/Uniforum meeting in July, would anybody here show up? Private replies welcome. Just trying to decide whether or not to bother trying :) [this is the kind of thing I am talking about: http://www.nanog.org/mtg-0110/pgp.html http://www1.ietf.org/mail-archive/ietf/Current/msg18089.html http://www.upenn.edu/computing/security/keyparty.html http://www.nluug.nl/events/sane98/keysigning-party.html in case the concept is not familiar]

3 2

Heads up - LOTR STreaming Event
by Richard Naylor 17 Mar '03

17 Mar '03

CityLink is assisting with the streaming of a Video Conference between Richard Taylor (Weta FX) and a number of schools on Wednesday. The event co-ordinators (TKI) have emailed a number of schools and hence this heads up. There is the potential for a large number of unicast streams from WIX on Wednesday morning 12 March between 10am and 11am. Here is the publicity material from TKI for those interested. Kia ora koutou TKI invites you to join us for the live video conference featuring Richard Taylor - the Oscar-winning special effects expert from the Lord of the Rings. This Wednesday between 10 and 11am, selected KAWM and Otago Net schools will be participating in a video-conference based conversation with Richard. To watch the live simulcast, click on the link below: http://www.tki.org.nz/r/school_improvement/climate/intro_taylor_e.php -------------- ABOUT THE VIDEO CONFERENCE The schools involved in the Richard Taylor video conference are: Turakina Maori Girls' College (Marton) Rotorua Lakes High (Rotorua) John Paul College (Rotorua) Rotorua Girls High (Rotorua) Mount Aspiring College (Wanaka) Te Waha o Rerekohu Area School (Gisborne) Te Wharekura o Rakaumanga (Huntly) Te Kura Kaupapa Maori o Mana Tamariki (Palmerston North) Each of the schools will make a presentation to Richard on the theme "special effects". The students were guided by activities suggested in a teaching resource developed by the Museum of New Zealand Te Papa Tongarewa to complement The Lord of the Rings Motion Picture Trilogy - The Exhibition. ------------ ABOUT RICHARD TAYLOR Richard Taylor is the co-founder and director of Weta Workshop Ltd, the special effects company best known for its work on The Lord of the Rings film trilogy. Weta designed and produced all the weapons, armour, creatures, makeup, and miniature models for the film production.

8 10

RE: [nznog] Netforum 2003 (and 2004??)
by Donald Neal 13 Mar '03

13 Mar '03

> From: Roger De Salis [mailto:roger(a)desalis.gen.nz] > Sent: Sunday, 9 March 2003 20:10 > To: nznog(a)list.waikato.ac.nz; members(a)uniforum.org.nz > Subject: [nznog] Netforum 2003 (and 2004??) > > > A quick update on the the conference this year... (mark your > diaries, get your management primed that you need to attend) > > When: [8?,9?]10/11/12 July, 2003 > Where: Waipuna Lodge, Mt Wellington, Auckland > Cost: NZ$695 for Three Days, discounts for early bird > registration, lesser for less time, extensive > student discounts...) <HEAD ABOVE PARAPET> Nobody's complained yet ... </HEAD ABOVE PARAPET> - Donald Neal > The lead international speakers who have accepted are:- > (and I have fully funded travel sponsorship for...) > > Evi Nemeth (ex University of Boulder Colorado, and ISC Director) > who has indicated she would like to talk about > "ISP measurement stuff regarding dns and the slow > and infinite denial of service attack that > bugs/ features/config-errors in microsoft > software are > doing to the root servers. - Plus other measurement stuff" > > Barry Raveendran Greene (Lead author of ISP practice manual > from Cisco) talking about advanced ISP tools and > techniques in use worldwide, current practices. > > Joe Abley (local boy made good) talking about Advanced mosquito > control in Canadian summers, and "what is it really like > to work for Paul Vixie...." ( I am certain he will > provide an alternative title to his talks..) > > I'm still looking for papers and interesting topics for discussion. > My plan is to make the conference so interesting to the ISP industry > that I can get 2Day.com to stump up for a bar contribution. > (Its a test....) > > The web-site and conference brochure will be out this week, and > I'll be forwarding a URL for a double sided Colour PDF for those > with colour printers, who need glossies to sell to management. > > =============================================================== > > 2004 Conference:- > > I do not mind whether we go to Waikato, or stay in Acukland > I have no problem with changes by popular demand. > I have provisional speaker acceptances for 2004 from > DJ Bernstein (thanks Simon for the excellent talks in 2002) > Jeff Doyle (Juniper Networks) > > Thanks for reading this far, more to follow. > > =================================================================== > ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

1 0

Why is PoB taking a dig at IANA?
by Andy Gardner 12 Mar '03

12 Mar '03

Why is PoB taking a dig at IANA? http://www.itu.int/itudoc/itu-t/workshop/cctld/cctld010.html -- Andrew P. Gardner Buffoons need love too.

2 1

TelstraClear appear to have fallen off APE
by Richard Haakma 12 Mar '03

12 Mar '03

Hello. It appears to me that TelstraClear seems to have fallen off APE about 1:15 this morning and are still not there at 3:00. I can't ping the ip address 192.203.154.32 nor 192.203.154.33. Regards, RH.

2 1

more on LOTR
by Richard Naylor 10 Mar '03

10 Mar '03

since someone just asked, last year the streams were in addition to the webcams. The webcams were averaging 500+ users all day and the streams carried a similar volume. overall we were shifting 130mbps. The video streams are NOT the webcams. They use mixers, cameras, lights etc like a tv production. The webcams are little things bolted to flimsy bits of buildings in high places. (why is it always like that?) rich

1 0

RE: [nznog] search.msn.co.nz
by Simon Byrnand 10 Mar '03

10 Mar '03

At 21:16 10/03/03 +1100, Nathan Mercer wrote: >-----Original Message----- >From: Juha Saarinen [mailto:juha(a)saarinen.org] >Sent: Monday, 10 March 2003 11:10 p.m. >To: Nathan Mercer; Simon Byrnand; Craig Whitmore > >Nathan Mercer <nmercer(a)microsoft.com> wrote: > > Hi Guys > > > > Thanks for the info, I passed it onto the MSN people offshore. > > Do you have any more information about how this error appears - are > > your customers clicking something in their browser, or linking off > > another website or something? > > > > I can't seem to get the error here on my PC (but I'm running IE6) > >$ dig search.msn.co.nz. a >;; ANSWER SECTION: >search.msn.co.nz. 3600 IN CNAME search.msn.ca. >search.msn.ca. 3600 IN A 207.68.185.57 >search.msn.ca. 3600 IN A 207.68.176.254 > >Yeah, no idea why its in aliased to .ca The MSN admin guy who replied >to me was from China, so go figure. It sounds like search.msn.co.nz >isn't being used by MSN any longer, and they can't figure out why users >are ending up there. They can't figure it out ? The "Search" button in the latest version of Internet Explorer (and probably older versions too) takes you there when you use "Find a Web Page". It also happens if you try to search from the address bar. (EG enter something that isn't a URL) Maybe their webdesigners should keep in touch with the IE development team ? :p Perhaps the Microsoft people that are trying to test the problem aren't in an area that gets redirected to "search.msn.co.nz". I'm not sure what method it uses to determine if you're in NZ, perhaps not everyone in NZ is considered to be "in NZ" by IE, and thus doesn't get directed to the NZ version of that page... (But browsing directly to the URL as Craig first indicated should be visible anywhere I would have thought...) Regards, Simon

4 8

Time for a change...
by Dean Pemberton 10 Mar '03

10 Mar '03

Hi all. Remember a while ago I posted a message here, saying I wanted to return to Wellington? Well it all turned out for the best. As of yesterday afternoon I no longer work for Juniper Networks. And in mid April I'll be starting at a new job in Wellington. So just a quick FAQ Q: I have a cellphone number for you is it still going to work. A: Nope - all my Juniper goods were confiscated yesterday. I do have a prepay cellphone in Australia at the moment, but after next month that will be useless too. If you think you will need to contact me in that time period, then drop me an email asking for the number. Q: Who do I call at 3 in the morning to ask about Juniper questions? A: Well if you happen to work for the company that I've just joined, then probably still me =) If not, and it's still urgent, then support(a)juniper.net is your friend. *note* I do still answer questions for beer or curry, just not at 3am Q: When do you arrive? What are your plans? A: I fly in on the 11th of Apr to start work on the 14th. I have to find a place to live. Other than that, I plan to eat curry on a thursday as is written in the good book =) Q: What are you doing in the meantime A: Packing mostly. I also have a pilots test to sit if the weather ever clears up (and they fix the alternator in the plane) =) Q: Does this mean that I/We can collect on the beer that you owe Me/Us? A: Who are you? Crank caller! Crank caller! Q: Ok - fess up - who are you working for A: TelstraClear. So I'll be seeing all the Wellington people in April - I expect a big turnout at the first Curry =) Later Dean

1 0

RE: [nznog] Re: ISP Regulation
by Frank March 09 Mar '03

09 Mar '03

I agree that NZNOG is not the right place to discuss these matters in depth. I will be posting a commentary (I dont think 'answer' is quite the right description) on Lin's points on the public-discuss(a)internetnz.net.nz tonight (I am sure others will do so as well) --- Frank March Senior Specialist Adviser, IT Policy Group Ministry of Economic Development, PO Box 1473, Wellington, New Zealand Phone (+64 4) 474 2908; Fax (+64 4) 474 2659; Mobile (+64) 21 042 9205 -----Original Message----- From: Lin Nah [mailto:lin(a)darkmere.gen.nz] Sent: Friday, 7 March 2003 15:17 To: nznog(a)list.waikato.ac.nz Cc: public-discuss(a)internetnz.net.nz Subject: [nznog] Re: ISP Regulation While nznog isn't the right forum for this discussion, I don't know what will be. InternetNZ does have a public discussion list. Would that be a good place for such discussions? Any suggestions? _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog http://www.govt.nz - connecting you to New Zealand central & local government services Any opinions expressed in this message are not necessarily those of the Ministry of Economic Development. This message and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivery to the intended recipient, be advised that you have received this message in error and that any use is strictly prohibited. Please contact the sender and delete the message and any attachment from your computer.

2 1

RE: [nznog] search.msn.co.nz
by Nathan Mercer 09 Mar '03

09 Mar '03

Thanks for the info, what OS are you running? IE6 on Windows XP doesn't seem to repro with the steps below, it goes to ie.search.msn.com Cheers Nathan -----Original Message----- From: Steve Winter [mailto:steve(a)roadshow.org] Sent: Tuesday, 11 March 2003 12:35 a.m. To: Nathan Mercer; nznog(a)list.waikato.ac.nz Nathan, > Thanks for the info, I passed it onto the MSN people offshore. > Do you have any more information about how this error appears - are > your > customers clicking something in their browser, or linking off another > website or something? On the tool bar, between the home button and the favorites button is a search button...when you click on it a pane appears to the left of your browser window, in which you can allegedly search, it has the options 'find a web page', 'previous searches', 'find a map', and 'look up a word', then a dialog box in which you can 'find a web page containing' It is then proudly 'Brought to you by MSN'...when you hit search you get the wonderfully useful 'Sorry, the system is not working properly.' error... > I can't seem to get the error here on my PC (but I'm running IE6) Well, I'm also using IE6 and it gives just the same results... :-( Cheers Steve

1 0

RE: [nznog] search.msn.co.nz
by Nathan Mercer 09 Mar '03

09 Mar '03

Hi Guys Thanks for the info, I passed it onto the MSN people offshore. Do you have any more information about how this error appears - are your customers clicking something in their browser, or linking off another website or something? I can't seem to get the error here on my PC (but I'm running IE6) Thanks Nathan Microsoft NZ -----Original Message----- From: Simon Byrnand [mailto:simon(a)igrin.co.nz] Sent: Monday, 10 March 2003 4:53 p.m. To: Craig Whitmore At 16:48 10/03/03 +1300, Craig Whitmore wrote: >Just a heads up.... > >Over the last couple days we have had a large number of calls saying when >people are searching for stuff on the net they are seeing a message saying > >"Sorry, the system is not working properly." > >It took us a short while while to figure it out, but its coming from >Microsoft when you do a search from the search button in MSIE. >search.msn.co.nz is giving that error. > >search.msn.co.nz = search.msn.ca (For some reason). I've emailed a few >people at Microsoft, but if anyone is listening from Microsoft. I first noticed it on Friday morning, so its been broken for a while now. (I assumed it was one of those things that would be fixed in a few minutes and didn't check it again until now....) Not a particularly informative error message either... Regards, Simon Byrnand iGRIN Internet _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3 2

RE: [nznog] search.msn.co.nz
by Nathan Mercer 09 Mar '03

09 Mar '03

-----Original Message----- From: Juha Saarinen [mailto:juha(a)saarinen.org] Sent: Monday, 10 March 2003 11:10 p.m. To: Nathan Mercer; Simon Byrnand; Craig Whitmore Nathan Mercer <nmercer(a)microsoft.com> wrote: > Hi Guys > > Thanks for the info, I passed it onto the MSN people offshore. > Do you have any more information about how this error appears - are > your customers clicking something in their browser, or linking off > another website or something? > > I can't seem to get the error here on my PC (but I'm running IE6) $ dig search.msn.co.nz. a ;; ANSWER SECTION: search.msn.co.nz. 3600 IN CNAME search.msn.ca. search.msn.ca. 3600 IN A 207.68.185.57 search.msn.ca. 3600 IN A 207.68.176.254 Yeah, no idea why its in aliased to .ca The MSN admin guy who replied to me was from China, so go figure. It sounds like search.msn.co.nz isn't being used by MSN any longer, and they can't figure out why users are ending up there.

2 1

Packet loss with Xtra
by David Mill 09 Mar '03

09 Mar '03

Hi, At the moment there seems to be severe packet loss when an Xtra dial-up customer (maybe other types of customers) connects to a TelstraClear connection. 20 - 40 % packet loss that is. It may also be a problem when an Xtra customer is connecting to other networks, I do not believe it is TelstraClear specific. Traceroute details (sorry if this doesn't look any good in plain text): merlin.inspire.net.nz Mon Mar 10 19:17:57 2003 Keys: D - Display mode R - Restart statistics Q - Quit Packets Pings Hostname %Loss Rcv Snt Last Best Avg Worst Y1. 203-79-89-47.inspire.net.nz 0% 71 71 0 0 0 2 2. g9-0-972.u21.tar.telstraclear.net 0% 71 71 5 4 6 91 3. 210-55-41-1.citylink.xtra.co.nz 0% 71 71 5 4 5 9 4. a9-0-0-3.XTRAK2-B1.xtra.co.nz 36% 46 71 83 37 47 83 5. v60.XTRAK1-B1.xtra.co.nz 43% 41 71 55 33 46 57 6. f5-0.ipa1-r16-5.xtra.co.nz 45% 39 71 47 33 51 96 7. 192.168.244.6 38% 44 71 63 49 72 100 8. 192.168.246.14 39% 43 71 116 47 74 116 9. 210-55-45-165.dialup.xtra.co.nz 31% 48 70 175 149 172 275 Can anyone on this list take a look at this, or point in the direction of the right person / phone number at Xtra to contact? Regards, David Mill

2 1

search.msn.co.nz
by Craig Whitmore 09 Mar '03

09 Mar '03

Just a heads up.... Over the last couple days we have had a large number of calls saying when people are searching for stuff on the net they are seeing a message saying "Sorry, the system is not working properly." It took us a short while while to figure it out, but its coming from Microsoft when you do a search from the search button in MSIE. search.msn.co.nz is giving that error. search.msn.co.nz = search.msn.ca (For some reason). I've emailed a few people at Microsoft, but if anyone is listening from Microsoft. Thanks Craig Whitmore Orcon Internet http://www.orcon.net.nz

2 1

Fw: [nznog] XTRA DNS Issues - anyone else?
by Brian Gibbons 09 Mar '03

09 Mar '03

>----- Original Message ----- >From: Dan Clark >If we update a record in our name server, ns1.clear.net.nz gets it pretty quickly >The problem appears to be anyone logged into XTRA or using their DNS >is there something different about the way their DNS servers operate? I would suggest that Xtra's servers are probably confused by the configuration of your name servers. A quick audit shows... For scarfies.co.nz the SRS (.co.nz) list two name servers ns1.scarfies.net ns3.scarfies.net "rootservers".net shows 5 Name Server delegations for scarfies.net ns1.scarfies.net ns2.scarfies.net ns3.scarfies.net ns2.zoneedit.com ns3.zoneedit.com ns1.scarfies.net returns two name servers as authorititive for scarfies.net ns1.scarfies.net (210.55.10.201) ns3.scarfies.net (210.54.31.84) ns3.scarfies.net lists only one authorititive name server for scarfies.net zues.scarfies.net (210.55.10.201) It does not list itself (by name) as Authorititive 210.55.10.201 resolves "ns1.scarfies.net" (itself) as 210.55.10.201 210.55.10.201 resolve "ns3.scarfies.net " as 210.54.31.84 210.54.31.84 (ns3.scarfies.net?) resolves "ns1.scarfies.net " as a CNAME for nemisis.scarfies.net (GULP!) with an IP address of 210.54.31.84 (this is the Opposite IP address) 210.55.10.201 resolves "zues.scarfies.net" as a CNAME for ns1.scarfies.net.nz this is a circular CNAME reference when included with the zone file on 210.54.31.84 210.55.10.201 (ns1.scarfies.net) resolves "nemesis.scarfies.net" to 210.54.31.84 210.55.10.201 (ns1.scarfies.net) resolves "zues.scarfies.net" as a CNAME for ns1.scarfies.net with an IP address of 210.55.10.201 this is difference answer from the other name server (which returned 210.54.31.84) 210.54.31.84 (ns3.scarfies.net?) returns no answers for a lookup of ns3.scarfies.net (Hmm) Perhaps a little tidyup might solve your problem @ Xtra Cheers BG

3 3

Netforum 2003 (and 2004??)
by Roger De Salis 09 Mar '03

09 Mar '03

A quick update on the the conference this year... (mark your diaries, get your management primed that you need to attend) When: [8?,9?]10/11/12 July, 2003 Where: Waipuna Lodge, Mt Wellington, Auckland Cost: NZ$695 for Three Days, discounts for early bird registration, lesser for less time, extensive student discounts...) The lead international speakers who have accepted are:- (and I have fully funded travel sponsorship for...) Evi Nemeth (ex University of Boulder Colorado, and ISC Director) who has indicated she would like to talk about "ISP measurement stuff regarding dns and the slow and infinite denial of service attack that bugs/ features/config-errors in microsoft software are doing to the root servers. - Plus other measurement stuff" Barry Raveendran Greene (Lead author of ISP practice manual from Cisco) talking about advanced ISP tools and techniques in use worldwide, current practices. Joe Abley (local boy made good) talking about Advanced mosquito control in Canadian summers, and "what is it really like to work for Paul Vixie...." ( I am certain he will provide an alternative title to his talks..) I'm still looking for papers and interesting topics for discussion. My plan is to make the conference so interesting to the ISP industry that I can get 2Day.com to stump up for a bar contribution. (Its a test....) The web-site and conference brochure will be out this week, and I'll be forwarding a URL for a double sided Colour PDF for those with colour printers, who need glossies to sell to management. =============================================================== 2004 Conference:- I do not mind whether we go to Waikato, or stay in Acukland I have no problem with changes by popular demand. I have provisional speaker acceptances for 2004 from DJ Bernstein (thanks Simon for the excellent talks in 2002) Jeff Doyle (Juniper Networks) Thanks for reading this far, more to follow. =================================================================== Rgds Roger De Salis -- \_ Roger De Salis rdesalis(a)fx.net.nz </' FX Networks +64 25 481 452 /) Wellington, New Zealand roger(a)desalis.gen.nz (/ ` DSL - the 56k modem technology of 2004

4 3

XTRA DNS Issues - anyone else?
by Dan Clark 09 Mar '03

09 Mar '03

Hi All, Just before I go and call the XTRA Help Desk I thought I might check weather or not anyone else is noticing a similar problem... For example if we update a record in our name server, ns1.clear.net.nz gets it pretty quickly similar situation to 203.109.252.42 (Ihug). The problem appears to be anyone logged into XTRA or using their DNS, is there something different about the way their DNS servers operate? They just dont seem to get updated records for days sometimes. Please excuse me if this post is inappropriate. Kind Regards Dan Clark Network Manager Scarfies.Net Ltd

2 1

Networkers
by Michael Newbery 06 Mar '03

06 Mar '03

Anyone else going to Networkers in Brisbane next week? See you there. -- Michael Newbery IP Architect TelstraClear Limited

1 0

Zone Push Time table Review
by Nick Griffin 06 Mar '03

06 Mar '03

*ZONE PUSH REVIEW* The response to the request for comment on the .nz Zone Push timetable was extremely positive. I received many recommendations in regards the Zone Push review. taking those recommendations into account I am pleased to advise that from Monday 31st March 2003 the Zone Push Timetable will be started at the following NZ local times: 05:00 09:00 12:00 15:00 18:00 22:00 This notice will also be published on the NZRS website, DNC website, the SRS newsletter and the NZNOG. if there are any questions regarding the Zone push timetable please email , zonepush(a)nzrs.net.nz cheers Nick Nick Griffin Registry Manager .nz Registry Services PO Box 24361 Wellington New Zealand e nick.griffin(a)nzrs.net.nz <mailto:nick.griffin(a)nzrs.net.nz> m 64 21 505 229 p 64 4 931 6977 f 64 4 931 6979 w www.nzrs.net.nz <http://www.nzrs.net.nz> CAUTION : This Email message and accompanying data may contain information that is confidential and subject to privilege. If you are not the intended recipient, you are notified that any use, dissemination, distribution or copying of this message or data is prohibited. If you have received this Email in error, please notify me immediately and delete all material pertaining to this Email. Thank you.

1 0

Fwd: [public-discuss] ISP Regulation
by David Farrar 06 Mar '03

06 Mar '03

I was unsure about forwarding this on here as it is a judgement call how close to an operational issue this is, but the potential effects of legislation have significant operational issues so I hope no-one objects. Also rather concerned that the mainstream media reports on the select committee inquiry have only focused on the increased penalties for child porn with almost no reference to the quite significant talk of licensing and regulating ISPs, so that many ISPs may be unaware of what has been proposed. If discussion is off-topic for here then public-discuss(a)internetnz.net.nz is certainly a suitable and open to all forum. DPF Forwarded Message: > From: David Farrar <david(a)farrar.com> > Subject: [public-discuss] ISP Regulation > Date: Wed, 5 Mar 2003 22:15:52 GMT > ----- > Some major issues for InternetNZ and the industry with the report back of the > inquiry into Films, Videos and Publications Classification Act. The report is > at http://www.clerk.parliament.govt.nz/Content/SelectCommitteeReports/i5a.pdf. > It is 90- pages long - the Internet related stuff is from page 55 on. > > Law Commission mades a good point in comparing attempts to have the Act deal > with the Internet as being like King Canute stopping the tide. The Committee > reports the problems with the Australian model but shows some sympathy for the > scheme. > > They specifically say "Despite our reservations about the Australian model, we > consider the only effective way to police objectionable material emanating from > outside New Zealand is by placing obligations on ISPs that operate in NZ ..." > > "We also consider a code of practice would ensure all ISPs give customers > information on how to best protect their families from exposure to internet > content such as objectionable material, making sure ISPs provide clear and > consistent terms and conditions consumers can understand. ... we would > support ISPs being required to provide to their customers acceptable or > approved filtering software products." > > They also say "We would like the Government to provide such filterware free of > charge to Internet users" > > On a Code of Practice, they state: > > "We consider the Government should work with key ISPs to develop a code of > practice for all ISPs. We consider industry compliance with a COP shoual, as a > first step, be voluntary, but if necessary we would support legislation to > enforce compliance by ISPs. There may be a need for ISPs to be licensed or > registered in order to control their behaviour." > > "We note InternetNZ recently approved a $40,000 plan to redraft and relaunch a > draft code following a new round of industry consultation. The draft, we > understand, has been on the table since 1999 but certain key players such as > Xtra have refused to buy in to such a code of practice. We hope the industry > will take up this challenge to develop a code and the notion of responsible > self regulation." > > > The upcoming InternetNZ summit in May 2003 may be an opportune forum to discuss > an industry response to the report of the Select Committee. I don't think > anyone wants us to go down the Australian approach (which even the Aust Govt > admits has failed), but if we don't do something the status quo doesn't look > very viable. > > > DPF > > > _______________________________________________ > public-discuss mailing list > public-discuss(a)internetnz.net.nz > http://listserver.internetnz.net.nz/mailman/listinfo/public-discuss >

2 1

Mailserver re-encoding of attachments valid ?
by Simon Byrnand 05 Mar '03

05 Mar '03

Hi All, While trying to help a customer that was having trouble receiving specific attachments through our mailserver, but which seemed to be received ok through another ISP's mailserver, I came across an interesting thing.... It turned out that the troublesome attachments were in UUENCODE format, and something about the way the customers own mailserver/client machines were set up were causing them problems... The strange thing was, that the same message sent through another well known ISP was being received, seemingly with no problems getting the attachment. A bit of investigation found that while our server was passing the UUENCODE'ed attachment through as-is, the other ISP is decoding the UUENCODE'ed attachment, and re-attaching it in the more common BASE64 Mime attachment type. Now I havn't looked through RFC's exhuastively, but I was under the impression that although mailservers are allowed to add their own Headers, etc, they must NOT alter the message body of a message. (Or at least, "Should not") Is this decoding of attachments and re-encoding/attaching them in a different format breaking the RFC's ? Just wondering... :) Regards, Simon Byrnand iGRIN Internet

3 2

FW: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail
by Tony Wicks 03 Mar '03

03 Mar '03

Just incase people havn't seen this ! > -----Original Message----- > From: CERT Advisory [mailto:cert-advisory(a)cert.org] > Sent: Tuesday, March 04, 2003 7:07 AM > To: cert-advisory(a)cert.org > Subject: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail > > Original release date: March 3, 2003 > Last revised: -- > Source: CERT/CC > > A complete revision history can be found at the end of this file. > > Systems Affected > > * Sendmail Pro (all versions) > * Sendmail Switch 2.1 prior to 2.1.5 > * Sendmail Switch 2.2 prior to 2.2.5 > * Sendmail Switch 3.0 prior to 3.0.3 > * Sendmail for NT 2.X prior to 2.6.2 > * Sendmail for NT 3.0 prior to 3.0.3 > * Systems running open-source sendmail versions prior to 8.12.8, > including UNIX and Linux systems > > Overview > > There is a vulnerability in sendmail that may allow remote attackers > to gain the privileges of the sendmail daemon, typically root. > > I. Description > > Researchers at Internet Security Systems (ISS) have discovered a > remotely exploitable vulnerability in sendmail. This vulnerability > could allow an intruder to gain control of a vulnerable sendmail > server. > > Most organizations have a variety of mail transfer agents (MTAs) at > various locations within their network, with at least one exposed to > the Internet. Since sendmail is the most popular MTA, most > medium-sized to large organizations are likely to have at least one > vulnerable sendmail server. In addition, many UNIX and Linux > workstations provide a sendmail implementation that is enabled and > running by default. > > This vulnerability is message-oriented as opposed to > connection-oriented. That means that the vulnerability is triggered by > the contents of a specially-crafted email message rather than by > lower-level network traffic. This is important because an MTA that > does not contain the vulnerability will pass the malicious message > along to other MTAs that may be protected at the network level. In > other words, vulnerable sendmail servers on the interior of a network > are still at risk, even if the site's border MTA uses software other > than sendmail. Also, messages capable of exploiting this vulnerability > may pass undetected through many common packet filters or firewalls. > > Sendmail has indicated to the CERT/CC that this vulnerability has been > successfully exploited in a laboratory environment. We do not believe > that this exploit is available to the public. However, this > vulnerability is likely to draw significant attention from the > intruder community, so the probability of a public exploit is high. > > A successful attack against an unpatched sendmail system will not > leave any messages in the system log. However, on a patched system, an > attempt to exploit this vulnerability will leave the following log > message: > > Dropped invalid comments from header address > > Although this does not represent conclusive evidence of an attack, it > may be useful as an indicator. > > A patched sendmail server will drop invalid headers, thus preventing > downstream servers from receiving them. > > The CERT/CC is tracking this issue as VU#398025. This reference number > corresponds to CVE candidate CAN-2002-1337. > > For more information, please see > > http://www.sendmail.org > http://www.sendmail.org/8.12.8.html > http://www.sendmail.com/security/ > http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21950 > http://www.kb.cert.org/vuls/id/398025 > > II. Impact > > Successful exploitation of this vulnerability may allow an attacker to > gain the privileges of the sendmail daemon, typically root. Even > vulnerable sendmail servers on the interior of a given network may be > at risk since the vulnerability is triggered from the contents of a > malicious email message. > > III. Solution > > Apply a patch from Sendmail > > Sendmail has produced patches for versions 8.9, 8.10, 8.11, and 8.12. > However, the vulnerability also exists in earlier versions of the > code; therefore, site administrators using an earlier version are > encouraged to upgrade to 8.12.8. These patches are located at > > ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.security.cr.patch > > ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.11.6.security.cr.patch > > ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.9.3.security.cr.patch > > Apply a patch from your vendor > > Many vendors include vulnerable sendmail servers as part of their > software distributions. We have notified vendors of this vulnerability > and recorded their responses in the systems affected section of > VU#398025. Several vendors have provided a statement for direct > inclusion in this advisory; these statements are available in Appendix > A. > > Enable the RunAsUser option > > There is no known workaround for this vulnerability. Until a patch can > be applied, you may wish to set the RunAsUser option to reduce the > impact of this vulnerability. As a good general practice, the CERT/CC > recommends limiting the privileges of an application or service > whenever possible. > > Appendix A. - Vendor Information > > This appendix contains information provided by vendors for this > advisory. As vendors report new information to the CERT/CC, we will > update this section and note the changes in our revision history. If a > particular vendor is not listed below, we have not received their > comments. > > Apple Computer, Inc. > > Security Update 2003-03-03 is available to fix this issue. Packages > are available for Mac OS X 10.1.5 and Mac OS X 10.2.4. It should be > noted that sendmail is not enabled by default on Mac OS X, so only > those systems which have explicitly enabled it are susceptible to the > vulnerability. All customers of Mac OS X, however, are encouraged to > apply this update to their systems. > > Avaya, Inc. > > Avaya is aware of the vulnerability and is investigating impact. As > new information is available this statement will be updated. > > BSD/OS > > Wind River Systems has created patches for this problem which are > available from the normal locations for each release. The relevant > patches are M500-006 for BSD/OS version 5.0 or the Wind River Platform > for Server Appliances 1.0, M431-002 for BSD/OS 4.3.1, or M420-032 for > BSD/OS 4.2 systems. > > Cisco Systems > > Cisco is investigating this issue. If we determine any of our products > are vulnerable that information will be available at: > http://www.cisco.com/go/psirt > > Cray Inc. > > The code supplied by Cray, Inc. in Unicos, Unicos/mk, and Unicos/mp > may be vulnerable. Cray has opened SPRs 724749 and 724750 to > investigate. > > Cray, Inc. is not vulnerable for the MTA systems. > > Hewlett-Packard Company > > SOURCE: > Hewlett-Packard Company > HP Services > Software Security Response Team > > x-ref: SSRT3469 sendmail > > HP will provide notice of the availability of patches through standard > security bulletin announcements and be available from your normal HP > Services support channel. > > IBM Corporation > > The AIX operating system is vulnerable to the sendmail issues > discussed in releases 4.3.3, 5.1.0 and 5.2.0. > > A temporary patch is available through an efix package which can be > found at > ftp://ftp.software.ibm.com/aix/efixes/security/sendmail_efix.tar.Z > > IBM will provide the following official fixes: > > APAR number for AIX 4.3.3: IY40500 (available approx. > 03/12/2003) > APAR number for AIX 5.1.0: IY40501 (available approx. > 04/28/2003) > APAR number for AIX 5.2.0: IY40502 (available approx. > 04/28/2003) > > Openwall GNU/*/Linux > > Openwall GNU/*/Linux is not vulnerable. We use Postfix as the MTA, not > sendmail. > > Red Hat Inc. > > Updated sendmail packages that are not vulnerable to this issue are > available for Red Hat Linux, Red Hat Advanced Server, and Red Hat > Advanced Workstation. Red Hat Network users can update their systems > using the 'up2date' tool. > > Red Hat Linux: > > http://rhn.redhat.com/errata/RHSA-2003-073.html > > Red Hat Linux Advanced Server, Advanced Workstation: > > http://rhn.redhat.com/errata/RHSA-2003-074.html > > SGI > > SGI acknowledges VU#398025 reported by CERT and has released an > advisory to address the vulnerability on IRIX. > > Refer to SGI Security Advisory 20030301-01-P available from > ftp://patches.sgi.com/support/free/security/advisories/20030301-01-P > or http://www.sgi.com/support/security/. > > The Sendmail Consortium > > The Sendmail Consortium suggests that sites upgrade to 8.12.8 if > possible. Alternatively, patches are available for 8.9, 8.10, 8.11, > and 8.12 on http://www.sendmail.org/ > > Sendmail, Inc. > > All commercial releases including Sendmail Switch, Sendmail Advanced > Message Server (which includes the Sendmail Switch MTA), Sendmail for > NT, and Sendmail Pro are affected by this issue. Patch information is > available at http://www.sendmail.com/security. > _________________________________________________________________ > > Our thanks to Internet Security Systems, Inc. for discovering this > problem, and to Eric Allman, Claus Assmann, and Greg Shapiro of > Sendmail for notifying us of this problem. We thank both groups for > their assistance in coordinating the response to this problem. > _________________________________________________________________ > > Authors: Jeffrey P. Lanza and Shawn V. Hernan > ______________________________________________________________________ > > This document is available from: > http://www.cert.org/advisories/CA-2003-07.html > ______________________________________________________________________ > > CERT/CC Contact Information > > Email: cert(a)cert.org > Phone: +1 412-268-7090 (24-hour hotline) > Fax: +1 412-268-6989 > Postal address: > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh PA 15213-3890 > U.S.A. > > CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / > EDT(GMT-4) Monday through Friday; they are on call for emergencies > during other hours, on U.S. holidays, and on weekends. > > Using encryption > > We strongly urge you to encrypt sensitive information sent by email. > Our public PGP key is available from > http://www.cert.org/CERT_PGP.key > > If you prefer to use DES, please call the CERT hotline for more > information. > > Getting security information > > CERT publications and other security information are available from > our web site > http://www.cert.org/ > > To subscribe to the CERT mailing list for advisories and bulletins, > send email to majordomo(a)cert.org. Please include in the body of your > message > > subscribe cert-advisory > > * "CERT" and "CERT Coordination Center" are registered in the U.S. > Patent and Trademark Office. > ______________________________________________________________________ > > NO WARRANTY > Any material furnished by Carnegie Mellon University and the Software > Engineering Institute is furnished on an "as is" basis. Carnegie > Mellon University makes no warranties of any kind, either expressed or > implied as to any matter including, but not limited to, warranty of > fitness for a particular purpose or merchantability, exclusivity or > results obtained from use of the material. Carnegie Mellon University > does not make any warranty of any kind with respect to freedom from > patent, trademark, or copyright infringement. > _________________________________________________________________ > > Conditions for use, disclaimers, and sponsorship information > > Copyright 2003 Carnegie Mellon University. > > Revision History > Mar 03, 2003: Initial release > > -----BEGIN PGP SIGNATURE----- > Version: PGP 6.5.8 > > iQCVAwUBPmOZEWjtSoHZUTs5AQGNUwP/YC0aRMqrFoLxUjG9pZIOBb98z8BFPfTW > w/5u09rcW7WpH52XGaOWbu9PYtnLKtPaMrwevc38r6ILvZywasxdpUcUtR4W9XPZ > 9EW4LYB1EaU81PLpzkQXWkVAhlX4vgHTU75oEcjfsacxXHlxtMYM1JpmyO8gvlnl > pD4vLdvJqHE= > =PfHu > -----END PGP SIGNATURE----- >

1 1

Orcon Internet Prefix List Update (2003-3-4)
by Craig Whitmore 03 Mar '03

03 Mar '03

For all those peering with Orcon Internet (AS17746) Nationally, please update your Prefix Lists to add the Following Networks ip prefix-list orcon-national permit 219.88.128.0/20 le 24 A full Cisco Prefix List is attached. Thanks Craig Whitmore Orcon Internet http://www.orcon.net.nz

1 0

.geek.nz - last day to vote
by Dean Pemberton 03 Mar '03

03 Mar '03

The vote is drawing to a close. If you still want to have a say then here is the page Closes at midnight. http://vote.internetnz.net.nz/ Dean

1 0

CCIP EXTERNAL ADVISORY REDISTRIBUTION: Remote Sendmail HeaderProcessing Vulnerability
by Andrew Evans 03 Mar '03

03 Mar '03

A little heads up for those running sendmail. Information on the vulnerability was released at around 6:30am NZT. Note that this vulnerability is message oriented, i.e. an exploit can be contained in the body of an email message. CCIP EXTERNAL ADVISORY REDISTRIBUTION ---------------- Start of External Reference --------------- CERT® Advisory CA-2003-07 Remote Buffer Overflow in Sendmail Original release date: March 3, 2003 Last revised: -- Source: CERT/CC A complete revision history can be found at the end of this file. Systems Affected * Sendmail Pro (all versions) * Sendmail Switch 2.1 prior to 2.1.5 * Sendmail Switch 2.2 prior to 2.2.5 * Sendmail Switch 3.0 prior to 3.0.3 * Sendmail for NT 2.X prior to 2.6.2 * Sendmail for NT 3.0 prior to 3.0.3 * Systems running open-source sendmail versions prior to 8.12.8, including UNIX and Linux systems Overview There is a vulnerability in sendmail that may allow remote attackers to gain the privileges of the sendmail daemon, typically root. I. Description Researchers at Internet Security Systems (ISS) have discovered a remotely exploitable vulnerability in sendmail. This vulnerability could allow an intruder to gain control of a vulnerable sendmail server. Most organizations have a variety of mail transfer agents (MTAs) at various locations within their network, with at least one exposed to the Internet. Since sendmail is the most popular MTA, most medium-sized to large organizations are likely to have at least one vulnerable sendmail server. In addition, many UNIX and Linux workstations provide a sendmail implementation that is enabled and running by default. This vulnerability is message-oriented as opposed to connection-oriented. That means that the vulnerability is triggered by the contents of a specially-crafted email message rather than by lower-level network traffic. This is important because an MTA that does not contain the vulnerability will pass the malicious message along to other MTAs that may be protected at the network level. In other words, vulnerable sendmail servers on the interior of a network are still at risk, even if the site's border MTA uses software other than sendmail. Also, messages capable of exploiting this vulnerability may pass undetected through many common packet filters or firewalls. Sendmail has indicated to the CERT/CC that this vulnerability has been successfully exploited in a laboratory environment. We do not believe that this exploit is available to the public. However, this vulnerability is likely to draw significant attention from the intruder community, so the probability of a public exploit is high. A successful attack against an unpatched sendmail system will not leave any messages in the system log. However, on a patched system, an attempt to exploit this vulnerability will leave the following log message: Dropped invalid comments from header address Although this does not represent conclusive evidence of an attack, it may be useful as an indicator. A patched sendmail server will drop invalid headers, thus preventing downstream servers from receiving them. The CERT/CC is tracking this issue as VU#398025. This reference number corresponds to CVE candidate CAN-2002-1337. For more information, please see http://www.sendmail.org http://www.sendmail.org/8.12.8.html http://www.sendmail.com/security/ http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21950 http://www.kb.cert.org/vuls/id/398025 II. Impact Successful exploitation of this vulnerability may allow an attacker to gain the privileges of the sendmail daemon, typically root. Even vulnerable sendmail servers on the interior of a given network may be at risk since the vulnerability is triggered from the contents of a malicious email message. III. Solution Apply a patch from Sendmail Sendmail has produced patches for versions 8.9, 8.10, 8.11, and 8.12. However, the vulnerability also exists in earlier versions of the code; therefore, site administrators using an earlier version are encouraged to upgrade to 8.12.8. These patches are located at ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.security.cr.patch ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.11.6.security.cr.patch ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.9.3.security.cr.patch Apply a patch from your vendor Many vendors include vulnerable sendmail servers as part of their software distributions. We have notified vendors of this vulnerability and recorded their responses in the systems affected section of VU#398025. Several vendors have provided a statement for direct inclusion in this advisory; these statements are available in Appendix A. Enable the RunAsUser option There is no known workaround for this vulnerability. Until a patch can be applied, you may wish to set the RunAsUser option to reduce the impact of this vulnerability. As a good general practice, the CERT/CC recommends limiting the privileges of an application or service whenever possible. Appendix A. - Vendor Information This appendix contains information provided by vendors for this advisory. As vendors report new information to the CERT/CC, we will update this section and note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments. Apple Computer, Inc. Security Update 2003-03-03 is available to fix this issue. Packages are available for Mac OS X 10.1.5 and Mac OS X 10.2.4. It should be noted that sendmail is not enabled by default on Mac OS X, so only those systems which have explicitly enabled it are susceptible to the vulnerability. All customers of Mac OS X, however, are encouraged to apply this update to their systems. Avaya, Inc. Avaya is aware of the vulnerability and is investigating impact. As new information is available this statement will be updated. BSD/OS Wind River Systems has created patches for this problem which are available from the normal locations for each release. The relevant patches are M500-006 for BSD/OS version 5.0 or the Wind River Platform for Server Appliances 1.0, M431-002 for BSD/OS 4.3.1, or M420-032 for BSD/OS 4.2 systems. Cisco Systems Cisco is investigating this issue. If we determine any of our products are vulnerable that information will be available at: http://www.cisco.com/go/psirt Cray Inc. The code supplied by Cray, Inc. in Unicos, Unicos/mk, and Unicos/mp may be vulnerable. Cray has opened SPRs 724749 and 724750 to investigate. Cray, Inc. is not vulnerable for the MTA systems. Hewlett-Packard Company SOURCE: Hewlett-Packard Company HP Services Software Security Response Team x-ref: SSRT3469 sendmail HP will provide notice of the availability of patches through standard security bulletin announcements and be available from your normal HP Services support channel. IBM Corporation The AIX operating system is vulnerable to the sendmail issues discussed in releases 4.3.3, 5.1.0 and 5.2.0. A temporary patch is available through an efix package which can be found at ftp://ftp.software.ibm.com/aix/efixes/security/sendmail_efix.tar.Z IBM will provide the following official fixes: APAR number for AIX 4.3.3: IY40500 (available approx. 03/12/2003) APAR number for AIX 5.1.0: IY40501 (available approx. 04/28/2003) APAR number for AIX 5.2.0: IY40502 (available approx. 04/28/2003) Openwall GNU/*/Linux Openwall GNU/*/Linux is not vulnerable. We use Postfix as the MTA, not sendmail. Red Hat Inc. Updated sendmail packages that are not vulnerable to this issue are available for Red Hat Linux, Red Hat Advanced Server, and Red Hat Advanced Workstation. Red Hat Network users can update their systems using the 'up2date' tool. Red Hat Linux: http://rhn.redhat.com/errata/RHSA-2003-073.html Red Hat Linux Advanced Server, Advanced Workstation: http://rhn.redhat.com/errata/RHSA-2003-074.html SGI SGI acknowledges VU#398025 reported by CERT and has released an advisory to address the vulnerability on IRIX. Refer to SGI Security Advisory 20030301-01-P available from ftp://patches.sgi.com/support/free/security/advisories/20030301-01-P or http://www.sgi.com/support/security/. The Sendmail Consortium The Sendmail Consortium suggests that sites upgrade to 8.12.8 if possible. Alternatively, patches are available for 8.9, 8.10, 8.11, and 8.12 on http://www.sendmail.org/ Sendmail, Inc. All commercial releases including Sendmail Switch, Sendmail Advanced Message Server (which includes the Sendmail Switch MTA), Sendmail for NT, and Sendmail Pro are affected by this issue. Patch information is available at http://www.sendmail.com/security. Our thanks to Internet Security Systems, Inc. for discovering this problem, and to Eric Allman, Claus Assmann, and Greg Shapiro of Sendmail for notifying us of this problem. We thank both groups for their assistance in coordinating the response to this problem. Authors: Jeffrey P. Lanza and Shawn V. Hernan This document is available from: http://www.cert.org/advisories/CA-2003-07.html CERT/CC Contact Information Email: cert(a)cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo(a)cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. Conditions for use, disclaimers, and sponsorship information Copyright 2003 Carnegie Mellon University. Revision History Mar 03, 2003: Initial release ---------------- End of External Reference --------------- CCIP only issues those external alerts that we assess as serious and would affect a large number of NZ users. For notification of all discovered software vulnerabilities we recommend that you subscribe to a commercial Computer Emergency Response Team or to vendor alert lists. The CCIP also maintains a list of the more recent mainstream alerts and advisories at: http://www.ccip.govt.nz/alerts-advisories/alerts-advisories.htm While this advisory is accurate to the best of our knowledge, CCIP does not accept any responsibility for errors or omissions. If the vulnerability affects you, you are advised to ensure that you have the most current information available. CCIP will not be liable for any loss or damage howsoever caused, arising from or in connection with the use of information contained in this advisory. Reference in this advisory in any manner to any commercial product, process or service does not constitute or imply its endorsement or recommendation by CCIP. Views and opinions expressed herein may not be used for advertising or product endorsement purposes. Please refer to the CCIP web site (www.ccip.govt.nz) for a complete list of recent alerts and advisories. Issued by: Watch Centre, Centre for Critical Infrastructure Protection, P O Box 12-209, Wellington. Internet: www.ccip.govt.nz E-mail: alerts(a)ccip.govt.nz Tel: +64 4 498 7654 Fax: +64 4 498 7655

1 0

RBL's used
by Craig Whitmore 28 Feb '03

28 Feb '03

As the amount of spam grows as the internet grows bigger, using RBL's is growing as well (to try and stop/slow the spam). I am wondering what RBL's other ISP's/Companies in NZ Use? There are quite a number (of RBL's) but a few can't be used as they still have Xtra's Network in them (for "Sueing ORBS" they say), but the best I've found so far has been http://relays.osirusoft.com. Can anyone suggest a better one/comments/pitfalls on using RBL's for slowing down spam. Thanks Craig Whitmore Orcon Internet http://www.nzdsl.co.nz

16 27

Re: [nznog] RBL's used
by Michael Newbery 27 Feb '03

27 Feb '03

At 5:24 PM -0800 27/2/03, Chris Wedgwood wrote: >On Fri, Feb 28, 2003 at 11:27:06AM +1300, Russell Fulton wrote: > >> This isn't really feasible since the whole point of the RBL is that >> you dump the session before it sends anything so you don't know who >> its for. > >I *think* barfing (5xx) when you get a connection or on "MAIL FROM" >strictly speaking isn't allowed in the RFC (I've not check rfc2821 so >this may have changed since '821). From RFC 2821 3.1 Session Initiation The SMTP protocol allows a server to formally reject a transaction while still allowing the initial connection as follows: a 554 response MAY be given in the initial connection opening message instead of the 220. I.e. if an RBL'd host connects to you, even before the HELO/EHLO, you can tell them to go away 554 Transaction failed (go away evil spammer) -- Michael Newbery IP Architect TelstraClear Limited

1 0

Persistent spammer 210.24.225.148
by Simon Byrnand 26 Feb '03

26 Feb '03

Anyone else had trouble with a very persistant spammer on adsl148.dyn225.pacific.net.sg [210.24.225.148] or nearby ip addresses belonging to the same ISP lately ? Doing dictionary attacks, and attempting connections at the rate of several hundred per minute, (up to 50 simultaneous connections at once) and still attempting the same connection rate even after being firmly 550'ed.....not funny at all. Had the same thing happen a week ago from another adsl ip address belonging to the same ISP and actually got what seemed like a positive response to abuse@ saying that they had sorted out the problem, only for it to happen again less than a week later from a slightly different ip address. Just paying lip service to abuse emails, or do they have a high percentage of scum like customers I wonder... :) Regards, Simon Byrnand iGRIN Internet

1 0

Heads Up - streaming event thursday
by Richard Naylor 25 Feb '03

25 Feb '03

Heads up There is a streaming event in Wgtn tomorrow, covering a presentation by the CEO of MTV-Europe, Brent Hansen. The stream will start with test pattern and "curtain opener" stuff at around 4:30pm with the main event at 5:30pm until around 8:00pm. Streams will be at 56k, 128k and 384kbps and will be on WIX coming from l1.r2.co.nz (203.118.144.36) While we don't expect the traffic volumes of the LOTR event last year, they have managed to sell some tickets and maybe someone might watch (other than us in the hall). So there appears to be some interest. We also have advanced warning of a LOTR event in mid March. I'll advise as soon as I get told something. rich

1 0

E1 / PRI equipment (Lucent Ascend Max)
by Michael Hallager 21 Feb '03

21 Feb '03

Hello all, Has anyone on the list had experiance with setting up and/or using imported Lucent Ascend Max 4048 56k RAS servers? (E1 version of course). I would like to know what peoples experiences are. I can be contacted at: michael(a)comsolve.net.nz Michael Hallager

1 0

Big increase in 419 spam?
by Juha Saarinen 21 Feb '03

21 Feb '03

Am I just being unlucky, or are others seeing a big surge in 419 spam? Not just from Nigeria (blocked), but from freemail servers all over the place -- Europe, Asia, the US, South America etc. 419 spam accounts for the vast majority of UCE/UBE that I receive now. -- Juha Saarinen

4 3

ENUM
by Philip D'Ath 21 Feb '03

21 Feb '03

I've been doing quite a bit of development in the VoIP word of late, and one project I need to get going is a +64 ENUM reverse delegation for 4.6.e164.arpa. Is anyone on this list working is this area, or have done work in this area? Philip D'Ath IFM Ltd http://www.ifm.net.nz/

1 0

RE: [nznog] Big increase in 419 spam?
by Mike Clark 20 Feb '03

20 Feb '03

for a proactive approach try the nigerian fraud masterclass: http://www.fattibastardo.com/fraud.html -----Original Message----- From: Michael Newbery [mailto:Michael.Newbery(a)team.telstraclear.co.nz] Sent: Friday, 21 February, 2003 12:43 To: NZNOG Subject: Re: [nznog] Big increase in 419 spam? At 12:19 PM +1300 21/2/03, Juha Saarinen wrote: >Am I just being unlucky, or are others seeing a big surge in 419 spam? Someone appears to be working on a filter. http://www.theregister.co.uk/content/6/29410.html -- Michael Newbery IP Architect TelstraClear Limited _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Re: [nznog] NZNOG 2003 Content
by Jamie Baddeley 19 Feb '03

19 Feb '03

Hi, "..Managing IP Networks with Free Software.." Free as in speech or Free as in Beer? I'd be happy to help out/swap notes with anyone doing "..Managing IP Networks with Open Source Software.." jamie >>> "Donald Neal" <Donald.Neal(a)telecom.co.nz> 02/20 3:58 PM >>> Suggestions I've received for NZNOG 2003 content are summarised below. The first number listed after each topic is the number of expressions of interest I've received, the second is the number of offers to present. NB: One volunteer has heroically made multiple offers to present and can't possibly deliver on all of them. So further feed back on preferences and/or offers to present definitely remain relevant. DNS [1/0] DNS Security [0/1] f-root Server Deployment [0/1] Email [1/0] Measurement New Zealand Network Measurement Infrastructure [1/0] Passive Network Measurement [2/1] New Zealand Next Generation Internet [2/0] The Future of IP Addressing [0/1] Spam [1/0] Spam Filtering at the Provider Level [0/1] Tutorials BGP [0/1] Congestion Mitigation [0/1] Managing IP Networks with Free Software [0/1] Mitigating Network Abuse using BGP [0/1] Real-World Network Operations [0/1] For now I'm seeking content independent of the conference format. I'm hoping we'll be guided in the format by the content. Feedback to me rather than the list, please. - Donald Neal ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------ _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

RE: [nznog] NZNOG 2003 Content
by Stephen Andrew 19 Feb '03

19 Feb '03

Given that this is a NZ event "Managing IP Networks using Wet String and the Change from Parking Meters[1]" might be a go? ;-) -- Andrew [1] For the providers out there doing a remarkably good job of managing effective IP networks with wet string and the change from parking meters who may take offence, please don't; New Zealand has done remarkably well with wet string ever since we worked out the interference from the zapper thing on the No 8. was what was causing the problem. ----Original Message---- From: Jamie Baddeley [mailto:jamie.baddeley(a)bclnz.com] Sent: Thursday, 20 February 2003 4:32 PM To: nznog(a)list.waikato.ac.nz; Donald.Neal(a)telecom.co.nz Subject: Re: [nznog] NZNOG 2003 Content > Hi, > > "..Managing IP Networks with Free Software.." > > Free as in speech or Free as in Beer? > > I'd be happy to help out/swap notes with anyone doing > > "..Managing IP Networks with Open Source Software.." > > jamie > >>>> "Donald Neal" <Donald.Neal(a)telecom.co.nz> 02/20 3:58 PM >>> > Suggestions I've received for NZNOG 2003 content are summarised > below. The first number listed after each topic is the number of > expressions of interest I've received, the second is the number of > offers to present. > > NB: One volunteer has heroically made multiple offers to present and > can't possibly deliver on all of them. So further feed back on > preferences and/or offers to present definitely remain relevant. > > DNS [1/0] > DNS Security [0/1] > f-root Server Deployment [0/1] > > Email [1/0] > > Measurement > New Zealand Network Measurement Infrastructure [1/0] > Passive Network Measurement [2/1] > > New Zealand Next Generation Internet [2/0] > > The Future of IP Addressing [0/1] > > Spam [1/0] > Spam Filtering at the Provider Level [0/1] > > Tutorials > BGP [0/1] > Congestion Mitigation [0/1] > Managing IP Networks with Free Software [0/1] > Mitigating Network Abuse using BGP [0/1] > Real-World Network Operations [0/1] > > For now I'm seeking content independent of the conference format. I'm > hoping we'll be guided in the format by the content. > > Feedback to me rather than the list, please. > > - Donald Neal > > ---------------------------------------------------------------------------- -- > "This communication, including any attachments, is confidential. > If you are not the intended recipient, you should not read > it - please contact me immediately, destroy it, and do not > copy or use any part of this communication or disclose > anything about it. Thank you." > > ---------------------------------------------------------------------------- -- > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog This email with any attachments is confidential and may be subject to legal privilege. If it is not intended for you please reply immediately, destroy it and do not copy, disclose or use it in any way.

1 0

NZNOG 2003 Content
by Donald Neal 19 Feb '03

19 Feb '03

Suggestions I've received for NZNOG 2003 content are summarised below. The first number listed after each topic is the number of expressions of interest I've received, the second is the number of offers to present. NB: One volunteer has heroically made multiple offers to present and can't possibly deliver on all of them. So further feed back on preferences and/or offers to present definitely remain relevant. DNS [1/0] DNS Security [0/1] f-root Server Deployment [0/1] Email [1/0] Measurement New Zealand Network Measurement Infrastructure [1/0] Passive Network Measurement [2/1] New Zealand Next Generation Internet [2/0] The Future of IP Addressing [0/1] Spam [1/0] Spam Filtering at the Provider Level [0/1] Tutorials BGP [0/1] Congestion Mitigation [0/1] Managing IP Networks with Free Software [0/1] Mitigating Network Abuse using BGP [0/1] Real-World Network Operations [0/1] For now I'm seeking content independent of the conference format. I'm hoping we'll be guided in the format by the content. Feedback to me rather than the list, please. - Donald Neal ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

1 0

Xtra moving APE peering to new router port 06:00 tomorrow
by Kevin Stewart 18 Feb '03

18 Feb '03

Xtra moving APE peering to new router port 06:00 tomorrow Sorry for the short notice The outage should be less than 10 Min I will broadcast ping once I am done but you may wish to clear your ARP if you don't see your BGP session up after this For those who MAC filter I will send the new MAC to the list when I work it out Kevin Stewart Services Specialist Telecom New Zealand DDI: +64 9 363 5849 Cell: +64 25 412 731

1 0

HELP Please - Mail record resolution for fisherfunds.co.nz
by zapf11＠ihug.co.nz 18 Feb '03

18 Feb '03

Hi All, Have always been reading but never posted. Have this problem here with resolving the mail record for fisherfunds.co.nz . Tkns for any assistance in advance. I have this mail server at clients connecting via Xtra ADSL network using their default DNS servers (202.27.184.3 / 202.27.184.5) to resolve a mail record. Have tried mail / smtp / mx @fisherfunds.co.nz without any luck. I know that fisherfunds.co.nz is hosted on Xtra and uses Xtras mail servers. As I can successfully send mail to fisherfunds.co.nz from Orcon internet. So to sum it up my mail server and the target domain is both on Xtras network, but my mail server cant resolve their Mail record to deliver mail. How does other people E.g Orcon get the mail delivered? What is not working? Thanks Felix Ultra Tech Ltd

5 4

[public-consult] RFV - Request for Votes - .geek.nz (fwd)
by Juha Saarinen 16 Feb '03

16 Feb '03

Thought this might be of interest to some who aren't subbed to the public consult list. -- Juha Saarinen ---------- Forwarded message ---------- Date: Mon, 17 Feb 2003 17:15:57 +1300 From: Peter Macaulay <exe.dir(a)internetnz.net.nz> Reply-To: "vote-geek(a)internet.net.nz" <vote-geek(a)internet.net.nz>, InternetNZ Public Consultation List <public-consult(a)internetnz.net.nz> To: "members-announce(a)internetnz.net.nz" <members-announce(a)internetnz.net.nz>, "public-consult(a)internetnz.net.nz" <public-consult(a)internetnz.net.nz>, "public-announce(a)internetnz.net.nz" <public-announce(a)internetnz.net.nz> Subject: [public-consult] RFV - Request for Votes - .geek.nz InternetNZ, through the Office of the Domain Name Commissioner, is conducting a vote to gauge whether there is support for the creation of a new second level domain in the *.nz namespace - namely geek.nz. The details of the application can be found at http://www.dnc.org.nz/story/30058-30-1.html and it is being considered based on the current Second Level Domains Policy. This policy can be found at http://dnc.org.nz/content/second_level_domains.pdf. Voting for this application will start February 18 2003 at 23:59 and close at March 4 2003 at 23:59. The application must receive at least 200 votes and at least 70% support for it to enter the next phase which is a formal submission process. This vote will not determine if .geek.nz is implemented, only to see if it has wide enough support for it to continue in the approval process. Voting is available via a website or email and details of voting can be found at http://www.internetnz.net.nz/dns/2nd-level-domains/2ld030304-voting_details… Please note - to be able to vote you have to have a valid email address and a New Zealand postal address. The NZ postal address would be such that mail sent to that address would be expected to reach the voter. There are no other restrictions on who can vote. Any missing information on the ballot will result in the ballot being ruled invalid. Please check to make sure all the required information is included on your ballot. Voting opens online at http://vote.internetnz.net.nz at 23:59 on 18 February. Any inquiries should be sent to the Voting Officer at vote-help(a)internetnz.net.nz An email ballot can be cast by emailing vote-geek(a)internetnz.net.nz. The following form may be used. A 'reply' to this email should work but please check the email address before sending as only votes to the correct email will be counted. Delete two of the three voting options plus all text before and after the ballot. --BEGINNING OF BALLOT-- Name: Email address: NZ Postal Address: I VOTE FOR THE CREATION OF .GEEK.NZ I VOTE AGAINST THE CREATION OF .GEEK.NZ I ABSTAIN --END OF BALLOT -- Peter Macaulay Executive Director InternetNZ Direct +64 4 495 2113

1 0