- 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