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

Aryeh Friedman aryeh.friedman at gmail.com
Fri Aug 14 06:52:44 UTC 2020


On Fri, Aug 14, 2020 at 2:29 AM Polytropon <freebsd at edvax.de> wrote:

> On Fri, 14 Aug 2020 06:57:01 +0100, Steve O'Hara-Smith wrote:
> > On Fri, 14 Aug 2020 00:43:12 +0200
> > Polytropon <freebsd at edvax.de> wrote:
> >
> > > On Thu, 13 Aug 2020 16:12:18 -0400, Aryeh Friedman wrote:
> > > > They have a whacko firewall config that will eat 443/decrypt
> it/forward
> > > > it on as plain http via a proxy on the firewall
> > >
> > > So what you're saying is: They don't care about security,
> > > in fact, they're making things worse, by being the "man in
> > > the middle"?! Wow...
> >
> >       It is a very common corporate firewall technique, and appropriate
> > in that context. But for a hosting company it seems odd.
> >
> > > "Boohoohoo! SSH is so insecure, we must not allow that!"
> >
> >       Again many corporate firewalls don't allow ssh out (or in directly)
> > because tunnelling bypasses the firewalls. And again it seems odd for a
> > hosting company.
>
> Exactly my impression. For a regular "boring paper office",
> such limitations are not a surprise, and seem to work fine,
> eliminating a few of the most common attack vectors. Smear
> a few gallons of snake oil on the whole IT infrastructure
> and perform security theatre twice a month, and everyone
> will be happy. And look at the shiny new ISO-9660 certificate
> we have bought!
>
> Again, as a _hosting_ service, the decisions mentioned above,
> especially with no usable workaround ("Due to security
> considerations, we do offer a different way of doing this.")
> is really strange. VPN can help to a certain degree, but
> crippling the networking between VMs (and of the VMs to
> the outside where the devices are located which needs to
> be communicated with) looks quite contrary to what one would
> assume a hosting company would be doing... but hey, what do
> I know, I'm just a stupid old man... ;-)
>

1. I should mention that firewall/VPN situation we mentioned is what they
are attempting to force us to move towards but currently since we were
customer before the Great Firewall of NewTek Hosting Services (I might as
well name them by name so people know who to avoid for completeness the
full name is "NewTek Hosting Services, a division of NewTek Business
Solutions") we were grandfathered in with our current config.  But we fear
due to political factors (the new head of technical operations not only put
this monstrosity in place but was described -- by our old tech when being
informed that they where no longer authorized to talk to us -- as being "an
asshole") they might "forget" we are grandfathered in.  The new config they
want us to use is even worse in that they will not even allow VPN access
under it.   Since we have medical IoT devices (using a custom
port/protocol) forcing into their "correct (in)security" way of doing
things will not only be a show stopper but life threatening to the patients
of our clients own clients (mostly cardiologists but a few other doctors)
who use the system to do long term cardiac diagnosis for deciding things
like do you need a pacemaker/open heart surgery/etc.

2. There internal/infrastructure, which was decent in it's config using
true server grade OS's [here I admit Linsucks is better than Window$, but
it still much worse for a desktop] just got completely gutted and replaced
(without any customers being told) by a complete monsterity as demostrated
by the following comment when they finally added our reverse DNS (see other
message in thread):

"I have made the necessary adjustments to the rDNS/PTR records on your
domain controller"  (who the f*ck uses Windows to run a hosting service
except for MicroSlut with Azure!... it should be noted that when they set
the VPN it was via our Windows Server not a *nix based/dedicated firewall)
-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org


More information about the freebsd-questions mailing list