ssh dictionary attacks - Security

This is a discussion on ssh dictionary attacks - Security ; "john yeo" wrote in message 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 29 of 29

Thread: ssh dictionary attacks

  1. Re: ssh dictionary attacks


    "john yeo" wrote in message
    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.


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



  2. Re: ssh dictionary attacks

    >>>>> "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


  3. Re: ssh dictionary attacks


    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


  4. Re: ssh dictionary attacks

    "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.

  5. Re: ssh dictionary attacks

    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.

  6. Re: ssh dictionary attacks

    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

  7. Re: ssh dictionary attacks

    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.

  8. Re: ssh dictionary attacks

    (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.

  9. Re: ssh dictionary attacks

    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

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2