Re: Re: Concepts: Security and Obscurity

[TheGesus <thegesus () gmail com>]

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
> > >
> >