March 2003 - NZNOG - lists.nznog.org

list.waikato.ac.nz Has Moved
by Donald Neal 11 Dec '24

11 Dec '24

NZNOG-People, I have just finished migrating all of the mailing lists held at The University of Waikato from one server to another. I don't have any reason to believe that anything's gone wrong, but please bear with me for today if it turns out that something has. - Donald Neal -- Donald Neal | Q: How many Aucklanders does it take to change Systems Programmer/Analyst | a light bulb? The University of Waikato | A: Pass me that candle and I'll tell you. Hamilton, New Zealand | --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

4 3

RE: Sort of OT: are there any "Internet enabled" temperature sens ors/servers for Auckland?
by Greg Clare 18 Aug '21

18 Aug '21

May not be exactly what you are after? However DSE have an Internet weather station at the Albany HQ. http://www.dse.gen.nz/public/webdata/weather.htm Regards Greg > -----Original Message----- > From: Juha Saarinen [mailto:juha(a)saarinen.org] > Sent: Wednesday, 2 January 2002 2:47 pm > To: NZNOG > Subject: Sort of OT: are there any "Internet enabled" temperature > sensors/servers for Auckland? > > > Measuring the outside temperature, with geographic location given. > > -- > Juha > Take off every sig! > > - > To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz > where the body of your message reads: > unsubscribe nznog > - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

problems with NTP on bigben?
by Simon Blake 03 Mar '05

03 Mar '05

Anybody else observed that bigben gained about 19 years at about 1:25pm this arvo? $ date Tue Jan 1 14:54:33 NZDT 2002 $ /usr/sbin/ntpdate -q truechimer.waikato.ac.nz server 130.217.76.32, stratum 2, offset -0.001089, delay 0.04276 1 Jan 14:49:38 ntpdate[17537]: adjust time server 130.217.76.32 offset -0.001089 sec $ /usr/sbin/ntpdate -q bigben.clix.net.nz server 203.167.224.60, stratum 1, offset 619315199.998172, delay 0.03613 1 Jan 14:49:55 ntpdate[17540]: step time server 203.167.224.60 offset 619315199.998172 sec - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

13 20

Netforum Call for Papers
by Donald Neal 27 May '03

27 May '03

Roger De Salis sent this to the list: - - - - - The Netforum conference for 2003 is scheduled for July 10,11,12. The Theme of the conference is Next Generation Internet: Advanced Network Operations and Computer Networking in Aviation The conference will be extremely technical with >2/3 content devoted to advanced networking and related topics. Speakers are invited to submit proposals for papers to the conference committee by sending a synopsis and Title to "netforum(a)fx.net.nz". We look forward to an expanded conference in 2003, and the conference committee will be working very hard to meet or exceed the standard set by the 2002 conference, which I hope many of you enjoyed. The committee looks forward to receiving proposals. ==================================================================== In a similar manner, attendees are welcome to suggest topics or papers they are interested in seeing, and the conference organisers will then be able to help persuade likely speakersto stump up a talk. Send to "suggestions(a)fx.net.nz" Rgds Roger De Salis ------------------------------------------------------------------------------ "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." ------------------------------------------------------------------------------

3 2

RE: CERT Advisory CA-2003-12 Buffer Overflow in Sendmail
by Tony Wicks 31 Mar '03

31 Mar '03

Hi all, the Redhat mirror server ftp.wicks.co.nz ( ftp.isl.net.nz ) now has the Sendmail updates. Infact it just synced up the updates for Redhat 9.0, which is a bit ironic as 9.0 is not even released yet. > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > CERT Advisory CA-2003-12 Buffer Overflow in Sendmail > > > > Original release date: March 29, 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.6 > > * Sendmail Switch 2.2 prior to 2.2.6 > > * Sendmail Switch 3.0 prior to 3.0.4 > > * Sendmail for NT 2.X prior to 2.6.3 > > * Sendmail for NT 3.0 prior to 3.0.4 > > * Systems running open-source sendmail versions prior > to 8.12.9, > > including UNIX and Linux systems > > > > Overview > > > > There is a vulnerability in sendmail that can be exploited > to cause a > > denial-of-service condition and could allow a remote > attacker to > > execute arbitrary code with the privileges of the > sendmail daemon, > > typically root. > > > > I. Description > > > > There is a remotely exploitable vulnerability in sendmail > that could > > allow an attacker to gain control of a vulnerable > sendmail server. > > Address parsing code in sendmail does not adequately check > the length > > of email addresses. An email message with a specially > crafted address > > could trigger a stack overflow. This vulnerability was > discovered by > > Michal Zalewski. > > > > This vulnerability is different than the one described in CA-2003-07. > > > > 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. > > > > This vulnerability has been successfully exploited to > cause a > > denial-of-service condition in a laboratory > environment. It is > > possible that this vulnerability could be used to execute > code on some > > vulnerable systems. > > > > The CERT/CC is tracking this issue as VU#897604. This > reference number > > corresponds to CVE candidate CAN-2003-0161. > > > > For more information, please see > > > > http://www.sendmail.org > > http://www.sendmail.org/8.12.9.html > > http://www.sendmail.com/security/ > > > > For the latest information about this vulnerability, > including the > > most recent vendor information, please see > > > > http://www.kb.cert.org/vuls/id/897604 > > > > This vulnerability is distinct from VU#398025. > > > > II. Impact > > > > Successful exploitation of this vulnerability may > cause a > > denial-of-service condition or 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 by the contents of a > malicious > > email message. > > > > III. Solution > > > > Apply a patch from Sendmail, Inc. > > > > 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.9. These patches, and a > signature file, > > are located at > > > > ftp://ftp.sendmail.org/pub/sendmail/prescan.tar.gz.uu > > ftp://ftp.sendmail.org/pub/sendmail/prescan.tar.gz.uu.asc > > > > 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 the statements they provided in Appendix > A of this > > advisory. The most recent vendor information can be > found in the > > systems affected section of VU#897604. > > > > 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. > > > > Red Hat Inc. > > > > Red Hat distributes sendmail in all Red Hat Linux > distributions. We > > are currently [Mar29] working on producing errata packages > to correct > > this issue, when complete these will be available > along with our > > advisory at the URL below. At the same time users of > the Red Hat > > Network will be able to update their systems using the > 'up2date' tool. > > > > Red Hat Linux: > > > > http://rhn.redhat.com/errata/RHSA-2003-120.html > > > > Red Hat Enterprise Linux: > > > > http://rhn.redhat.com/errata/RHSA-2003-121.html > > > > The Sendmail Consortium > > > > The Sendmail Consortium recommends that sites upgrade > to 8.12.9 > > whenever 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 Eric Allman, Claus Assmann, Greg > Shapiro, and Dave > > Anderson of Sendmail for reporting this problem and > for their > > assistance in coordinating the response to this problem. We > also thank > > Michal Zalewski for discovering this vulnerability. > > _________________________________________________________________ > > > > Authors: Art Manion and Shawn V. Hernan > > > ______________________________________________________________________ > > > > This document is available from: > > http://www.cert.org/advisories/CA-2003-12.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 > > > > March 29,2003: Initial release > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGP 6.5.8 > > > > iQCVAwUBPoX5XGjtSoHZUTs5AQHvjgQAqTy3GQnszPHtUnUBX7VDM4NKSesFHHvC > > 2JmDAMPYmCO2b32xvWDmMcWdPhOBmJLB2o6zv7mRWX1K0B1GN5TBErIii6dxTaDD > > OAUNjirMGdTr+WnxIjdk0gj57JbOU6ZdHHcAijG5SE/dZq4sMrOCGEAMJTVNDzYp > > BtHbFwDeLEY= > > =dgBI > > -----END PGP SIGNATURE----- > >

1 0

Moderation etc.
by Donald Neal 30 Mar '03

30 Mar '03

NZNOG People, I'd like to make a number of comments about events on this list over the last couple of days. This is partly because I simply don't have the time to respond individually to all of the emails sent to me. Sorry. But first, a brief chronology of some of this morning's events: 9:03 List notified that mastermithras(a)yahoo.co.nz has been unsubscribed 10:11 List notified that phuct up(a)msn.com has been unsubscribed 10:19 Abusive email with forged From address posted to the list 10:31 "^god" with address god(a)hackers.net.nz subscribes to the list 10:39 Address god(a)hackers.net.nz unsubscribed by administrator 11:00 Notice from Xtra received that originator of abusive email has been removed from Xtra's network. All of which makes sense to me, but it's taken us some time to get here. The current AUP process is written to allow a certain amount of stupidity to take place before people get unsubscribed. For myself, I'd prefer to keep it that way. Complaining to the List ----------------------- Over the last couple of days, we've seen a considerable number of postings to the list complaining about AUP breaches. I don't mind people emailing me directly, and I certainly don't mind people emailing the senders of such email directly either, but please don't send this sort of thing to the list. It does not seem to influence people who are being intentionally silly, but does swell the volume of non-operational postings. Moderation ---------- There have been a number of quite understandable suggestions of late that the list should become moderated, if only for a time. I remain unwilling to do this. This is partly to ensure that relevant operational material can be disseminated quickly. It is also because it doesn't look to me possible to square moderation in any circumstances with continuing denial that the administrator is responsible for the content of the list or its archive. Administration Head Count ------------------------- The existing process for dealing with idiocy in varying degrees relies on the issuing of warnings. Faster issuing of warnings would result in faster unsubscription of the determinedly anti-social. One way to achieve that would be to move from having a single list administrator to having more than one. Which raises the twin questions of whether there'd be any volunteers for such a role, and "In whom do the people trust?" - Donald Neal List Administrator -- Donald Neal | piano - a musical Technical Specialist | shipping line. Network Delivery | [ Graeme Garden ] Telecom Corp. NZ Ltd | ------------------------------------------------------------------------------ "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." ------------------------------------------------------------------------------

17 22

Peer moderation
by Michael Hallager 28 Mar '03

28 Mar '03

Hello all, I do not trust peer moderation or a pair review process to get on this list. There is currently a issue going on between two respectable ISP's that has culminated in mail blocking - A sad state of affiars for the NZ Internet as I thought we got over this nonsense last century. (Remember Voyager vs. Xtra?). I will not name these two ISPs at this point as I respect them both and I believe that my mail is able to get through although I havn't checked. To the two ISP's involved I say - You have both been around for long enough and you are both of a big enough size to sort this out in an amicable fastion and set a good example for newer and/or smaller players. I suggest that your relevant management peoples gets together and sorts the issues out. (That is, if you havn't already). I do not run an ISP (Although I work part time for one in a technical role). I run a business selling used high end networking equipment and setting up Linux systems. I am a one man band here trying to make an honest living. As I have the skills and inclination, I run all my own servers (Mail, web etc). My network is used purely by myself and I have *never* caused anyone any trouble or had any complaints about how my system is operated. Yet, despite being an innocent third party, I am caught out by what is going on higher up in the scheme of things. C'mon you two, what is the use of a knowledge economy, internet yada yada etc, if this sort of games are still going on? No wonder ISP's have the reputation of used car dealers. (Many of whom have actually cleaned up their act now). No wonder there is call for ISP's to be "licensed". http://computerworld.co.nz/webhome.nsf/UNID/DF3A054F76F9698ECC256CE10008E9D… Best regards to all, Michael Hallager Comsolve Networks (NZ) Limited Networkstuff Limited

3 2

Re: [nznog] Moderation etc.
by Ewen McNeill 27 Mar '03

27 Mar '03

In message <20030328020710.GH10265(a)citylink.co.nz>, Simon Blake writes: >On Fri, Mar 28, 2003 at 01:31:53PM +1200, Donald Neal said: >> The existing process for dealing with idiocy in varying degrees relies >> on the issuing of warnings. [....] One achieve that would be to move >> from having a single list administrator to having more than one. [...] > >Rather than moderate the content, why not just close list membership? >[delete all; add only "genuine NZ network operators"] I'm not sure if I officially get a say (I probably don't count technically count as a "genuine NZ network operator"), but I've been around the 'net a fair while now, and I'm opinionated, so I'm going to have one anyway. Some points in vague order: - I know of a bunch of people who are not technically "genuine NZ network operators" who benefit from reading the list (and more have posted in this thread) -- "up and coming" people, people loosely related to network operation who wish to stay "in touch" with what is going on (I'm probably most accurately in that category), etc. - For the most part those people get the benefit from reading, rather than posting to the list; "read only" access might well be sufficient 99% of the time for them. - Following a list (in "real time") by reading archives on the Interweb sucks. Screen scraping off the archives of a mailing list that are on a web page into email again to make it easier to follow is rather baroque. (But better than trying to follow discussions in real time on the Interweb; seems 20 years of UI discoveries got thrown out when the WWW got invented....) - People who "listen but don't talk" don't create much of a disturbance to the list operation. There aren't really (m)any secrets where public knowledge in "real time" would be an issue. - So if there needs to be moderation (note: I've not yet expressed a view), then it need only be on the posting side. "Read only" subscriptions could be left open to "those who can understand the content" or similar with no obvious downside. - Moderation of all postings is very disruptive to discussion particularly of things happening in real time (not to mention a high load on the moderator(s)) - Therefore it is probably desirable that as few postings as possible be moderated, without allowing the list to be flooded with large volumes of off topic stuff. - The set of people who post (on topic) often is relatively small, and relatively static, and could probably be maintained by hand by a small (eg, one person) team of moderators. - So if there is to be moderation (note: still not expressing a view) a potentially more workable solution is not to moderate who can join the list read-only; just to moderate who can post, and "hand moderate" the remaining posts. People posting a few good posts would be added to the "can post without additional moderation" list. Over a short period of time (especially with pre-seeding) those posting "on topic" messages would get put on the "can post without additional moderation" list, and that list would be fairly static. This should be relatively non-intrustrive, and relatively non-demanding on moderator time. This basically boils down to Simon (Blake)'s proposal, but with the restriction being on "posting access" only. The only real catch is "when good posters go bad", which could perhaps be dealt with in the same way as now (but with the implicit addition that their newly invented addresses would not immediately gain posting access). As to the original question: - I lean towards the point of view that this has basically been a one-shot deal and going closed-list/all-moderated/etc over it is probably an over-reaction. If people would stop feeding the trolls (even off list) then it'll probably all die a natural death. - As such I'm not particularly in favour of moderation. - With a little arm twisting I would be willing to be one of a team of moderators for the list (on a "if it needs to be done, and no one else is doing it" basis). I could recite a list of reasons why I'm qualified, but what it boils down to is that I've been about the NZ Internet for quite a while, seen my share of flame wars, etc, but don't work at any network operators so would hopefully be seen as neutral. (As I said above, I'd rather it wasn't moderated. But if it is, I'm willing to help out if necessary) Ewen

1 0

Re: [nznog] Moderation etc.
by Jamie Baddeley 27 Mar '03

27 Mar '03

for what it's worth I agree with this. alternatively don't accept list members that have disposable email addresses (hotmail.com, email.com, msn.com, yahoo.co.nz etc etc), or a perverse fascination with bonzai buddy ;-) jamie >>> Simon Blake <simon(a)citylink.co.nz> 03/28 2:07 PM >>> On Fri, Mar 28, 2003 at 01:31:53PM +1200, Donald Neal said: > The existing process for dealing with idiocy in varying degrees relies > on the issuing of warnings. Faster issuing of warnings would result in > faster unsubscription of the determinedly anti-social. One way to > achieve that would be to move from having a single list administrator > to having more than one. Which raises the twin questions of whether > there'd be any volunteers for such a role, and "In whom do the people > trust?" Rather than moderate the content, why not just close list membership? Delete everybody off the list, add back on the people you know are genuine NZ network operators, and set the list up so that requests to join get sent to some group of moderators (or to the list). Then, vett new requests to join through the current members. Leave the web pages and archives public, so that the world can still read about what we're up to. Yes, it's cliquey, yes, it's elitist, but well, who cares. It's the Network Operators Group - we need to get it a back on topic PDQ, otherwise it'll cease to have any relevancy to the community it seeks to serve, and it'll get replaced with something else (that probably will have a closed membership). Cheers Si > - Donald Neal > List Administrator > > -- > Donald Neal | piano - a musical > Technical Specialist | shipping line. > Network Delivery | [ Graeme Garden ] > Telecom Corp. NZ Ltd | > > ------------------------------------------------------------------------------ > "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

2 1

RE: [nznog] Moderation etc.
by Zanetti David 27 Mar '03

27 Mar '03

Simon Lyall [mailto:simon.lyall(a)ihug.co.nz] wrote: > I'm a great believer in leaving things alone. Currently we have a > large number of people on the list who aren't exactly "network > operators" . The vast majority of these people are no problem and > don't even post. Some of them will post sometimes when something > in their area comes up. I tend to support this view. I'm sure I don't qualify as a "network operator" by implying a definition from people's posts, but I don't believe I've been seeding the list with problems, and one or two trouble makers just need to be dealt with and we move on. Ironically I suspect more traffic will be created by debating this than was created by the orignal outburst or the last six months.. IMO. :) -- David Zanetti <david.zanetti(a)nzpost.co.nz> Desk: +64-4-496-4005 Mobile: +64-25-832-572 "Hope.. is a dangerous thing" 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