[Gllug] compromised?

[James de Lurker]

Tethys wrote:

> James de Lurker writes:
>>Oh - and make the software LIE or be unspecific about what version it
>>is ( a simple telnet connection to port 22 and a couple of CRs will
>>persuade a target system to yield too much information than can be
>>good for it ).


> Don't kid yourself. 

Rarely do. I had specific objectives in mind when using this as one of a
number of tactics in a custom Linux distribution, several years ago.


>.........................How many times does the "security through obscurity
> doesn't work" mantra have to be repeated?

Probably as many times as necessary to achieve a totally trance like state.
That can be helpful in solving (some) problems, too. <*grin*>


> .........................................Any halfway decent cracking script
> will try to negotiate an SSH handshake to test what's on the end of an open
> port, rather than just trusting what's reported in the banner. If it finds
> an ssh daemon it's likely to try known exploits anyway, in case you're
> lying about the version of sshd.

The point is, it will be obliged to try inappropriate attacks even it the
script is written with the contingency of defeating deception (unlikely).
That increases by a big factor the window of opportunity for an IDS,
or the application itself, to take appropriate action to curb the assault,
of alert a human defender. It's just raising the bar.

The objectives are fairly simple, and merit this tactic in most cost / 
benefit considerations of having patchfiles against security application 
sources to make port and challenge/response or operating dialogues differ
from the norm. If you build from source routinely, that is.

Look at the recent vulnerability in SSL as a good example of why you don't
want to be in the position of having the application provide known 
plaintext for attackers to exploit.

I put it to the community here that the vast majority of kiddie scripted
attacks are single purpose, or procedural steps that will fail with a
minimum measure of port shifting and dialogue obfuscation. At a minimum
their failure will demand a human in the loop, or more likely move along
to easier targets, elsewhere, of which there are plenty.

The goal is to increase the cost of an attacker and defeat or delay fast
automated approaches. Not lock 'em out entirely.

Increasing complexity using "security through obscurity" is a term that
is drawn from a cryptanalysis security context, where obscurity has an
entirely different, and disproportionate effect on risk of compromise.

In a network security context, it is used only to delay the inevitable.
There is no need to insist upon NP or even P increase in difficulty to
prevent reverse engineering of the concept/algorithm.

HTH

-- 

   -- James

 From and Reply To are INVALID.

All public postings use munged headers[1]- To contact me off list:
   1) Remove "M U N G I E j u m p" ONLY: leave that "nospam" in there!
   2) change "hotmail" 2 "myrealbox" after the @




-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug