New worm / port 1434?

This one seemed to be particularly nasty as it was generating traffic to
multicast addresses too. It caused a nice flood on the switched ethernet
segment I had a vulnerable box on. (And took out a router in the process.
Great fun.)

William Astle
finger lost@l-w.net for further information

Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w--- !O
!M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?

Dont panic, its all ok

"Howard Schmidt, one of President George W Bush's top cyber-security advisers,
said the FBI's National Infrastructure Protection Center and private experts at
the CERT Co-ordination Center were monitoring the attacks. "

:wink:

I'm monitoring too, hope you all feel better!

Steve

Ok,

I'm not sure if this helps at all. Our campus has two primary connections -
the main Internet and something called Internet2. Internet2 has a routing
table of order 10,000 routes and includes most top-tier research instituations
in the US (and a few other places). By 1am this morning (Eastern US time),
all of our Internet links saturated outbound but we didn't appear to see any
noticable increase in our Internet2 bandwidth. I'm throwing this out there
because it may indicate that the destinations for the traffic - though large -
aren't completely random.

Has anyone else seen this?

Eric :slight_smile:

PS: Yep - we're a university and we're a source - big surprise there... I
just filtered out our 200Mbps contribution to this problem in case you're
curious...

Can you give me any information about which multicast group addresses were being attacked ?

I have seen very little sign of this worm in interdomain multicast; it does not seem
to be causing MSDP havoc the way that the RAMEN worm did.

                                  Regards
                                  Marshall Eubanks

This one seemed to be particularly nasty as it was generating traffic to
multicast addresses too. It caused a nice flood on the switched ethernet
segment I had a vulnerable box on. (And took out a router in the process.
Great fun.)

William Astle
finger lost@l-w.net for further information

Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w--- !O
!M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?

T.M. Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624 Fax : 703-293-9609
e-mail : tme@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
  Status of Multicast on the Web :
  multicasttech.com - Diese Website steht zum Verkauf! - Informationen zum Thema multicasttech.

Can you give me any information about which multicast group addresses
were being attacked ?

I didn't have any logging turned on at the time so I don't have the
addresses laying around. I just remember I had a storm of traffic trying
to go to addresses between 224.x.x.x and 247.x.x.x - the addresses looked
fairly random though. It may have been just a result of whatever random
address algorithm was being used. Since I don't route multicast, it stayed
local to the network segment but every host on the segment saw the
traffic.

I have seen very little sign of this worm in interdomain multicast; it
does not seem
to be causing MSDP havoc the way that the RAMEN worm did.

                                  Regards
                                  Marshall Eubanks

>
> This one seemed to be particularly nasty as it was generating traffic to
> multicast addresses too. It caused a nice flood on the switched ethernet
> segment I had a vulnerable box on. (And took out a router in the
> process.
> Great fun.)
>
> William Astle
> finger lost@l-w.net for further information
>
> Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N
> w--- !O
> !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?
>

T.M. Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624 Fax : 703-293-9609
e-mail : tme@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
  Status of Multicast on the Web :
  multicasttech.com - Diese Website steht zum Verkauf! - Informationen zum Thema multicasttech.

William Astle
finger lost@l-w.net for further information

Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w--- !O
!M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?

Ok,

I'm not sure if this helps at all. Our campus has two primary connections -
the main Internet and something called Internet2. Internet2 has a routing
table of order 10,000 routes and includes most top-tier research instituations
in the US (and a few other places). By 1am this morning (Eastern US time),
all of our Internet links saturated outbound but we didn't appear to see any
noticable increase in our Internet2 bandwidth. I'm throwing this out there
because it may indicate that the destinations for the traffic - though large -
aren't completely random.

Has anyone else seen this?

Sources from our customers are in pockets so not a good spread of source but the
destination is -very- random.. I'm not seeing that many packets duplicating the
same destination

Now having said that there is some algorith at work perhaps the same one that
was used in the Codered worm

There is many more hits to the same /16 and same /8 as source with a general
spread over the rest of the IP space

There appears to be significantly more over 128/1 than 0/1 which is odd altho
certain /8s appear to be popular (32, 81, 53, 35, 38)

Steve

Dear Eric;

Ok,

I'm not sure if this helps at all. Our campus has two primary connections -
the main Internet and something called Internet2. Internet2 has a routing
table of order 10,000 routes and includes most top-tier research instituations

I would concur. worm is not attacking multicasting in general, but seems to be generating multicast traffic.
For these two statements to make sense, the IP address scanning must be very non random. This does not appear
to be the sort of consecutive address block scanning that the RAMEN worm did.

(BTW, This AM we have 11052 I2 routes vs 116983 in all, or about 9.4% of the total.)

Marshall

in the US (and a few other places). By 1am this morning (Eastern US time),
all of our Internet links saturated outbound but we didn't appear to see any
noticable increase in our Internet2 bandwidth. I'm throwing this out there
because it may indicate that the destinations for the traffic - though large -
aren't completely random.

Has anyone else seen this?

Eric :slight_smile:

PS: Yep - we're a university and we're a source - big surprise there... I
just filtered out our 200Mbps contribution to this problem in case you're
curious...

                                  Regards
                                  Marshall Eubanks

This e-mail may contain confidential and proprietary information of
Multicast Technologies, Inc, subject to Non-Disclosure Agreements

T.M. Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624 Fax : 703-293-9609
e-mail : tme@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
  Status of Multicast on the Web :
  multicasttech.com - Diese Website steht zum Verkauf! - Informationen zum Thema multicasttech.

On Sat, Jan 25, 2003 at 10:49:01AM -0500, Eric Gauthier mooed:

Ok,

I'm not sure if this helps at all. Our campus has two primary connections -
the main Internet and something called Internet2. Internet2 has a routing
table of order 10,000 routes and includes most top-tier research instituations
in the US (and a few other places). By 1am this morning (Eastern US time),
all of our Internet links saturated outbound but we didn't appear to see any
noticable increase in our Internet2 bandwidth. I'm throwing this out there
because it may indicate that the destinations for the traffic - though large -
aren't completely random.

Has anyone else seen this?

  It's actually fairly rational. If you look at the size of the
I2 routing table in terms of how much of the IP space it covers,
it's a fair bit smaller than the full Internet routing table. And
most institutions have _more_ I2 bandwidth than commodity internet
connectivity. If the probing's roughly random, you'd expect the
I2 connection to fare better.

  MIT's I2 connectivity was better off than its commercial Internet
connection as well. Our private peering link to AT&T/mediaone was
actually in great shape (DS3, very small address space).

  -Dave