nanog mailing list archives
RE: Update to BCP-38?
From: "Keith Medcalf" <kmedcalf () dessus com>
Date: Tue, 08 Oct 2019 14:15:15 -0600
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 () 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 anadversaryto expend more effort searching for a vulnerability. It doesn'tmagicallyprotect 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.
Current thread:
- RE: Update to BCP-38?, (continued)
- RE: Update to BCP-38? Keith Medcalf (Oct 04)
- Re: Update to BCP-38? Mike Meredith via NANOG (Oct 08)
- Re: Update to BCP-38? Rich Kulawiec (Oct 08)
- RE: Update to BCP-38? Mark Collins (Oct 08)
- RE: Update to BCP-38? Keith Medcalf (Oct 08)
- Re: Update to BCP-38? Mike Meredith via NANOG (Oct 09)
- Re: Update to BCP-38? William Herrin (Oct 08)
- RE: Update to BCP-38? Keith Medcalf (Oct 08)
- Re: Update to BCP-38? Valdis Klētnieks (Oct 08)
- Re: Update to BCP-38? Mark Collins (Oct 10)
- RE: Update to BCP-38? Keith Medcalf (Oct 08)
- Re: Update to BCP-38? Rich Kulawiec (Oct 09)
- Re: Update to BCP-38? Fred Baker (Oct 03)
- Re: Update to BCP-38? Stephen Satchell (Oct 03)
- Re: Update to BCP-38? Fred Baker (Oct 03)