OT: Dealing with a hosting company with it's head up it's rear end

[Aryeh Friedman]

On Thu, Aug 13, 2020 at 3:25 PM Polytropon <freebsd at edvax.de> wrote:

> On Thu, 13 Aug 2020 14:56:43 -0400, Aryeh Friedman wrote:
> > "[Insert client name here], we do not allow RDP or SSH into our
> datacenter.
> > They are the primary vehicles for ransomware and cryptolocker breaches.
> We
> > utilize a secure access portal with multi-factor authentication to ensure
> > you don't get breached."
>
> Their "secure access portal" is probably something web-based.
> What is that? Something consisting of HTML, CSS, and JS, plus
> probably some kind of "security by obscurity" backend that has
> never seen any kind of security audit.
>

SolarWind


> Their advice sounds good, but seems to be the opposite of what
> happens in the real world.
>

More detached from reality than Trump.

>
>
>
> > I kind of understand RDP (but we have had bad luck with VNC on the same
> > hosting provider in the past so we prefer RDP), but SSH!?!?!?!?!    Their
> > idea of a "two factor" authentication is each connection will only be
> > allowed via a web portal and must use a one-time password sent the users
> > smartphone.
>
> For more than 10 years now, we know (!) that this method is
> not secure. How does it arrive on the smartphone? By SMS? By
> e-mail (2nd address)? Or do they have a dedicated app? Oh
> yes, I know, smartphones are sooooo secure...
>

Custom app but they also let you use any TOTP client but will only give you
the client key as a bar code and thus not easy to use with security/totp-cli


>
>
> > Not only does this make automated deploy impossible it is a
> > complete show stopper since our service is IoT and uses its own custom
> > protocol.
>
> They probably won't be able to even _understand_ what you're
> saying.
>

This is the same one I have told you about privately (the one that claimed
that block level backups where all that was needed to backup a live MySQL
instance and refused to read anything we sent saying otherwise).


>
>
> > So how do we/the client tell the hosting company they are full of sh*t
> (the
> > client has a 3 year contract with a pay in full to break clause with them
> > which would be over $100k to break)
>
> That is a good question. Those contracts are often designed
> with "if we do something wrong, it's your fault" in mind...
>

See our private conversation (TL; dr -- for everyone else that is the
summery of the entire contract)


> My suggestion would be: Try to find a "technical person"
> who you can talk to, layout your arguments, and explain
> what is going to happen. Yes, this sounds like elementary
> school, but sometimes it helps. However, the "technical
> person" should have power (!) in that hosting company to
> make things happen.
>

We were working directly with a technical person until the new contract was
signed then within 72 hrs the person we were working with said that neither
they nor anyone else on the sys/netadmin staff where authorized to talk to
end users/customers directly any more and we had to go through the sales
dept. (?!!?!?!??) to file a ticket and if needed it would be forwarded to
tech support and if they didn't work to the techies but the techies could
only tell tech support what to say not to talk to us directly.


>
>
>
> On Thu, 13 Aug 2020 14:58:54 -0400, Aryeh Friedman wrote:
> > Forgot to ask how common is such idiocy?  And is it becoming more common?
>
> Sadly I have experienced this already a few times, where
> secure methods were considered "insecure" and replaced
> with "secure" and "convenient" methods that would be more
> expensive, more prone to security breaches, inconvenient,
> or just unusable (read: it doesn't work at all).
>

I think the bottom line is they want someone to sue if there is a security
breach... this is a hosting company run by bankers and other financial
services types.


-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org