alex This is a very bad band-aid. The solution is amazingly simple -
Just to be clear, the solution to WHAT is amazingly simple?
alex make it uneconomical to have unprotected networks,
For whom to have unprotected networks? What constitutes a protected
network? How does one make it
From: [EMAIL PROTECTED]
unprotected are). For example, have a machine that had been broken into
and
used to attack a company which lost $5M because of that attack, make
whoever
owns the machine was broken into pay $5M + attorney frees + punitive
damages. Suddently, the unprotected (for
On Mon, 27 Jan 2003 15:53:07 EST, [EMAIL PROTECTED] said:
The amazingly simple solution is to make it uneconomical for anyone to
maintain unprotected network (for whatever two sets uneconomical and
unprotected are). For example, have a machine that had been broken into and
used to attack a
JB Date: Mon, 27 Jan 2003 15:19:25 -0600
JB From: Jack Bates
JB So, if I'm reading this right, user of Vendor L doesn't like
JB Vendor M. Instead of attacking Vendor M's software, the user
JB just needs to make sure Vendor M's corporate servers get
JB infected and cause enough damage to run
The first MPEG-4 HD set top boxes are beginning to appear
http://www.sigmadesigns.com/news/press_releases/030108.htm
Watch this space
If you read the document carefully, you´ll figure that they support MPEG2 HDTV
(1920x1080)
and MPEG4 SDTV (640x480/720x576), which was my point earlier.
On Wed, 22 Jan 2003, Baldwin, James wrote:
Something I'm surprised no one has commented on considering the
direction of this thread has been should ISPs be responsible for
customer actions if they are not allowed to refuse service to customers?
ISP's can't refuse service to customers?
Doesn't ECN depend on 'well behaved' traffic? In other words, wouldn't it
require the hosts sending traffic to slow down? So... even if the hosts
slowed down, 10,000 hosts still is a high traffic rate at the end point.
:(
Yes, for ECN to work the sending host must honor the slowdown request/
On Wed, 22 Jan 2003 11:11:19 -0500 Damian Gerow [EMAIL PROTECTED] wrote:
(Taking NANOG out, as this is moving a little towards personal
conversation)
Apparently, I didn't read my own Cc: line. Sorry, folks.
:[EMAIL PROTECTED]] On
Behalf Of Vadim Antonov
Sent: Tuesday, January 21, 2003 5:51 PM
To: todd glassey
Cc: [EMAIL PROTECTED]
Subject: Re: FW: Re: Is there a line of defense against
Distributed Reflective attacks?
On Tue, 21 Jan 2003, todd glassey wrote:
Vadim - the instant
At 09:28 AM 1/22/2003 -0800, Al Rowland wrote:
Not to mention that fact that 99.99% of current consumer connections are
not up to the task. Standard full-screen video digital stream is ~6Mbps,
HDTV requires 19.4Mbps. Don't know many consumers with T3s. ;)
Drifting off-topic, but those are
: Is there a line of defense against Distributed
Reflective attacks?
At 09:28 AM 1/22/2003 -0800, Al Rowland wrote:
Not to mention that fact that 99.99% of current consumer connections are
not up to the task. Standard full-screen video digital stream is ~6Mbps,
HDTV requires 19.4Mbps. Don't know
: Wednesday, January 22, 2003 10:02 AM
To: [EMAIL PROTECTED]
Subject: RE: FW: Re: Is there a line of defense against
Distributed Reflective attacks?
At 09:28 AM 1/22/2003 -0800, Al Rowland wrote:
SNIP
Drifting off-topic, but those are 'raw' data rates.
Compression algorithms along
Al Rowland [EMAIL PROTECTED] writes:
mention the effect everyone on AOL going to broadband and downloading
Disney clips all the time would have on their settlement plans with
backbone providers.
Of course, because you are definitely being kept in the loop regarding
the AOL settlement plans?
At 10:58 AM 1/22/2003 -0800, Al Rowland wrote:
1. I also remember when web page standards required you to design
everything to fit in a 640x400 screen. DTV/HDTV will significantly
change your 'not much in the way of image quality loss' yardstick. My
viewing habits have changed significantly in
Drifting off-topic, but those are 'raw' data rates. Compression algorithms
along with motion-estimation allow you to get full-screen video down to
~1.5 Mbps with not much in the way of image quality loss.
Raw HDTV is about 1.2Gbps. RAW NTSC SDI bitstream is a few hundred.
The 6 and 19.8
Hello;
On Wednesday, January 22, 2003, at 06:04 PM, Petri Helenius wrote:
Drifting off-topic, but those are 'raw' data rates. Compression
algorithms
along with motion-estimation allow you to get full-screen video down to
~1.5 Mbps with not much in the way of image quality loss.
Raw HDTV
Andy -
- Original Message -
From: Andy Dills [EMAIL PROTECTED]
To: todd glassey [EMAIL PROTECTED]
Cc: Vadim Antonov [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, January 22, 2003 9:07 AM
Subject: Re: FW: Re: Is there a line of defense against Distributed
Reflective attacks
Something I'm surprised no one has commented on considering the
direction of this thread has been should ISPs be responsible for
customer actions if they are not allowed to refuse service to customers?
I'm surprised this hasn't come up since the latter half of the question
also represented a
businesses.
Todd Glassey
- Original Message -
From: Vadim Antonov [EMAIL PROTECTED]
To: Avleen Vig [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, January 20, 2003 7:59 PM
Subject: Re: FW: Re: Is there a line of defense against Distributed
Reflective attacks?
On Mon, 20 Jan
Stoned koalas drooled eucalyptus spit in awe as Avleen Vig exclaimed:
Doesn't this stop kazaa/morpheus/gnutella/FTP/some aim stuff like
private chats? This is a problematic setup, and woudl require the cable
modem provider to maintain a quickly changing 'firewall' :( I understand
the want to
PROTECTED]; Daniel Senie [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, January 20, 2003 5:22 PM
Subject: Re: FW: Re: Is there a line of defense against Distributed
Reflective attacks?
On Mon, 20 Jan 2003, Avleen Vig wrote:
Doesn't this stop kazaa/morpheus/gnutella/FTP/some aim stuff
*shrug* just seems like it would make more sense to block all incoming
'syn' packets.
Wouldn't that be faster than inspecting the destination port against two
seperate rules?
blocking all SYN's will break too much other stuff (Instant Messangers,
games ...). I think we would be much better
Glassey
- Original Message -
From: Christopher L. Morrow [EMAIL PROTECTED]
To: Stewart, William C (Bill), RTLSL [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, January 17, 2003 6:29 PM
Subject: Re: FW: Re: Is there a line of defense against Distributed
Reflective attacks?
On Fri
-
From: todd glassey [mailto:[EMAIL PROTECTED]]
Sent: January 19, 2003 12:02
To: Christopher L. Morrow; Stewart, William C (Bill), RTLSL
Cc: [EMAIL PROTECTED]
Subject: Re: FW: Re: Is there a line of defense against
Distributed Reflective attacks?
You nor any of the ISP's may like
Without getting too much into the likelihood of any legal body actually
understanding anyone's role in an attack besides the attacker and the
victim, in this land where tobacco companies are sued by smokers who
get lung cancer and fast food restaurants are sued by fat people there
must be room
What incentive does the end-user have to use secure systems? Should
Microsoft, Sun, Sendmail Inc or ISC be required to send a technician out
to fix every defective system they released? Why should the ISP be held
accountable for the defects created by others? Car makers have to fix
On Mon, Jan 20, 2003 at 12:25:27AM -0500, Deepak Jain mooed:
As long as the car _moves_ under its own power across the highway, its
essentially not the car manufacturers' (or the consumers') immediate
concern.
That's really not true. Before car companies sell cars, they
pass (lots of)
against Distributed Reflective
attacks?
Many of these attacks can be mitigated by ISPs that do
anti-spoofing filtering on input - only accepting packets from user ports
Sure, but this is a proven non-scalable solution. HOWEVER, filtering as
close to the end host is scalable and feasible... do
On Sat, Jan 18, 2003 at 08:58:13AM -0500, Daniel Senie wrote:
While it's nice that router vendors implemented unicast RPF to make
configuration in some cases easier, using simple ACLs isn't necessarily
hard at the edges either.
It might be nice if all router vendors were able to associate
In message [EMAIL PROTECTED], David G. Andersen writes:
On Fri, Jan 17, 2003 at 01:11:14AM -0500, David G. Andersen mooed:
b) Ioannidis and Bellovin proposed a mechanism called Pushback
for automatically establishing router-based rate limits to
staunch packet flows during DoS
Once upon a time, John Kristoff [EMAIL PROTECTED] said:
It might be nice if all router vendors were able to associate the
interface configured address(es)/nets as a variable for ingress
filters. So for in the Cisco world, a simple example would be:
interface Serial0
ip address
What kinds of mechanisms exist for keeping track of the origins of
something of this nature?
Normally that's not very productive as they are mostly owned boxes that
will be rebuilt and reowned in days :(
We could automate the tracing process, like *57 customer initiated trace
on the
On Thu, Jan 16, 2003 at 08:48:03PM -0500, Brad Laue wrote:
Having researched this in-depth after reading a rather cursory article
on the topic (http://grc.com/dos/drdos.htm), only two main methods come
to my mind to protect against it.
There are a few more methods, some have already mentioned
Do we need te equivalent of a dog bite law for computers. If your
computer attacks another computer, the owner is responsible. File a
police report, and the ISP will give the results of the *57 trace to
the local police. The police can then put down the rabid computer,
permanently.
Vadim Antonov wrote:
Caution this won't program a router:
The police can then put down the rabid computer,
permanently.
Good in theory... in practice police has more important things to do. Like
catching pot smokers.
Not -=too=- much problem soon, thanks to the USA Patriot act.
In
On Fri, 17 Jan 2003, Vadim Antonov wrote:
Do we need te equivalent of a dog bite law for computers. If your
computer attacks another computer, the owner is responsible. File a
police report, and the ISP will give the results of the *57 trace to
the local police. The police can
On Fri, Jan 17, 2003 at 06:38:08PM +, Christopher L. Morrow mooed:
has something called Source Path Isolation Engine (SPIE). There
This would be cool to see a design/whitepaper for.. Kelly?
The long version of the SPIE paper is at:
On Fri, 17 Jan 2003, David G. Andersen wrote:
On Fri, Jan 17, 2003 at 06:38:08PM +, Christopher L. Morrow mooed:
has something called Source Path Isolation Engine (SPIE). There
This would be cool to see a design/whitepaper for.. Kelly?
The long version of the SPIE paper is
I guess the question of all this is may be... what could be done to
perhaps... to minimize the impact of DoS attacks pointed at a victim host?
Getting everyone to take security more seriously will most likely never
going to happen.. :(
-hc
On Fri, 17 Jan 2003, Clayton Fiske wrote:
On Fri,
On Fri, 17 Jan 2003 18:38:08 + (GMT)
Christopher L. Morrow [EMAIL PROTECTED] wrote:
has something called Source Path Isolation Engine (SPIE). There
This would be cool to see a design/whitepaper for.. Kelly?
In addition to David's link:
http://www.ir.bbn.com/projects/SPIE/
Getting everyone to take security more seriously will most likely never
going to happen.. :(
If this is the case then we are screwed... I hope its not the case, I hope
that the customer service folks at ISP/NSP's and NOC and Engineering folks
all keep this in their minds and push their
-Original Message-
From: Stewart, William C (Bill), RTLSL
Sent: Friday, January 17, 2003 5:35 PM
To: '[EMAIL PROTECTED]'
Subject: Re: Is there a line of defense against Distributed Reflective
attacks?
Many of these attacks can be mitigated by ISPs that do
anti-spoofing filtering
Having researched this in-depth after reading a rather cursory article
on the topic (http://grc.com/dos/drdos.htm), only two main methods come
to my mind to protect against it.
By way of quick review, such an attack is carried out by forging the
source address of the target host and sending
On Thu, 16 Jan 2003, Brad Laue wrote:
Having researched this in-depth after reading a rather cursory article
on the topic (http://grc.com/dos/drdos.htm), only two main methods come
to my mind to protect against it.
By way of quick review, such an attack is carried out by forging the
Because syn cookies are available on routing gear??? Either way syn
cookies are not going to keep the device from sending a 'syn-ack' to the
'originating host'.
True.. At least it will have some stop in the amount of attacks.
It is quite unfortunate that it is impossible to control
On Thu, 16 Jan 2003, hc wrote:
Because syn cookies are available on routing gear??? Either way syn
cookies are not going to keep the device from sending a 'syn-ack' to the
'originating host'.
True.. At least it will have some stop in the amount of attacks.
It is quite
Normally that's not very productive as they are mostly owned boxes that
will be rebuilt and reowned in days :(
I agree, keeping track of the attacks would not be very useful nor helpful.
I bet if more ISP's would implement egress filtering on their border routers,
it'd help quite a bit.
On Fri, 17 Jan 2003 04:29:07 GMT, Christopher L. Morrow said:
How quickly is quickly? Often times as has been my recent experience
(part of my motivation for posting this thread) the flood is over before
one can get a human being on the phone.
Once the call arrives and the problem is
Good point.
I suppose another basic but effective method of prevention would be
egress filtering. An increasing minority of network providers are
instituting it, but it doesn't seem like it will be a widespread thing
in the near-term.
Yes, but egress filtering is only effective by
On Fri, 17 Jan 2003 [EMAIL PROTECTED] wrote:
On Fri, 17 Jan 2003 04:29:07 GMT, Christopher L. Morrow said:
How quickly is quickly? Often times as has been my recent experience
(part of my motivation for posting this thread) the flood is over before
one can get a human being on the
My previous experience with UUNET security team was excellent dealing with
DoS.
I am not here to point fingers, but my DoS-response experience with various
Tier-2/3 level ISP's was like talking to some K-12 teacher who barely knows
what internet is. It really takes hours to get thru and reach
On Thu, 16 Jan 2003, hc wrote:
Normally that's not very productive as they are mostly owned boxes that
will be rebuilt and reowned in days :(
I agree, keeping track of the attacks would not be very useful nor
helpful. I bet if more ISP's would implement egress filtering on their
On Fri, 17 Jan 2003, hc wrote:
Good point.
I suppose another basic but effective method of prevention would be
egress filtering. An increasing minority of network providers are
instituting it, but it doesn't seem like it will be a widespread thing
in the near-term.
Yes,
According to hc [EMAIL PROTECTED]
Of course, egress filters don't
solve the issue. But considering most script kiddies' intelligence
level
is limited, it will help at least a bit. :-) The problem with egress
filtering is that it's mostly applicable at the end tier2+ level,
not at
the
On Fri, 17 Jan 2003 00:03:56 EST, hc said:
It will help of course, but really not The solution... Or is there one?
In this industry, anybody who advertises The Solution should automatically
be considered a snake oil salesman. There's no One Great Answer, because
there's more than one question.
On Thu, Jan 16, 2003 at 08:48:03PM -0500, Brad Laue mooed:
By way of quick review, such an attack is carried out by forging the
source address of the target host and sending large quantities of
packets toward a high-bandwidth middleman or several such.
One method that comes to mind that
At 12:00 AM 17-01-03 -0500, [EMAIL PROTECTED] wrote:
nsp-security now has 277 members and gets many of these warnings and
alerts. For further details:
http://puck.nether.net/mailman/listinfo/nsp-security
-Hank
We see a *LOT* of postings here anybody know a clueful at XYZ, we've been
On Fri, Jan 17, 2003 at 01:11:14AM -0500, David G. Andersen mooed:
b) Ioannidis and Bellovin proposed a mechanism called Pushback
for automatically establishing router-based rate limits to
staunch packet flows during DoS attacks.
[NDSS 2002, Implementing Pushback:
58 matches
Mail list logo
