Security Basics mailing list archives
Re: Re: Concepts: Security and Obscurity
From: TheGesus <thegesus () gmail com>
Date: Tue, 17 Apr 2007 18:33:07 -0400
Again, last I heard availability had something to do with security. Maybe we can all agree that "port obscurity" is a special case of STO. Somehow, I doubt it. http://en.wikipedia.org/wiki/Credentialism On 4/17/07, Craig Wright <Craig.Wright () bdo com au> wrote:
This is not obscurity for security - rather a use of a different port for a reason other than security. There are differences in this assertion and little to do with security in the reasoning. Craig Craig Wright Manager of Information Systems Direct +61 2 9286 5497 Craig.Wright () bdo com au BDO Kendalls (NSW) Level 19, 2 Market Street Sydney NSW 2000 GPO Box 2551 Sydney NSW 2001 Fax +61 2 9993 9497 www.bdo.com.au Liability limited by a scheme approved under Professional Standards Legislation in respect of matters arising within those States and Territories of Australia where such legislation exists. The information in this email and any attachments is confidential. If you are not the named addressee you must not read, print, copy, distribute, or use in any way this transmission or any information it contains. If you have received this message in error, please notify the sender by return email, destroy all copies and delete it from your system. Any views expressed in this message are those of the individual sender and not necessarily endorsed by BDO Kendalls. You may not rely on this message as advice unless subsequently confirmed by fax or letter signed by a Partner or Director of BDO Kendalls. It is your responsibility to scan this communication and any files attached for computer viruses and other defects. BDO Kendalls does not accept liability for any loss or damage however caused which may result from this communication or any files attached. A full version of the BDO Kendalls disclaimer, and our Privacy statement, can be found on the BDO Kendalls website at http://www.bdo.com.au or by emailing administrator () bdo com au. BDO Kendalls is a national association of separate partnerships and entities. -----Original Message----- From: TheGesus [mailto:thegesus () gmail com] Sent: Wednesday, 18 April 2007 8:08 AM To: Craig Wright Cc: Florian Rommel; levinson_k () securityadmin info; security-basics () securityfocus com Subject: Re: Re: Concepts: Security and Obscurity I'd just like to point out - I'm not really interested in this "prove me wrong" game/troll, per se - that, in the specific case of SSH, port obscurity is sometimes a necessity. The PuTTy SSH client for Windows can be used through a proxy server. But the port has to be authorized for SSL on that (non-SOCKS) proxy. Port 22 is never, ever authorized. You are always guaranteed port 443, but you can't always use it if you already have something listening on 443. In that case, the next most common (obscure) SSL ports are generally available. Oracle, for some obscure reason, likes to use TCP 8000, 8001, 8002, and 8003 for https. These are often "SSL authorized" on proxies. The various offices of the federal government (USA) are also fond of obscure ports for SSL. So I keep a list of obscure SSL ports, because it comes in very handy. I have found the Oracle SSL ports to be the most commonly authorized, so I use TCP 8000. As it turns out, TCP 8000 is not obscure. It is scanned regularly, but never for SSH. It's scanned for the presence of an anonymous proxy. Every single day. But with my crappy company-issued Windows laptop I can always "get in" wherever I am even if I can only "get out" through a proxy. THAT is availability, and last I heard availability had something to do with security. http://en.wikipedia.org/wiki/Credentialism On 4/16/07, Craig Wright <Craig.Wright () bdo com au> wrote: > Hi Florian, > Well I have to state that you are lucky, I still get a subnet at home > that is no longer connected scanned about once a second from new > addresses. Than again, maybe it is me and I attract this ;). The > anecdote you have provided is a start, but it needs to be made > scientifically sound. Also, the results demonstrate a record of the > scans and not the survival. > > There is a little more than the number of scans to be considered. I am > sure that none of us really cares (in more than general interest) how > many scan we receive. What is important is to check the survivability > without all the confounding variables which people keep adding. > > This needs to be done in a manner which is statistically valid, i.e. not > anecdote from either side of the table and it has to be replicable. > > A real world Honeypot experiment would suffice. I have setup Linux and > Windows hosts in the past to check them attractiveness of these, but in > this case it would be to see the general attractiveness of a service and > than how long it took to be compromised. > > So, as an example (one amongst many possibilities) a group of hosts (or > virtual hosts) could be setup and run with SSH on half on the standard > ports and the other half on random ports. Leave these as a Honeypot and > time the survival - i.e. the time to initial compromise. Repeat the test > a number of times till a valid statistical sample is obtained. > > The hosts could be mixed (i.e. Linux, Solaris etc), but they have to be > mirrored in the standard vs. obscured configs (eg 3 Linux SSH, 3 Linux > SSH on TCP 443; Solaris SSH and Solaris SSH on TCP 443) with equal > patching. > > This experiment would remove the confounding variables and provide a > means of actually measuring the level of additional protection as a > factor of time provided through the addition of an "obscurity" factor > and would categorically answer the question - does obscurity provide > additional security. > > The way to test the results would be to take the means of the survival > times from both the standard (SSH on TCP 22) and Obscured hosts (TCP not > equal to 22). The results from the hosts would than have to be modelled > and a simple ANOVA based test of the 2 hypothesis: > Ho: There is no additional security through obscurity > Ha: Obscurity gives some level of additional security > ... Could lead us to the answer. > > In this, if there is enough evidence of a variation in survival times, > then Ha is valid and you can state that there is an improvement in > security from adding a layer of obscurity. If there is not sufficient > evidence, than Ho the Null hypothesis stands and the premise that we > have no gain in security through obscurity stands. > > This is what scientific proof is about. My offer of the donation stands > and I will even help anyone who wishes to do this with time in analysis > and experimental design in an unbiased manner. > > Doing this and writing it up should provide the tester a document that > they could publish, so there is a little more than proving me wrong in > it. > > So again - any takers? Who wishes to attempt to prove me wrong and get > to categorically state that obscurity is a valuable tool in the security > professional's arsenal? Of course that also means you have to have an > open mind and you may be demonstrating that there is no evidenced to > support the claim the obscurity adds anything. > > Regards, > Dr Craig Wright > > > > Craig Wright > Manager of Information Systems > > Direct +61 2 9286 5497 > Craig.Wright () bdo com au > > BDO Kendalls (NSW) > Level 19, 2 Market Street Sydney NSW 2000 > GPO Box 2551 Sydney NSW 2001 > Fax +61 2 9993 9497 > www.bdo.com.au > > Liability limited by a scheme approved under Professional Standards Legislation in respect of matters arising within those States and Territories of Australia where such legislation exists. > > The information in this email and any attachments is confidential. If you are not the named addressee you must not read, print, copy, distribute, or use in any way this transmission or any information it contains. If you have received this message in error, please notify the sender by return email, destroy all copies and delete it from your system. > > Any views expressed in this message are those of the individual sender and not necessarily endorsed by BDO Kendalls. You may not rely on this message as advice unless subsequently confirmed by fax or letter signed by a Partner or Director of BDO Kendalls. It is your responsibility to scan this communication and any files attached for computer viruses and other defects. BDO Kendalls does not accept liability for any loss or damage however caused which may result from this communication or any files attached. A full version of the BDO Kendalls disclaimer, and our Privacy statement, can be found on the BDO Kendalls website at http://www.bdo.com.au or by emailing administrator () bdo com au. > > BDO Kendalls is a national association of separate partnerships and entities. > > -----Original Message----- > > From: Florian Rommel [mailto:frommel () gmail com] > Sent: Monday, 16 April 2007 4:24 PM > To: Craig Wright > Cc: levinson_k () securityadmin info; security-basics () securityfocus com > Subject: Re: Re: Concepts: Security and Obscurity > > Hello to everyone. I actually think this discussion is very fruitful. > It provides a good way of proofing/unproofing the concept. > > I would like to add one thing though. > > Craig, your argument is that you need proof of declined hack attempts. > > I would like to take the simple example of SSH. SSH bruteforcing is > still going through the roof. I have a DSL connection and when my SSH > server was on port 22 I received about 50-100 false logins per day. > Not much you say and I agree but for a home connection it is. However > I then moved ssh to port 443 (SSL) as I am not running a secure > webserver. I need the standard port access to be able to ssh from work > to home and I have had 0 bruteforce attempts per day now. Would that > not qualify as some sort of Security through obscurity? > > //Flosse > http://blog.2blocksaway.com > > PS: I haven't gotten a 443 attempt either though port 80 does get > "accessed" quite a lot. > > > > On 4/15/07, Craig Wright <Craig.Wright () bdo com au> wrote: > > No Karl, you have not provided mathematical proof or something that > serves to prove your point. > > > > I stated survivability - the number of scans by service not the key to > this test. The number of scans and attacks are differnt factors. A scan > is not an attack. Now as you state, proving a negative for all cases is > near impossible, but you have to prove the positive, and this is not > being done. You have not as yet proved proof. > > > > As I have stated, please provide some proof. Demonstrate how obscurity > works. Either provide an experiment or a peer reviewed paper. > Speculation is not proof. You keep stating that there are other cases to > my proofs and I have stated that disproving a negative is often a futile > effort. Please provide real proof and not just state that your views are > proof. > > > > The number of scans example is not a survivability case and is not > proof for your assertion. > > > > Craig > > > > > > > > Craig Wright > > Manager of Information Systems > > > > Direct +61 2 9286 5497 > > Craig.Wright () bdo com au > > > > BDO Kendalls (NSW) > > Level 19, 2 Market Street Sydney NSW 2000 > > GPO Box 2551 Sydney NSW 2001 > > Fax +61 2 9993 9497 > > www.bdo.com.au > > > > Liability limited by a scheme approved under Professional Standards > Legislation in respect of matters arising within those States and > Territories of Australia where such legislation exists. > > > > The information in this email and any attachments is confidential. If > you are not the named addressee you must not read, print, copy, > distribute, or use in any way this transmission or any information it > contains. If you have received this message in error, please notify the > sender by return email, destroy all copies and delete it from your > system. > > > > Any views expressed in this message are those of the individual sender > and not necessarily endorsed by BDO Kendalls. You may not rely on this > message as advice unless subsequently confirmed by fax or letter signed > by a Partner or Director of BDO Kendalls. It is your responsibility to > scan this communication and any files attached for computer viruses and > other defects. BDO Kendalls does not accept liability for any loss or > damage however caused which may result from this communication or any > files attached. A full version of the BDO Kendalls disclaimer, and our > Privacy statement, can be found on the BDO Kendalls website at > http://www.bdo.com.au or by emailing administrator () bdo com au. > > > > BDO Kendalls is a national association of separate partnerships and > entities. > > > > ________________________________ > > > > > > From: listbounce () securityfocus com on behalf of > levinson_k () securityadmin info > > Sent: Sat 14/04/2007 2:53 PM > > To: security-basics () securityfocus com > > Subject: Re: Re: Concepts: Security and Obscurity > > > > > > > > > > > > > In a test that is determined scientifically and without bias, > > > > > the results show that obscurity does not reduce risk and is thus > not a > > > > > benefit. > > > > > > > > I'd love to see such a study. It does not exist. > > > > > > Actually, I believe the honeynet project compiles statistics on how > well > > > obfuscation of ports works, and last I read they have decided it > makes > > > no difference at all. Services running on nonstandard ports are > > > attacked just as much as services on standard ports over time. > > > > It is easy to demonstrate this is false. > > > > http://www.incidents.org/top10.html > > > > The top ports receiving unsolicited scans are all well known, > published server ports: > > TCP 8080 > > TCP 2967 (symantec) > > TCP 445 > > TCP 139 > > TCP 1434 > > TCP 5900 > > > > Put a server on any other port, and your number of attacks is going to > be demonstrably lower than the numbers above. Hence, reduced risk by > obscurity. > > > > Besides, given that so much hacking nowadays is financially motivated > and aims at compromising the most systems starting with low hanging > fruit, I don't see how could anyone could prove that non-standard ports > are attacked just as often as standard ports. > > > > Anyways, obfuscation of ports is just one example of obscurity, and > any study of that countermeasure would not be applicable to all forms of > obscurity. That's why I objected to the absurd claim that it has been > mathematically proven that all forms of obscurity are ineffectual, and > objected to the attempts here to point out some examples of bad > obscurity in order to prove that obscurity is universally bad. > Certainly some forms of obscurity are ineffectual. I only need to point > out one beneficial form of obscurity to invalidate such universal > statements. People talking about math should realize my side is more > likely to be proven true. > > > > There, I gave mathematical data suggesting that obscurity > significantly reduces the number and type of threats it was intended to > reduce. Let's see some statistics proving otherwise. > > > > > > > > > Obscurity does not work. > > > > > > > > It is impossible for you to make that assertion for all > > > environments and situations. > > > > > > Yes it is possible to make that assertion, based on logic and hard > math. > > > Security has nothing at all to do with raw numbers of break in > > > attempts, > > > > Incorrect. Security is based on risk management and (quantitative) > risk assessment, which are mathematical formulas that evaluate the > likelihood of certain risks occurring in a given year, e.g. raw numbers > of break in attempts. Furthermore, risk assessment, while mathematical, > is pretty meaningless unless you apply it to specific situations, > because the value, threats and existing countermeasures of a particular > system are variables that have to be known and inserted into the > mathematical formula. That's why I say you cannot assert that obscurity > is never a (cost) effective measure at reducing risk. > > > > Obscurity absolutely can and often does reduce certain kinds of risks, > such as risk of script kiddies and viruses, frequently at very low cost. > I can't see how anyone can debate that point. Though some here clearly > do not see any value > > > > > > > and everything to do with how resilient a system is to any > > > and all attacks. > > > > That's not how security and countermeasure evaluation, e.g. > quantitative risk assessment, work. Countermeasures are designed to > mitigate JUST SPECIFIC THREATS, not all of them. It is meaningless to > evaluate countermeasures by including threats that they were never > designed to mitigate. Firewalls don't protect against social > engineering, but that doesn't mean you don't need one. > > > > > > > The "obscurity factor" is utterly irrelevant because > > > it has no impact what so ever on actual security. Using offered > > > examples, if your passwords are good ones it makes absolutely no > > > difference how many times an attacker tries to guess them because > they > > > simply can't make enough attempts in any sane time frame to do any > > > damage. Inversely, a single attempt is all it might take to "crack" > a > > > weakly protected system regardless of what port it's made on. So the > > > only security one could possibly gain by limiting the numbers of > > > attempts is of type "false sense". > > > > Not true. It is an obvious truism that most all computers, especially > those on the Internet, are going to be vulnerable to unpatched zero day > vulnerabilities from time to time. Once a vulnerability is exploited by > a network worm or easily downloadable script tool, your likelihood of > being compromised (a key component in quantitative risk assessment) > increases. If you change the port on which your server listens, you > evade those attacks, and your likelihood of being compromised decreases > significantly. > > > > > Please note here that by your purely theoretical definition, the > system is just as secure in both cases, because its configuration and > resistance to attack have not changed at all. And yet, in the real > world, the system has a reduced risk and/or reduced number of compromise > events (which is the key result in quantitative risk assessment formulas > used to judge security). > > > > > > > conclusion that it can't be any other way. Obscurity carries with it > > > precisely as much potential for disaster as it does its ability to > "hide > > > something". That direct relationship exists by the very definition > of > > > obscurity. > > > > Most of the supposed dangers, risks and costs of obscurity are > actually risks of incompetent administration and failures of other > recommended security countermeasures such as the system procedures and > configuration being documented. If your sysadmin assumes a system is in > the default configuration and takes a damaging action based on that > assumption, that's arguably not the fault of obscurity, and that damage > would arguably be just as likely to happen without obscurity, when you > have an incompetent sysadmin plus inadequate documentation. > > > > > > > And before we meander off into an endless debate about "would have" > and > > > "should have", I'll point out that all that is irrelevant. Obscurity > > > adds far more complexity than it affords protection, and no amount > of > > > after the fact tail chasing can change the fact that this is a bad > > > thing at its core. > > > > Another broad, unsupportable generalization. Tell me how something > like changing an FTP banner adds prohibitively costly complexity. > Obscurity includes a lot of different things. > > > > > > > This is the brittleness experts warn you about. It's a real life > issue, > > > not some theoretical mumbo-jumbo. By performing tasks in > "nonstandard" > > > ways you're as likely to confound the good guys as the bad. Not only > > > does obscurity not work, if it has any real effect at all it's > > > more likely to be a negative one than not. :( > > > > Again, quantitative risk assessment comes to the rescue. Risk > assessment is an example of theory that is useful in the real world. > When using risk assessment to evaluate whether or not a countermeasure > is beneficial, you quantify and compare the amount that risks go up and > down. You are not using or demonstrating mathematics when you state > that the increased risk/cost of obscurity's complexity outweighs the > other security risks that obscurity decreases. Are you jumping to > conclusions, or do you have data to show that proves that in most all > environments, systems and obscurity-related countermeasures, > > > > > > > There > > > may be brief respites and fluctuations, but they're invariably > > > discovered and quite often attacked even harder than services on > > > standard ports, for obvious reasons. > > > > I don't see how that's very likely. Putting hundreds of thousands of > servers on the same nonstandard port would not be a good implementation > of obscurity. Attacking a poor implementation of anything is not really > relevant to whether or not a good implementation of it has merit. > > > > Besides, unless you're talking hundreds of thousands of systems using > the same non-standard port, you're still pretty much talking about > determined human attackers. I thought I made it clear that obscurity is > not intended as a countermeasure to determined human attackers, social > engineering, earthquakes, etc. > > > > kind regards, > > Karl Levinson > > http://securityadmin.info > > >
Current thread:
- Re: Concepts: Security and Obscurity, (continued)
- Re: Concepts: Security and Obscurity Michael Rash (Apr 17)
- RE: Concepts: Security and Obscurity Craig Wright (Apr 17)
- Re: Concepts: Security and Obscurity Michael Rash (Apr 17)
- Re: Concepts: Security and Obscurity Michael Rash (Apr 17)
- Re: Re: Concepts: Security and Obscurity levinson_k (Apr 16)
- RE: Re: Concepts: Security and Obscurity Craig Wright (Apr 17)
- RE: Re: Concepts: Security and Obscurity Craig Wright (Apr 17)
- Re: Re: Concepts: Security and Obscurity TheGesus (Apr 17)
- RE: Concepts: Security and Obscurity Craig Wright (Apr 17)
- RE: RE: Re: Concepts: Security and Obscurity Craig Wright (Apr 17)
- RE: Re: Concepts: Security and Obscurity Craig Wright (Apr 17)
- Re: Re: Concepts: Security and Obscurity TheGesus (Apr 17)
- RE: Concepts: Security and Obscurity Craig Wright (Apr 17)
- RE: Re: Concepts: Security and Obscurity Craig Wright (Apr 17)
- Re: Re: Concepts: Security and Obscurity TheGesus (Apr 17)
- Re: Re: Concepts: Security and Obscurity levinson_k (Apr 17)
- RE: RE: Re: Concepts: Security and Obscurity Craig Wright (Apr 17)
- RE: Re: Concepts: Security and Obscurity Nhon Yeung (Apr 17)
- RE: Concepts: Security and Obscurity Craig Wright (Apr 17)
- RE: Re: Concepts: Security and Obscurity Craig Wright (Apr 17)
- RE: Concepts: Security and Obscurity Craig Wright (Apr 17)
- RE: Re: Concepts: Security and Obscurity Craig Wright (Apr 17)