Re: [bitfolk] How to handle unresponsive customers with issu…

Top Page

Reply to this message
Author: Michael Stevens
Date:  
To: users
Subject: Re: [bitfolk] How to handle unresponsive customers with issues that cannot be ignored
On Thu, Dec 15, 2016 at 03:20:08PM +0000, Andy Smith wrote:
> Hi,
>
> As you may be aware there are a few things that we (or third party
> services on our behalf) scan for on our own network. A
> non-exhaustive list of these things are:
>
> - Open SNMP servers
>
> - Open DNS resolvers
>
> - Open portmapper services
>
> - Open MongoDB / Memcached / Elasticsearch / Redis
>
> - Open Remote Desktop
>
> - Open multicast DNS (Avahi)
>
> - Open TFTP server
>
> - SSLv3/Poodle vulnerable services
>
> …and so on.
>
> Where these can only negatively affect the operator of the service
> (e.g. SSLv3/Poodle or an open MongoDB), we are content to just email
> you forever.
>
> However, many of these problems are worth scanning for because they
> are easily and frequently used to attack other hosts. For example,
> any "chatty" UDP protocol like portmapper or DNS can receive spoofed
> requests which will amplify, making for a DDoS on a third party.
>
> So, when we email customers about these it's because we need them
> fixed.
>
> Unfortunately some customers are either not receiving these emails
> or are happy to ignore them, for months at a time, basically until
> we open a support ticket with them and ask why they aren't dealing
> with it. This is taking up too much human time.
>
> "We did not receive the email" is now no longer a valid excuse
> because there is provision in our web panel for an
> emergency/alternate contact:
>
>     https://panel.bitfolk.com/account/contacts/#toc-address-book

>
> If we've been emailing a customer for weeks about this then we will
> have also sent a copy to the emergency/alternate contact at some
> point.
>
> So, I would like your opinions on how you think we should deal with
> this. Two proposals I can think of are:
>
> a) After at least 21 days of sending email alerts to the main
>    contact and the emergency contact and receiving no response, a
>    firewall rule will be added to block the problematic service and
>    an invoice will be raised for a managed firewall service, which
>    will be a monthly recurring charge. This will be quite expensive.

>
> Or:
>
> b) After at least 21 days of sending email alerts to the main
>    contact and the emergency contact and receiving no response, the
>    VPS's networking will be suspended. Networking will be re-enabled
>    when contact is re-established and a plan for securing the
>    problem service is agreed by both BitFolk and the customer.

>
> I have already broached this question on IRC and basically no one
> was in favour of (a) because they did not feel that surprise
> invoices would go down well.
>
> If you have other suggestions for how it should be handled I would
> be happy to read and consider them. Ideas that involve either not
> dealing with the problematic services or that aren't suitable for
> automation are not likely to be acceptable though.


I'm fairly happy with (b) however it'd be nice to be more specific about
what can get you suspended, maybe visibility in the panel of your scan
status, that sort of thing.

Michael