- NZNOG - lists.nznog.org

RE: [nznog] vISP
by Steve Phillips 07 Apr '03

07 Apr '03

Was it really necessary to reply to the list like this Seeby ? This sort of marketing thing should be kept off list - a simple "yes, contact me off list for details" would have sufficed. (but then you already know this as you have been told repeatedly about this sort of thing in various forums over the past two to three years _at least_) I guess this would mean that Orcon doesn't fit at least one of his criteria then, an ISP that SPAMs to sell its own services could hardly be called "reputable" -- Steve. At 20:07 6/04/2003, Seeby Woodhouse wrote: >Hi there Neo > >I notice that you are a HyperNet user. >Orcon purchased HyperNet a while ago - so you're already a customer of >ours. >Currently Orcon is the largest VISP provider / ISP wholesaler in NZ >We supply around 40 ISP's in NZ with VISP style services, and a couple >in Australia. > >Talk to us and we can simply add VISP services onto your existing bill >:-) >(pretty much) > >The person you need to contact is Patrick Sharp (patrick(a)orcon.net.nz) >he's our VISP account manager and he can tell you everything you need to >know.. > >Cheers > >Seeby Woodhouse >Orcon Internet Ltd - www.orcon.net.nz >Ph +64-9-444-4414 Fax +64-9-444-4444 Mob +64-21-366-666 > > > > -----Original Message----- > > From: neo [mailto:neo(a)hyper.net.nz] > > Sent: Sunday, 6 April 2003 6:58 p.m. > > To: nznog(a)list.waikato.ac.nz > > Subject: [nznog] vISP > > > > > > Does anyone provide reasonable priced vISP type packages? > > Providing your an honest entity and capable of providing a > > quality, if not, standard service. > > > > neo > > > > _______________________________________________ > > 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 -- Steve Phillips Professional Slacker -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT/CS/CC d- s+:- a- C++++(---)$ UL++++$ UB++++$ US++++$ UC++++$ P+ L+++$ E- W-(+) N+$ w$ O V PS+ PE++ Y+ PGP++ t+@ 5+++ tv++ b+ G e+>* h r--- z+ ------END GEEK CODE BLOCK------ To decode see http://www.ebb.org/ungeek/

1 0

New IANA IPv4 DE-allocations and bogon updates
by Rob Thomas 06 Apr '03

06 Apr '03

[ Apologies to those who have received this post in other fora. ] The numerous Team Cymru bogon projects have been updated to reflect the following IANA DE-allocations on April 05, 2003: 173/8 Apr 03 IANA - Reserved 174/8 Apr 03 IANA - Reserved 175/8 Apr 03 IANA - Reserved 176/8 Apr 03 IANA - Reserved 177/8 Apr 03 IANA - Reserved 178/8 Apr 03 IANA - Reserved 179/8 Apr 03 IANA - Reserved 180/8 Apr 03 IANA - Reserved 181/8 Apr 03 IANA - Reserved 182/8 Apr 03 IANA - Reserved 183/8 Apr 03 IANA - Reserved 184/8 Apr 03 IANA - Reserved 185/8 Apr 03 IANA - Reserved 186/8 Apr 03 IANA - Reserved 187/8 Apr 03 IANA - Reserved 189/8 Apr 03 IANA - Reserved 190/8 Apr 03 IANA - Reserved Note well: These are IP DE-allocations which increases the number of Bogon networks! Also note that 188/8 is NOT part of the list above. IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to the FIRST community, as well as on lists such as NANOG, isp-routing, isp-security, isp-bgp, cisco-nsp, and bogon-announce. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not blindly apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the master Bogon Reference Page can be found here: http://www.cymru.com/Bogons/index.html A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List The Text Bogon List, Unaggregated The Text Bogon List, Aggregated Secure BIND Template Secure IOS Template (Cisco) Secure BGP Template (Cisco) Secure JUNOS Template (Juniper) Secure JUNOS BGP Template (Juniper) Ingress Prefix Filter Templates, Loose and Strict (Cisco) Ingress Prefix Filter Template, Loose (Juniper) Ingress Prefix Filter Template, Strict (Juniper) BGP Bogon route-server * RADb fltr-unallocated fltr-martian fltr-bogons DNS Bogon (bogons.cymru.com) zone Monitoring Bogon prefix monitoring * All of the bogon peers have received the appropriate BGP prefix updates. Please feel free to contact Team Cymru with any comments, questions, or concerns. Thanks! Rob, for Team Cymru. [http://www.cymru.com/About/teamcymru.html] -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

vISP
by neo 06 Apr '03

06 Apr '03

Does anyone provide reasonable priced vISP type packages? Providing your an honest entity and capable of providing a quality, if not, standard service. neo

1 0

New IANA IPv4 allocations and bogon updates
by Rob Thomas 04 Apr '03

04 Apr '03

Hi, NZNOG folks. [ Apologies to those who have received this post in other fora. ] The numerous Team Cymru bogon projects have been updated to reflect the following IANA allocation on April 04, 2003: 201/8 Apr 03 LACNIC (whois.lacnic.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to the FIRST community, as well as on lists such as NANOG, isp-routing, isp-security, isp-bgp, cisco-nsp, and bogon-announce. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not blindly apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the master Bogon Reference Page can be found here: http://www.cymru.com/Bogons/index.html A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List The Text Bogon List, Unaggregated The Text Bogon List, Aggregated Secure BIND Template Secure IOS Template (Cisco) Secure BGP Template (Cisco) Secure JUNOS Template (Juniper) Secure JUNOS BGP Template (Juniper) Ingress Prefix Filter Templates, Loose and Strict (Cisco) Ingress Prefix Filter Template, Loose and Strict (Juniper) BGP Bogon route-server * RADb fltr-unallocated fltr-martian fltr-bogons DNS Bogon (bogons.cymru.com) zone Monitoring Bogon prefix monitoring * All of the bogon peers have received the appropriate BGP prefix updates. Please feel free to contact Team Cymru with any comments, questions, or concerns. Thanks! Rob, for Team Cymru. [http://www.cymru.com/About/teamcymru.html] -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

Fwd: [public-consult] Geek.nz up for submissions
by Robert McDonald 02 Apr '03

02 Apr '03

FYI ---------- Forwarded Message ---------- Subject: [public-consult] Geek.nz up for submissions Date: Wed, 2 Apr 2003 13:25:23 +1200 From: "Gavin Lambert" <gavinl(a)compacsort.com> To: <public-consult(a)internetnz.net.nz> I'm a little surprised there hasn't been an official announcement on this list; or perhaps there has and I just missed it somehow. Anyway, for those like me that hadn't heard before, the proposal for geek.nz has now entered the "Request for Submissions" phase. More details can be found at: http://www.dnc.org.nz/story/30107-30-1.html _______________________________________________ public-consult mailing list public-consult(a)internetnz.net.nz http://listserver.internetnz.net.nz/mailman/listinfo/public-consult ------------------------------------------------------- -- -------------- Robert McDonald NZPages.Net Web Services Ph: 021 1770061 ICQ: 86984875 http://www.nzpages.net

1 0

NZ importer for reliawave WLAN ?
by Steve Wright 01 Apr '03

01 Apr '03

Can anyone point me to a NZ importer for Reliawave WLAN Gear ? vis, http://www.demarctech.com/products/reliawave-rwz/reliawave-rwz-200mw-prism2… TIA, Steve

1 0

FW: RFC 3514
by mark.harris＠ssc.govt.nz 01 Apr '03

01 Apr '03

I'm surprised nobody posted this yesterday > -----Original Message----- > > You may like to check out this excellent new RFC: > > ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt > > Mark Harris > Senior Advisor, State Services Commission > Tel: 64 4 495 2844 >

1 0

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