- NZNOG - lists.nznog.org

M1122 --- spontaneously corrupting flash
by Chris Wedgwood 01 Aug '01

01 Aug '01

Anyone out there inflicted with an M1122? I am, and for the second time to me, and third time in total (once at my old work) have had these modem die completely... Investigation (via console) has shown, in every single case, the flash has gotten corrupted or something, as image.exe (the firmware that is booted from ROM) is either corrupt or deleted. The worst thing is, the console refused to respond, which really sucks, as it means I can't revert to the previous image or put a new one on it. To make life even more interesting, the phone lines here are pretty spectacular, modems barely work and when they do, they drop about every 10 minutes or so even when you lock the modulation to v34 in an attempt to make things more reliable. --cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Re: Crap
by Donald Neal 01 Aug '01

01 Aug '01

>>> "Matt Camp" <gargoyle(a)noise.net.nz> 08/01/01 08:55 >>> >I'd like to ask that this list is immediatly changed to drop non-member >submissions, and that Joe and Jeff are removed. >There is off topic conversation, and then there is pointless, induced, >drivel. NZNOG People, I'm not willing to get involved in a process of deciding for myself that one poster's five postings are cause for blocking, and someone else's are not. And the balance of the (admittedly small) number of emails I got on the subject last month was against restricting postings. On the other hand, I'm not at all happy with this list's s/n ratio. I have this morning sent to a number of posters requests not to send further inappropriate postings to this list. If these result in much improved behaviour, well and good. If not, I plan to move to a practice familiar to followers of cricket. Friendly warnings for misbehaviour may be given. Formal warnings follow. Too many formal warnings and you are asked to retire from the match. And yes, that would mean a move to restricting postings to addresses previously supplied, if not necessarily subscribed. Comments on that plan to the list, please. If it seems to me necessary to implement it I plan to put it to a vote as a set of additions to the AUP. When that might happen depends on postings. - Donald Neal List Administrator -- Donald Neal Mobility & Calling Platforms Network Delivery Telecom New Zealand Ltd --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

10 13

Code Red Early warning for SANS
by Jeff Williams 01 Aug '01

01 Aug '01

All, For your interest on Code Red Worm... See: http://www.digitalisland.net/codered/ for hour to hour reports... I also have an Eradicator if anyone is interested... Regards, -- Jeffrey A. Williams Spokesman for INEGroup - (Over 118k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1(a)ix.netcom.com Contact Number: 972-447-1800 x1894 or 214-244-4827 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Dean's Wireless Walkabout
by Dean Pemberton 01 Aug '01

01 Aug '01

Hi all; Yes this might be a first, I'm going to drag the topic BACK to something network related. I happen to be in Auckland today. Flew in for customer chit chat which will happen tommorow. Had a spare afternoon and no one to see so I thought I might do the geek thing and see how little old Auckland was getting along with it's wireless networking. SO, I slapped the 802.1Q card into the laptop and strapped the GPS onto the outside of my backpack and went for a walk. I walked down Queen Street from the top to the water, and then back up to Albert St to Wellesley then back up Symonds to my hotel. Well. Auckland sure is brimming with wireless. But the concern (and I spose the reason that I posted this at all) was that most of it is insecure. Now I'm a good guy. I don't want to get access to anything, god knows I see enough internet as it is. I just wanted to see how many places had embraced the 802.1Q fad. So all in all 29 networks jumped out and grabbed me as I was walking past. only 4 of them were using WEP. Now because I didn't actually try to gain access to any of them, I have no idea what the internal security of them is like. But I'm not expecting much. I don't think I sniffed anything off the sky tower, I was only using the small antenna on the card. So if you run a wireless network in the center of Auckland and you were using the strategy of "Oh it will never make it down to the street" Then you are wrong and you might like to put some more security on. I thought about mailing my networklist out as well. But I decided against it. Mainly because it has exact GPS locations and network names. It would make easy pickings for anyone who wanted to gain access. If you want to mail me privatly with your network name and/or card MAC address then I will give you a yes or no answer. Dont feel alone though. I've done the same in North Sydney and come up with similar numbers. Next week wellington. Have fun Dean --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

4 4

RE: Code Red (Take Two)
by Thomas Salmen 01 Aug '01

01 Aug '01

A little less of an impact this time then, huh? We've had two customers infected, both installs of which were less than a few days old. Seems that most admins (in NZ at least) have been rather better prepared this time round. Don't know if I can say the same for our friends overseas - many of the IPs that I have logged originate in Asia. Some in the States and Europe, but not as many. A few illegal, unpatched IIS installs, maybe... Must say, though, it was rather funny reading about the 'Code Red no-show' in the news this morning... Regards, Thomas Salmen System Administrator Radionet Ltd. 1/72 Paul Matthews Road Albany, Auckland, New Zealand Ph: +64 9 414 0300 ext 718 -----Original Message----- From: Thomas Salmen [mailto:thomas(a)radionet.co.nz] Sent: Thursday, 2 August 2001 2:12 p.m. To: nznog(a)list.waikato.ac.nz Subject: Code Red (Take Two) Just curious... have many people been affected by the second round of Code Red infections? We have seen plenty of inbound traffic here (well, the odd bit, anyway) but very few of our customers web servers have been hit - not like last time... Regards, Thomas Salmen System Administrator Radionet Ltd. 1/72 Paul Matthews Road Albany, Auckland, New Zealand Ph: +64 9 414 0300 ext 718 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

3 2

Code Red (Take Two)
by Thomas Salmen 01 Aug '01

01 Aug '01

Just curious... have many people been affected by the second round of Code Red infections? We have seen plenty of inbound traffic here (well, the odd bit, anyway) but very few of our customers web servers have been hit - not like last time... Regards, Thomas Salmen System Administrator Radionet Ltd. 1/72 Paul Matthews Road Albany, Auckland, New Zealand Ph: +64 9 414 0300 ext 718 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

9 9

Hmm.
by David Robb 01 Aug '01

01 Aug '01

Is this true? http://www.bogusjourney.com/08018.html David Robb --- Senior Network Engineer DDI +64-9-359-2710 ihug (AS7657) NOC +64-9-359-2708 "The Earth is a single point of failure" --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

13 25

(off topic) Stop with all the garbage please.
by stephen sheehan 01 Aug '01

01 Aug '01

Jeff, Dr Joe and all, I see myself as being fortunate to be a member of this mailing list, to here the wisdom of the local net Gods. It appears some of you do not share this view. I see this list as a valuable resource for the local net industry, and of late it seems to have deteriated into basicly a type of email chatroom for all sorts of off-topic bitching. So I am asking that you please have some respect for the intended purpose of this list and other list members. If you want to bitch to each other or discuss stuff that is not relavent, please do so by private email, as I am sure most of you have better things to do than sort through all the shit that has been posted to the list lately. Sorry for posting this off topic e-mail and sounding like a hypocrite and also adding to the large amount of crap alread on this list. Your sincerely Stephen Sheehan __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Alternative List
by Matt Camp 01 Aug '01

01 Aug '01

A while back an alternative list was proposed... most people seemed quite receptive to the idea... so it now exists. To subscribe, send a mail to majordomo(a)noise.net.nz with 'subscribe nznet' in the body. The alternative list is more informal, and more generally aimed at the NZ Networking industry. It may contain things such as details of used equipment for sale, and discussions which would be regarded as off topic here. Hopefully this will give us a place to discuss such things, and will keep the noise level down here somewhat. --- Matt Camp --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

RE: Crap
by Michael Bordignon 01 Aug '01

01 Aug '01

maybe uh, ending discussion of this completely off-topic discussion and refraining from replying to any further attempts to revive it may be productive? (including replying to this rhetorical post) Michael > i know this well and so does jeff. example - you filter me > out - or jeff > - or whomever it may be you choose to filter - then some third party > begins the drivel about jeff williams. well - you end up on > the receiving > end of the drivil from the third parties. in most cases > filtering ends up > causing confusion. you would essentially have to filter out > everyone who > is speaking about jeff williams - and that in my opinion is counter > productive. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

Validation of INEGROUP.GOD Domain
by The dot.GOD Registry, Limited 01 Aug '01

01 Aug '01

Hello: This email will confirm that we have processed your domain registration request for: INEGROUP.GOD. Someone, hopefully you, has registered this domain with us. If not please let us know. You must now visit our web site to validate your domain and enter your validation ticket number. TICKET: 52396544d99665168490 Please click on the following URL to activate your new domain name now. https://secure.dot-god.com/god.nic/validate.cgi?inegroup=52396544d996651684… Or if the above URL does not work (some email systems may crop the URL) then please visit: https://secure.dot-god.com/cgi-bin/validate.cgi and enter the following information manually at the prompt: DOMAIN: inegroup TICKET: 52396544d99665168490 Regards hostmaster(a)dot-god.com http://www.dot-god.com/ The dot.GOD Registry, Limited Executive Plaza, Suite 908 150 West 51st Sreet New York, New York, 10019 US --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

5 5

RED WORM Virus
by Mike Conner 01 Aug '01

01 Aug '01

Has any one seen the worm yet? Mike Conner. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

3 3

Code Red growth stats (fwd)
by !Dr. Joe Baptista 01 Aug '01

01 Aug '01

my contribution to keeping this conference topical today. ---------- Forwarded message ---------- Date: Wed, 1 Aug 2001 09:44:05 -0700 From: k claffy <kc(a)ipn.caida.org> To: nanog(a)nanog.org Subject: Code Red growth stats (david moore with help from a bunch of elves) http://www.caida.org/analysis/security/code-red/aug1-live-hosts.gif was exponential till about an hour ago, we're not sure if leveling off is due to our monitor load or an actual peak in the data. log-scale version http://www.caida.org/analysis/security/code-red/aug1-live-hosts-log.gif will put on main caida home page later today and update every minute (you'll have to hit reload, and you won't actually notice changes at a minute granularity so please no per-minute cron jobs to reload :) ) note the corresponding graph for 19-20 july: http://www.caida.org/analysis/security/code-red/gifs/cumulative-ts.log.gif no per AS stats for this outbreak yet, also under construction. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Preemptive strike.
by Andrew Garrett 01 Aug '01

01 Aug '01

Yes, the name Andrew Garrett has been in the news lately. No, I'm not that Andrew Garrett. Yes, my employer is aware of the name similarity, and has investigated the difference between the two individuals, and is satisfied that we are different people. No, the New Zealand Stock Exchange has not hired a "known hacker". Yes, it is rather amusing. No, not very amusing when you're involved. Regards Andrew "sigh, no, not that one" Garrett --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

6 6

Re: nznog subscriber test (jwkckid1@ix.netcom.com)]
by Jeff Williams 31 Jul '01

31 Jul '01

Olderon and all, All I did was be sure to send my response along with my question to the list. I also send Andrew's response as well to the list as I am this one. It seems that perhaps that Andrew is not in agreement with your assessment. As such, it seems that the test was in and of itself a failure or misleading... ????? Olderon wrote: > Jeff. > That was an Intelligence test. you failed. > > "The easiest was for me to do this is to send each subscriber this > brief email and then examine any bounces and errors." > > See the word each? > > That email was sent to everyone on the list. If any of the email addresses > got bounced back or got errors then they would be deemed inactive and > removed from the list. > > ----- Original Message ----- > From: "Jeff Williams" <jwkckid1(a)ix.netcom.com> > To: <nznog(a)list.waikato.ac.nz> > Cc: "Chris Wedgwood" <cw(a)f00f.org> > Sent: Wednesday, August 01, 2001 3:06 PM > Subject: [Fwd: nznog subscriber test (jwkckid1(a)ix.netcom.com) > > > Chris, > > > > What is this all about? Why is My E-mail being singled out? > > > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup - (Over 118k members strong!) > > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > > Information Network Eng. Group. INEG. INC. > > E-Mail jwkckid1(a)ix.netcom.com > > Contact Number: 972-447-1800 x1894 or 214-244-4827 > > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup - (Over 118k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1(a)ix.netcom.com Contact Number: 972-447-1800 x1894 or 214-244-4827 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Re: [Fwd: nznog subscriber test (jwkckid1@ix.netcom.com)]
by Jeff Williams 31 Jul '01

31 Jul '01

Sheath and all, Thank you for this clarification. However it does not explain Andrew's response.... ????? sheath(a)paradise.net.nz wrote: > everyone got one with the email addy in the subject line to help with > recording the bounces. > > So each person got a test msg with their own email addy in it. > > SPH > > > Chris, > > > > What is this all about? Why is My E-mail being singled out? > > > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup - (Over 118k members strong!) > > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > > Information Network Eng. Group. INEG. INC. > > E-Mail jwkckid1(a)ix.netcom.com > > Contact Number: 972-447-1800 x1894 or 214-244-4827 > > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup - (Over 118k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1(a)ix.netcom.com Contact Number: 972-447-1800 x1894 or 214-244-4827 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Re: [Fwd: nznog subscriber test (jwkckid1@ix.netcom.com)]
by Donald Neal 31 Jul '01

31 Jul '01

>>> "Mark Foster" <blakjak(a)blakjak.net> 08/01/01 01:21 >>> >The list administrator sent every individual on the list an email in order >to analyse the bounces (if any). > >So therefore noone is 'singled out'. [...] No, I didn't. I'm advised of bounces automatically when they occur. The email in question appears to have originated from Chris Wedgwood. He will presumably now tell us why he sent it. - Donald Neal -- Donald Neal Mobility & Calling Platforms Network Delivery Telecom New Zealand Ltd --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Re: [Fwd: nznog subscriber test (jwkckid1@ix.netcom.com)]
by Jeff Williams 31 Jul '01

31 Jul '01

Andrew and all, I always read all my E-mail closely. What Bullshit? Andrew Garrett wrote: > 1. read the e-mail > 2. learn to not clog lists will bullshit. > > At 08:06 PM 7/31/01 -0700, you wrote: > >Chris, > > > > What is this all about? Why is My E-mail being singled out? > > > >-- > >Jeffrey A. Williams > >Spokesman for INEGroup - (Over 118k members strong!) > >CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > >Information Network Eng. Group. INEG. INC. > >E-Mail jwkckid1(a)ix.netcom.com > >Contact Number: 972-447-1800 x1894 or 214-244-4827 > >Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > > >Return-Path: <cw+nznog-test-bounce-jwkckid1=ix.netcom.com(a)f00f.org> > >Received: from weta.f00f.org ([203.167.249.89]) > > by elektra (Earthlink/Netcom Mail Service) with ESMTP id > > tmejqq.lmr.37tiu4v > > for <jwkckid1(a)ix.netcom.com>; Tue, 31 Jul 2001 17:37:46 -0700 (PDT) > >Received: by weta.f00f.org (Postfix, from userid 1000) > > id 18BED159B7; Wed, 1 Aug 2001 12:38:14 +1200 (NZST) > >From: Chris Wedgwood <cw(a)f00f.org> > >To: jwkckid1(a)ix.netcom.com > >Subject: nznog subscriber test (jwkckid1(a)ix.netcom.com) > >X-NZNOG-USER: jwkckid1(a)ix.netcom.com > >Reply-To: cw+nznog-test-dont-reply(a)f00f.org > >Message-Id: <20010801003814.18BED159B7(a)weta.f00f.org> > >Date: Wed, 1 Aug 2001 12:38:14 +1200 (NZST) > >MIME-Version: 1.0 > > > >Firstly, my apologies for this brief intrusion. I'm currently testing > >which subscribers of nznog are invalid. > > > >The easiest was for me to do this is to send each subscriber this > >brief email and then examine any bounces and errors. > > > >If you have any questions, please feel free to contact me (create a > >new email, don't reply to this or use the subject above, as it may > >interfere with my primitive automagic filtering technique). > > > >I will post a summary of these results to nznog early next week if > >not sooner. > > > > > > > >Thanks, and once again my apologies for this interruption. > > > > --cw -- Jeffrey A. Williams Spokesman for INEGroup - (Over 118k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1(a)ix.netcom.com Contact Number: 972-447-1800 x1894 or 214-244-4827 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

[Fwd: nznog subscriber test (jwkckid1@ix.netcom.com)]
by Jeff Williams 31 Jul '01

31 Jul '01

Chris, What is this all about? Why is My E-mail being singled out? -- Jeffrey A. Williams Spokesman for INEGroup - (Over 118k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1(a)ix.netcom.com Contact Number: 972-447-1800 x1894 or 214-244-4827 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

2 1

Broadband in Greenhithe?
by Juha Saarinen 31 Jul '01

31 Jul '01

Possible? A person there needs something quicker than dial-up for remote access etc. but was told that Jet{start|stream} isn't available in Greenhithe. The area is Black's Road, top of the ridge. Any advice would be appreciated... :-) -- Juha --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 2

New Zealand Network Operators' Group
by Donald Neal 31 Jul '01

31 Jul '01

The New Zealand Network Operators' Group The New Zealand Network Operators' Group (NZNOG) has no king, president or formal membership. At present it consists of the subscribers to this mailing list, which anyone is free to join. This list has around 260 subscribers, growing by a handful each month. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by an employee of Telecom NZ Ltd. Neither of these organisations (nor the administrator) is responsible for its content. NZNOG Mailing List Acceptable Use Policy The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate. 4. Postings to multiple mailing lists are discouraged. 5. Postings that include foul language, character assassination, and lack of respect for other participants are unacceptable. 6. Blatant product or service marketing is unacceptable. 7. Postings of a political, philosophical or legal nature are discouraged. 8. Postings to the list should be in ASCII or MIME encoded as text/plain. Attachments should not be sent to the list. To present a document, a suitable URL may be referred to. For documents of general interest, the use of proprietary file formats is discouraged. 9. Breaches of list etiquette should be dealt with privately with the offending list user, and should not result in complaints being sent to the list. Mailing List Archives A full archive is available at http://list.waikato.ac.nz/archives/nznog/ Any message sent to the list will be archived and made available on the web automatically. Subscribing to the List To subscribe to the NZNOG list, send email to majordomo(a)list.waikato.ac.nz, where the body of the message reads subscribe nznog There are at present no restrictions on who may subscribe to the list, or even on who may post to the list. A recent suggestion that posting be restructed to subscribers received little support. Digest Mailing List If you don't wish to receive postings as they are sent, you can instead subscribe to the nznog-digest mailiing list, on which all postings are sent out in a single "digest" every couple of days. Other Activities NZNOG does not at present have other regular activities than this mailing list. Donald Neal NZNOG Mailing List Owner/Administrator/Muggins --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

IDGNet News: The fixed version
by IDGNetAdministrator＠idg.co.nz 26 Jul '01

26 Jul '01

This message has been sent to you by a user of IDGNet, New Zealand's leading I.T. information Website. Version as of 2:50 26/7/01 Privacy issue over mailing list archives Mailing lists that make archives of their postings publicly accessible on the internet could be in breach of the Privacy Act, according to an Auckland lawyer. http://www.idg.net.nz/webhome.nsf/UNID/29322B8165E1E256CC256A94001886CB?ope… For the latest in I.T. News, Reviews, Opinion and more visit http://idg.net.nz If you wish to block your email address from receiving further emails of this type please email nzwebmaster(a)idg.co.nz. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

5 4

FW: Help! Cistron major failure in production! (fwd)
by Matt Camp 26 Jul '01

26 Jul '01

Anyone had any experience with cistron radius? I'm suffering some sort of major magic weridy problem, if anyone has any ideas. --- Matt Camp ---------- Forwarded message ---------- Date: Wed, 25 Jul 2001 17:24:51 +1200 (NZST) From: Matt Camp <gargoyle(a)noise.net.nz> To: cistron-radius(a)lists.cistron.nl Subject: Help! Cistron major failure in production! I run a network of 4 cistron 1.6.3 servers on FreeBSD machines. This afternoon, all 4 of them stopped responding. Its as like the radiusd process isn't running. Neither our lucent NAS gear, radtest, or the various people who have proxys pointed at our servers get any response at all. The server logs, and console when running in -xxx mode show that the server starts, and then is just waiting for connections. Every 5 minutes, i propagate a new raddb/users file out from a central host. This system has worked fine for around 18 months now. On _ONE_ of the servers, if i restart it (totally. Kill and restart radiusd), the log shows "Wed Jul 25 17:21:38 2001: Info: Starting - reading configuration files ...", then there is nothing for approximately 4 minutes, after which it appears to process all the requests that have been sent to it during that time. (of course, most of them actually fail in reality since the NAS has long since dropped the call). Then it will run fine, up until it detects a new users file, and reloads the config files, at which point its back into total non-responsiveness until i manually restart it. This only works on one server. The other 3 don't come back at all, even after a restart. ANd they're all on the same config. (Which i rsync to them after making a change) radtest tests from localhost which normally work fine just act exactly as if the radiusd process isn't even running. I've tried everything i can think of, including the microsoft approach of power-cycling all machines involved. Load averages are normal, disk space is fine. Heaps of memory available. File descriptor loads seem ok, in that there are only around 100 or so connections to each box in total. (for the other services they run) Any ideas? This is urgent... I've got thousands customers who can't log in right now. --- Matt Camp --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

7 8

xtra rejecting mail from mailing lists?
by Simon Blake 25 Jul '01

25 Jul '01

Hi folks I've got a mailing list on one of my servers that appears to have a bunch of xtra subscribers on it. Postings to the list get sent to about the first 10 xtra users, and then I start getting: Jul 25 21:49:03 wilbur qmail: 996054543.173139 delivery 2330: deferral: Connected_to_203.96.92.131_but_greeting_failed./Remote_host_said: _421_mta4-rme.xtra.co.nz_connection_refused_from_[203.97.152.50]/ It's a fairly unhelpful message from xtra, I assume it's some kind of antispam rate limiting thing - anybody know what they're up to? These things appear to get delivered later, since I've not had any grizzles about non delivery of mail (and there's nothing in the qmail queue). Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

9 13

RE: IDG article.
by David Buckingham 25 Jul '01

25 Jul '01

Privacy Act 1993 028 Commenced: 1 Jul 1993 VI: Codes of Practice and Exemptions from Information Privacy Principles Specific Exemptions 55 Certain personal information excluded 55. Certain personal information excluded---Nothing in principle 6 or principle 7 applies in respect of--- (a) Personal information in the course of transmission by post, telegram, cable, telex, facsimile transmission, electronic mail, or other similar means of communication; or (b) Evidence given or submissions made to--- (i) A Royal Commission; or (ii) A commission of inquiry appointed by an Order in Council made under the Commissions of Inquiry Act 1908,--- at any time before the report of the Royal Commission or commission of inquiry has been published or, in the case of evidence or submissions given or made in the course of a sitting open to the public, at any time before the Royal Commission or commission of inquiry has reported to the Governor-General; or (c) Evidence given or submissions made to a commission of inquiry or board of inquiry or court of inquiry or committee of inquiry appointed, pursuant to, and not by, any provision of an Act, to inquire into a specified matter; or (d) Information contained in any correspondence or communication that has taken place between the office of the Ombudsmen and any agency and that relates to any investigation conducted by an Ombudsman under the Ombudsmen Act 1975 or the Official Information Act 1982 or the Local Government Official Information and Meetings Act 1987, other than information that came into existence before the commencement of that investigation; or (e) Information contained in any correspondence or communication that has taken place between the office of the Commissioner and any agency and that relates to any investigation conducted by the Commissioner under this Act, other than information that came into existence before the commencement of that investigation. PRINCIPLE 6 Access to personal information (1) Where an agency holds personal information in such a way that it can readily be retrieved, the individual concerned shall be entitled--- (a) To obtain from the agency confirmation of whether or not the agency holds such personal information; and (b) To have access to that information. (2) Where, in accordance with subclause (1) (b) of this principle, an individual is given access to personal information, the individual shall be advised that, under principle 7, the individual may request the correction of that information. (3) The application of this principle is subject to the provisions of Parts IV and V of this Act. (This part is from section 6 of the act)... PRINCIPLE 7 Correction of personal information (1) Where an agency holds personal information, the individual concerned shall be entitled--- (a) To request correction of the information; and (b) To request that there be attached to the information a statement of the correction sought but not made. (2) An agency that holds personal information shall, if so requested by the individual concerned or on its own initiative, take such steps (if any) to correct that information as are, in the circumstances, reasonable to ensure that, having regard to the purposes for which the information may lawfully be used, the information is accurate, up to date, complete, and not misleading. (3) Where an agency that holds personal information is not willing to correct that information in accordance with a request by the individual concerned, the agency shall, if so requested by the individual concerned, take such steps (if any) as are reasonable in the circumstances to attach to the information, in such a manner that it will always be read with the information, any statement provided by that individual of the correction sought. (4) Where the agency has taken steps under subclause (2) or subclause (3) of this principle, the agency shall, if reasonably practicable, inform each person or body or agency to whom the personal information has been disclosed of those steps. (5) Where an agency receives a request made pursuant to subclause (1) of this principle, the agency shall inform the individual concerned of the action taken as a result of the request. -----Original Message----- From: owner-nznog(a)list.waikato.ac.nz [mailto:owner-nznog(a)list.waikato.ac.nz]On Behalf Of Greg Clare Sent: Thursday, 26 July 2001 1:23 p.m. To: nznog(a)list.waikato.ac.nz Subject: RE: IDG article. Does this mean that what was originally reported and quoted as having been said by someone, has now been edited and changed? Does this constitute creative reporting? By chance does the article include an addendum to state that it has since been edited due to people or terms being mis-quoted... for the archive of course ;) Greg > -----Original Message----- > From: Simon Lyall [mailto:simon.lyall(a)ihug.co.nz] > Sent: Thursday, 26 July 2001 12:46 pm > To: nznog(a)list.waikato.ac.nz > Subject: IDG article. > > > Looks like they have gone through and changed all the mentions of > "newsgroups" to "mailing list" and changed other stuff around. > > This includes the the stuff in quotes. > > -- > Simon Lyall. | Newsmaster | Work: > simon.lyall(a)ihug.co.nz > Senior Network/System Admin | Postmaster | Home: > simon(a)darkmere.gen.nz > ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

IDG article.
by Simon Lyall 25 Jul '01

25 Jul '01

Looks like they have gone through and changed all the mentions of "newsgroups" to "mailing list" and changed other stuff around. This includes the the stuff in quotes. -- Simon Lyall. | Newsmaster | Work: simon.lyall(a)ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon(a)darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

RE: IDG article.
by Greg Clare 25 Jul '01

25 Jul '01

Does this mean that what was originally reported and quoted as having been said by someone, has now been edited and changed? Does this constitute creative reporting? By chance does the article include an addendum to state that it has since been edited due to people or terms being mis-quoted... for the archive of course ;) Greg > -----Original Message----- > From: Simon Lyall [mailto:simon.lyall(a)ihug.co.nz] > Sent: Thursday, 26 July 2001 12:46 pm > To: nznog(a)list.waikato.ac.nz > Subject: IDG article. > > > Looks like they have gone through and changed all the mentions of > "newsgroups" to "mailing list" and changed other stuff around. > > This includes the the stuff in quotes. > > -- > Simon Lyall. | Newsmaster | Work: > simon.lyall(a)ihug.co.nz > Senior Network/System Admin | Postmaster | Home: > simon(a)darkmere.gen.nz > ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

prefix list update
by James Tyson 25 Jul '01

25 Jul '01

Can all Attica's BGP peers please update their filters: ip prefix-list attica-networks seq 5 permit 202.180.96.0/19 ip prefix-list attica-networks seq 10 permit 202.180.64.0/18 le 19 ip prefix-list attica-networks seq 15 permit 210.55.254.0/24 ip prefix-list attica-networks seq 20 permit 210.55.5.0/24 ip prefix-list attica-networks seq 25 permit 202.50.170.0/24 ip prefix-list attica-networks seq 30 permit 202.55.111.0/24 Cheers. James Tyson --- Samizdat New Media Solutions --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

3 5

RE: xtra rejecting mail from mailing lists?
by Jeremy Clyma 25 Jul '01

25 Jul '01

At 08:17 26/07/2001 +1200, Tech Support wrote: > >On Wed, 25 Jul 2001, Simon Blake wrote: > >> I've got a mailing list on one of my servers that appears to have a > >> bunch of xtra subscribers on it. Postings to the list get sent to about > >> the first 10 xtra users, and then I start getting: > >I had someone come up to me with this too. > >Apparently when they rang up the helpdesk about it they were told > >it wasn't xtra's problem. All I did was suggest they forward the > >bounce to postmaster(a)xtra hoping someone does read email there. > > > >With the 2 examples I saw, it was bouncing emails sent to domains that > >were not hosted at xtra. However emails were sent by xtra customers > >using xtra's smtp server. One of them tried xtra's smtp server after > >they had a problem sending from their own in-house smtp server (thus > >eliminating perhaps a possible problem with their server). > > > >I'll try to get the actual bounce emailed to me. I think it said > >something about being unable to relay email > > > >Lin > >Hmmm, perhaps Xtra subscribe to ORBS, and have blacklisted their own >server..... ;) /sv_tui_ad Yeah. Right. Looks like its a transient error, one which could be caused by the backoff limits we've got in place. Simon, do you know how many concurrent smtp connections was your server attempting to open? --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Fwd: 'we should all be uncomfortable with the extent to which luck..' (fwd)
by n.brownlee＠auckland.ac.nz 25 Jul '01

25 Jul '01

Hello all: You might find this article interesting reading ... Cheers, Nevil ------------------------------------------------------------- Nevil Brownlee Internet Researcher Phone: (858) 534 8338 CAIDA, San Diego ---------- Forwarded message ---------- Date: Tue, 24 Jul 2001 22:35:37 -0700 From: k claffy <kc(a)caida.org> To: nanog(a)nanog.org Cc: caida(a)caida.org Subject: 'we should all be uncomfortable with the extent to which luck..' david moore's analysis of code red: episode 0/1 is at http://www.caida.org/analysis/security/code-red/ [funded by DARPA's ITO office NGI/NMS programs, NSF ANIR, and CAIDA members, david a caida PI] definitely check out jeff brown's animation at bottom; watch carefully around 15:00 for pretty ominous elbow in infection rate (get an epidemiologist to look at it without telling them what it is...) 360,000 machines (well, IP addresses) infected in under 14 hours. from conclusion: // ..in the final analysis, we should all be uncomfortable with the extent to which luck, rather than proactive diligence, maintains the stability of the Internet infrastructure. // it goes without saying that many hosts are still vulnerable. and will likely remain so (to this or the next poison) until our luck runs out. do we expect the next version to have the two weaknesses christopher pointed out today? do we expect the next version won't clear every 3rd bit on the hard drive? almost makes me wonder if some white hat might (should?) have been behind CodeRed as some 'vaccination' attempt. "The bad news is, nobody will do anything about critical infrastructure protection until there's a global catastrophic failure," said Rasch. The good news is, there will be a global catastrophic failure." -- http://www.nando.net/technology/story/44887p-694372c.html the worse news is: protecting 'critical infrastructure' is far from enough. again from http://www.caida.org/analysis/security/code-red/ This assault also demonstrates that machines operated by home users or small businesses (hosts less likely to be maintained by a professional sysadmin) are integral to the robustness of the global Internet. As is the case with biologically active pathogens, vulnerable hosts can and do put everyone at risk, regardless of the significance of their role in the population. fwiw, caida trying to do gentle survey of patching speed, see http://worm-security-survey.caida.org/ k ps: john maddog hall (linux int'l) had a great slide a few months ago at UCSD talk; upshot something like INSTALLED BASE (EARTH) + 20 million linux systems + 450 million gates licenses ==> 4.4 - 6.6 % of the population total ... world population: ~6B ==> 5.4 billion people haven't selected an OS yet [k: maybe we can get them on OS-antioxidants before it's too late] --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

RE: xtra rejecting mail from mailing lists?
by Tech Support 25 Jul '01

25 Jul '01

>On Wed, 25 Jul 2001, Simon Blake wrote: >> I've got a mailing list on one of my servers that appears to have a >> bunch of xtra subscribers on it. Postings to the list get sent to about >> the first 10 xtra users, and then I start getting: >I had someone come up to me with this too. >Apparently when they rang up the helpdesk about it they were told >it wasn't xtra's problem. All I did was suggest they forward the >bounce to postmaster(a)xtra hoping someone does read email there. > >With the 2 examples I saw, it was bouncing emails sent to domains that >were not hosted at xtra. However emails were sent by xtra customers >using xtra's smtp server. One of them tried xtra's smtp server after >they had a problem sending from their own in-house smtp server (thus >eliminating perhaps a possible problem with their server). > >I'll try to get the actual bounce emailed to me. I think it said >something about being unable to relay email > >Lin Hmmm, perhaps Xtra subscribe to ORBS, and have blacklisted their own server..... ;) Peter Gray Telstra Saturn Tech Support E-mail: tech(a)tsnz.net Phone: 0800 949 000 Fax: 04 922 8401 Website: www.netlink.net.nz PO Box 5358, Wellington, New Zealand "Smile," they said "things could be worse!" So I smiled, and things were worse.... --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

'we should all be uncomfortable with the extent to which luck..'
by k claffy 24 Jul '01

24 Jul '01

david moore's analysis of code red: episode 0/1 is at http://www.caida.org/analysis/security/code-red/ [funded by DARPA's ITO office NGI/NMS programs, NSF ANIR, and CAIDA members, david a caida PI] definitely check out jeff brown's animation at bottom; watch carefully around 15:00 for pretty ominous elbow in infection rate (get an epidemiologist to look at it without telling them what it is...) 360,000 machines (well, IP addresses) infected in under 14 hours. from conclusion: // ..in the final analysis, we should all be uncomfortable with the extent to which luck, rather than proactive diligence, maintains the stability of the Internet infrastructure. // it goes without saying that many hosts are still vulnerable. and will likely remain so (to this or the next poison) until our luck runs out. do we expect the next version to have the two weaknesses christopher pointed out today? do we expect the next version won't clear every 3rd bit on the hard drive? almost makes me wonder if some white hat might (should?) have been behind CodeRed as some 'vaccination' attempt. "The bad news is, nobody will do anything about critical infrastructure protection until there's a global catastrophic failure," said Rasch. The good news is, there will be a global catastrophic failure." -- http://www.nando.net/technology/story/44887p-694372c.html the worse news is: protecting 'critical infrastructure' is far from enough. again from http://www.caida.org/analysis/security/code-red/ This assault also demonstrates that machines operated by home users or small businesses (hosts less likely to be maintained by a professional sysadmin) are integral to the robustness of the global Internet. As is the case with biologically active pathogens, vulnerable hosts can and do put everyone at risk, regardless of the significance of their role in the population. fwiw, caida trying to do gentle survey of patching speed, see http://worm-security-survey.caida.org/ k ps: john maddog hall (linux int'l) had a great slide a few months ago at UCSD talk; upshot something like INSTALLED BASE (EARTH) + 20 million linux systems + 450 million gates licenses ==> 4.4 - 6.6 % of the population total ... world population: ~6B ==> 5.4 billion people haven't selected an OS yet [k: maybe we can get them on OS-antioxidants before it's too late] --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Re: anything going?
by Simon Lyall 24 Jul '01

24 Jul '01

On Wed, 25 Jul 2001, Matt Camp wrote: > Anyone know of any jobs going for experienced > IP/Cisco/Lucent/Unix/perl/php/database/networky type engineers that > don't suck? > > This ones getting kinda old, (the job, not the engineer) and the pay is > actually decreasing. You could apply at ihug Matt, someone with NT experience would be useful :) Actually does anyone know the best places to find jobs in the industry? , I notice that Telecom and I assume most of the others don't advertise a lot of their jobs online (or on their own websites). ObOperational: www.whitehouse.gov has akamai's themselves. Resume online here. | | V -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

6 5

Re: anything going?
by Donald Neal 24 Jul '01

24 Jul '01

Simon Lyall: >You could apply at ihug Matt, someone with NT experience would be useful :) >Actually does anyone know the best places to find jobs in the industry? , I >notice that Telecom and I assume most of the others don't advertise a lot >of their jobs online (or on their own websites). Telecom's jobs are at http://telecomnz.hire.com/joblist.html, which is linked to from the official web site. Donald Neal (who works for Telecom but generally does not speak for them) -- Donald Neal Mobility & Calling Platforms Network Delivery Telecom New Zealand Ltd --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

anything going?
by Matt Camp 24 Jul '01

24 Jul '01

Anyone know of any jobs going for experienced IP/Cisco/Lucent/Unix/perl/php/database/networky type engineers that don't suck? This ones getting kinda old, (the job, not the engineer) and the pay is actually decreasing. --- Matt Camp Head Geek Mercury/Quicksilver --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

SuSe Linux Mirrors
by Matthew G Brown 23 Jul '01

23 Jul '01

Anyone Mirroring SuSe 7.x ? , 3.0 isn't cutting the mustard :) Matthew G Brown Tasman Solutions LTD --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Blank vendor letter
by Andrea Moran 23 Jul '01

23 Jul '01

Hi! How are you? I send you this file in order to have your advice See you later. Thanks

5 5

Fax to vendor
by Andrea Moran 23 Jul '01

23 Jul '01

Hi! How are you? I send you this file in order to have your advice See you later. Thanks

5 4

NZNOG Posting Policy
by Donald Neal 23 Jul '01

23 Jul '01

NZNOG People, At present, NZNOG accepts postings from anywhere. A previous effort to switch to accepting mail only from subscribed addresses was abandoned due to the inconveince caused. If anyone wishes another attempt made at that change, please contact me directly. Donald Neal List Administrator -- Donald Neal Mobility & Calling Platforms Network Delivery Telecom New Zealand Ltd --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Antigen found Win32.SirCam.137216 (CA(Vet)) virus
by Antigen 23 Jul '01

23 Jul '01

Antigen for Exchange found Blank vendor letter.doc~pif infected with Win32.SirCam.137216 (CA(Vet)) virus. The file is currently Removed. The message, "Blank vendor letter", was sent from Andrea Moran and was discovered in SMTP Messages\Inbound located at JUNIPER/AMERICAS/BETA. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Antigen found Win32.SirCam.137216 (CA(Vet)) virus
by Antigen 23 Jul '01

23 Jul '01

Antigen for Exchange found Fax to vendor.doc~bat infected with Win32.SirCam.137216 (CA(Vet)) virus. The file is currently Removed. The message, "Fax to vendor", was sent from Andrea Moran and was discovered in SMTP Messages\Inbound located at JUNIPER/AMERICAS/BETA. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

RE: Fax to vendor
by Steven Perich 23 Jul '01

23 Jul '01

Guys, Anyone with half a brain who's concerned about security wouldn't open this, I know, but I thought I'ld inform the masses of this as a friendly, public service announcement :-) Scan type: Realtime Protection Scan Event: Virus Found! Virus name: W32.Sircam.Worm(a)mm File: Fax to vendor.doc.bat Location: Mail System Action taken: Clean failed : Quarantine succeeded : Date found: Tue Jul 24 09:22:26 2001 Steve > -----Original Message----- > From: owner-nznog(a)list.waikato.ac.nz > [mailto:owner-nznog(a)list.waikato.ac.nz]On Behalf Of Andrea Moran > Sent: Tuesday, July 24, 2001 09:06 > To: nznog(a)list.waikato.ac.nz > Subject: Fax to vendor > > > Hi! How are you? > > I send you this file in order to have your advice > > See you later. Thanks > --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

RE: Fax to vendor
by Greg Clare 23 Jul '01

23 Jul '01

WARNING:- This message contained a virus (W32.Sircam.Worm(a)mm). For more details refer:- http://service1.symantec.com/SUPPORT/nav.nsf/aab56492973adccd882569450055235 5/f75929f63f73df5f882569a80022dbd0?OpenDocument Norton Virus definitions dated 17 July 2001 or later will detect this recent worm. Regards Greg > -----Original Message----- > From: Andrea Moran [mailto:andrea(a)petrinamoran.freeserve.co.uk] > Sent: Tuesday, 24 July 2001 9:06 am > To: nznog(a)list.waikato.ac.nz > Subject: Fax to vendor > > > Hi! How are you? > > I send you this file in order to have your advice > > See you later. Thanks > --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

(no subject)
by AngelaMcIntee＠aol.com 23 Jul '01

23 Jul '01

Can anyone tell me the physical address of the Sprint NAP in Pennsauken, NJ? Thanks, Angela --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Julian Angelo - Conclusion
by Donald Neal 22 Jul '01

22 Jul '01

<Multimedia>If you wish this posting to be a multimedia experience, go to http://www.netspace.org/~dmacks/internet-songbook/lart-lart-lart-the-spamme… and sing the contents of that page to yourself while reading.</Multimedia> NZNOG People, Three days ago I posted to this list, saying >Just over a year ago, there was discussion on this list of spamming by >one Julian Angelo. He has now approached me, asking to have these >references removed from the NZNOG archive. It seems that prospective >employers who look up his name on the web find these archive entries, a >fact which may not be helping his career any. >If any network operator has an objection to these entries being removed >from the archive, could they please contact me directly. I had a number of reasons for doing things in this way. For one thing, I do not see myself as owner in the usual sense of that word of this list or its archive. For another, the content of email sent to me in response to such an enquiry might conceivably be actionable. I also take the view that spammers are thieves who must be shown the error of their ways and encouraged to live useful, constructive lives. I am in principle very happy with the idea of editing the names of the guilty out of publicly-readable archives a suitable period after their offending ceases. The chance to gain useful employment would then be one of the reasons why they would give up their vile activities in the first place. My request to be contacted directly was followed by close to fifty emails to the list. Some had particularly disappointing content. The acceptable use policy for this list states that character assassination is unacceptable. It also states that discussion unrelated to Internet technical and operational matters is not appropriate. Discussions of a legal nature are particularly discouraged. This has not been a good week for this list's s/n ratio, nor for constructive discussion. I am all in favour of a certain amount of humour of questionable relevance, but there was little of that here. The only such contribution was Matt Camp's, which observed "I'm sure there's a lesson there. f33r the far-reaching p0w3rz of NZNOG! [...] we shall [...] smite the career prospects of spammers and script kiddies with our flaming LARTting tool of justice!" I have doubts about his spelling of LARTing, but I too am sure there's a lesson here. As I've already said, I see publicity and its withdrawal as a useful tool in encouraging spammers into the paths of righteousness. Regrettably, the point was not taken up by others. My thanks to those who did respond directly to me. The suggestion that by altering the archive's contents on any occasion I might become responsible for all of its content was one I had not previously considered. Other opinions expressed fell into two groups. Some subscribers believed that an apology was called for before Mr Angelo's name was removed from the archive, while others felt that archives should not ever be altered. Some of this latter group observed that archiving an apology from Julian Angelo would give prospective employers a full piucture of events. I count four subscribers in the first group and thirteen in the second. Removing from the count people I believe not to be staff of network operators, and the subscriber who expressed both opinions, leaves three in the first group and eight in the second. I feel myself to be bound by this expression of the views of subscribers, and will not seek to have the archives changed. At no point has anyone even implied to me that Julian Angelo has done anything wrong since the events of July 2000. I went into this thinking that was the question. Donald Neal List Administrator/Muggins <Multimedia>You can stop singing now.</Multimedia> -- Donald Neal Mobility & Calling Platforms Network Delivery Telecom New Zealand Ltd --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

12 21

[dranch@trinnet.net: How the IIS Red Worm works..]
by Dean Pemberton 21 Jul '01

21 Jul '01

> so which ISP in Wellington was it that is reported to have lost its servers > as a result of thei worm (reported in the Herald).... and did it really > infect/affect 250000 sites? > > Ian Dunno about the first one - but there is a portion in this article that talks to your second point. Dean ----- Forwarded message ----- Interesting.. From http://www.w2knews.com/subscribe.cfm?id=W2K -- Explanation As stated earlier the .ida "Code Red" worm is spreading throughout IIS Web servers on the Internet via the .ida buffer-overflow attack that was published last month. The following are the steps that the worm takes once it has infected a vulnerable Web server: Setup initial worm environment on infected system. Setup 100 threads of the worm. Use the first 99 threads to spread the worm (infect other Web servers). � The worm spreads itself by creating a sequence of random IP addresses. However, the worm's list of IP addresses to attack is not all together random. In fact, there seems to be a static seed (a beginning IP address that is always the same) that the worm uses when generating new IP addresses. Therefore every computer infected by this worm is going to go through the same list of "random" IP addresses. Because of this feature, the worm will end up re-infecting the same systems multiple times, and traffic will cross traffic back and forth between hosts ultimately creating a denial-of-service type effect. The denial-of-service will be due to the amount of data being transferred between all of the IP addresses in the sequence of random IP addresses. The worm could have done truly random IP generation and that would have allowed it to infect many more systems much faster. We are not sure why this was not done, but a friend of ours did pose an interesting idea: If the person who wrote this worm owned an IP address that was one of the first hundred or thousand to be scanned, then they could setup a "sniffer" and anytime and IP address tried to connect to port 80 on their server they would get confirmation that the IP address that connected to them was infected with the worm. With this knowledge, they would be able to create a list of the majority of systems that were infected by this worm. The 100th thread checks to see if it is running on an English (US) Windows NT/2000 system. � If the infected system is found to be a English (US) system, the worm will proceed to deface the infected system's website. The local Web server's Web page will be changed to a message that says: "Welcome to http://www.worm.com!, Hacked By Chinese!". This hacked Web page message will stay "live" on the Web server for 10 hours and then disappear. The message will not appear again unless the system is re-infected by another computer. � If the system is not an English (US) Windows NT/2000 system, the 100th worm thread is also used to infect other systems. Each worm thread checks for c:\notworm. � If the file c:\notworm is found, the worm goes dormant. � If the file is not found, each thread will continue to attempt to infect more systems. Each worm thread checks the infected computer's system time. � If the date is past the 20th of the month (GMT), the thread will stop searching for systems to infect and will instead attack www.whitehouse.gov. The attack consists of the infected system sending 100k bytes of data (1 byte at a time + 40 bytes overheard for the actually TCP/IP packet) to port 80 of www.whitehouse.gov. This flood of data (410 megabytes of data every 4 and a half hours per instance of the worm) would potentially amount to a denial-of- service attack against www.whitehouse.gov. � If the date is between the 1st and the 19th of the month, this worm thread will not attack www.whitehouse.gov and will continue to try to find and infect new Web servers. We have calculated that the worm can attempt to infect roughly half a million IP addresses a day. This is a rough estimate generated by testing on a very slow network. At the time of writing this document (July 19th, 3:00pm), we have had reports from administrators that have been probed by over 196 thousand unique hosts. This leads us to believe that this worm has infected at least 196 thousand computers. During testing we noticed that sometimes the worm does not execute "normally" and will continue to spawn new threads until the infected machine crashes and has to be rebooted, effectively killing itself. We have not been able to isolate the cause of this behavior. ----- End forwarded message ----- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

RE: the .ida "Code Red" worm - ISP suffers?
by PhoneNet 21 Jul '01

21 Jul '01

so which ISP in Wellington was it that is reported to have lost its servers as a result of thei worm (reported in the Herald).... and did it really infect/affect 250000 sites? Ian --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

China-diesel fuel injection 7/20
by china-lutong.com 20 Jul '01

20 Jul '01

hi: My name is ChenHua, and I'm writing on behalf of the China-Lutong mechanical company. Located in the south east of China, we specialize in hydraulic heads for the VE distributor pump. We can supply standard, good quality units at a very competitive price. The following types are available: Engine model VE PUMS code NO UNIT PRICE(EX WORK) ISUZU 4JB1 NP-VE4/11F1800LNP777 146402-0920 $USD40 ISUZU 4JB1 NP-VE4/11L(DENSO) 096400-1600 $USD40 ISUZU 4JB1 NP-VE4/11R 146402-0820 $USD45 ISUZU 4JA1 NP-VE4/11R 146402-3820 $USD45 ISUZU 4JA1 NP-VE4/12R 146430-1420 $USD45 CUMMINS 6BT NP-VE6/12F1050R381-7 1 468 336 423 $USD45 IVECO 8140 NP-VE4/11FR1900R127 1 468 334 798 $USD45 We use precision forging technology to create our products and surface treat them using an imported shot-blasting machine. The constant grinding process guarantees identical clearance in each plunger. Because we have been in the field of diesel fuel injection systems for quite a few years, we are acquainted with many domestic manufacturers of, and sales agents for, parts such as injector nozzles, plungers, delivery valves and so on. If you are interested in our products, please contact me. Thank you for your interest in our company. Best regards! C.Hua Sale & purchasing department director HTTP://WWW.China-LuTong.COM C.H(a)CHINA-LUTONG.COM

1 0

Full analysis of the .ida "Code Red" worm.
by Chris Rigby 19 Jul '01

19 Jul '01

I think this is something we should all be aware of for those of you not on bugtraq (which I hope most of you are.) This attack has gone from something like 0 hits in my web logs yesterday to 11 in the last 4 hours Some people are estimating over 12,000 hosts infected already. Also to worry about are later announcements that : "A notable side effect of this.. the worm signature is wreaking havoc with Cisco 675, 677, and 678 DSL routers that have the Web Based Configuration Interface enabled." since they lock up when "?" is sent to them in a URL. And apparently has issues for some 7500 size routers. The main thing I'm concenred over is that the worm is programmed to flood www.whitehouse.gov between 20:00pm and 23:59 (local system time). I'm not looking forward to what effect this might have on the internet. Escpecially the small outbound links in NZ. Chris Rigby Senior Systems Engineer IHUG - Into the Internet ---------- Forwarded message ---------- Date: Wed, 18 Jul 2001 22:40:11 -0700 From: Marc Maiffret <marc(a)eeye.com> To: BUGTRAQ <BUGTRAQ(a)securityfocus.com> Subject: Full analysis of the .ida "Code Red" worm. The following is a detailed analysis of the "Code Red" .ida worm that we reported on July 17th 2001. This analysis was performed by Ryan Permeh and Marc Maiffret of eEye Digital Security. The disassembly (complete with comments) was done by Ryan "Shellcode Ninja" Permeh. Table of Contents ================= 1. Introduction 2. Explanation 3. Commentary 4. Deep Analysis 5. Conclusion 6. Appendix 7. Credits You can get a copy of this analysis, commented disassembly, full IDA database, and binary of worm from http://www.eeye.com/html/advisories/codered.zip Introduction ============ On Friday July 13th we received packet logs and information from 2 network administrators that were experiencing large amounts of attacks targeting the recent .ida vulnerability that eEye Digital Security discovered (http://www.eeye.com/html/Research/Advisories/AD20010618.html) on June 18, 2001. After reviewing the logs sent to us we determined that in fact someone had released a worm into the Internet that was spreading rapidly through IIS web servers. The full analysis of the .ida "Code Red" worm has provided numerous new details as to the functionality and method of propagation of this worm. For instance this worms purpose ultimately seems to be to perform a denial of service attack against www.whitehouse.gov. Also it has been found that only US English Windows NT/2000 systems will show the defaced ("Hacked by Chinese !") web page. We've designated this the .ida "Code Red" worm, because part of the worm is designed to deface web pages with the text "Hacked by Chinese" and also because code red mountain dew was the only thing that kept us awake all last night to be able to disassemble this exploit even further. Explanation =========== As stated earlier the .ida "Code Red" worm is spreading throughout IIS web servers on the Internet via the .ida buffer overflow attack that was published weeks ago. The following are the steps that the worm takes once it has infected a vulnerable web server. 1. Setup initial worm environment on infected system. 2. Setup a 100 threads of the worm 3. The first 99 threads are used to spread the worm (infect other web servers). -The worm spreads itself by creating a sequence of random IP addresses. However, the worm's randomization of IP addresses to attack is not all together random. In fact there seems to be a static seed that the worm uses when generating new IP addresses to try to attack. Therefore every computer infected by this worm is going to go through the same list of random IP addresses to try to infect. The "problem" with that is that the worm is going to end up reinfecting systems and also end up crossing traffic back and forth between hosts to end up creating a denial of service type affect because of the amount of data that will be transferred between all the IP addresses in the sequence of random IP addresses. The worm could have done truly random IP generation and that would have allowed it to infect a lot more systems a lot faster. We are not sure why that was not done but a friend of ours did pose an interesting idea... If the person who wrote this worm owned an IP address that was one of the first hundred or thousand etc... to be scanned then they could setup a sniffer and anytime and IP address tried to connect to port 80 on their IP address they would know that the IP address that connected to them was infected with the worm and they would therefore be able to create a list of the majority of systems that were infected by this worm. 4. The 100th thread checks to see if it is running on a English (US) Windows NT/2000 system. -If the infected system is found to be a English (US) system then the worm will proceed to deface the infected systems website. That means... the local web servers web page will be changed to a message that says Welcome to http://www.worm.com !, Hacked By Chinese!. This hacked web page message will stay "live" on the web server for 10 hours and then disappear and never appear again unless the infected system is re-infected by another host. -If the system is not a English (US) Windows NT/2000 system then the 100th worm thread is also used to infect other systems. 5. Each worm thread checks for c:\notworm -If the file c:\notworm is found, the worm goes dormant. -If the file is not found then each thread will continue to attempt to infect more systems. 6. Each worm thread will now check the infected computers time. -If the time is between 20:00 UTC and 23:59 UTC then the worm will proceed to use this thread to attack www.whitehouse.gov. The attack consists of the infected system sending 100k bytes of data to port 80 of www.whitehouse.gov therefore potentially performing a denial of service attack against www.whitehouse.gov. -If the time is below 20:00 UTC then this worm thread will try to find and infect new web servers. In testing we have calculated that the worm can attempt to infect roughly half a million IP addresses a day and that was a ruff estimate made from using a very slow network. As of writing this document (July 18 6:49pm) we have had reports from administrators that have been probed by over 12 thousand unique hosts. That basically means at least 12 thousand hosts have been infected by this worm. In testing we have seen that sometimes the worm does not execute correctly and will continue to spawn new threads until the infected machine crashes and has to be rebooted. We have not been able to isolate the cause of this behavior. Commentary ========== As we sat and watched this worm spread itself through the Internet we were somewhat dumbfounded as to the number of reported systems being infected. The main reason for that is that this worm is using a, what we thought to be, very well known vulnerability. A patch for this vulnerability has been available for over a month now and at the time of the release of the vulnerability many news agencies ran stories about it therefore trying to spread awareness. Even with all of that though there have still been, at the very least, 12 thousand web servers infected by this worm. So we once again encourage administrators to pay attention to security issues and patch their systems as soon as patches are available for holes. All of this research would not be available if we were not a Full Disclosure company and if the many people who helped us research this worm were against full disclosure. Although we did not release any exploit code for the .ida vulnerability, the computer underground still had no problem creating a devastating worm. In the past we have seen a much higher percentage of patched systems when example exploit code was provided. System administrators do not believe vulnerabilities exist without a public exploit, or until something like this worm happens forcing them to patch their systems. We feel that if the security community moves away from Full Disclosure more incidents like this will happen and everyone will be left in the dark as to what is going on. An example of why full disclosure is so important would be this worm itself. Chances are this worm would have not been discovered if we had not fully disclosed details about the .ida vulnerability, allowing Intrusion Detection System vendors to create signatures for the .ida buffer overflow attack. Because of the way that IIS performs logging (logging a request after processing it), servers hit with this worm will actually have no traces of information left in the IIS log files making tracking this worm (via IIS logs) virtually impossible. The first instances of _anyone_ learning anything useful about this worm was via Intrusion Detection Systems that had signatures based on our .ida vulnerability research which would not have been there if not for full disclosure. The computer underground continues to find vulnerabilities everyday. If full disclosure goes away, then the general security community is left in the dark, and therefore so are administrators. More and more we are seeing an increase in worms attacking the Internet. There have been about 2 or 3 worms in as many months. Worms force computer security to become a global issue. With the rise of the Internet, not only do you have to worry about securing your own systems, you must also be careful of your "neighbors" systems. For instance with this worm even if you have done everything right (installed the .ida patch etc...) your network connection could still be taken down because of the amount of data flooding you from all of the "other guys" who hadn't applied patches and were infected by this worm. It is important to not only maintain your own security but make sure that other people you come in contact with secure their sites. Only with global cooperation to maintain security will the threat of worms start disappear. We received information from "friends" that leads us to believe that this worm is actually a derivative of another worm which was written to exploit the first ever remote IIS buffer overflow (also discovered by eEye Digital Security), the .htr buffer overflow. From reports, the .htr worm had a much smaller infection base and seemed to go under the radar probably because the .htr vulnerability was/is very old. Deep Analysis ============= The following is a very detailed analysis of what the worm is doing at each step of its infection. Full disassembled and commented worm code is available at our website at http://www.eeye.com/html/advisories/codered.zip. It will be provided as both a assembly text dump and as a IDA (Interactive Disassembler) database file. We have chosen not distribute the worm code in this eMail as to not clog up your bandwidth anymore then we already are >:-] Note: We will use CODEREF comments in the analysis to reference where we are in the disassembled code so you can "follow along" with us. The tools that we used to perform this detailed analysis were: IDA (Interactive Disassembler) from www.datarescue.com. IDA is an advanced disassembler that made this analysis possible. MS VC++ debugging environment. We used this to monitor modified pieces of the worm as they interacted with IIS. Ryan's brain + Marc's brain + private eEye tools. No... you cant have any of those. We will be heavily referencing the disassembled worm code in the following analysis. In an attempt to make this easier to understand we have broken the functionality of the worm into 3 parts. The core worm functionality, the worm hack web page functionality and the attack www.whitehouse.gov functionality. Core worm functionality ----------------------- 1. Initial infection vector (i.e. host is vulnerable to the .ida attack and gets hit with this worm). The initial infection starts to take place when a web server, vulnerable to the .ida attack, is hit with a HTTP get request that contains the necessary code to exploit the .ida attack and uses this worm as its payload. At the time of the .ida overflow a systems stack memory will look like the following: <MORE 4E 00> 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 92 90 58 68 4E 00 4E 00 4E 00 4E 00 4E 00 4E 00 FA 00 00 00 90 90 58 68 D3 CB 01 78 90 90 58 68 D3 CB 01 78 90 90 58 68 D3 CB 01 78 90 90 90 90 90 81 C3 00 03 00 00 8B 1B 53 FF 53 78 EIP is overwritten with 0x7801CBD3 which an address within msvcrt.dll. The code at 0x7801CBD3 disassembles to: call ebx When EIP is overwritten with call ebx it then causes program flow to divert back to the stack. The code on the stack jumps into the worm code that's held in the body of the initial HTTP request. 2. Sets up some initial stack variables CODEREF: seg000:000001D6 WORM At this point we are executing the initial code of the worm. The first thing to happen is that the worm sets up a new stack for its own use. The new stack is 218h bytes, filled with CCh. The worm code then moves on to initialize its function jump table. The entire worm heavily uses an EBP stack based memory offset system. This means that all variables are referenced as EBP-X values. On our website we have a document called worm-ebp.txt that attempts to track stack usage throughout the course of the worm code. 3. Load functions (create the "jump table") CODEREF: seg000:00000203 DataSetup The first thing the worm code does is reference the data portion of the exploit code at EBP-198h. The worm then needs to setup its internal function jump table. A function jump table is a stack based table used to store function addresses. It allows the worm to generate the function addresses at run time (This makes the worm have a better chance of executing cleanly on more systems). The technique used by this worm is what is called an RVA (Relative Virtual Addresses) lookup. Basically this means that all functions, or specifically GetProcAddress, are found within IIS itself. For more details on RVA please consult any good PE (Portable Executable, the executable file format for Microsoft platforms) documentation, or read through the assembly code of this worm. In a nutshell, RVA techniques are used to get the address of GetProcAddress. GetProcAddress is then used to get the address of LoadLibraryA. Between these two functions all other functions that the worm may need can be easily found. The worm uses these two functions to load the following functions: >From kernel32.dll: GetSystemTime CreateThread CreateFileA Sleep GetSystemDefaultLangID VirtualProtect >From infocomm.dll: TcpSockSend >From WS2_32.dll: socket connect send recv closesocket Finally the worm stores the base address of w3svc.dll which it will later use to potentially deface the infected website. 4. Check the number of threads the worm has created. CODEREF: seg000:00000512 FUNC_LOAD_DONE Here the worm seems to perform a WriteClient (Part of the ISAPI Extension API), sending "GET" back to the attacking worm. This possibly could be a way of telling attacking worms that they have successfully infected a new host. Next the worm code will count the number of worm threads already in action. If the number of threads is 100 then control is shifted to the Worm hack web page functionality. If the number of threads is below 100 then the worm creates a new thread. Each new thread is an exact replica of the worm (Using the same code base). The worm now continues its path of execution. 6. Checks for the existence of c:\notworm CODEREF: seg000:0000079D DO_THE_WORK There seems to be a to be built in "lysine deficiency" (See Jurassic Park, or Caesar's paper on this at www.rootkit.com) A "lysine deficiency" is a built in check to keep malicious code from spreading further. In this case the "lysine deficiency" is a check for the existence of the file c:\notworm. If this file exists then the worm will become dormant. This means it will not attempt to make connections out to other IP addresses to try to infect. If this file does not exist then the worm continues onto the next step. 7. Check the infected systems time (computer clock) CODEREF: seg000:00000803 NOTWORM_NO The worm will now check the infected systems local time (in UTC). If the hour is greater then 20:00 UTC then the worm will proceed to goto the first step of the attack www.whitehouse.gov functionality. If the time is less than 20:00 UTC then the worm will attempt to continue to try to infect new systems. 8. Infect a new host (send .ida worm to a "random" IP address on port 80). At this point the worm will resend itself to any IP addresses which it can connect to port 80 on. It uses multiple send()'s so packet traffic may be broken up. On a successful completion of send, it closes the socket and goes to step 6... therefore repeating this loop infinitely. Worm hack webpage functionality ------------------------------- This functionality is called after a hundred threads are spawned within the worm. 1. Check if local system default language is English us then goto step 6 of core worm functionality. CODEREF: seg000:000005FE TOO_MANY_THREADS The first thing the worm does is get the local codepage. A codepage specifies the local operating system language (I.E. English (US), Chinese, German etc...). It then compares the local codepage against 0x409. 0x409 is the codepage for English (US) systems. If the infected system is an English (US) system then the worm will proceed to deface the local systems webpage. If the local codepage is not English (US) then this worm thread will goto step 6 of core worm functionality. 2. Sleep for 2 hours. CODEREF: seg000:00000636 IS_AMERICAN This worm thread now sleeps for 2 hours. We anticipate that this is to allow the other worm threads to attempt to spread the infection before making a presence known via defacing the infected systems webpage. 3. Attempt to modify infected systems webpages in memory. CODEREF: seg000:0000064F HACK_PAGE This worm uses an interesting technique called "hooking" to effectively deface (alter) an infected systems webpages. Hooking is modifying code in memory to point to code that the worm provides. In this case the worm is modifying w3svc.dll to change the normal operation of a function called TcpSockSend. TcpSockSend is what w3svc.dll (IIS core engine) uses to send information back to the client. By modifying this, the worm is able to change data being written back to clients who request web pages of an infected server. To perform hooking, first the worm makes the first 4000h bytes of w3svc.dll's memory writable. In a normal situation the memory for w3svc.dll (and basically all mapped dll's) is read-only. It uses the function VirtualProtect to change the memory of w3svc.dll to be writable, saving the old state to a stack variable. It then uses the saved codebase of w3svc.dll (from step 3 of core worm functionality) as a start point to search the import table (again see PE header documentation) for the address of TcpSockSend. Once the address for TcpSockSend is located the worm then replaces TcpSockSend's actual address with an address within the worm. The address that TcpSockSend now points to is a function within the worm that will return the "Hacked by Chinese !" webpage. The CODEREF for this function is seg000:00000C9A FAKE_TCPSOCKSEND. This thread of the worm now sleeps for 10 hours. During this 10 hours all web requests to the infected server will return the "Hacked by chinese !" webpage. After the 10 hours is up this thread will return w3svc.dll to its original state, including re-protecting memory. Execution after this proceeds to step 6 of the core worm functionality. Attack www.whitehouse.gov functionality --------------------------------------- Sooner or later every thread within the worm seems to shift its attacking focus to www.whitehouse.gov. 1. create socket and connect to www.whitehouse.gov on port 80 and send 100k byes of data CODEREF: seg000:000008AD WHITEHOUSE_SOCKET_SETUP Initially the worm will create a socket and connect to 198.137.240.91 (www.whitehouse.gov/www1.whitehouse.gov) on port 80. CODEREF: seg000:0000092F WHITEHOUSE_SOCKET_SEND If this connection is made then the worm will create a loop that performs 18000h single byte send()'s to www.whitehouse.gov. CODEREF: seg000:00000972 WHITEHOUSE_SLEEP_LOOP After 18000h send()'s the worm will sleep for about 4 and a half hours. It will then repeat the attack against www.whitehouse.gov (goto step one of Attack www.whitehouse.gov functionality). Appendix ======== This is associated information about the "Code Red" worm including how to stop the worm, commentary on the worm, and dispelling common misconceptions about this worm. How to secure your system from this .ida "Code Red" worm? --------------------------------------------------------- Microsoft patch for this .ida vulnerability http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/ bulletin/MS01-033.asp The worm spreads itself to new vulnerable systems via the .ida vulnerability. Applying this patch will keep your server from being infected. However, as stated earlier, because of the way the worm creates its list of "random" IP addresses to attack, you could still be affected by a high traffic overload denial of service. eEye Digital Security Advisory for .ida vulnerability http://www.eeye.com/html/Research/Advisories/AD20010618.html We initially discovered the .ida vulnerability which is being used by this worm as its infection vector. The above advisory details our research of that specific vulnerability. We worked with Microsoft to help them create a patch for the .ida vulnerability. SecureIIS - Application firewall, stops known and unknown IIS vulnerabilities. http://wwww.eeye.com/secureiis We do produce a product that protects IIS web servers from attack which is one of the reasons that we were so quick to research this worm. Funny enough in our initial testing we couldn't get the worm to work because we forgot we had SecureIIS enabled on the lab web server. heh. I have been infected by this worm what can I do? ------------------------------------------------ The first thing you must do is goto the Microsoft security site, as referenced above, and install the .ida patch ASAP. The worm will remain in memory until you reboot your server so make sure to reboot after installing the .ida patch. I think I am infected, how can I tell? -------------------------------------- An infected system will show an increase in load (processor/network). It will also show a number of external connections (or attempts) to port 80 of random IP addresses. You can see this by doing a "netstat -an" from a MS-DOS prompt. Either way do not take any chances... if your system is missing the .ida patch then install it ASAP and reboot. How to setup your IDS to detect this specific worm? --------------------------------------------------- The following is part of the packet data that is sent for this .ida "Code Red" worm attack: GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3% u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0 Just add that to your IDS signature database. What are some common misconceptions about the "Code Red" worm? -------------------------------------------------------------- 1. It connects to worm.com. This worm only specifies www.worm.com in the initial HTTP GET request HOST: header and in the defaced page show on English (US) systems. This worm does _not_ connect to www.worm.com. This worm operates completely independent and can spread and infect systems without having a single point of failure. What that means is that this worm will be wild on the Internet until there is a _VERY_ high degree of systems that go and install the .ida patch. 2. This worm is based off of hsj's "proof of concept" .ida exploit. This worm is _NOT_ based off of hsj's "proof of concept" .ida exploit. His exploit code had no worm functionality. It was a simple exploit shell that had little to no implicit functionality. It was designed to prove to administrators the seriousness of this vulnerability so that they would install patches ASAP. Credits ======= Ken Eichman of Chemical Abstracts Service Matthew Asham of Left Coast Systems Corp and a large handful of administrators who gave us much needed data to piece this together. Signed, eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities "Its not a virus! Its a worm!" - z3r0 c00l "Whats this one eat?" - l0rd n1k0n "th1s 0n3 34ts 11S s3rv3rs!" - ch4m3l30n h4ck3rs --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

17 35

Code Red --- request for logs (from NANOG)
by Chris Wedgwood 19 Jul '01

19 Jul '01

>From NANOG: From: "Steven M. Bellovin" <smb(a)research.att.com> To: nanog(a)merit.edu Cc: Balachander Krishnamurthy <bala(a)research.att.com> Subject: Re: Code Red -> Router Memory depletion? Date: Thu, 19 Jul 2001 20:39:31 -0400 Message-Id: <20010720003931.77D057B57(a)berkshire.research.att.com> X-Mailer: exmh version 2.1.1 10/15/1999 A colleague of mine, Balachander Krishnamurthy, is looking for Web server logs from sites that have been attacked by Code Red. He's working on analysis techniques to detect flash crowds, DDoS attacks, etc. Please reply directly to him (bala(a)research.att.com) if you can supply any data. (You can see the kind of stuff he's been doing by looking at some of his recent papers, at www.research.att.com/~bala/papers) --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0