- NZNOG - lists.nznog.org

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

RE: [nznog] nznog 2003. Possible clash
by Donald Neal 16 Feb '03

16 Feb '03

> > -----Original Message----- > > From: Simon Lyall [mailto:simon.lyall(a)ihug.co.nz] > > Sent: Friday, 14 February 2003 10:34 > > To: nznog(a)list.waikato.ac.nz > > Subject: [nznog] nznog 2003. Possible clash > > > > > > Can someone confirm the date for nznog 2003? According to > this email: > > > > http://list.waikato.ac.nz/pipermail/nznog/2003-January/005754.html > > > > it's on the 10th to 12th of July. > > Yes, those are the planned dates. > > > just I notice that this appears to clash with the Netsafe > conference: > > > > http://www.netsafe.org.nz/conferences/conferences default.asp > > > > I'm not sure how much the overlap of people is but it might > > affect some. I've heard back from one person that this is likely to affect them. If there isn't anyone else, I don't think we'll be doing anything about this. - 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

FW: APEC TEL IPv6 Workshop
by Frank March 14 Feb '03

14 Feb '03

Forwarded for your information. I am not aware of any NZers attending and would be very interested to hear from anyone thinking of going. --- 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: Crick, Gabrielle [mailto:Gabrielle.Crick(a)dcita.gov.au] Sent: Thursday, 13 February 2003 12:40 To: 'apectel-poc(a)lists.dcita.gov.au' Subject: APEC TEL IPv6 Workshop Dear colleagues The organisers of the APEC TEL IPv6 workshop invite APEC member economies to participate in the APEC TEL IPv6 workshop being held in Bangkok, Thailand on 20-21 March 2003, just prior to APEC TEL27 in Malaysia. The workshop will cover: Issues surrounding the current standard of Internet Protocol version 4 (IPv4) and how it limits the number of Internet Protocol (IP) addresses available globally. This lack of potential access will threaten all other efforts to bridge the digital divide. The need for policy makers, regulators, and decision makers in APEC economics to be familiar with issues in moving from IPv4 to IPv6 including transition, operation, financial impact, applications, security, and quality of service issues. Risks and benefits of adopting IPv6. For further information on the workshop and registration details please read the attached documents or go to www.totacademy.com. If you require additional information please contact either: Dr. Jack Treuhaft e-mail: treuhaj(a)algonquincollege.com Dr. Pongthiti Pongsilamanee e-mail: ppongs01(a)tot.co.th Kind regards Ms Gabrielle Crick Office of the APEC Telecommunications and Information Working Group Chair Department of Communications, Information Technology and the Arts Level 1, 38 Sydney Ave, BARTON GPO Box 8771 Canberra 2601 AUSTRALIA Ph +61 2 6271 1296 Fax +61 2 6271 1800 _________________________________________________________________________ The information transmitted is for the use of the intended recipient only and may contain confidential and/or legally privileged material. Any review, re-transmission, disclosure, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may result in severe penalties. If you have received this e-mail in error please notify the Security Adviser of the Department of Communications, Information Technology and the Arts, telephone (02) 6271-1880 and delete all copies of this transmission together with any attachments. _________________________________________________________________________ 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.

6 6

RE: [nznog] nznog 2003. Possible clash
by Donald Neal 13 Feb '03

13 Feb '03

> -----Original Message----- > From: Simon Lyall [mailto:simon.lyall(a)ihug.co.nz] > Sent: Friday, 14 February 2003 10:34 > To: nznog(a)list.waikato.ac.nz > Subject: [nznog] nznog 2003. Possible clash > > > Can someone confirm the date for nznog 2003? According to this email: > > http://list.waikato.ac.nz/pipermail/nznog/2003-January/005754.html > > it's on the 10th to 12th of July. Yes, those are the planned dates. > just I notice that this appears to clash with the Netsafe conference: > > http://www.netsafe.org.nz/conferences/conferences default.asp > > I'm not sure how much the overlap of people is but it might > affect some. Could anyone affected by this please speak up NOW. - 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

My apologies to the list for the auto responder, the problem has been rectified.
by Gavin Palmer 13 Feb '03

13 Feb '03

Cheers Gavin Palmer

1 0

nznog 2003. Possible clash
by Simon Lyall 13 Feb '03

13 Feb '03

Can someone confirm the date for nznog 2003? According to this email: http://list.waikato.ac.nz/pipermail/nznog/2003-January/005754.html it's on the 10th to 12th of July. just I notice that this appears to clash with the Netsafe conference: http://www.netsafe.org.nz/conferences/conferences_default.asp I'm not sure how much the overlap of people is but it might affect some. -- 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

1 0