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
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.
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 thought.
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.
rant style=moaning and useless context=naive
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.
/rant
-hc
--
Haesu C.
TowardEX
Haesu wrote:
rant style=moaning and useless context=naive
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.
/rant
Seems like
[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,
REPLY_WITH_QUOTES,USER_AGENT_PINE
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 tools
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 ideas on
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? Just
- 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 traffic is coming from) as well
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
: 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 traffic is coming from) as well as with your DSL
provider.
Your
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
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
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 ACL
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
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
## 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 it
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...
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 path
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
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 you
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
investigate or
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 know the
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
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
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
if you
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 notice of CPU load over normal
traffic. Apparently a 7206 can block more PPS
29 matches
Mail list logo
