ED]>
To: Haesu <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Extensions to RFC1998 - WAS: Re: DoS Attacks
In-Reply-To: <[EMAIL PROTECTED]>
X-Spam-Status: No, hits=-2.0 required=5.0
tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
REPL
Haesu wrote:
>
>
>
> I really don't give a ^H^H^H^H!H * !X *!X about what timeframe abuse departments
> operate. I just want more upstreams (or specifically my upstreams) to have a
> community that I can announce a /32 to null.
>
>
Seems like they ought to be made to offer a 1/3-the-pr
I really don't give a ^H^H^H^H!H * !X *!X about what timeframe abuse departments
operate. I just want more upstreams (or specifically my upstreams) to have a community
that I can announce a /32 to null.
-hc
--
Haesu C.
TowardEX Technologies, Inc.
Consulting, colocation, web hosting, n
>
> Due to the efficiency of our upstream provider's abuse department,
> opening efficiently at 8 am and closing just as efficiently at 5 pm
(because we all know network abuse only occurs between 8 and 5), the ISP
wasn't going to be of much help with an attack that started at 6:30pm
localtime.
>
>
On Wed, 08 Oct 2003 08:44:26 +0100
Martin Hepworth <[EMAIL PROTECTED]> wrote:
>
>
> Can SLA's be used to cover this sort of thing. (starts to dig out his
> own contracts).
>
> Surely you should be able to bounce it to your upstream provider who
> should deal with it for you??
>
> Just a tho
On Tue, 7 Oct 2003, Brian Bruns wrote:
> So, now for the fun part. Being offsite, I wasn't the one to place the
> calls, but my admin on site started with FSU's abuse desk. No help
> whatsoever. Claimed that because the abuse desk was gone, they had no
> authority to deal with the problem. Fr
Can SLA's be used to cover this sort of thing. (starts to dig out his
own contracts).
Surely you should be able to bounce it to your upstream provider who
should deal with it for you??
Just a thought.
--
Martin Hepworth
Senior Systems Administrator
Solid State Logic Ltd
tel: +44 (0)1865 8423
ge -
> From: "Mark Radabaugh" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, October 07, 2003 11:56 PM
> Subject: Re: DoS Attacks
>
>
> >
> > I think I would follow two avenues next time - the direct approach with
> FS
On Tue, 7 Oct 2003, Avleen Vig wrote:
> You knew the sources are small and you knew where they were. You did the
> right thing by contacting FSU, and then their upstream.
> If either was unresponsive, they are being extremely neglegent.
Its generally a better idea to contact your own upstream pro
- Original Message -
From: "Mark Radabaugh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 07, 2003 11:56 PM
Subject: Re: DoS Attacks
>
> I think I would follow two avenues next time - the direct approach with
FSU
> (or wherever the
On Tue, Oct 07, 2003 at 11:45:35PM -0400, Brian Bruns wrote:
> So here I am, asking if anyone here has any advice on dealing with these
> issues in the future? Its painfully apparent noone takes these situations
> seriously enough. What should we do when we are put in a position like
> this? Ju
> So here I am, asking if anyone here has any advice on dealing with these
> issues in the future? Its painfully apparent noone takes these situations
> seriously enough. What should we do when we are put in a position like
> this? Just sit back and hope it goes away itself?
>
> Also, any idea
e out DoS attacks pretty well - this was an exception)
Then suddenly, out of the blue it dropped. Outside connectivity was
restored and things were back to normal.
20 minutes later, the relentless attack began again. This time, we were
ready and waiting with tcpdump and several other handcrafted
With Juniper gear there is no performance difference between what you propose
and an ACL, both run at wire rate. So implementing "CPU saving measures" is pointless
waste of time.
Pete
>
> We could ask Cisco and Juniper to add a way of 'artificially' remove networks from
> the CEF table (with an
On Fri, 28 Mar 2003, Andre Chapuis wrote:
>
> We could ask Cisco and Juniper to add a way of 'artificially' remove
> networks from the CEF table (with an ACL or so). That way, even with
> loose-RPF, the packet will be dropped based on source-address at the
> ingress without consuming CPU.
Keep
Andre,
Actually it already exists. But to do it, you need
to ensure you have loose-RPF checking enabled and null-route
the network you want the data dropped for. Since a null-route
is considered by loose-RPF checking as a "bad" route, it will
drop the data for you.
thanks,
charles
On
We could ask Cisco and Juniper to add a way of 'artificially' remove networks from the
CEF table (with an ACL or so). That way, even with loose-RPF, the packet will be
dropped based on source-address at the ingress without consuming CPU.
Or maybe such a feature already exist
André
At 09:06 25.0
d when doing special caching
policies before our load exceeded what the ArrowPoint and the 7206 cpu's
could handle. FYI: one of my DOS attacks was a PPS attack, and since the
packets were small and not using bandwidth, blocking via access-list
recovered the network completely with little not
> >
> > i am not really sure what kind of traffic we are talking about,
> > but if its around 100Mbits/sec or so bandwidth, TurboACL should do it just
> > fine (around ~20% or lower CPU usage on a 7206VXR with NPE-G1)
>
> most likely the pps would kill the 5500 long before the bps :( especially
>
On Tue, 25 Mar 2003, Jim Deleskie wrote:
> >If you fooled the router into thinking that the reverse path for the
> >source is on another another interface and then used strict unicast RPF
> >checking, that may accomplish what you want without using ACLs. I don't
> >know what impact it would have
On Tue, 25 Mar 2003, Haesu wrote:
>
> uRPF will certainly save a bit of CPU cycles than access-lists or policy
that is HIGHLY dependent on the platform in question. For the stated
'router' (5500+rsm) I'd think the impact would be about the same as for an
acl. 7500+RSP or 5500+RSM (which is pret
On Tue, 25 Mar 2003, Christian Liendo wrote:
>
> Looking for advice.
>
> I am sorry if this was discussed before, but I cannot seem to find this.
> I want to use source routing as a way to stop a DoS rather than use
> access-lists.
you can null route it also.
>
> In other words, lets say I kno
>If you fooled the router into thinking that the reverse path for the
>source is on another another interface and then used strict unicast RPF
>checking, that may accomplish what you want without using ACLs. I don't
>know what impact it would have on your CPU however, you'll have to
>investigat
> uRPF will certainly save a bit of CPU cycles than access-lists or policy
> routing.. it would be intertesting to know any kind of 'common practice'
> ways people use to fool the router so that it will think such offensive
> source IP's are hitting uRPF.
null route? even with a loose check, if y
uRPF will certainly save a bit of CPU cycles than access-lists or policy
routing.. it would be intertesting to know any kind of 'common practice'
ways people use to fool the router so that it will think such offensive
source IP's are hitting uRPF.
i am not really sure what kind of traffic we are
On Tue, 25 Mar 2003 09:06:01 -0500
Christian Liendo <[EMAIL PROTECTED]> wrote:
> I am sorry if this was discussed before, but I cannot seem to find
> this. I want to use source routing as a way to stop a DoS rather than
> use access-lists.
If you fooled the router into thinking that the reverse
At 09:21 AM 3/25/2003 -0500, Haesu wrote:
I dunno how you want to implement this; but as far as I know, the way most
people generally do policy routing on cisco thru routemap is they define
the source IP's via access-list... Does that make a huge difference than
regular access lists? I dunno...
We
## On 2003-03-25 09:06 -0500 Christian Liendo typed:
[snip]
CL>
CL> Depending on the router and the code, if I implement an access-list then
CL> the CPU utilization shoots through the roof.
CL> What I would like to try and do is use source routing to route that traffic
CL> to null. I figured
I dunno how you want to implement this; but as far as I know, the way most
people generally do policy routing on cisco thru routemap is they define
the source IP's via access-list... Does that make a huge difference than
regular access lists? I dunno...
I've kinda tested it in the lab with two 72
Looking for advice.
I am sorry if this was discussed before, but I cannot seem to find this.
I want to use source routing as a way to stop a DoS rather than use
access-lists.
In other words, lets say I know the source IP (range of IPs) of an attack
and they do not change.
If the destination st
30 matches
Mail list logo
