Update to BCP-38?

Tue Oct 8 18:17:08 UTC 2019

Any additional effort put in by an attacker will increase the chance of an attack being detected before it is successful. COnsider the following two scenerios.

Scenerio 1 is a webserver that makes no effort to obfuscate:

  1.  Attacker does HEAD request on /, which is a legitmate request, and sees the webserver vendor name
  2.  Attacker does a quick search, and finds there is a vulnerabilty in webserver
  3.  Attacker exploits vulnerability

Now, consider scenerio 2, where the server is configured to hide the webserver vendor and has an IDS/IPS system in place

  1.  Attacker does HEAD request on /, which is a legitmate request, but there is no usable information in the respone.
  2.  Attacker does a probe on the webserver to try a number of attacks, which generate a number of 403, 404, 500 etc errors in the webserver logs
  3.  IDS/IPS sees the sudden spike in errors from a single IP address and  blocks the source IP

The act of obfuscation made it possible for the IDS/IPS to detect the probe, preventing the attack. WIll this block every attack? Probably not, but it increases the effectiveness of the security by forcing the attacker to take additional (detectable) actions when trying to break in.

The lock on your front door can be picked by anyone with a $10 lockpick set in under 5 minutes, does that mean you shouldn't bother locking your doors?

Mark
________________________________
From: NANOG <nanog-bounces+mark.collins=mariestopes.org at nanog.org> on behalf of Keith Medcalf <kmedcalf at dessus.com>
Sent: 08 October 2019 18:53
To: nanog at nanog.org <nanog at nanog.org>
Subject: RE: Update to BCP-38?

On Tuesday, 8 October, 2019 11:03, William Herrin <bill at herrin.us> wrote:

>Limiting the server banner so it doesn't tell an adversary the exact OS-
>specific binary you're using has a near-zero cost and forces an adversary
>to expend more effort searching for a vulnerability. It doesn't magically
>protect you from hacking on its own. As you say, your security must not
>be breached just because the adversary figures out what version you're
>running. But viewed as one layer in an overall plan, limiting that
>information enhances your security at negligible cost. That's security
>smart.

I think your analysis is incorrect.

There are two cases which are relevant:
(1) The attack is non-targetted (that is, it is opportunistic)
(2) The attack is targetted at you specifically.

In the former (1) case, it does not matter whether the "banner" identifies the specific OS binary or not as it is irrelevant.  The script either works or it does not.  Even if the "banner" says "Beyond this point there be monsters" will make absolutely not one whit of difference.

In the latter (2) case, it does not matter whether the "banner" identifies the specific OS binary or not as it is irrelevant.  You have been targetted.  All possible exploits will be attempted until success is achieved or the vat of exploits to try runs dry.

So while the cost of doing the thing may be near-zero, it is not zero.  All those near-zero cost things you do that have no actual advantage can add up to quite a huge total and it will be more advantageous to spend that somewhere where it will, in fact, make a difference.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

This Email from Marie Stopes International and any attachments may contain information which is privileged or confidential. It is meant only for the individual(s) or entity named above. If you are not the intended recipient(s) of this Email or any part of it please notify the sender immediately on receipt and delete it from your system. Any opinion or other information in this email or its attachments that does not relate to the business of Marie Stopes International is personal to the sender and is not given or endorsed by Marie Stopes International.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191008/8abc0c23/attachment.html>