Re: Cogent
Dave, It looks like Cogent still has connectivity via the old NetRail network: * 38.8.50.0/24 0.0.0.0 100 0 701 4006 16631 i * 38.8.81.0/24 0.0.0.0 100 0 701 4006 16631 i * 38.8.82.0/24 0.0.0.0 100 0 701 4006 16631 i * 38.8.84.0/24 0.0.0.0 100 0 701 4006 16631 i * 38.8.92.0/24 0.0.0.0 100 0 701 4006 16631 i * 38.8.93.0/24 0.0.0.0 100 0 701 4006 16631 i * 38.9.96.0/24 0.0.0.0 100 0 701 4006 16631 i * 38.9.124.0/240.0.0.0 100 0 701 4006 16631 i * 38.9.128.0/240.0.0.0 100 0 701 4006 16631 i * 38.9.129.0/240.0.0.0 100 0 701 4006 16631 i * 38.9.130.0/240.0.0.0 100 0 701 4006 16631 i * 38.9.203.0/240.0.0.0 100 0 701 4006 16631 i * 38.9.204.0/240.0.0.0 100 0 701 4006 16631 i * 38.9.206.0/240.0.0.0 100 0 701 4006 16631 i and so on... Where specifically did you see they 'lost' the connectivity? charles On Mon, Feb 24, 2003 at 10:19:44AM -0500, David Reale wrote: > >Has any one else noticed Cogent's loss of UUnet routes. It appears >that they may have lost UUnet early Friday. > > >David
Re: Symantec detected Slammer worm "hours" before
> http://www.theregister.co.uk/content/56/29406.html Interesting. So they meant they got IDS "hits" hours before anyone posted a full description of the attacks to bugtraq when they said they had detected the worm hours before it spread? That's a novel use of english :)
RE: Homeland Security Alert System
On Mon, 24 Feb 2003, St. Clair, James wrote: > ..Once again, reason to pursue getting involved with the Telecomm ISAC. Or FIRST, IT-ISAC, MSC-ISAC, WW-ISAC, ISP-ISAC, IOPS,
Re: untied
I just called the IT help desk at corporate HQ (847-700-4000) and forwarded them the summary of the groups concerns, so its up to UAL now what to do about this. Todd Glassey - Original Message - From: "Ron da Silva" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 24, 2003 6:55 AM Subject: Re: untied > > > Hmm...I've called one of their 800's before and had an > option to select "3" to complain (er I mean talk to someone) > about their website. Maybe you can reach someone who > knows someone with a clue that way... > > -ron
Re: Symantec detected Slammer worm "hours" before
Another anomaly detection product and its proactive/reactive response to the Slammer Worm. http://www.q1labs.com/qvision_slammer_white_paper.pdf Glen - Original Message - From: "Terry Baranski" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 4:37 PM Subject: RE: Symantec detected Slammer worm "hours" before > > Apologies if this is old news. It's from Thursday, but I didn't see it > until today. > > Symantec comes clean Somewhat: > > http://www.theregister.co.uk/content/56/29406.html > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Sean Donelan > Sent: Thursday, February 13, 2003 12:00 PM > To: [EMAIL PROTECTED] > Subject: Symantec detected Slammer worm "hours" before > > > > > Wow, Symantec is making an amazing claim. They were able to detect the > slammer worm "hours" before. Did anyone receive early alerts from > Symantec about the SQL slammer worm hours earlier? Academics have > estimated the worm spread world-wide, and reached its maximum scanning > rate in less than 10 minutes. > > I assume Symantec has some data to back up their claim. > > http://enterprisesecurity.symantec.com/content.cfm?articleid=1985&EID=0 > "For example, the DeepSight Threat Management System discovered the > Slammer worm hours before it began rapidly propagating. Symantec's > DeepSight Threat Management System then delivered timely alerts and > procedures, enabling administrators to protect against the attack > before their environment was compromised." >
Cogent
Has any one else noticed Cogent’s loss of UUnet routes. It appears that they may have lost UUnet early Friday. David
Re: The good old days (was Re: M$SQL cleanup incentives)
Sean, Plus ca change, plus c'est le meme chose. Of course the past is with us: look at Bob Metcalfe's RFC 602 (1973). Have we fixed anything over the nearly 30 years? How recently have you seen a password on a Post-It? How many folks have their spouse's/significant other's/ offspring's name as a password? How many uninstalled fixes can dance on a port? Peter
Re: untied
Hmm...I've called one of their 800's before and had an option to select "3" to complain (er I mean talk to someone) about their website. Maybe you can reach someone who knows someone with a clue that way... -ron
RE: Homeland Security Alert System
..Once again, reason to pursue getting involved with the Telecomm ISAC. Jim -Original Message- From: Sean Donelan [mailto:[EMAIL PROTECTED] Sent: Saturday, February 22, 2003 6:47 PM To: [EMAIL PROTECTED] Subject: Re: Homeland Security Alert System I'm certain the government folks working to protect us 24x7 are doing everything they can, but the fact of the matter is the public alert systems in the US suck. Some just suck less. http://www.nj.com/news/gloucester/index.ssf?/base/news-0/104590500555170.xml "Butts said he often finds out about things like the change in the national threat level on CNN hours before the Communications Center receives a teletype about it." Butts is the Gloucester County Emergency Response Coordinator including the county 9-1-1 communications center. ISPs and other communication providers should be prepared to share information directly and quickly with each other. If you wait to hear from government officials to decide what sanitized information to share, it will be hours later. If ever.
Re: 223.255.255.0/24 (fwd)
RFC3330 issued in September 2002 does indicate that this address block
is subject to future allocations. But I think people were expecting
something from the IAB/IETF before IANA actually allocated previous
special use reserved address blocks. My understanding was RFC3330 was
written by IANA and published by IANA to document existing practices, not
to change previous practices. Eventually we'll use it.
The simpliest solution is for IANA to inform APNIC that it was an
oversight. The 223.255.255.0/24 network block within the 223/8 CIDR block
assigned to APNIC is still IANA-RESERVED per RFC3330 and previous
practice; and not allocated for APNIC's use at this time.
Its probably easier for APNIC to flag the 223.255.255.0/24 network within
the CIDR block 223/8 as IANA-RESERVED in the APNIC database just like
ARIN does with the other IANA-RESERVED blocks in ARIN's database; rather
than do the ugly CIDR block breaking of 223.0.0.0-223.255.254.255 and
223.255.255.0-223-255.255.255. But that is a decision for APNIC.
On Mon, 24 Feb 2003, Geoff Huston wrote:
> My interpretation of this is that the IETF, by publishing an RFC with an
> "IANA Considerations" section can nominate that an address block
> declared allocatable under certain criteria, or they can "reserve" the prefix.
>
> "reserving" in my mind constrains IANA from undertaking any activity
> on this block, and this is the state until the IETF elects to produce
> a successor document with an IANA Considerations section that nominates
> some other status to the block.
>
> "Reserved" blocks in my opinion cannot be passed to RIRs, or anyone
> else - the IANA cannot do anything with the block other than register its
> reserved status, and this can only be undone by an action of the IETF.
>
> Hence, my reading of the IANA registry:
> http://www.iana.org/assignments/ipv4-address-space
> is that this is a flawed implementation of the instructions in RFC 3330,
> and that
> the 233.255.255.0/24 should be listed IDENTICALLY to 128.0.0.0/16
>
> i.e. its status is actually:
> 223.255.255/25 IANA - Reserved - RFC 3330
>
> if the IANA is to consistently act upon RFC 3330 (as indeed it should)
>
> Perhaps the IETF folk on this message should review the RFC and the IANA
> registry and see if they agree with this interpretation, and make their
> conclusion
> as to the accuracy of the registry as it is currently published:
>
>("223/8 Feb 03 APNIC (whois.apnic.net)")
>
> My view is that this block as properly "Reserved", and that the "subject to
> allocation"
> is an addendum that indicates a forward intention of the IETF, but not a
> capability
> for any IANA action.
>
> As my only humble suggestion, perhaps the best thing right now is for the
> APNIC folk
> to refrain from any assignment actions regarding this prefix until the IETF
> folk and the
> IANA sort out this inconsistency in the interpretation of RFC 3330.
>
>Geoff
>
>
>
> >Date: Mon, 24 Feb 2003 00:32:47 -0500 (EST)
> >From: Sean Donelan <>
> >To:
> >Cc:
> >Subject: Re: 223.255.255.0/24
> >
> >On Sun, 23 Feb 2003 [EMAIL PROTECTED] wrote:
> > > why would an APNIC/AP region specific issue need to be discussed
> > > on the NANOG list and not the RIPE/AFNOG/et.al. regional ops lists?
> > > This is a prefix delegated to the APregion and so they should be
> > > the ones who set the policies for the prefixes they are responsible
> > > for. I appreciate their willingness to share the outcome of their
> > > deliberations, but why NAites have any special say in AP policies
> > > is a bit beyond me.
> >
> >The question is really whether IANA properly implemented the relevant
> >RFC's by delagating a block containing a reserved special use address to a
> >registry without maintaining the previous reservations on those addresses.
> >
> >Its not up to APNIC how to handle the reserved special use addresses, just
> >like the other special use addresses in ARIN's space are really outside
> >of ARIN's scope. ARIN can't re-assign special use addresses in "its"
> >space for other purposes. Nor should APNIC or RIPE or LANIC or any other
> >registry which is assigned a /8 block containing special use addresses.
> >
> >Its not APNIC bashing. If the ARIN board got to gether and decided to
> >assign 128.0.0.0/16 I think folks would be raising questions about ARIN.
> >
> >IANA should have properly excluded the IANA reserved special use block
> >from the delegation to APNIC, just like the other reserved special use
> >blocks are reserved from ARIN's use.
>
>
>
>
The good old days (was Re: M$SQL cleanup incentives)
On Sat, 22 Feb 2003, William Allen Simpson wrote: > > I see. So you're still filtering port 25 from the Morris sendmail worm. > > Funny thing, I was a researcher visiting at Cornell, and had just left > in the car for the 9.5 hour drive home when it struck. I've often > wished I'd stuck around for a few more hours for the excitement. > > Anyway, we didn't need to put in a long term block, as everyone took > down their systems and cleaned them. I didn't even find out about the > problem until over a day later, by which time it was long gone. > > Ah, the days when we all cooperated In 1988 we had ad-hoc responses, with people posting to various USENET newsgroups or some mailing lists still working, about what they were seeing and how to fix it. There was no CERT, BBN (and others) disconnected from the net (and took many people downstream with them), even though most people knew each other they didn't all have alternate contact information, and most of the methods the Morris worm used in 1988 are still being used *effectively* today. 1) Backdoor in SENDMAIL 2) Buffer overflow in Fingerd 3) Password guessing in Rsh/Rexec Some people blocked the ports used. Some people still block ports such as Finger (79) and rsh/rexec (513/514). But generally ports were blocked by the local institution, not on the ARPANET. The version numbers change, the executables change, but the basic problems haven't changed in 30 years. We still have backdoors, buffer overflows and pasword guessing. We still have ad-hoc response by people sharing solutions on mailing lists. The people who cut themselves off from the open process are still slower to get stuff fixed. And we still have weak methods for contacting people through alternate methods. I wish it was as easy as paying a managed security company to watch out for me. But unfortunately, paying several thousand dollars for the privilege of getting "confidential alerts" which look amazingly similar to what I wrote on a public mailing list a few hours earlier is a bit silly.
