[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Handling of Abuse Complaints
- Subject: Handling of Abuse Complaints
- From: hugo at slabnet.com (Hugo Slabbert)
- Date: Mon, 29 Aug 2016 09:05:13 -0700
- In-reply-to: <CABD5c[email protected]>
- References: <CABD5c[email protected]>
On Mon 2016-Aug-29 10:55:27 -0500, Jason Lee <jason.m.lee at gmail.com> wrote:
>I was curious how various players in this industry handle abuse complaints.
>I'm drafting a policy for the service provider I'm working for about
>handing of complaints registered against customer IP space. In this example
>I have a customer who is running an open resolver and have received a few
>complaints now regarding it being used as part of a DDoS attack.
>My initial response was to inform the customer and ask them to fix it. Now
>that its still ongoing over a month later, I'd like to take action to
>remediate the issue myself with ACLs but our customer facing team is
>pushing back and without an idea of what the industry best practice is,
>management isn't sure which way to go.
>I'm hoping to get an idea of how others handle these cases so I can develop
>our formal policy on this and have management sign off and be able to take
>quicker action in the future.
If you've informed them of the issue, given them time to resolve, and
they've failed to take action, at some point you need to escalate and
cauterize the wound to prevent abuse traffic spewing forth from the
cusotmer's (and subsequently your) network.
How you implement that specifically is your call, but I would at least
start giving specific timelines to the customer and outline the steps that
will be taken if they fail to remediate by those times in order to give
them fair warning.
I've been fairly specific previously about crafting filters to drop just
the offending traffic, which should be doable here given the vector, but in
other cases where it was obvious the offending hosts were simply
compromised to hell and spewing myriad garbage traffic, I have cut users
off completely to chop C&C access etc.
This was during time at a regional commercial ISP on business circuits.
Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E | also on Signal
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature