-----Original Message----- From: Mark Collins <mark.collins@mariestopes.org> Sent: Tuesday, 8 October, 2019 12:17 To: Keith Medcalf <kmedcalf@dessus.com>; nanog@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@nanog.org> on behalf of Keith Medcalf <kmedcalf@dessus.com> Sent: 08 October 2019 18:53 To: nanog@nanog.org <nanog@nanog.org> Subject: RE: Update to BCP-38?
On Tuesday, 8 October, 2019 11:03, William Herrin <bill@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
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. 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.