NYT covers China cyberthreat

Tue Feb 26 11:43:09 UTC 2013

On Thu, Feb 21, 2013 at 11:47:44AM -0600, Naslund, Steve wrote:

[a number of very good points ]

Geoblocking, like passive OS fingerprinting (another technique that
reduces attack surface as measured along one axis but can be defeated
by a reasonably clueful attacker), doesn't really solve problems, per se.
If you have a web app that's vulnerable to SQL injection attacks, then
it's still just as hackable -- all the attacker has to do is try from
somewhere else, from something else.

But...

1. It raises the bar.  And it cuts down on the noise, which is one of the
security meta-problems we face: our logs capture so much cruft, so many
instances of attacks and abuse and mistakes and misconfigurations and
malfunctions, that we struggle to understand what they're trying to tell
us.  That problem is so bad that there's an entire subindustry built
around the task of trying to reduce what's in the logs to something
that a human brain can process in finite time.  Mountains of time
and wads of cash have been spent on the thorny problems that arise
when we try to figure out what to pay attention to and what to ignore...
and we still screw it up.  Often.

So even if the *only* effect of doing so is to shrink the size of
the logs: that's a win.  (And used judiciously, it can be a HUGE win,
as in "several orders of magnitude".)  So if your security guy is
as busy as you say...maybe this would be a good idea.

And let me note in passing that by raising the bar, it ensures that
you're faced with a somewhat higher class of attacker.  It's one
thing to be hacked by a competent, diligent adversary who wields
their tools with rapier-like precision; it's another to be owned
by a script kiddie who has no idea what they're doing and doesn't
even read the language your assets are using.  That's just embarassing.

2. Outbound blocks work too, y'know.  Does anybody in your marketing
department need to reach Elbonia?  If not, then why are you allowing
packets from that group's desktops to go there?  Because either
(a) it's someone doing something they shouldn't or (b) it's something doing
something it shouldn't, as in a bot trying to phone home or a data
exfiltration attack or something else unpleasant.  So if there's
no business need for that group to exchange packets with Elbonia
or any of 82 other countries, why *aren't* you blocking that?

3. Yes, this can turn into a moderate-sized matrix of inbound and
outbound rules.  That's why make(1) and similar tools are your friends,
because they'll let you manage this without needing to resort to scotch
by 9:30 AM.  And yes, sometimes things will break (because something's
changed) -- but the brokeness is the best kind of brokeness: obvious,
deterministic, repeatable, fixable.

It's not hard.  But it does require that you actually know what your
own systems are doing and why.

4. "We were hacked from China" is wearing awfully damn thin as the
feeble whining excuse of people who should have bidirectionally firewalled
out China from their corporate infrastructure (note: not necessarily
their public-facing servers) years ago.  And "our data was exfiltrated
to Elbonia" is getting thin as an excuse too: if you do not have an
organizational need to allow outbound network traffic to Elbonia, then
why the hell are you letting so much as a single packet go there?

Like I said: at least make them work for it.  A little.  Instead of
doing profoundly idiotic things like the NYTimes (e.g., "infrastructure
reachable from the planet", "using M$ software", "actually believing that
anti-virus software will work despite a quarter-century of uninterrupted
failure", etc.).  That's not making them work for it: that's inviting
them in, rolling out the red carpet, and handing them celebratory champagne.

---rsk