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

Tim Daneliuk tundra at tundraware.com
Fri Aug 14 18:48:06 UTC 2020

On 8/14/20 12:49 PM, Aryeh Friedman wrote:
> If the controls can be circumvented they are essentially useless and
> shouldn't be in place in the first place.   Besides anyone who knows what
> RDP or SSH is would also know how to circumvent controls designed for
> non-technical people so that makes the blocking of them even more short
> sighted.   This is what I meant by security by obfuscation (i.e. hiding
> obvious truths that everyone with any knowledge knows).

I am not taking a position on whether or not blocking ssh is always good,
bad, or irrelevant.  However, I pretty fundamentally disagree with the
position above as written. It is absolutely possible to dramatically
reduce the technical attack surface by limiting what ports can be accessed on a
given machine.

For example, suppose I have some batch process  that ingests data and
produces some sort of results.  Assume that I only permit the inbound
data and outbound results to be made available over a single mechanism -
let's use an MQ system if you like. No other ports of any kind are open
beyond the TCP/IP interface to the MQ system.

Let's further suppose that access to the MQ system, in- or outbound,
is narrowly limited in time with dynamic firewalling/network rules.
And let's harden this even more by making those inbound- and outbound
payloads encrypted using one-time pad asymmetric keys.

Can that system NEVER be compromised?  Of course it can,  but the
compromise has to happen either at the physical server (or, by proxy,
the hosting entity's console interface... OR it has to happens somewhere
*outside* the server itself.

Think about what an attack on this system would entail:

- Hacking access into the private network where all this runs.

- Figuring out how to compromise access to the MQ system at the moments
  in time it was handling traffic to/from the server AND showing up
  as a legitimate subscriber to those topics.

- Figuring out how to crack into an one-time pad encoded payload -
  something known to be computationally impossible in reasonable time
  for a sufficiently good key - at least until quantum cell phones are available.

Is the risk zero?  No.  And certainly the same set of concerns have to be extended
to the surrounding infrastructure (network, MQ series, key management and distribution
system ...)  But the system as described above, and built with proper rigor and skill,
is really, really, REALLY hard to break into, in large part because the only place
where the plain data lives is in a server that has only very brief connection with
anything and then only over a very narrow mechanism.

My point is that the "principle of least privilege" is very much a proper construct
for designing security hardened systems. So not allowing ssh on a system
with a web server isn't security by obscurity.  It's just limiting the attack
surface ... a very reasonable decision for some applications.

In general, security has to be seen as a risk management activity, not
a technical one.  The amount of security focus on, say, the nuclear launch
codes, had jolly well be exponential greater than protecting the grocery list
on your cell phone.  But *if* you need great protection, reduction of access
is entirely legit.

The truth is that the single greatest weakness in the design above has nothing
to do with the technology at all.  It has to do with the recipient of the
report generated by our mythical server.  If that recipient is a person, the
risk is that they will "leak" the report outside the organization in a stupid
or malevolent manner. THAT is what Data Loss Prevention systems are supposedly
addressing (often poorly in my experience).  Most companies try to materially
reduce this particular threat by turning off USB access on laptops, eliminating
any form of remote access outside their own networks, dividing their networks into
separate, hardened subnets, doing deep scans and audits on email traffic, and so
forth.  And yet, even when done with almost infinite money and endless security
paranoia, this remains one of the most intractable problems in information
security. Two words: Edward Snowden

Tim Daneliuk     tundra at tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

More information about the freebsd-questions mailing list