Update to BCP-38?

Tue Oct 8 20:15:15 UTC 2019

You would still be better served by forgetting about hiding the
webserver vendor name and using that money to buy an IDS/IPS that works
properly by detecting the actual exploit attempt rather than looking for
"a spike of errors in the log" in order to block the originating
address, especially since a "spike of errors in the log" can have quite
a few causes other than exploit attempts -- in fact such a "spike in
errors" is more likely to occur for reasons other than attempts to find
a vulnerability.  Furthermore, it is quite possible for the first
exploit attempt to be successful despite having hidden the banner, in
which case the entire thing was merely nothing more than security
theatre.  This is especially true when you consider "many" systems using
this method of protection and millions of attempted exploits per second.

Furthermore, why on earth would an opportunistic attacker use two
requests when one would suffice?  There is nothing to be gained by
probing only to discover "Oh, I am getting all wet cuz this is a juicy
target" when one would merely send the exploit and see what happens --
it either works or it does not -- and probing first adds no value -- in
just makes each attempt expend more resources.  In the time you have
probed a server and gotten a response, you could have simply sent the
exploit to a dozen servers.  So clearly probing for a "good target" is
just a waste of time.

This is why most dirty e-mail spammers just "blast" out their spam
without waiting for the appropriate responses from the SMTP server, and
why having the SMTP server insist on strict RFC compliance (and test
that the connected MTA is RFC compliant) works so well at getting rid of
95% of spam.

So given a choice between:
(1) Spending money hiding the headers and using software to reconfigure
the firewall based on errors in the log; or,
(2) Spending money on an IDS/IPS that can detect and drop an exploit
dynamically

you are probably better served by (2) than by (1).  The software that
monitors the log is most useful to send a notification that there is an
excessive error rate (since that is what it is detecting).

Of the millions of ransomware attacks per second, the 617 victims so far
this year probably relied on method (1) and in hindsight wished they had
been a little smarter and used method (2) instead.

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

>-----Original Message-----
>From: Mark Collins <mark.collins at mariestopes.org>
>Sent: Tuesday, 8 October, 2019 12:17
>To: Keith Medcalf <kmedcalf at dessus.com>; nanog at nanog.org
>Subject: Re: Update to BCP-38?
>
>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.