RE: Re: Concepts: Security and Obscurity

["Craig Wright" <Craig.Wright () bdo com au>]

Hello Karl,
How is sniffing not relevant? Please supply some evidence to attest for
this assertion.

As for your claim about proof, I am asking for a valid statistically
rigorous test. There are others who have asked off list about methods to
configure experiments, why not you?

As for the scanning and as I have stated, the number of scans does not
relate directly to how secure a system is.

"How?  So you're saying that if I take my one or ten SSH servers on the
Internet and run them on port 42386, an attacker running a Honeypot is
going to discover that and all of a sudden systems across the Internet
are going to be scanned on that port?  Or are the attackers going to
scan all 65,535 ports on my system and keep an enormous database of what
ports are open across the Internet, and then start attacking my system
based on that?  And then furthermore, that my system will then be
scanned and attacked MORE OFTEN than SSH servers running on standard
ports?  Does any of that sound likely to happen?"

Who cares how you think it sounds - what is being asked is proof? Proof
is not common sense, belief or anecdote. "That assertion makes no
sense." Well than it should be easy for you to prove. Go for it.

"So far people have vaguely alluded to studies they think they read,
without posting links."
I think that if you check I have quoted over 30 papers and even added a
few links. How is this none?

"No uncertain terms, except that it's one person's anecdotal evidence
being applied to everyone and every system on the planet.  Am I really
the only person that sees anything wrong with this kind of broad
generalization?"

Agreed - but again, you are calling on your own experience as an example
of proof. Please I have asked for quantifiable proof. I have - in
postings earlier today - set the definitions for risk, hazard and
survivability as related to reliance engineering.

"No, obscuring services by running on non-standard ports is an
acknowledgement that there is always some residual risk that there may
be an unpatched, unmitigated zero day vulnerability on your system at
some point in the future"

Well it should be easy for you to prove. Quantify it. Show us the
evidence to your claims. You can not validly assign another's anecdote
to the trash heap and than rely on your own.

If it was just an argument of philosopical nature, than your retorical
aswaygence may have value, but here I am calling for scientific proof.
Show me the numbers. You are asserting that it adds value - the onus of
proof lies with you to prove the claim - not as you have agreed - that
there is a way to categorically disprove it.

> From your responses it should be a simple task? Go for it.

Have a rerad of the papers by J Voas and K Miller in particular - and
maybe some of B Schneier's books? I have attached several more papers -
how about reading these before stating that they are not relivant?

There are another 10 papers attached, where is your evidence??? I am
waiting.

Regards,
Craig

Nice simple link for scientific method:
http://en.wikipedia.org/wiki/Scientific_method
http://school.discovery.com/sciencefaircentral/scifairstudio/handbook/sc
ientificmethod.html
http://biology.clc.uc.edu/Courses/bio104/sci_meth.htm
http://teacher.pas.rochester.edu/phy_labs/AppendixE/AppendixE.html

More papers etc:
Secrecy, Security, and Obscurity
B Schneier (May 15, 2002)

Security Engineering, A Guide to Building Dependable Distributed Systems
- p310+ by Ross J Anderson

An Approach for Certifying Security in Software Components
Anup K, Ghosh & Gary McGraw

B Schneier "Cryptography, security and the future Communications of the
ACM, January 1997

J Voas and K Miller "Predicting softwares minimum time to hazard and
mean time to hazard for rare input events
 In Proc  of the Int Symp on Software Reliability Eng

J Voas C Michael and K Miller "Condently assessing a zero probability of
software failure High Integrity Systems Journal

Why cryptosystems fail - RJ Anderson

Large scientific databases - R Williams, P Messina, F Gagliardi, J
Darlington, ... - Joint EU-US Workshop, Annapolis, USA, September, 1999

The Hidden Cost of Ubiquity: Globalisation and Terrorism 
B Krug, P Reinmoeller - 2003 - dspace.ubib.eur.nl

PK Algorithms, T Cryptology, C Editors, JE Cordant (emeraldinsight.com)



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: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
On Behalf Of levinson_k () securityadmin info
Sent: Tuesday, 17 April 2007 7:48 AM
To: security-basics () securityfocus com
Subject: Re: Re: Concepts: Security and Obscurity


> > The top ports receiving unsolicited scans are all well known, 
> published server ports:
>
> This entire assertion is a faulty conclusion based on irrelevant data.
> It's obvious that SANS is going to show standard ports being probed
> more often, there's simply more of them to probe. 

You're saying there are more standard TCP/IP ports to probe than
unassigned ports?  How do you figure that?

> This tells us
> absolutely nothing about whether or not any given port is more likely
> to be attacked.

I disagree.  Services running on Internet hosts on non-standard ports
can only be discovered, and attacked, by scanning.  (Or by sniffing a
network connection near a server, but that is a less common occurrence
that is not relevant to this discussion.)

> For SANS data to be relevant to this discussion in any way we would
> have to know the actual numbers of both standard and nonstandard
> services existing on the net and the exact numbers of "scans" directed
> at each. 

We know that info already.  SANS lists all packets dropped by firewalls
they monitor.  You can tell from the port number with a high degree of
accuracy which ones are registered server ports.

> That's the only way we can know the likelihood that a given
> service of either "type" is going to be probed. 

Can we see some of this rigor of proof applied equally at the other
side?  The side that argued that obscurity is never ever beneficial to
anyone ever?  With this burden of proof required, no one would be able
to assert anything about security ever.  Security isn't about absolute
proof, it's about probability and likelihoods, it's about using Occam's
Razor to arrive at the most likely scenario.  Before you buy a firewall,
you wouldn't hire a consultant to do a risk assessment and require them
to prove all of their figures.  Risk assessments are at least partly
based on future predictions, and on this you choose what countermeasures
to implement.

The bottom line is that I don't have to prove anything to anyone.
Everyone chooses their own countermeasures based on their own individual
environment and needs, and people who attempt to dictate absolute musts
to these people with zero knowledge of their environment are on very
shaky ground.

> Simple math... if you have 1000 standard configurations and 10
> nonstandard, a level playing field would be some multiple of that
> ratio... 20 probes of nonstandard and 2000 probes of standard. If the
> nonstandard configuration were probed 21 times, even though it's a
much
> smaller raw number than 2000, it still means the nonstandard
> configuration is more likely to be probed.

This is a wrong conclusion.  You are saying you'd rather have your
server scanned 2000 times than 20 times, and that there's no benefit in
reducing the number of times you're scanned from 2000 to 20.  The
systems listening on nonstandard ports just sidestepped 1,980 scans, and
probably a similar ratio of attackers.

> It's also important to note that the SANS numbers are rendered even
> less relevant in context by virtue of the fact that they're
> compilations of logged incidents, which are naturally skewed in favor
> of listening services. They don't generally reflect an accurate number
> of raw "probes" to begin with.

No, if anything, the reverse is true.  Attacks on open ports on
listening servers are usually allowed in by the firewall without being
dropped, logged and sent to SANS.


> It's a very straightforward process. Dummy services are specifically
> configured to listen on both standard and nonstandard ports, and then
> closely observed. Invariably, nonstandard ports are discovered and
> attacked as aggressively or in some cases more aggressively than the
> same services listening on standard ports.

How?  So you're saying that if I take my one or ten SSH servers on the
Internet and run them on port 42386, an attacker running a honeypot is
going to discover that and all of a sudden systems across the Internet
are going to be scanned on that port?  Or are the attackers going to
scan all 65,535 ports on my system and keep an enormous database of what
ports are open across the Internet, and then start attacking my system
based on that?  And then furthermore, that my system will then be
scanned and attacked MORE OFTEN than SSH servers running on standard
ports?  Does any of that sound likely to happen?


> > 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.  
>
> Please don't delve into the ridiculous to try and make a point.
> Nobody is putting hundreds of thousands of anything anywhere. 

I'm simply pointing out how absurd it is to assume that if I put 1 or 10
SSH servers on the Internet on a nonstandard port, that those servers
will quickly be identified and attacked MORE OFTEN than SSH servers
running on standard ports.  That assertion makes no sense.  If you were
www.whitehouse.gov, it would be discovered and attacked, but that's not
a good case to use if you're going to try to draw conclusions for the
entire world.

> What they
> *are* doing is comparing real world attacks against standard daemons
and
> nonstandard, and coming to the conclusion that there's no actual
> difference by way of a hard comparison of relative numbers of attacks
> launched against actual, listening services (or simulations thereof).
>
> That's not theory, extrapolation, or any conclusion drawn from
> irrelevant numbers. It's plain vanilla reality.

Link please.  Show me.  So far people have vaguely alluded to studies
they think they read, without posting links.

> My own experience supports this. I've been running services and
reading
> logs for over 2 decades now. I've run services on standard ports and
> nonstandard ports, and the only real effect I've ever seen nonstandard
> port configurations produce has been a negative one. 
> This tells me in no uncertain terms that port numbers have nothing at
> all to do with anything.

No uncertain terms, except that it's one person's anecdotal evidence
being applied to everyone and every system on the planet.  Am I really
the only person that sees anything wrong with this kind of broad
generalization?


> That's one of the main
> reasons for running honeypots in the first place... to both quantify
> and qualify attack patterns so you can better understand them and
> devise sane, informed defenses. Obscuring services by running them on
> nonstandard ports is neither. 

No, obscuring services by running on nonstandard ports is an
acknowledgement that there is always some residual risk that there may
be an unpatched, unmitigated zero day vulnerability on your system at
some point in the future, and that most environments are most likely to
be at risk to that vulnerability if they are listening on a standard
port.  It can be a part of defense in depth for some users.


kind regards,
Karl Levinson
http://securityadmin.info