Re: Fwd: A warning from Register.com, Inc.

[Richard A Steenbergen]

On Sat, Feb 22, 2003 at 12:57:32AM -0500, David Diaz wrote:
> Thought this might be important.  If anyone has any more information 
> please post.

Whoa. Wait a minute. You mean there are people going around pretending to
be some legitmate organization and asking for peoples credit cards? *gasp*
Say it's not so... Quickly, to the NANOG-mobile...

Next you'll be telling us that there are people out there using peer to 
peer file sharing services to trade MP3's they don't own the rights to, or 
that I won't be getting my $50mil from that nice guy who wrote me from 
Nigeria... You are far too cynical.

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Fwd: A warning from Register.com, Inc.

[David Diaz]

Title: Fwd: A warning from Register.com,
Inc.


Thought this might be important.  If anyone has any more
information please post.



dd




We have learned that a Website located at Renewal-Center.com
has been soliciting our customers and encouraging them to
renew and enter their credit card, address, and other personal
information.

Register.com is not affiliated with Renewal-Center.com. Any
renewal attempts through this site will not be successful.
The personal information that you have provided to Register.com
remains safe and secure.

If you receive a solicitation from Renewal-Center.com, delete
it. Customers who fall prey to this scheme could have their
personal information abused. If you have already submitted your
credit card information to Renewal-Center.com you should
contact your credit card company immediately and have the
card number cancelled and report the problem as fraud.

We have taken the appropriate steps to have this Website turned
off so that none of our customer's accounts or personal
information will be threatened. In addition, we've contacted
the appropriate authorities who are taking all necessary steps
to address this situation.

Register.com's customers are incredibly important to us. As
always, we are committed to providing a secure environment for
our customers and their information.

Should you have any questions regarding this email or any
inquiries
concerning your Register.com account, please do not hesitate to
contact us through our Website (http://www.register.com) or by calling:

Within the U.S. and Canada: (800) 899-9723
Outside the U.S. and Canada: +1 (902) 742-1466

Sincerely,
Richard D. Forman
President and CEO
Register.com, Inc.




-- 


David Diaz
[EMAIL PROTECTED] [Email]
[EMAIL PROTECTED] [Pager]
www.smoton.net [Peering Site under development]
Smotons (Smart Photons) trump dumb photons

Re: [Re: [Re: M$SQL cleanup incentives]]

[Doug Barton]

On Sat, 22 Feb 2003, E.B. Dreger wrote:

> BB> Recent versions of un*x BIND will pick a random port above
> BB> 1024 for udp conversations. It can and has picked 1434.
>
> Standard socket(2) behavior.  BIND [hopefully] runs chown(2)ed,
> so the source port number must be >= 1024.

At startup, named bind(2)'s a UDP port to send queries from, and get the
answers back on. In the absence of a query-source option that specifies
otherwise, this will be a random ephemeral port, however that's defined on
the system. TCP queries follow "standard" behavior, binding a random
ephemeral port for each query.

Pardon the pedantry, but since this is an often misundertood topic, I
thought it might help to lay out the facts.

HTH,

Doug

-- 

"The last time France wanted more evidence, it rolled right
through Paris with a German flag." - David Letterman

being nice to IRR/RADB (Re: scripts to map IP to AS?)

[E.B. Dreger]

VK> Date: Thu, 20 Feb 2003 15:25:52 -0500
VK> From: Valdis.Kletnieks


JK> Just a reminder to everyone who intends to query the
JK> IRR/RADB...  Please be nice to the RADB whois server and
JK> don't DoS it.  Open a persistant connection instead of one

VK> Are there any recommendations for caching of the results? Do,
VK> don't, not for over 72 hours, etc?  I think most people that
VK> do an AS-enabled traceroute are always going to be getting
VK> the same answers back for the first few hops to *ANYWHERE* -
VK> caching at least "your local neighborhood" could dramatically
VK> cut the number of queries

Better yet, a DNS authd that resolves

origin-asn.1.0.0.127.in-addr.arpa IN TXT

appropriately.


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to
be blocked.

Re: [Re: [Re: M$SQL cleanup incentives]]

[E.B. Dreger]

BB> Date: Fri, 21 Feb 2003 14:08:46 -0600 (CST)
BB> From: Bryan Bradsby


JS> it isn't legit for what i have in my network though :-)

BB> Really? So you're blocking udp/1434 both in and out?
BB>
BB> Got any DNS servers on your network? Any of your desktop
BB> clients use DNS?

s/DNS/UDP-based servers/


BB> Recent versions of un*x BIND will pick a random port above
BB> 1024 for udp conversations. It can and has picked 1434.

Standard socket(2) behavior.  BIND [hopefully] runs chown(2)ed,
so the source port number must be >= 1024.


BB> DNS clients will eventually timeout and fall back to another
BB> server, so any problems would be transient, but the packets
BB> were legit, right?

Stateful packet filters are nice.  Properly written, they protect
both inbound and outbound traffic and need to track very little
state.


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to
be blocked.

Re: manhole covers

[Allan Liska]

On Fri, 21 Feb 2003, Marshall Eubanks wrote:

> 
> The interesting thing is that this happens every few weeks (at least -
> sometimes multiple times per week), and generally they don't know why.
> 
> Not in Adams Morgan. Not in Foggy Bottom. Not even
> in Georgetown Heights. Only in Georgetown, Its become a local joke.
> 

Well of course we know why, its the St. Elmo's Fire ;).


allan
-- 
Allan Liska
[EMAIL PROTECTED]
http://www.allan.org

Re: manhole covers

[Marshall Eubanks]

The interesting thing is that this happens every few weeks (at least -
sometimes multiple times per week), and generally they don't know why.
Not in Adams Morgan. Not in Foggy Bottom. Not even
in Georgetown Heights. Only in Georgetown, Its become a local joke.
 Regards
 Marshall Eubanks
On Thursday, February 20, 2003, at 05:43  PM, Sean Donelan wrote:

Check out Georgetown in Washington DC, the exploding manhole capital of
the world.  They have a lot of experience with exploding manholes, from
many different causes.  The most recent incident was in the last couple 
of
days.  There is a lot of energy in being pumped into utility lines.  A
short circuit can release that energy into the underground vaults, and
blow the manhole cover a considerable distance.

http://www.washingtonpost.com/wp-dyn/articles/A33073-2003Feb19.html

The Washington Post also has a special report covering exploding 
manholes

http://www.washingtonpost.com/wp-dyn/metro/specials/manholes/



On Thu, 20 Feb 2003, Allen Hamner wrote:

I am a chemist who consults with the mayor of Bluefield WV where an
incident two weeks ago (a cold day) blew a 70 pound iron cover 10 feet
from an conduit tunnel containing several public untility lines.  We
believe we can exclude a natural gas leak.  Rumor has it that hydrogen
is involved, which may arise by electrolysis (?) or pyrolysis of
insulation (?).  A previous incident had done no damage but this
explosion destroyed a nearby plate-glass window.
There is no coal in the area so mine gas seepage is excluded.  Sewer
gas is tentatively not an issue.  The source of the spark is unknown.
I would like to participate in the exchange on this topic.

Allen Hamner (Ph.D.)
[EMAIL PROTECTED]


T.M. Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624   Fax : 703-293-9609
e-mail : [EMAIL PROTECTED]
http://www.multicasttech.com
Test your network for multicast :
http://www.multicasttech.com/mt/
 Status of Multicast on the Web  :
 http://www.multicasttech.com/status/index.html

Re: M$SQL cleanup incentives

[Iljitsch van Beijnum]

On Fri, 21 Feb 2003, William Allen Simpson wrote:

> I've been pretty disappointed with some of the responses on this issue.

:-)

> I'm of the technical opinion that everyone will need to filter outgoing
> 1434 udp forever.

Forget it. That's a port used for legitimate traffic. Besides, filtering
on port numbers is a flawed proposition to begin with. The fact that it
more or less works is just luck. Too bad we can't filter on competence.

> Now, some folks have expressed the opinion we should just all drop
> filters and let the infected machines DoS our networks, hoping against
> experience that the miscreant customers will notice their bad machines
> and fix them promptly.

> That's technically incompetent!

Thank you. I agree that at this time it is often not feasible to simply
not filter. But that's certainly the place I want to be in the future.
If a customer wants to spew out 50 Mbps worth of UDP I don't want that
to influence my network. So either I forward the traffic and the
customer pays for the bandwidth or I rate limit it and they live with
the packet loss.

> For one thing, experience shows that the miscreant won't notice they're
> infected for DAYS!  Why do you think there are 20K+ still infected?

Most of those are dial-up so their traffic isn't all that much and
they're hard to track down. Depending on how the OS works, such a host
may not even experience a very significant slowdown.

> For another thing, I'm happy for all those of you that have such huge
> resources to overspecify your networks and equipment.  The rest of us
> were swamped.  We don't have any (that's right: zero zip nil) M$
> machines in the operational network (only Linux, *BSD, Macs), and we
> still lost all accounting, network management, and basic services,
> until the border filters were in place.

Strange.

By the way: I manage ~ 4 networks. One just upgraded to "huge resources"
and they didn't feel the extra 100 Mbps traffic from two infected
customer boxes (I filtered it anyway, good netizen as I am). Another has
more or less adequate resources; one router also had 2 infected boxes on
the local network but this one could handle it. The next router (behind
a 1:3 funnel) had a meltdown even though the hardware is identical.
Always use CEF, kids. Two other networks are more or less underpowered,
but no real trouble (one also with two infected boxes).

Re: M$SQL cleanup incentives

[Randy Bush]

> I'd be very interested in hearing how opeators feel about 'pushback'. 

the only interesting thing i have seen in this space

randy

Re: M$SQL cleanup incentives

[John Kristoff]

On Fri, 21 Feb 2003 17:25:46 -0500
William Allen Simpson <[EMAIL PROTECTED]> wrote:

> I've been pretty disappointed with some of the responses on this
> issue. 

Maybe you won't like this one either, but here goes.

I'd be very interested in hearing how opeators feel about 'pushback'. 
It may make more sense near ingress edges or where there is limited
aggregate capacity on the egress (a bottleneck), but debating that point
is probably secondary.

You can refer to some of the material, particularly by Bellovin, Floyd
and others here:

  

In the simplest scenario, pushback could be similarly deployed to the
way RED is deployed (if you consider that easy or useful or not, I'm not
sure).  Signals do not even necessarily need to propagate to upstream
routers, rather anomalous traffic (based on a simple, hopefully, policy)
could be dropped more aggressively.  This response could be automatic or
require intervention.  I think there are a number interesting properties
to this approach, especially since if it behaves similar as one might
hope, it could still allow some valid traffic through.  Hint: think
about what will happen if a Slammer/Sapphire-like worm hits port
25/53/80 and cannot be easily filtered without affecting all traffic on
those ports.

Coming up with a policy that determines what is anomalous is one of the
hard parts.  Vendor implementation being another, but you can kind of do
this sort of thing already if you're so inclined.
  
Thoughts?

John

Re: M$SQL cleanup incentives

[William Allen Simpson]

I've been pretty disappointed with some of the responses on this issue. 

Yes, we filter both incoming and outgoing 1434 udp.  No, we cannot keep 
doing that forever, the router CPU utilization is pretty high.  We only 
logged for a couple of hours before turning that off (weeks ago)

I'm of the technical opinion that everyone will need to filter outgoing 
1434 udp forever.  Yet, since we are (currently) free of infection, 
that's the direction we don't _need_ to filter. 

Now, some folks have expressed the opinion we should just all drop 
filters and let the infected machines DoS our networks, hoping against 
experience that the miscreant customers will notice their bad machines 
and fix them promptly. 

That's technically incompetent! 

For one thing, experience shows that the miscreant won't notice they're 
infected for DAYS!  Why do you think there are 20K+ still infected?

For another thing, I'm happy for all those of you that have such huge 
resources to overspecify your networks and equipment.  The rest of us 
were swamped.  We don't have any (that's right: zero zip nil) M$ 
machines in the operational network (only Linux, *BSD, Macs), and we 
still lost all accounting, network management, and basic services, 
until the border filters were in place.  


Iljitsch van Beijnum wrote:
> Maybe the best approach is to try and deliberately infect the entire
> local net every few minutes or so to detect new vulnerable systems while
> the people installing them are still on the premises.
> 
Gosh, should we do that for every known virus/worm/vulnerability?

Or maybe you don't actually own and/or have legal and financial 
accountability for your own network? 

Is there anybody around here serious about actually cleaning up the 
mess, and thinking of network operational mechanisms to prevent such 
things in the future?
-- 
William Allen Simpson
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: Homeland Security Alert System

[Martin Hannigan]

On Fri, Feb 21, 2003 at 03:32:12PM -0500, [EMAIL PROTECTED] wrote:
> On Fri, 21 Feb 2003 14:41:05 EST, Martin Hannigan said:
> 
> > Example: DHS sets RED level. Reaction: Move some third level 
> > engineers into the SOC. Audit the DR plan if it's not on schedule
> > to be audited. Audit the backup plans if not on schedule to be
> > audited. Light the medium warm NOC to HOT NOC level.
> 
> Do you buy fire extinguishers when there's no fire, or do you do it
> when the smoke alarm is already going off?  Or is this the converse, where
> a leaky roof doesn't get fixed because you can't work on it on rainy days,
> and on sunny days it doesn't leak?

DR is a continous loop. It's not the kind of thing you 
develop and then toss on a shelf. Right now is always a good 
time to audit your DR planning, or your disaster prevention 
planning.

[ SNIP ]

> If you audit your backup plan, and discover you're low on tapes to send
> off-site, what are the chances that we'll still be at RED when the tapes
> actually arrive from the vendor?

If I didn't audit the backup plan, I wouldn't discover I was low
on tapes. The state of the alert is irrelevant when related to the
DR plan. It's the event itself.

I believe there is no bad time to conduct a drill or audit
a DR plan. In fact, confusing or non-standard conditions would
be optimal for such a test or audit.

-M

RE: Homeland Security Alert System

[Jeffrey Meltzer]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of David Barak
>
> Well, an example could be "if threat level is yellow,
> permit traffic from $foreign_country_x, but if it goes
> to orange, deny all from $foreign_country_x, or
> perhaps log all from there.
> 

Um, you're not really serious, are you?  Are you worried about some cell
being activated by sending a packet through your servers?  I can't think
of one useful purpose to do something like that.

Jeff

Not to beat a dead hose, but about the Bank of America ATM Article

[Temkin, David]

Title: Message



... some very 
interesting reading to follow up on the discussions that were had last month 
regarding ATM machine security and PIN storage.  Turns out CitiBank has a 
serious flaw in their system that they'd rather everyone not know about.  
As well, as was noted, the PIN numbers are no longer stored on the 
cards.
 
See the article @ 
cryptome:
 
http://cryptome.org/pacc.htm
 
-Dave
 
David 
Temkin
S-I-G
401 City Avenue
Bala Cynwyd, PA 19004
http://www.sig.com
 



IMPORTANT:The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments.  Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited.  Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument.  Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Re: [Re: [Re: [Re: M$SQL cleanup incentives]]]

[Joshua Smith]

Bryan Bradsby <[EMAIL PROTECTED]> wrote:
> > > udp/1434 is not a reserved port. [...] legit
> > > traffic that picked a random port to use for an ad-hoc use.
> >
> > it isn't legit for what i have in my network though :-)
> 

i should clarify this - my data center has www/dns/ftp servers and a bunch
of voip gateways (mostly cisco), so they all talk on the same udp ports
(most of which are greater than 3)

my corporate lan does have a ms sql server or two (running on nt4), but 
there is no reason that those servers should be talking to anything
outside of my network (or outside of their vlan)

> 
> Really? So you're blocking udp/1434 both in and out?
> 

yep

> Got any DNS servers on your network? Any of your desktop clients use DNS?
> 

options {
 query-source * port 53
};

> Recent versions of un*x BIND will pick a random port above 1024 for udp
> conversations. It can and has picked 1434.

destination port will be 53, i suppose it is possible that the client
could pick 1434 for a source.

> 
> DNS clients will eventually timeout and fall back to another server, so
> any problems would be transient, but the packets were legit, right?
> 

on the off chance that someone's windows desktop picked 1434 for a source.
those packets however will not be leaving my network.

it may not be the best way to do all of it, but it keeps my network from
being killed (it also helps that the lan admin keeps all the servers
well patched)

> 
> -bryan bradsby
> Texas State Government Net
> 
> 
> 

joshua
(the grouchy ip/security/*nix guy sitting alone in the dark corner of the 
office)


"Walk with me through the Universe,
 And along the way see how all of us are Connected.
 Feast the eyes of your Soul,
 On the Love that abounds.
 In all places at once, seemingly endless,
 Like your own existence."
 - Stephen Hawking -

Re: Homeland Security Alert System

[Valdis . Kletnieks]

On Fri, 21 Feb 2003 14:41:05 EST, Martin Hannigan said:

> Example: DHS sets RED level. Reaction: Move some third level 
> engineers into the SOC. Audit the DR plan if it's not on schedule
> to be audited. Audit the backup plans if not on schedule to be
> audited. Light the medium warm NOC to HOT NOC level.

Do you buy fire extinguishers when there's no fire, or do you do it
when the smoke alarm is already going off?  Or is this the converse, where
a leaky roof doesn't get fixed because you can't work on it on rainy days,
and on sunny days it doesn't leak?

If your DR/backup plan isn't already squared away, RED is a *very* bad time to
be screwing with it.  Anybody who's read this list for a while has seen
enough examples of "attempt to fix broken network only makes it worse".

If you audit your backup plan, and discover you're low on tapes to send
off-site, what are the chances that we'll still be at RED when the tapes
actually arrive from the vendor?

-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09240/pgp0.pgp
Description: PGP signature

Re: Homeland Security Alert System

[Richard Irving]

>conf t
router> warning you cannot configure a router
with this one

Martin Hannigan wrote:
> I have my duct tape and plastic, but haven't applied it to the
> windows.

  I hear it is more effective, if you wrap the plastic
around your head, and seal it with the duck tape
 
  Never had a -single- complaint, from users of this 
methodology. as long as they don't cheat. 

 :P

Nothing gets through ... (of course, including air..)

 But this -=is=- a time of WAR, 
  we MUST be willing to make sacrifices :*
  
FACT:  Did you know that Government studies show 
100% of terrorists, participating in fatal terrorist attacks,
were shown to have been breathing -=air=-, right prior
to the accident.

  That's right, AIR!

 =-All=- of them do it.

  Well, We've got them NOW!

  :\

"There are liars, damned liars, and statiticians."

 :O  :*  ;) 

.Richard.

===
Famous President Bush words:

Bush 1: "Read my lips, -NO- ... -NEW- ... -TAXES-!"
Bush 2: "There can -ONLY- ... -BE- ... -=ONE=- ... -POSSIBLE- ... -OUTCOME-!"

 Next time, cough up money for the -real- acting class guys,
the "William Shatner" class is too cheap, and everyone graduates
sounding alike.

 * shrug *

  ;)

Re: [Re: [Re: M$SQL cleanup incentives]]

[Bryan Bradsby]

> > udp/1434 is not a reserved port. [...] legit
> > traffic that picked a random port to use for an ad-hoc use.
>
> it isn't legit for what i have in my network though :-)


Really? So you're blocking udp/1434 both in and out?

Got any DNS servers on your network? Any of your desktop clients use DNS?

Recent versions of un*x BIND will pick a random port above 1024 for udp
conversations. It can and has picked 1434.

DNS clients will eventually timeout and fall back to another server, so
any problems would be transient, but the packets were legit, right?


-bryan bradsby
Texas State Government Net

Re: [Re: [Re: M$SQL cleanup incentives]]

[Kevin Oberman]

> Date: Fri, 21 Feb 2003 14:02:09 -0500
> From: "Johannes Ullrich" <[EMAIL PROTECTED]>
> 
>  
> > On the other hand, Timeline's case is YEARS old and they are going
> > after treble damages from companies who just took Microsoft's word
> > that there was nothing to worry about. Some people should be VERY
> > nervous, indeed.
> 
> Thats the part that worries me greatly. This general idea may apply
> to a lot of other cases. The way I read the news story, you can not
> rely on your vendor to provide you with legally licensed software.
> Do you have to check for each software (firmware?) component you 
> buy? How do you ever find out which licensed components are included?

This is slightly different in that the case was public fairly well
known. Microsoft was asked explicitly by several customers if there
was an issue and were assured that there were none. The fact that a
company asked Microsoft when the KNEW that the license was at issue
implies that they should have asked a lawyer about it and knowingly
ignored the patent. That is the cause for treble (punitive) damages.

Any company that is can substantiate that they had no reason to
suspect a possible problem is probably safe from more than direct
damages which will amount to back royalties. (Not that this is
insignificant.) 

Oh, by the way, IANAL, so don't take this as having any actual basis
in case law.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]  Phone: +1 510 486-8634

Re: [Re: [Re: M$SQL cleanup incentives]]

[Johannes Ullrich]

 
> On the other hand, Timeline's case is YEARS old and they are going
> after treble damages from companies who just took Microsoft's word
> that there was nothing to worry about. Some people should be VERY
> nervous, indeed.

Thats the part that worries me greatly. This general idea may apply
to a lot of other cases. The way I read the news story, you can not
rely on your vendor to provide you with legally licensed software.
Do you have to check for each software (firmware?) component you 
buy? How do you ever find out which licensed components are included?


-- 

[EMAIL PROTECTED] Collaborative Intrusion Detection
 join http://www.dshield.org

Re: [Re: [Re: M$SQL cleanup incentives]]

[Kevin Oberman]

> Date: Fri, 21 Feb 2003 09:53:59 -0800 (PST)
> From: David Barak <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> 
> I think the bigger issue for all of the M$SQL
> customers will be the new licensing fees they get
> stuck with...
> 
> http://www.theregister.co.uk/content/53/29419.html

It could be a huge problem for some companies, but appears to have no
impact on most M$SQL server users. Just companies that base products
on the server. 

Let's not start a panic.

On the other hand, Timeline's case is YEARS old and they are going
after treble damages from companies who just took Microsoft's word
that there was nothing to worry about. Some people should be VERY
nervous, indeed.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]  Phone: +1 510 486-8634

FW: CERT Advisory CA-2003-06 Multiple vulnerabilities in SIP

[St. Clair, James]

-Original Message-
From: CERT Advisory [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 21, 2003 10:25 AM
To: [EMAIL PROTECTED]
Subject: CERT Advisory CA-2003-06 Multiple vulnerabilities in
implementations of the





*** PGP Signature Status: unknown
*** Signer: Unknown, Key ID = 0xD9513B39
*** Signed: 2/21/2003 10:19:02 AM
*** Verified: 2/21/2003 1:09:03 PM
*** BEGIN PGP VERIFIED MESSAGE ***

CERT Advisory CA-2003-06 Multiple vulnerabilities in implementations of the
Session Initiation Protocol (SIP)

   Original release date: February 21, 2003
   Last revised: --
   Source: CERT/CC

   A complete revision history can be found at the end of this file.

Systems Affected

   SIP-enabled  products  from  a  wide  variety of vendors are affected.
   Other  systems  making  use of SIP may also be vulnerable but were not
   specifically  tested.  Not  all  SIP implementations are affected. See
   Vendor Information for details from vendors who have provided feedback
   for this advisory.

   In  addition to the vendors who provided feedback for this advisory, a
   list  of  vendors  whom  CERT/CC contacted regarding these problems is
   available from VU#528719.

Overview

   Numerous  vulnerabilities  have  been  reported  in  multiple vendors'
   implementationsof   the   Session   Initiation   Protocol.   These
   vulnerabilities  may allow an attacker to gain unauthorized privileged
   access,  cause  denial-of-service  attacks,  or  cause unstable system
   behavior.  If your site uses SIP-enabled products in any capacity, the
   CERT/CC  encourages  you  to  read this advisory and follow the advice
   provided in the Solution section below.

I. Description

   The  Session  Initiation  Protocol  (SIP)  is  a  developing and newly
   deployed  protocol  that  is  commonly  used  in Voice over IP (VoIP),
   Internet telephony, instant messaging, and various other applications.
   SIP  is  a  text-based  protocol for initiating communication and data
   sessions between users.

   The  Oulu  University  Secure  Programming  Group  (OUSPG)  previously
   conducted  research  into vulnerabilities in LDAP, culminating in CERT
   Advisory CA-2001-18, and SNMP, resulting in CERT Advisory CA-2002-03.

   OUSPG's most recent research focused on a subset of SIP related to the
   INVITE message, which SIP agents and proxies are required to accept in
   order to set up sessions. By applying the PROTOS c07-sip test suite to
   a  variety  of  popular  SIP-enabled  products,  the  OUSPG discovered
   impacts ranging from unexpected system behavior and denial of services
   to  remote  code  execution.  Note  that  "throttling"  is an expected
   behavior.

   Specifications  for  the  Session Initiation Protocol are available in
   RFC3261:

 http://www.ietf.org/rfc/rfc3261.txt

   OUSPG  has  established the following site with detailed documentation
   regarding SIP and the implementation test results from the test suite:

 http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/

   The IETF Charter page for SIP is available at

 http://www.ietf.org/html.charters/sip-charter.html

II. Impact

   Exploitation  of these vulnerabilities may result in denial-of-service
   conditions,  service  interruptions,  and  in  some cases may allow an
   attacker  to gain unauthorized access to the affected device. Specific
   impacts will vary from product to product.

III. Solution

   Many  of  the  mitigation steps recommended below may have significant
   impact   on   your   everyday   network   operations   and/or  network
   architecture.  Ensure  that  any  changes  made based on the following
   recommendations  will  not  unacceptably  affect  your ongoing network
   operations capability.

  Apply a patch from your vendor

 Appendix  A  contains  information  provided  by  vendors  for this
 advisory.  Please  consult this appendix and VU#528719 to determine
 if  your  product is vulnerable. If a statement is unavailable, you
 may need to contact your vendor directly.

  Disable the SIP-enabled devices and services

 As  a general rule, the CERT/CC recommends disabling any service or
 capability  that  is  not explicitly required. Some of the affected
 products  may  rely  on  SIP to be functional. You should carefully
 consider the impact of blocking services that you may be using.

  Ingress filtering

 As  a  temporary  measure, it may be possible to limit the scope of
 these  vulnerabilities  by  blocking  access  to  SIP  devices  and
 services at the network perimeter.

 Ingress  filtering  manages  the  flow  of  traffic  as it enters a
 network  under  your  administrative control. Servers are typically
 the  only  machines  that  need  to accept inbound traffic from the
 public  Internet.  Note  that  most  SIP  User Agents (including IP
 phones  or  "clien"t software) consist of a User Agent Client and a
 User

Re: [Re: [Re: M$SQL cleanup incentives]]

[David Barak]

I think the bigger issue for all of the M$SQL
customers will be the new licensing fees they get
stuck with...

http://www.theregister.co.uk/content/53/29419.html

-David Barak
fully RFC 1925 compliant

--- Joshua Smith <[EMAIL PROTECTED]> wrote:
> 
> it isn't legit for what i have in my network though
> :-)
> 


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: Homeland Security Alert System

[David Barak]

Peter,

I didn't say that I did that, only that I know that
there are networks which deny all mail traffic from
certain ASes and/or TLDs on a fairly regular basis. 
Personally I don't have a problem with .cc

I would say that for a US operator to respond to a
threat by enabling additional, temporary
logging/monitoring of specific ports would not be
unreasonable.  Denying all traffic is a bit harsh,
especially from a paying customer, but I could
understand watching them really closely.  Public
peers, on the other hand, might get a different sort
of treatment entirely...

The only reason this makes any sense at all is that
most networks are basically OK most of the time, so
the rest of your network can probably spare a little
bit of attention for a short period of time.  If it
were forever, then that solution wouldn't work.

-David Barak
fully RFC 1925 compliant


--- Peter Salus <[EMAIL PROTECTED]> wrote:
> 
> 
> David, what does "from" mean in your "rules"?
> 
> with .cc at the end?  But there are very many
> places with addresses in TLDs and ccTLDs other
> than the geographical location.
> 
> passing through an AS known to be in a given
> location?
> 
> Peter


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Support needed in LA (Downtown)

[Sven Engelhardt]

Hello,

can anyone provide a contact of a professional service company available
in Downtown LA, I have a router there that needs to be packed up for
shipment early next week. Please reply off-list.

thanks in advance,


Sven Engelhardt
Manager Network Engineering
-- 
Tiscali International Network   phone:  +49 6103 91 64 80
Robert Bosch Strasse 32 fax:+49 6103 91 64 64
D-63303 Dreieich / Germany  e-mail: [EMAIL PROTECTED]

Re: [Re: [Re: M$SQL cleanup incentives]]

[Joshua Smith]

it isn't legit for what i have in my network though :-)

"Gary E. Miller" <[EMAIL PROTECTED]> wrote:
> Yo Joshua!
> 
> On Thu, 20 Feb 2003, Joshua Smith wrote:
> 
> > i still get 8K plus hits against my acls per day for udp/1434...(75 in
the
> > time it took to write this email)
> 
> You are probably doing as much damage as good.
> 
> udp/1434 is not a reserved port. A lot of what you are blocking is legit
> traffic that picked a random port to use for an ad-hoc use.
> 
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
>   [EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676
> 



"Walk with me through the Universe,
 And along the way see how all of us are Connected.
 Feast the eyes of your Soul,
 On the Love that abounds.
 In all places at once, seemingly endless,
 Like your own existence."
 - Stephen Hawking -

Re: Homeland Security Alert System

[Peter Salus]

David, what does "from" mean in your "rules"?

with .cc at the end?  But there are very many
places with addresses in TLDs and ccTLDs other
than the geographical location.

passing through an AS known to be in a given
location?

Peter

Re: Homeland Security Alert System

[David Barak]

Okay, I'll bite...

--- Sean Donelan <[EMAIL PROTECTED]> wrote:
> 
> On Fri, 21 Feb 2003, Martin Hannigan wrote:

> Isn't your NOC normally vigilant?  

Of course.


> > Perhaps even use different sets of ACL's on the
> edge, etc. It could also
> > be used
> > to explain an unexpected surge in traffic, calls,
> or other things. Ever
> > look at some traffic stats and see a major surge
> and want to make sure
> > you understand why?
> 
> Again wouldn't you also do all of these things
> "normally?"  If an ACL is a
> good idea at "Orange" wouldn't you protect your
> network with those ACL's
> when the level is "Yellow."  Or would you remove
> those ACL's when the
> threat level is reduced.  How do would you explain
> to your management when
> you are hacked at level "Yellow" you had better
> ACL's, but you only used
> the good ACL's at level "Orange."

Well, an example could be "if threat level is yellow,
permit traffic from $foreign_country_x, but if it goes
to orange, deny all from $foreign_country_x, or
perhaps log all from there.

I know that there are certain ISPs which deny all mail
traffic from certain ASes, because of the volume of
Spam.  The same principle could be at work here: if
(threat_level++) then deny(unknown_from_Source[nasty])
else permit.

-David Barak
fully RFC 1925 compliant


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: Homeland Security Alert System

[Sean Donelan]

On Fri, 21 Feb 2003, Martin Hannigan wrote:
>   But what would you do with the information?
>
> Let the noc know what's up so they can be more vigilant based on the the
> threat level.

I'm not trying to be sarcastic, because lots of people have been going
through these same conversations.

"Threat level" is different from an attack.

Isn't your NOC normally vigilant?  If the DHS lowered the threat level to
"Green" would you stop monitoring your network just because the government
says there is no more threat?  Do you have more or fewer people on duty in
your NOC as the government threat level goes up or down watching the big
TV screens?

> Perhaps even use different sets of ACL's on the edge, etc. It could also
> be used
> to explain an unexpected surge in traffic, calls, or other things. Ever
> look at some traffic stats and see a major surge and want to make sure
> you understand why?

Again wouldn't you also do all of these things "normally?"  If an ACL is a
good idea at "Orange" wouldn't you protect your network with those ACL's
when the level is "Yellow."  Or would you remove those ACL's when the
threat level is reduced.  How do would you explain to your management when
you are hacked at level "Yellow" you had better ACL's, but you only used
the good ACL's at level "Orange."

> I'd take it serious and consider NBC as well as "cyberAttacks".

Secretary Ridge has said to keep the plastic sheets and duct tape in
storage.  Don't start sealing your house (or NOC) yet.  The FEMA/Red Cross
prepardness recommendations are a good idea irregardless of the alert
level.

Staten Island refinery fire

[Kai Schlichting]

News reports say that about 10:10am EST, a refinery (Mobile Port) at the
channel between New Jersey and Staten Island caught fire due to a propane
barge explosion:
When I passed by the Verrezano Narrows bridge (on the other side of S.I.,
towards Brooklyn) at around 10:25am, there was a GIANT plume of smoke
rising at least several miles into the air before being blown by the wind
in south/south-eastern direction. www.news12.com and
www.ny1.com are completely slashdotted right now, with www.cnn.com having
slowed to a crawl.

Re: Homeland Security Alert System

[Martin Hannigan]

At 01:44 AM 2/21/2003 -0500, Sean Donelan wrote:

On Thu, 20 Feb 2003, Martin
Hannigan wrote:
> Is anyone running an automated Terror Alert system that's
> real time with the DHS?

CNN (or Fox, MSNBC, etc) news satellite feed (for national alerts)

Radio Shack National Weather Service Alert radio (for local alerts)

Individual states have other alert systems.  For example,
California
has EDIS, Oklahoma and Florida have their own systems.

When the alert level was raised from Yellow to Orange, the DHS web
site
was updated long after all the 24-hour news networks were running
scrolls across the bottom of the screen announcing the upcoming
press
conference about the change.

But what would you do with the information?

Let the noc know what's up so they can be more vigilant based on the the
threat level. 
Perhaps even use different sets of ACL's on the edge, etc. It could also
be used
to explain an unexpected surge in traffic, calls, or other things. Ever
look at some traffic stats and see a major surge and want to make sure
you understand why?

I'd take it serious and consider NBC as well as "cyberAttacks".







Regards,

--
Martin
Hannigan   
[EMAIL PROTECTED]

Re: Homeland Security Alert System

[Richard Forno]

Hey - I have a Def Leppard CD and MP3 collection that I am VERY proud of!!!

Regarding the HLS thing, could you not just do a simple automated
screenscrape of the DHS website and then flag an alert if the code for the
alert changed from one scrape to another?

And no, even though I'm in DC, I don't own a pair of hip-boots.


-Rick,
who submitted the HLAS Scheme as "Stupid Security Scheme" last week



> From: "Stretch" <[EMAIL PROTECTED]>
> Date: Thu, 20 Feb 2003 20:54:19 -0600
> To: "Martin Hannigan" <[EMAIL PROTECTED]>, "Richard Irving"
> <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Subject: Re: Homeland Security Alert System
> 
> 
> "People who bought HIP BOOTS also shopped for:
> * Duct Tape
> * Jack Daniels
> * Def Leppard CD's
> * Clean Underwear"
> 
> on-topic: I use a plug-in for my NMS that looks for abnormalities in the
> load times of various popular sites. (it's helped me spot routing problems
> more than once). Looking back at historical data, all the news-related ones
> show a clear change immediately after events like the Columbia disaster. I
> was not using the same system on 9/11 so I don't know how quickly one would
> have spotted an abnormality.
> 
> - Original Message -
> From: "Martin Hannigan" <[EMAIL PROTECTED]>
> To: "Richard Irving" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, February 20, 2003 8:27 PM
> Subject: Re: Homeland Security Alert System
> 
> 
>> 
>> On Thu, Feb 20, 2003 at 08:08:58PM -0500, Richard Irving wrote:
>>> Yes.
>>> 
>>>  But, until elections 2004, the "FUD" field is hardcoded to "High".
>>> 
>>>  However, if there are changes to the -=actual=- dhs.gov status,
>>> it sends out an automatic Amazon.Com order for
>>> Hip Boots for all members of the list.
>>> 
>>> Would you like to subscribe to the notification list ?
>> 
>> [ snip ]
>> 
>> 
 Is anyone running an automated Terror Alert system that's
 real time with the DHS?
>> 
>> 
>> Ok, that was interesting. :)
>> 
>> The diving thing is my fun stuff. I'm actually working in
>> Security. :)
>> 
>> I was writing a little tool that scanned their page for the alert
>> image name change, but that's subject to them making changes to
>> their site and the images are multi layer graphics, etc. etc.
>> 
>> I'm going to call them and see if they can offer
>> a place to poll something simple that we can trip
>> changes off in the NOC.
>> 
>> If anyone does have some insight to anything they are
>> doing, or a good contact number for the DHS webite, please
>> ping me in email and I'll follow up if I find something
>> or get them to do something.
>> 
>> -M
>> 
> 
> 

RE: Homeland Security Alert System

[St. Clair, James]

Martin,

>From the NANOG perspective, the best place to tie your own alert system to
nat'l threat levels is with the Telecomm ISAC, which is run out of the NCS.
That is the 27/7/365 commander center for telecomm sector security. Bear in
mind, a change in the HSAS may NOT be as a result of a specific threat to
Telecomm, so get with the ISAC instead.

Jim 

-Original Message-
From: Martin Hannigan
To: [EMAIL PROTECTED]
Sent: 2/20/03 7:35 PM
Subject: Homeland Security Alert System



Is anyone running an automated Terror Alert system that's
real time with the DHS? 


-M

The Cidr Report

[cidr-report]

This report has been generated at Fri Feb 21 21:46:27 2003 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org/as4637 for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
14-02-03119071   85433
15-02-03119072   85385
16-02-03118946   85348
17-02-03118884   85299
18-02-03118939   85352
19-02-03119053   85338
20-02-03119156   85478
21-02-03119400   85502


AS Summary
 14614  Number of ASes in routing system
  5749  Number of ASes announcing only one prefix
  1577  Largest number of prefixes announced by an AS
AS701  : ALTERNET-AS UUNET Technologies, Inc.
  73048064  Largest address span announced by an AS (/32s)
AS568  : SUMNET-AS DISO-UNRRA

Possible Bogus Routes

10.0.0.0/8   AS4637  REACH Reach Network Border AS
192.168.0.0/16   AS4637  REACH Reach Network Border AS


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 21Feb03 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 119491854713402028.5%   All ASes

AS3908  1062  565  49746.8%   SUPERNETASBLK SuperNet, Inc.
AS18566  4826  47698.8%   COVAD Covad Communications
AS701   1577 1145  43227.4%   ALTERNET-AS UUNET
   Technologies, Inc.
AS4151   524   92  43282.4%   USDA-1 USDA
AS7018  1427 1034  39327.5%   ATT-INTERNET4 AT&T WorldNet
   Services
AS4323   529  170  35967.9%   TW-COMM Time Warner
   Communications, Inc.
AS7843   569  234  33558.9%   ADELPHIA-AS Adelphia Corp.
AS7046   578  246  33257.4%   UUNET-CUSTOMER UUNET
   Technologies, Inc.
AS6197   478  158  32066.9%   BATI-ATL BellSouth Network
   Solutions, Inc
AS1221  1119  821  29826.6%   ASN-TELSTRA Telstra Pty Ltd
AS4355   402  120  28270.1%   ERMS-EARTHLNK EARTHLINK, INC
AS22927  295   14  28195.3%   AR-TEAR2-LACNIC TELEFONICA DE
   ARGENTINA
AS1239   960  680  28029.2%   SPRINTLINK Sprint
AS705447  194  25356.6%   ASN-ALTERNET UUNET
   Technologies, Inc.
AS4814   261   15  24694.3%   CHINANET-BEIJING-AP China
   Telecom (Group)
AS1  666  435  23134.7%   GNTY-1 Genuity
AS6347   330  101  22969.4%   DIAMOND SAVVIS Communications
   Corporation
AS6198   433  204  22952.9%   BATI-MIA BellSouth Network
   Solutions, Inc
AS22291  243   32  21186.8%   CHARTER-LA Charter
   Communications
AS17676  227   26  20188.5%   GIGAINFRA XTAGE CORPORATION
AS690498  308  19038.2%   MERIT-AS-27 Merit Network Inc.
AS209523  335  18835.9%   ASN-QWEST Qwest
AS4134   304  117  18761.5%   CHINANET-BACKBONE
   No.31,Jin-rong Street
AS2386   443  263  18040.6%   INS-AS AT&T Data
   Communications Services
AS2048   260   87  17366.5%   LANET-1 State of Louisiana
AS852604  445  15926.3%   ASN852 Telus Advanced
   Communications
AS7303   240   90  15062.5%   AR-TAST-LACNIC Telecom
   Argentina Stet-France Telecom
   S.A.
AS17557  340  190  15044.1%   PKTELECOM-AS-AP Pakistan
   Telecom
AS22773  181   31  15082.9%   CCINET-2 Cox Communications
   Inc. Atlanta
AS6140   283  137  14651.6%   IMPSAT-USA ImpSat

Total  16285 8295 799049.1%   Top 30 total



Please see http://www.cidr-report.org for the full report


Copies of this report are mailed to:
  [EMAIL PROTECTED]
  [EMAIL PROTECTE

Re: IP Management tool for service providers

[D'Arcy J.M. Cain]

On Thursday 20 February 2003 16:26, Daniel Abbey wrote:
> I am looking for an IP management which has flexible management
> capabilities. I need it for managing my customers IP assignments, and
> keeping stock of my IP pool.
> Do you have any suggestions?

We have a package that is very flexible based on Python and PostgreSQL.  I 
will copy [EMAIL PROTECTED] so they can send you some information.

-- 
D'Arcy J.M. Cain|  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

Re: [Re: M$SQL cleanup incentives]

[Iljitsch van Beijnum]

On Thu, 20 Feb 2003, Joshua Smith wrote:

> > Only if people didn't fix their servers. And if they didn't, this
> > "reverse" denial of service attack is a good reminder.

> what was that one worm from a year or two ago that was eliminated from the
> net, oh yeah, code red..if they didn't fix themselves the first round,
> what makes you think they will fix it the second time, or the third...

Their link to the net is unusable if they're infected so not doing
anything is not an option.

If a box is going to be infected, we want it to happen immediately upon
installation. Friday night late is no fun... (Un)fortunately, the number
of worm packets still coming in is too low for this (about 1 per second
for a /19, so it takes a few hours on average for an IP address to be
hit.) Also unfortunate is the fact that the worm has shown it can bypass
many filters. It's not clear how exactly, but I guess it has something
to do with broadcasts or multicasts. So depending on a filter to protect
vulnerable boxes isn't an entirely safe approach, especially if there is
a lot of infrastructure between the filter and the box.

Maybe the best approach is to try and deliberately infect the entire
local net every few minutes or so to detect new vulnerable systems while
the people installing them are still on the premises.