Re: Re: Re: Re: Re: Concepts: Security and Obscurity

[lordl3ane () gmail com]

Karl,

I’ve just stated that Oranges are Orange and Apples are not Oranges; and I believe you’ve just gone off and started 
talking about how we shouldn’t grow wheat because it’s not an effective fuel for space travel.

If that was confusing, well that’s kind of how I take your statements below.  Forgive me if I’ve misread or 
misinterpreted anything.

> > > Obscurity is just that, obscure. It?s ?hiding? rather than actually
> > > proactively keeping people out... just makes it 
> > > slightly harder. The attackers must try a few doors before they 
> > > find the one with the network gear, or call the company and say 
> > > there?s something wrong with the website ? can they talk with the 
> > > webmaster to let them know,
> >
> > One might as well throw away your antivirus and firewalls, because those won't block social >>engineering either.

I don’t understand the relevance of your statement.  Obscurity doesn’t actively BLOCK anything.  Firewalls don’t stop 
people from overpaying for automobiles or investing in ponzi schemes.  Firewalls DO filter traffic for valid 
external/internal pairing and provide a logging point for invalid attempts or intrusions over valid traffic.

> > > When we define things this way, then we can clearly see why 
> > > ?obscurity? doesn?t add much benefit against targeted attacks.
> >
> > Obscurity isn't intended to block targeted attacks, just as firewalls aren't intended to block >>social engineering. 
> > The people here who require countermeasures to be 100% effective >>against everything will quickly end up with no 
> > countermeasures at all. But at least they >>won't have, horror of horrors, a false sense of security!

Although I was making a point through examples, I can see where I may have lead you astray.  Through the examples I was 
comparing why the conversation was misinterpreting firewalls, port knocking daemons and other types of active 
*protective* controls as obscurity controls.  Obscurity statistically reduces the number of initial unstructured 
attacks, but will eventually be overcome by them as well.  Obscurity is not protective or detective, it’s deceptive.  
And as a deceptive control, its effectiveness is immeasurable accurately against your adversaries unless you go over 
and ask all of them “Were you fooled by me changing my port information?”

A public-facing door (outside a firewall) without a lock, even if unmarked, will eventually have a 12 year old skater 
smoking pot in it (please accept this as an analogy and not go into some statistical evaluation of how many 12 year 
olds smoke pot and ride skateboards in your particular country/state/whatever).  This happens only because someone 
tried to access your system.  The same applies to valuables in a car.  Your door being closed obscures the valuables 
inside, but if it’s unlocked, there’s nothing stopping some random person from tugging at the handle.

Your car in a lot with tons of other cars is obscurity – nothing preventing someone from either targeting (structured 
threat) or randomly selecting (unstructured threat) your vehicle.  The lock is the firewall.  The alarm is the IDS.  
And the security guard is the monitoring system.  Without having worked in physical security or law enforcement, or 
doing a basic study; you may miss how many times people simply walk down a street or through a parking lot, tugging on 
every handle along the way until they find one that’s open.

What I’m trying to show you here, is that obscurity is done to make the implementer “feel good”.  It does not actually 
prevent attacks, just statistically reduces the volume-over-time factor.  I guess you can take the fact that the 
statistical reduction is “attacks prevented” but, realistically they’re just “avoided”; meaning that there’s nothing 
that actually STOPPED the attack from occurring successfully at some time in the future.

> > Obscurity does help you against targeted attacks, in that targeted attacks that hit your >>SSH server listening on a 
> > nonstandard port will tend to stand out, because your logs will >>have less noise in them.

Karl, I completely agree with this last statement, as is stands alone.  If you’ve spent some initial investment in 
creating automatic configuration scripts, sending out browser bookmarks, deliver pre-configured systems, or send out 
configuration guides for services; then the investment-over-time may be minimal.  The detection process is definitely 
assisted in implementing obscurity programs because the attack volume-over-time is statistically reduced at the 
intrusion sensors.  However, if your monitoring system is configured properly and your handlers are properly trained in 
attack profiles and methodologies then the addition of obscurity shouldn’t add much benefit.  In effect, your 
investment-to-return ratio should be even or negative.  Functional structured attacks will probably not be that 
distinguishable from normal traffic even with obscurity in place, because the attacker has probably done enough 
research to mimic valid access.

To assume that an attacker on the outside does not know what port you run your services on is bad.  The ability to scan 
a firewall through a router to determine what ports are in use has transgressed from skilled network attack gurus 
manually banging away at the synchronization IDs on the inside interface to automated tools; although generally only 
for sale on invitation-only blackhat underground networks.

Eric B.