4 ms·

This argument seems disingenuous. It's no great insight that port knocking reduces unauthorized login attempts. What's disputed is whether it's better to have a

This argument seems disingenuous. It's no great insight that port knocking reduces unauthorized login attempts. What's disputed is whether it's better to have a system that's rarely challenged vs. a system that's regularly challenged and still holds. The argument against is that adding layers of bad security makes it easier for problems in the "real" security to go undetected or ignored since the obscurity layer works too well.

dogma1138 10y ago
I agree people confuse obscurity with "operational security". Reducing your footprint, and keeping information disclosure to a minimum isn't obscurity. On the more specific examples while port knocking is an acceptable security mechanism (so is geoblocking, and even whitelisting specific IP's only) it's again not obscurity, putting connections on random ports is and it can also be a very bad practice because obscurity often works both ways. In a large organization even one with great documentation and knowledge management things will fall between the cracks, if we take their example to the then while the attacker might be slightly less likely to identify a non standard SSH port (because for some reason they assume that port scanning is expensive) it can also mean that your own security teams and tools can miss them just as easily. When heartbleed came out for example people run it on the common SSL ports internally, pretty much all of it was patched rather quickly but from time to time you still find an instance of it and usually it's because some developer somewhere decided port 23216 is a good port for SSL. The attackers are considerably more likely to perform allot of information gathering on their target, more so than internal teams, internal security tools often limit their tests to standard and specified ports because when the security team has a 4 hour window each month to turn their vuln scan a full TCP port scan is probably out of the question on a network with few 1000's of IP's and larger. By adding unnecessary obscurity to your system you are effectively only increasing the likelihood of you missing something while the attacker is just as likely to find it as anything else.

dogma1138 10y ago

I agree people confuse obscurity with "operational security". Reducing your footprint, and keeping information disclosure to a minimum isn't obscurity. On the more specific examples while port knocking is an acceptable security mechanism (so is geoblocking, and even whitelisting specific IP's only) it's again not obscurity, putting connections on random ports is and it can also be a very bad practice because obscurity often works both ways. In a large organization even one with great documentation and knowledge management things will fall between the cracks, if we take their example to the then while the attacker might be slightly less likely to identify a non standard SSH port (because for some reason they assume that port scanning is expensive) it can also mean that your own security teams and tools can miss them just as easily. When heartbleed came out for example people run it on the common SSL ports internally, pretty much all of it was patched rather quickly but from time to time you still find an instance of it and usually it's because some developer somewhere decided port 23216 is a good port for SSL. The attackers are considerably more likely to perform allot of information gathering on their target, more so than internal teams, internal security tools often limit their tests to standard and specified ports because when the security team has a 4 hour window each month to turn their vuln scan a full TCP port scan is probably out of the question on a network with few 1000's of IP's and larger. By adding unnecessary obscurity to your system you are effectively only increasing the likelihood of you missing something while the attacker is just as likely to find it as anything else.