OT: Dealing with a hosting company with it's head up it's rear end
freebsd at edvax.de
Thu Aug 13 19:25:31 UTC 2020
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."
Verify, examine, and refute.
Primary vehicles for ransomware and cryptolockers are e-mail
(here: especially HTML e-mails and those containing attachments
in MICROS~1 "Office" formats), as well as e-mails encouraging
the user to visit "looks legitimate"-types of sites where
common tools like HTML, CSS, and JS are being used to install
ransomware and cryptolockers.
In reality, RDP and especially (!) SSH are a minority when it
comes to distribution of ransomware and cryptolocker software.
Why? Because technical reasons and social considerations apply,
as well as "who is our target audience".
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.
Their advice sounds good, but seems to be the opposite of what
happens in the real world.
> 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
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...
> Not only does this make automated deploy impossible it is a
> complete show stopper since our service is IoT and uses its own custom
They probably won't be able to even _understand_ what you're
> 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...
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.
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).
Luckily in Germany, you still sometimes find people who
are professionally educated _and_ allowed to make correct
decisions, and if you can get to talk to them, there often
is a solution. In my experience, this has become more and
more problematic due to a rise of bureaucracy and severe
cases of NIH ("not invented here", i. e., they don't know
about it, so it doesn't exist). There always are layers of
management that consist of "we know better than you" who
will disregard every help you (!) are offering to get the
problem solved, leading so strange cases where if you
point out their security flaws and how to properly deal
with them, you get accused of hacking ("You have a serious
SQLi problem in your login page." - "He hacked us! Call
In an ideal competetitive economy with a free market, you
should be able to find a provider who is able and willing
to provide what you're requiring. It's technically possible,
and in the end, it's _your_ responsibility anyway ("It's
not out fault when you get hacked, your signature on the
contract says so."), so it doesn't actually make any
difference. Even if we're just talking about VMs, that's
pretty standard today: _you_ are the administrator, and
you will keep the systems secure; _their_ respnsibilities
are different (e. g., keep the actual hardware running,
make sure it connects to the Internet, provide access to
the VMs, and so on).
Personally, I don't see a problem. But that doesn't stop
stpud prople from artificially creating problems. ;-)
On Thu, 13 Aug 2020 15:06:57 -0400, Aryeh Friedman wrote:
> All ports except 80 and 25 are firewalled
So they left the "insecure ports" open. Great.
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions