What's NANOG's opinion: assuming that uRPF is implemented on all
customer interfaces, are there any legitimate purposes for a customer to
forward packets with source IP addresses not currently routed by the
transit provider towards the customer (either static or BGP)?
IP Tunneling - it
On Wed, 1 May 2002, Pete Kruckenberg wrote:
I finally found a paper on this type of attack.
http://grc.com/files/drdos.pdf and
http://grc.com/dos/grcdos.htm describe the attack and a few
possible defenses, though they are about as ineffective as
most other DDoS defenses.
Has NANOG
On Mon, 6 May 2002, [EMAIL PROTECTED] wrote:
On Mon, 06 May 2002 19:04:11 EDT, Ralph Doncaster said:
IP Tunneling - it often makes more sense to send packets out that have a
source address reachable only through the tunnel.
But aren't those source addresses hidden *inside* the
In the referenced message, Steven W. Raymond said:
Stephen Griffin wrote:
Tell them they will need to register their routes in the IRR, even if they
don't necessarily advertise all or any of them. Build your exceptions
based upon the irr, as for all bgp-speaking customers.
On Mon, May 06, 2002 at 05:15:25PM -0600, Pete Kruckenberg wrote:
I finally found a paper on this type of attack.
http://grc.com/files/drdos.pdf and
http://grc.com/dos/grcdos.htm describe the attack and a few
possible defenses, though they are about as ineffective as
most other DDoS
Stephen Griffin wrote:
where for RPF, or traditional traffic filter is
access-list foo {permit|deny} ip source wildbits dest wildbits
Hrrmm, since uRPF checks only the source address, the standard ACL
seems most appropriate to me.
I guess you could use a standard acl however I wouldn't
Once upon a time, Richard A Steenbergen [EMAIL PROTECTED] said:
Don't confuse the rantings of a nutcase and his T1 with useful information
about DoS. I have to admit I like the direction the made up acronyms are
going though, can we have MS-DOS next? :)
You mean MicroSoft Denial Of
On Sun, 5 May 2002, Christopher L. Morrow wrote:
like with single homed customers. The only time when those sets of
prefixes is NOT the same is for a backup connection. But if a connection
Not always the case, customer behaviour can not be accurately modeled.
I was hoping someone
At 03:34 AM 5/05/2002 +, Christopher L. Morrow wrote:
I was hoping someone else might mention this, BUT what about the case of
customers providing transit for outbound but not inbound traffic for their
customers?
two methods:
[1] if your customer has their own AS, have them route the
PROTECTED]
Subject: Re: Effective ways to deal with DDoS attacks?
On Sun, 5 May 2002, Christopher L. Morrow wrote:
like with single homed customers. The only time when those sets of
prefixes is NOT the same is for a backup connection. But if
a connection
Not always the case, customer
On the subject of uRPF, I thought I should point out that Juniper just
added support for it in JunOS 5.3. The news seems to have been obscured
by the T640, but I think its a pretty big deal.
One less excuse for the people who still aren't RPF filtering their
customers (you know who you are). Go
In the referenced message, Iljitsch van Beijnum said:
On Fri, 3 May 2002, Stephen Griffin wrote:
for single-homed customers, simple uRPF
for multihomed customers, acl exceptions based upon their registered
IRR-policy, since the customer should already be registering in the IRR
you
On Sat, 4 May 2002, Stephen Griffin wrote:
In the referenced message, Iljitsch van Beijnum said:
On Fri, 3 May 2002, Stephen Griffin wrote:
For multihomed customers, these sets of prefixes should be identical, just
like with single homed customers. The only time when those sets of
In the referenced message, Eric Gauthier said:
snip
Another limitation that we've found with uRPF is that it doesn't
live well with multihomed systems (i.e. a host with two NIC's - each on
a different subnet) because of the way most OS'es handle their
default gateways. For anyone who is
On Fri, 3 May 2002, Stephen Griffin wrote:
for single-homed customers, simple uRPF
for multihomed customers, acl exceptions based upon their registered
IRR-policy, since the customer should already be registering in the IRR
you have a list of all networks reachable via the customer,
Do you mind sharing with us the 4 things that exists only in DoS packets ?
Rubens Kuhl Jr.
- Original Message -
They CAN filter on anything in the headers, it's just a matter of
convincing them that the specific filter you want is something they should
add to their software
Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Mark Turpin
Sent: Thursday, May 02, 2002 10:05 AM
To: LeBlanc, Jason
Cc: [EMAIL PROTECTED]
Subject: Re: Effective ways to deal with DDoS attacks?
On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote
On Thu, 2 May 2002, Christopher L. Morrow wrote:
On Thu, 2 May 2002, Avleen Vig wrote:
If you're being attacked by a SYN flood, you can ask try to rate-limit the
flood at your border (possible on Cisco IOS 12.0 and higher, and probably
other routers too?)
Let me say this one more
At 01:49 AM 02-05-02 +0100, Avleen Vig wrote:
As time goes by, tools are being developed (in fact they're used now) that
completely randomize the TCP or UDP ports attacked, or use a variety of
icmp types in the attack.
So cuurrently the only way you can 'block' such attacks is to block all
At 04:16 AM 02-05-02 +, Christopher L. Morrow wrote:
What we use and we're a 'largeish' network:
http://www.secsup.org/Tracking/
(shameless plug #1)
Among other things this is a tool we use... there was a great set of
slides and presentation given at NANOG23:
On Wed, May 01, 2002 at 05:18:24PM -0600, [EMAIL PROTECTED] said:
[snip]
A rather extensive survey of DDoS papers has not resulted in
much on this topic.
What processes and/or tools are large networks using to
identify and limit the impact of DDoS attacks?
It seems to me that the real
:51 AM
Subject: Re: Effective ways to deal with DDoS attacks?
At 01:49 AM 02-05-02 +0100, Avleen Vig wrote:
As time goes by, tools are being developed (in fact they're used now) that
completely randomize the TCP or UDP ports attacked, or use a variety of
icmp types in the attack.
So
On Thu, 2 May 2002, Christopher L. Morrow wrote:
1) I hack connected ISP X
2) I inject www.ebay.com /32 blackhole route
3) no more ebay
I use ebay as an example of course, I wouldn't want them harmed cause how
would I be able to buy all that nice routing gear at bargain basement
prices
[EMAIL PROTECTED] disait :
have been on the receiving end of, the first was generating a little over
300mbit/sec (steady for a prolonged time), and the second went over that by a
fair bit. In both cases, we had core equipment (M20's and BSN5000's) fall
over and die trying to work the
On Wed, 1 May 2002, Pete Kruckenberg wrote:
There's been plenty of discussion about DDoS attacks, and my
IDS system is darn good at identifying them. But what are
effective methods for large service-provider networks (ie
ones where a firewall at the front would not be possible) to
deal
On Thu, 2 May 2002, Avleen Vig wrote:
Basically, it works like this: when you identify the target of the attack,
you have traffic for those target addresses rerouted to a filter box.
This filter box then contains source address based filters to get rid of
the attacking traffic.
Two
Stoned koalas drooled eucalyptus spit in awe as Christopher L. Morrow
exclaimed:
I use ebay as an example of course, I wouldn't want them harmed cause how
would I be able to buy all that nice routing gear at bargain basement
^^^
Shouldn't this be s/I/WCOM/? :)
prices
On Wed, May 01, 2002 at 11:56:07PM -0600, Pete Kruckenberg wrote:
On Thu, 2 May 2002, Richard A Steenbergen wrote:
You have an interesting situation. I think rate limiting
outbound RSTs would be the least offensive thing you
could do, off the top of my head.
What about just
01, 2002 4:18 PM
To: [EMAIL PROTECTED]
Subject: Effective ways to deal with DDoS attacks?
There's been plenty of discussion about DDoS attacks, and my
IDS system is darn good at identifying them. But what are
effective methods for large service-provider networks (ie
ones where a firewall
On Thu, 2 May 2002, Christopher L. Morrow wrote:
On Wed, 1 May 2002 [EMAIL PROTECTED] wrote:
True DDoS attacks, fortunately, are rarer than most people believe. If they
were not, the Internet as we know it would look a lot more like a telephone
system in USSR-at-it's-worst-days.
On Wed, May 01, 2002 at 11:29:46PM -0600, Pete Kruckenberg wrote:
We do have a fairly aggressive security group that
identifies compromised machines and assists customers in
properly securing them. We can be fairly certain that the
way these hosts are responding to this DoS attack is not
On Thu, 2 May 2002, Hank Nussbacher wrote:
At 01:49 AM 02-05-02 +0100, Avleen Vig wrote:
As time goes by, tools are being developed (in fact they're used now) that
completely randomize the TCP or UDP ports attacked, or use a variety of
icmp types in the attack.
So cuurrently the only
-
From: Richard A Steenbergen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 02, 2002 9:23 AM
To: LeBlanc, Jason
Cc: 'Pete Kruckenberg'; [EMAIL PROTECTED]
Subject: Re: Effective ways to deal with DDoS attacks?
On Thu, May 02, 2002 at 08:54:05AM -0700, LeBlanc, Jason wrote:
uRPF and Radware DoShield
On Thu, 2 May 2002, Vincent Gillet wrote:
[EMAIL PROTECTED] disait :
have been on the receiving end of, the first was generating a little over
300mbit/sec (steady for a prolonged time), and the second went over that by a
fair bit. In both cases, we had core equipment (M20's and
On Thu, 2 May 2002, Iljitsch van Beijnum wrote:
On Wed, 1 May 2002, Pete Kruckenberg wrote:
There's been plenty of discussion about DDoS attacks, and my
IDS system is darn good at identifying them. But what are
effective methods for large service-provider networks (ie
ones where a
ways to deal with DDoS attacks?
On Thu, 2 May 2002, Vincent Gillet wrote:
[EMAIL PROTECTED] disait :
have been on the receiving end of, the first was generating a little
over
300mbit/sec (steady for a prolonged time), and the second went over
that by a
fair bit. In both cases, we had
On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote:
Yes, Juniper can be convinced to add things, we've asked for a few. ;)
Part of the problem with asking for new things on an ASIC, takes time.
Anything they add in their code to help filter will likely not be done
in hardware,
On Thu, 2 May 2002, LeBlanc, Jason wrote:
There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type. Impact should be minimal, as it simply
does a lookup in the CEF
On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something like this:
snip
There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type. Impact should be
On Thu, 2 May 2002, Christopher L. Morrow wrote:
Congrats on re-inventing the wheel :( This is what
mazuu/arbor/wanwall(riverhead now?) all do... this is also the way
CenterTrack(tm robert stone) was kind of supposed to work.
Thanks for the kind works.
Just to be clear: I'm not working on
that is
valid would be in CEF. If I'm misunderstanding, please do send more info.
-Original Message-
From: Mark Turpin [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 02, 2002 10:05 AM
To: LeBlanc, Jason
Cc: [EMAIL PROTECTED]
Subject: Re: Effective ways to deal with DDoS attacks?
On Thu, May
to be
worthwhile.
-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 02, 2002 9:58 AM
To: LeBlanc, Jason
Cc: [EMAIL PROTECTED]
Subject: RE: Effective ways to deal with DDoS attacks?
If you just filter out anything that's not in the routing table, that's
about
On Thu, May 02, 2002 at 12:04:35PM -0500, Mark Turpin wrote:
On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something like this:
snip
There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco). I believe it will work on 65xx
http://www.cisco.com/warp/public/707/newsflash.html
There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type. Impact should be minimal, as it simply
does a lookup
that is
valid would be in CEF. If I'm misunderstanding, please do send more info.
-Original Message-
From: Mark Turpin [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 02, 2002 10:05 AM
To: LeBlanc, Jason
Cc: [EMAIL PROTECTED]
Subject: Re: Effective ways to deal with DDoS attacks?
On Thu
On Thu, 2 May 2002, Richard A Steenbergen wrote:
RPF works by matching the source address of the packet against the CEF
table, in addition to the normal match against the destination address.
There are multiple modes of operation, ranging from is there a route
for the source address to the
On Thu, 2 May 2002, LeBlanc, Jason wrote:
Try a compiled ACL on a 3 port gigE for some fun.
Last I recall the IOS didn't even have 'ip access-group' in the config of
interfaces :( It took me like three hits of the 'tab' key at 'ip access-g'
before I realized it just wasn't there ;(
We have been working on this problem for the last two years and
have productized a practical way to deal with DDoS. Given what I have
read today, I think most people on this list would
like it. If you send me email, I will send you a white paper that is much
more
detailed than what you can find
RAS Date: Thu, 2 May 2002 12:23:01 -0400
RAS From: Richard A Steenbergen
RAS They CAN filter on anything in the headers, it's just a matter of
RAS convincing them that the specific filter you want is something they should
RAS add to their software language and microcode. I'm sure as a core
ED Date: Fri, 3 May 2002 02:35:53 + (GMT)
ED From: E.B. Dreger
ED Juniper being based on FreeBSD/x86, perhaps some kernel hooks
ED might be in order for those who wish to write their own code.
And, were my head on straight, I'd have been thinking about the
ASIC in the line card, _not_ the
There's been plenty of discussion about DDoS attacks, and my
IDS system is darn good at identifying them. But what are
effective methods for large service-provider networks (ie
ones where a firewall at the front would not be possible) to
deal with DDoS attacks?
Current method of updating ACLs
http://www.secsup.org/Tracking/
UUNet uses that...others might as well, Shrug.
Quick, simple, effective tracking of DDoS attacks.
As for identifying attacks, quite honestly large ISP's are typically still
relying on customer notification. I know that's how we do it.
On Wed, 1 May 2002,
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!
Additionally you are creating a way to basically destroy the Internet as a
whole. One kiddie gets ahold of a router, say of a large backbone
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 and
In a message written on Wed, May 01, 2002 at 08:17:04PM -0500, dies wrote:
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'm not sure what form this would take, but I have long wished
route
On Wed, May 01, 2002 at 09:38:52PM -0400, Wojtek Zlobicki wrote:
How about the following :
We develop a new community , being fully transitive (666 would be
appropriate ) and either build into router code or create a route map to
null route anything that contains this community. The
On Wed, 1 May 2002, Pete Kruckenberg wrote:
We experience a lot of types of attacks (education/research
network = easy hacker target). With DDoS incidents, it
seems we are more often an unknowing/unwilling participant
than the target, partly due to owning big chunks of IP
address space.
On Wed, 1 May 2002 [EMAIL PROTECTED] wrote:
and then again, there has been much discussion on simple
DoS attacks, where the term DDoS is erroneously used...
I am very much not trying to imply that this is the case
here, but it's important that the two be thoroughly
distinguished from
What we use and we're a 'largeish' network:
http://www.secsup.org/Tracking/
(shameless plug #1)
Among other things this is a tool we use... there was a great set of
slides and presentation given at NANOG23:
http://www.nanog.org/mtg-0110/greene.html
(shameless plug #2)
There is also a set of
On Wed, 1 May 2002 [EMAIL PROTECTED] wrote:
True DDoS attacks, fortunately, are rarer than most people believe. If they
were not, the Internet as we know it would look a lot more like a telephone
system in USSR-at-it's-worst-days. For example, of the two recent DDoS's I
have been on
On Wed, 1 May 2002, dies wrote:
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!
Yes.
Additionally you are creating a way to basically destroy the Internet as a
whole. One kiddie gets ahold
On Wed, 1 May 2002, Wojtek Zlobicki wrote:
Where are providers drawing the line ? Anyone have somewhat detailed
published policies as to what a provider can do in order to protect their
nework as a whole.
At what point (strength of the attack) does a customers netblock (assuming a
/24
On Thu, May 02, 2002 at 04:28:44AM +, Christopher L. Morrow wrote:
Let me say this one more time... RATE LIMITS DON'T DO SHIT TO STOP
ATTACKS for the victim atleast, all they do is make the job of the
attacker that much easier. For instance:
1) I synflood www.avleen.org
2) you
On Wed, 1 May 2002, Richard A Steenbergen wrote:
I give it 2 months, then they'll start hitting random dst IPs in a target
prefix (say a common /24 going through the same path).
Damn you, don't give them any ideas :)
On Thu, May 02, 2002 at 04:45:43AM +, Christopher L. Morrow wrote:
On Wed, 1 May 2002, Wojtek Zlobicki wrote:
Where are providers drawing the line ? Anyone have somewhat detailed
published policies as to what a provider can do in order to protect their
nework as a whole.
At what
On Wed, 1 May 2002, Pete Kruckenberg wrote:
On Wed, 1 May 2002, Richard A Steenbergen wrote:
DDoS attacks is such a generic term. There are a wide
variety of attacks which each need to be handled in
their own way, the extra D is just one possible twist.
Can you explain what kind of
On Wed, 1 May 2002, Pete Kruckenberg wrote:
On Wed, 1 May 2002 [EMAIL PROTECTED] wrote:
and then again, there has been much discussion on simple
DoS attacks, where the term DDoS is erroneously used...
I am very much not trying to imply that this is the case
here, but it's important
On Wed, 1 May 2002, Basil Kruglov wrote:
On Thu, May 02, 2002 at 04:45:43AM +, Christopher L. Morrow wrote:
On Wed, 1 May 2002, Wojtek Zlobicki wrote:
Where are providers drawing the line ? Anyone have somewhat detailed
published policies as to what a provider can do in order
On Thu, 2 May 2002, Richard A Steenbergen wrote:
SYN packet comes in, one of these machines responses with a
RST to the source, which is actually the target of the
You have an interesting situation. I think rate limiting
outbound RSTs would be the least offensive thing you
could do, off
On Wed, 1 May 2002, Pete Kruckenberg wrote:
On Thu, 2 May 2002, Richard A Steenbergen wrote:
SYN packet comes in, one of these machines responses with a
RST to the source, which is actually the target of the
You have an interesting situation. I think rate limiting
outbound RSTs
70 matches
Mail list logo
