The worm is being talked about on news.com and all the major virus vendors
already have advisories on their websites. The worm in my case masqueraded
as a Mailer Daemon bounce. Source email address appeared to be valid and
matching a domain of a website I visited recently (but have not for a long
Since all sniffers I know of are passive devices, there really shouldn't be
a way to track one down. From a Cisco standpoint, if I were mirroring a
port, and had a sniffer mirroring the sniffer port, I would see traffic of a
unicast nature with multiple unicast MAC destinations destined at a
swith
Ejay,
Those would be Intel NICs.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ejay
Hire
Sent: Thursday, January 08, 2004 10:17 AM
To: 'Alexei Roudnev'; [EMAIL PROTECTED]; 'Jeff Kell'
Cc: [EMAIL PROTECTED]
Subject: RE: GSR, 7600, Juniper M?, oh my!
"
I would hate to blame the users here. In most organizations it is the
role of the IT Dept to manage the workstations and not end users.
Severely restricting users privileges is often a good thing, at least
from the perspective of being able to control what gets installed on the
machines in questi
Its even funnier what happens when a customer confuses a Netopia console
connector with that of the power connector from the next revision :)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 10:57 AM
To
This type of situation has been extensively discussed and debated here.
If you are not UUNet's direct customer (or many other providers for that
manner), they likely cannot and will not open a ticket. If MFN is your
upstream, open up a ticket with them.
-Original Message-
From: [EMAIL PRO
> Then you are pushing out /32's and peers would need to accept them. Then
> someone will want to blackhole /30's, /29's, etc. Route bloat. Yum!
I am in no way proposing discounting current filtering rules. There are
alway two
different intersts one must consider, one that of the customer an
> > What processes and/or tools are large networks using to
> > identify and limit the impact of DDoS attacks?
>
> A great deal of thought is being expended on this question, I am certain,
> however, how many of these thought campaings have born significant fruit
yet,
> I do not know.
How about
