>>>>> "NKG" == Nico Kadel-Garcia writes:

NKG> "john yeo" wrote in message
NKG> news:yprFg.13283$fV1.4838@fe1.news.blueyonder.co.u k...
>> Nico Kadel-Garcia wrote:
>>> Ertugrul Soeylemez wrote:
>>>> john yeo (06-08-15 17:14:21):
>>>>
>>>>> enforce key+password logins
>>>> Using public key authentication is fully appropriate, if your key
>>>> itself is protected by a passphrase. In some environments it
>>>> would even be harmful to use password authentication, too,
>>>> because someone may somehow intercept your login password, and
>>>> thus be able to log in locally (i.e. not via SSH).
>>> Note that this is *impossible* to enforce, unless you can scan
>>> the user's home machines and anywhere they can log into for keys
>>> without passphrases. It's a long-term vulnerability of SSH.
>>>
>>>
>> its should be possible to generate the keypair with a suitable
>> passphrase and set up the ssh dir so that the user cant change his
>> key, or add any passphrase-less keys. then provide the user with
>> the private key and passphrase.

NKG> The user can then remove the passphrase from the key at
NKG> whim. Unless you can search their computers for un-passphraed
NKG> keys, you can't enforce this.

Not only that, but it's a very bad idea for the sysadmin to know
everyone's passphrase, and to not let people choose or change their own.

--
Richard Silverman
res@qoxp.net

Ertugrul Soeylemez wrote:
> "René Berber" (06-08-15 15:07:56):
>
> > > This is something that comes up once in a while... I've been subject
> > > to them as well.
> > >
> > > I've come across a couple of projects that build a 'tarpit' for
> > > attackers - the first one is for SMTP and the second one is more
> > > generic.
> > >
> > > I've often wondered if one couldn't use this to at least slow down a
> > > dictionary attack on ssh. It wouldn't do much good for a
> > > distributed attack, but it might for an attack comming from a few
> > > hosts.
> > >
> > > Any thoughts? Comments? This is sort of a curiosity quesiton for
> > > me; I don't know enough to really make a solid judgement if this
> > > would be useful.
> >
> > Why just slow them if you can stop them?
>
> Easy. Slowing them down saves bandwidth for the whole internet. As
> long as the scanner 'hangs' on scanning your box, it won't issue too
> much traffic. If you banned them, then they would just go further and
> scan the next box. There are in fact scanners, which could
> simultaneously scan multiple boxes, but that is rather rare. Even then,
> if _many_ people helped slowing them down, then a lot of useless traffic
> would be saved.
>
>
> Regards,
> E.S.

Until the blackhat integrates the polling with simple flatfile database
to distribute the attack on a per password basis. 20 lines of Perl
would probably be adequate.

Ultimately the solution is for an agency to provide the tarpit as a
proxy. Once the connection is determined to be offensive, the socket
should be forwarded to a server run by the police with an out-of-band
session to provide the true source address and related statistics. One
honeypot, many parallel data flows pointing back at the origin.

Billions are lost every year because of this kind of crap, and after a
decade of Public Internet, the investigative capacity of domestic
police has not evolved past inspecting its own colon. Any jackass can
write this kind of code. It is not significantly more complex than say:
Napster.

The people whose job it is to do it, don't understand the stakes or the
job, and the little light that has shown on them has been capitalized
into moral crusades. The people who do know, won't waste their time
because they would rather be productive than persue employment in
computerized colonoscopy. Snake oil peddlers dominate the marketspace
as a result. Same B.S. different day.

-Failure to understand strategy permits the perversion of the concept
of security.
-You are most likely to be exploited by those you hire to exploit
others.

-Matt

"shrike@cyberspace.org" (06-08-19 19:55:23):

> > > Why just slow them if you can stop them?
> >
> > Easy. Slowing them down saves bandwidth for the whole internet. As
> > long as the scanner 'hangs' on scanning your box, it won't issue too
> > much traffic. If you banned them, then they would just go further
> > and scan the next box. There are in fact scanners, which could
> > simultaneously scan multiple boxes, but that is rather rare. Even
> > then, if _many_ people helped slowing them down, then a lot of
> > useless traffic would be saved.
>
> Until the blackhat integrates the polling with simple flatfile
> database to distribute the attack on a per password basis. 20 lines of
> Perl would probably be adequate.
>
> Ultimately the solution is for an agency to provide the tarpit as a
> proxy. Once the connection is determined to be offensive, the socket
> should be forwarded to a server run by the police with an out-of-band
> session to provide the true source address and related statistics. One
> honeypot, many parallel data flows pointing back at the origin.

That's not a solution, because many, if not most of these attacks come
from innocent people, who don't even know about it. I'd rather call
these SSH _worms_, because they spread like them.


Regards,
E.S.

Ertugrul Soeylemez wrote:

> "shrike@cyberspace.org" (06-08-19 19:55:23):
>
>> > > Why just slow them if you can stop them?
>> >
>> > Easy. Slowing them down saves bandwidth for the whole internet. As
>> > long as the scanner 'hangs' on scanning your box, it won't issue too
>> > much traffic. If you banned them, then they would just go further
>> > and scan the next box. There are in fact scanners, which could
>> > simultaneously scan multiple boxes, but that is rather rare. Even
>> > then, if _many_ people helped slowing them down, then a lot of
>> > useless traffic would be saved.
>>
>> Until the blackhat integrates the polling with simple flatfile database
>> to distribute the attack on a per password basis. 20 lines of Perl
>> would probably be adequate.
>>
>> Ultimately the solution is for an agency to provide the tarpit as a
>> proxy. Once the connection is determined to be offensive, the socket
>> should be forwarded to a server run by the police with an out-of-band
>> session to provide the true source address and related statistics. One
>> honeypot, many parallel data flows pointing back at the origin.
>
> That's not a solution, because many, if not most of these attacks come
> from innocent people, who don't even know about it. I'd rather call these
> SSH _worms_, because they spread like them.

A _child_ is "innocent" and not (mostly, in civilized societies)
responsible even if s/he signs an otherwise valid contract. Many children
of well heeled parents have their own computers and internet connections.
If a phishing site were being hosted on that "innocent"'s computer, is the
financial damage to the victims any less real? (No.) Is there any less
reason to shut down that phishing site, just because it is running on a
computer in a child's bedroom, playroom or den? (No.)

An ISP will often or usually not disconnect a customer even when they
acknowledge the customer's system(s) are compromised, because then the ISP
loses the customer and its revenue base. Clearly, there needs to be new,
different or augmented motivation (and mechanisms) to enforce prompt
disconnection / remediation of maliciously compromised, networked
computers. The current pure "free market" capitalist model is not
effective in controlling these security issues.

The fact that the operator of a system is "innocent" by reason of being a
child, of being childlike, of being clueless or simply careless or
irresponsible does not remove the need for remediation or disconnection of
that system. Whether it is an SSH attack, a phishing site, malicious IRC
server for a botnet, and regardless what one chooses to call the type of
attack in nomenclature, the desired essential response to detection needs
to be immediate termination of the malicious activity.

There are probably several ways I could have seen to take legitimate
security issue with what was written above. But, to claim that a proposed
solution is invalid because the "attacks come from innocent people" is a
"red herring". The issue should not be cast in the light of how good or
bad the owners or operators of the equipment are, but rather what they do.
If what they do (or don't do) is a threat to others, they need to be
stopped. The more promptly and quickly they are stopped, the better.

One big giant step further, - a very, very hypothetical picture:

Suppose that in some time, - long long ago and in a universe far far away ...

(are you still with me on this ?) ...

On a day called September 11, 2001, ...

In a place called United States of America, ...

Nineteen "innocent" children, abused children, mentally incompetent
children, legally "innocent" children - managed to fly aircraft into
buildings and caused billions of dollars of financial damage, fortunately
without the loss of a single human life other than their own 19 "innocent"
lives. The people of the United States of America will be paying for that
financial damage for generations.

And here's the question:

If we had detected that attack beforehand and were able to prevent it,
should we have elected to _not_ prevent it because the people involved
were "innocent" ? I think not.

responder wrote:

> But, to claim that a proposed
> solution is invalid because the "attacks come from innocent people" is a
> "red herring".

http://en.wikipedia.org/wiki/Red_herring

responder (06-09-02 03:38:25):

> >> Ultimately the solution is for an agency to provide the tarpit as a
> >> proxy. Once the connection is determined to be offensive, the
> >> socket should be forwarded to a server run by the police with an
> >> out-of-band session to provide the true source address and related
> >> statistics. One honeypot, many parallel data flows pointing back at
> >> the origin.
> >
> > That's not a solution, because many, if not most of these attacks
> > come from innocent people, who don't even know about it. I'd rather
> > call these SSH _worms_, because they spread like them.
>
> A _child_ is "innocent" and not (mostly, in civilized societies)
> responsible even if s/he signs an otherwise valid contract. Many
> children of well heeled parents have their own computers and internet
> connections. If a phishing site were being hosted on that
> "innocent"'s computer, is the financial damage to the victims any less
> real? (No.) Is there any less reason to shut down that phishing
> site, just because it is running on a computer in a child's bedroom,
> playroom or den? (No.)
>
> [...]

Calm down, my friend. IMO the suggestion above is not a solution,
because it would be heuristic and _may_ prevent legitimate traffic from
passing through. Also it's a bit of security through obscurity, because
the actual problem (careless admins and software bugs) will not be
solved.

In the non-deterministic real life, defenses are the best bet in some
cases (such as in your example with 09/11), but in the deterministic
e-world problems shouldn't be hidden, but rather solved.

The other problem with the suggestion is: Firstly, the real bad guys
wouldn't be found that way, and the police had too much work filtering
out those "innocent" bad admins (i.e. PEBKAC users, who need the
computer for their work or other things, and wouldn't care much about
computing security). And there are probably hundrets of thousands of
them.

Secondly, it would have an immense impact on privacy, as the police
would have to be able to associate IP addresses with persons in this
case. "So don't send such packets out", might be your argument. But
depending on the filters at that "agency", this may be easy to enforce.

I wouldn't want any agency to intercept all my traffic, anyway. Neither
automatically, nor manually.


Regards,
E.S.

(The suggestion under discussion came from "shrike@cyberspace.org"
)

Ertugrul Soeylemez wrote:

[...]

> but in the deterministic
> e-world problems shouldn't be hidden, but rather solved.

What problems clearly did you think I wanted to be hidden, or did I not
understand your intent, please ?

> The other problem with the suggestion is: Firstly, the real bad guys
> wouldn't be found that way, and the police had too much work filtering
> out those "innocent" bad admins (i.e. PEBKAC users, who need the
> computer for their work or other things, and wouldn't care much about
> computing security). And there are probably hundrets of thousands of
> them.

But this is exactly the point: The '"innocent" bad admins' are a threat
to others if running compromised systems. "Innocence" or carelessness or
cluelessness is not a justification for running compromised, networked
systems, and should not be a guarantee of any percieved "right" to
continue doing so. The criterion is that if a connected system is
compromised it should be disconnected.

responder wrote:
>
> But this is exactly the point: The '"innocent" bad admins' are a threat
> to others if running compromised systems. "Innocence" or carelessness or
> cluelessness is not a justification for running compromised, networked
> systems, and should not be a guarantee of any percieved "right" to
> continue doing so. The criterion is that if a connected system is
> compromised it should be disconnected.
Disconnect them, help the get their systems and their understanding up
to snuff and then let them reconnect after proving that the problem no
longer exists.

We make people get drivers licenses because of the dangers involved both
physical and financial. Why don't we make computer users get a license
to show they have at least a little knowledge and understanding. Without
some training people can do an great deal of financial damage to others.

I have clients that ask me to buy and install anti virus software on
their computers. I do that for a price. After I leave the client turns
the anti virus software off because of some perceived inconvenience. And
then when things go bump in the night they call be again and say "what
happened I bought the anti virus software you told me to?"

People like that are either just too stupid to be allowed to own a
computer or they just don't care.

--
----------------
Barton L. Phillips
Applied Technology Resources, Inc.
Tel: (818)652-9850
Web: http://www.applitec.com