[sf-lug] SecurityEdge - DNS, "security" and double-edged swords, etc.

[Michael Paoli]

Well, putting some 'o this (back) on SF-LUG list because ... why not?!  :-)

> > SecurityEdge doesn't make me feel secure, but it does make me edgy.

Well, I'm guestimating it may have even been well (as in benevolently,
but not necessarily of quality) intended, and "just" quite poorly
implemented/executed.  Although it's rife with abuse potential (alas,
that often applies to some/many "security" products).
So, DNS, want to, e.g. offer customers some protection there, by
filtering "bad" (by whomever/whatever defines or categorizes those)
domains?  And yes, there certainly do exist and have existed malicious
domains, and that will likely always be the case.  But there are
many issues even with that alone, e.g. who decides/controls what goes
into any given category, who gets to select what categories are
"blocked" or otherwise intentionally altered (e.g. to "safe" or warning
about the risk/issue/danger/category), etc.  And at least some traces
of this are even, yes, government controlled ... but in a rather
different manner.  E.g. trademark law and domain dispute procedures and
such.  But that actually goes to getting the actual DNS data altered,
not mucking about an altering it between DNS server(s) and clients ...
though that's not even universally the case - I'm sure at least some
governments take to their own mucking about with network traffic, e.g.
firewalls, probably some mucking about with DNS, etc. - particularly
when they don't have the power/influence to change what's on the actual
DNS servers, and/or other content otherwise generally made available on
The Internet.  E.g. many states/governments may want to filter or block
or the like, based on different criteria ... and not uncommonly by
criteria that much/most of the rest of the world doesn't care (or care
so much) about.  But, back to SecurityEdge and DNS "security" by
blocking/altering DNS for "bad" domains and the like.  That also brings
up issues like, behind such, how does one even check or troubleshoot
actual Internet DNS data?  Yeah, that majorly gets in the way - at best.

And, of course, even if well intended, some flawed implementations also
cause great additional problem.  E.g. compelled caching.  Yeah, now one
can't get the actual Internet data.  Not uncommon for, e.g. corporate
environments ... but that's more reasonable - they get to decide what
they do/don't want there and how they want to operate.  Quite different
situation when it's between customer and ISP ... and ISP isn't even
giving the customer a choice ... or certainly not reasonably notifying
or informing the customer.  Likewise stuff that outright breaks DNS,
likewise, quite problematic.

And of course potential conflict-of-interest at best, if not nefarious
use at worst ... oh, now we're forcing all your DNS data where we can
look at it, collect it, sell it ... sell it with detailed customer data
... maybe all the way down to Ethernet Mac address to highly accurately
target individual consumers - perhaps along with digital profiles of
each Mac address's usage, to highly correlate to individual consumers.
What could possibly go wrong?  Yeah, ... a whole lot.

And, a lot of "security" items have such double-edged swords ... at
best.

E.g., for "security", at corporate level, for (most) all user computers,
implement a forced Man in the Middle (MITM) HTTPS proxy.
The advantages/security?  Oooh, if that HTTPS has some
dangerous/malicious content in it (malware, known bad/illegal content,
etc.) can intercede in those communications and block that or otherwise
render it harmless.  What could possibly go wrong?  All those systems
trusting that MITM - it has access to the clear text of everything going
through it - could risk data of, e.g. not only corporation, but all
kinds of other data going through such.  Just think what a gold mine if
an undetected intrusion happens on such a device.  So, remind me again
how much more secure that makes everything?

Examples abound, but, e.g. an ssh proxy system, "for security" (a
particular product jumps to mind, but regardless).  Have that product
manage all the ssh passwords, all the ssh private keys.  So, it can
manage/track/control that access, monitor it, log it, filter it, etc.
Can even automagically do thinks like key/password rotation, etc.  And
what could possibly go wrong?  It's also the keys to the kingdom server.
That gets compromised and ... it has basically free rein at
root/superuser/Administrator (yeah, likewise for Microsoft) level to
most or all key assets in the organization.  One ring ^Wserver to rule
the all!  All your eggs in or guarded by one basket?  Better be a damn
good basket.

E.g. Oh, TCP and security.  Many devices have (had) not so great initial
sequence number generation.  That's security risk (mostly a solved one
these days - used to be much more common).  Oooh, I know, we'll "fix"
that on our firewall devices.  We'll recognize that, and do a truly
secure initial sequence number generation, and we'll use that, rather
than that provided by device initiating that - so we'll substitute that
in the communication, and map 'em all back and forth ... and all is fine
and dandy and presumably more secure and all that.  Until ... firewall
is rebooted, state lost ... oops, that connection cannot functionally
continue.  But wait, you also get ... communication is going great,
with that (purported) added security ... and ... both sides using
sliding window acknowledgement.  Oops, a packet gets lost or mangled,
so sliding window acknowledgement kicks into action.  Uhm, ... but that
firewall ... it's got older firmware.  It doesn't know diddly about
sliding window acknowledgement.  So that connection is now doomed to
failure ... client and server will try for a while, but the sequence
numbers used in the sliding window acknowledgement - between client and
server they're not at all as expected, because the firewall had been
fixing all that up on the TCP packets ... but being clueless about
sliding window acknowledgement, that data within doesn't have the
corresponding substitution, so now every time sliding window
acknowledgement kicks into action, the connection fails ... every
bloody time.  So now you've got an intermittent but ugly fairly frequent
problem.  "Oops".  All because some firewall device thought it knew
better than actually following RFCs, and thought it could go 'n do its
own thing ... and ... yeah, it blew it, because it's not that smart,
and can't keep up with the RFCs ... and wasn't really even following
them to begin with.

Likewise, again, firewall.  SMTP.  Oooh, let's closely monitor and
control that.  Muck with the traffic between, dumb down the protocol,
force it to not be encrypted, so we can do stuff like look for bad
content.  Well, bloody hell.  Now you've introduced multiple problems.
Most notably, what was point-to-point - and often (at least
effectively) end-to-end encrypted across The Internet, etc. - of that
mail traffic - now you're making it go across in bloody clear text.
Gee, thanks.  Or maybe you "only" did that on the corporate network(s)
or whatever ... that's still much more risk there than when it was all
encrypted before, because client and server were perfectly cool with
that and (opportunistically) doing good strong encryption on all that -
but now you just went and blew that open by forcing it in the clear.
Additionally, many things will use or even depend upon the additional
functionality of more modern [E]SMTP capabilities.  Dumb that stuff
down between and you'll often majorly break stuff.  E.g. I've seen
stuff between client and server total break because some firewall was
doing things like that "in the interest of security".

Yeah many many times, even well intended, often poorly implemented
"security" breaks things or may not even make them more secure ...
sometimes even less secure.  Many, at best, are double-eged swords,
with important tradeoffs to be very carefully considered.  And
many that are even "the best", will still have at least some limited
downsides to them - if even slight.