RE: Re: Concepts: Security and Obscurity

Yes _ I have read this before.

I would use the quote from this paper:
"See, so long as you understand that the server location and port number
can't serve as a method of authentication, you haven't harmed your
security in the slightest." Jay Beale

In the case of SPA and portknocking, the obscurity is used as a form of
authentication and thus not what is being defined by the author (see
quote above).

In the chase of changing the ports for an SSH service this mirrors
Beale's assertion that "Obscurity Potentially Slows Down the Attacker".
The key here is that it is a potential control. I do see this as a valid
research topic and proposal, but nothing has followed up in regards to
this. It is just a hypothesis at present and an untested one. And as
regards to any untested hypothesis, without proof it should not be
believed. This is why the US FDA takes years to test drugs, why
engineering claims have to be tested etc.

An obscure system works on the idea that people do not know how it
functions. This is not the same as a password or secrecy as has been
suggested. I can know the process used by a host that accepts passwords
and this process can be published without my guessing the password. In
fact the protocols for Kerberous, NTLM etc are all published and I can
read them as often as I like.

In port forwarding, if I publish the process, the control is broken -
thus the control is reliant on obscuricy and not secrecy.

This is the difference of obscurity and secrecy.

To take another quote from the same paper:
"Now, remember, don't get too cocky. He can still find our server. It
might not even take tons of extra effort, if he guesses well. We might
still not observe him, if we have no procedures or technology set up to
do the observing!"

My argument lies with the value of what is supposedly gained. There is a
cost in configuring the service and updating clients. To be effective
the level of gain needs to exceed the cost.

At no point have I seen any valid attempt to quantify the supposed
gains. If the supposed gains are not measurable they are not real. There
may be a probabilistic error level and confidence range, but it needs to
be quantifiable.

Voas et al - http://csrc.nist.gov/nissc/1998/proceedings/paperA4.pdf in
"An Approach for Certifying Security in Software Components" have an
approach which would provide a assertion capability to allow the
assertion that obscurity adds value. In particular it could be used to
assess SPA and Portknocking.

To take a quote from B Schiener in this paper:
"Billions of dollars are spent on computer security, and most of it is
wasted on insecure products. After all, weak security looks the same on
the shelf as strong cryptography. Two e-mail encryption products may
have almost the same user interface, yet one is secure while the other
permits eavesdropping. A comparison chart may suggest that two programs
have similar features, although one has gaping security holes that the
other doesn't. An experienced cryptographer can tell the dierence. So
can a thief."

And from the Authors:
"Electronic commerce components may all appear to be equally secure on
the surface. Only objective assessment can ascertain the true story. The
role of the certication process will be to objectively evaluate the
security of software components."

Regards,
Craig



Craig Wright
Manager of Information Systems

Direct +61 2 9286 5497
Craig.Wright@xxxxxxxxxx

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

BDO Kendalls is a national association of separate partnerships and entities.

-----Original Message-----

From: Nhon Yeung [mailto:Nhon.Yeung@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, 18 April 2007 11:15 AM
To: Craig Wright; TheGesus
Cc: Florian Rommel; levinson_k@xxxxxxxxxxxxxxxxxx;
security-basics@xxxxxxxxxxxxxxxxx
Subject: RE: Re: Concepts: Security and Obscurity

<http://www.bastille-linux.org/jay/obscurity-revisited.html>
Jay Beale's take on obscurity.
I do believe that obscurity does have a role in security, as it can be
used as a deterrent much like a hiding your cash in dirty underwear. Any
thief would steal you hard earned if you leave it on your table, but it
takes a determined one to go through your dirty laundry.


-----Original Message-----
From: listbounce@xxxxxxxxxxxxxxxxx
[mailto:listbounce@xxxxxxxxxxxxxxxxx]On Behalf Of Craig Wright
Sent: Wednesday, 18 April 2007 8:39 AM
To: TheGesus
Cc: Florian Rommel; levinson_k@xxxxxxxxxxxxxxxxxx;
security-basics@xxxxxxxxxxxxxxxxx
Subject: RE: Re: Concepts: Security and Obscurity


This is not availablility - rather a configuration decision. After
configuring the service on the changed port, this now has little to do
with availability.

Craig



Craig Wright
Manager of Information Systems

Direct +61 2 9286 5497
Craig.Wright@xxxxxxxxxx

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

BDO Kendalls is a national association of separate partnerships and
entities.

-----Original Message-----

From: TheGesus [mailto:thegesus@xxxxxxxxx]
Sent: Wednesday, 18 April 2007 8:33 AM
To: Craig Wright
Cc: Florian Rommel; levinson_k@xxxxxxxxxxxxxxxxxx;
security-basics@xxxxxxxxxxxxxxxxx
Subject: Re: Re: Concepts: Security and Obscurity

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

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

BDO Kendalls is a national association of separate partnerships and
entities.

-----Original Message-----

From: TheGesus [mailto:thegesus@xxxxxxxxx]
Sent: Wednesday, 18 April 2007 8:08 AM
To: Craig Wright
Cc: Florian Rommel; levinson_k@xxxxxxxxxxxxxxxxxx;
security-basics@xxxxxxxxxxxxxxxxx
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@xxxxxxxxxx> 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@xxxxxxxxxx

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

BDO Kendalls is a national association of separate partnerships and
entities.

-----Original Message-----

From: Florian Rommel [mailto:frommel@xxxxxxxxx]
Sent: Monday, 16 April 2007 4:24 PM
To: Craig Wright
Cc: levinson_k@xxxxxxxxxxxxxxxxxx; security-basics@xxxxxxxxxxxxxxxxx
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@xxxxxxxxxx> 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@xxxxxxxxxx

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

BDO Kendalls is a national association of separate partnerships
and
entities.

________________________________


From: listbounce@xxxxxxxxxxxxxxxxx on behalf of
levinson_k@xxxxxxxxxxxxxxxxxx
Sent: Sat 14/04/2007 2:53 PM
To: security-basics@xxxxxxxxxxxxxxxxx
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




Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Crane Group

Loading