Re: Idea to secure ssh [was: howto block ssh brute-force]
On Monday 13 March 2006 20:07, Michael Stone wrote:
> On Mon, Mar 13, 2006 at 03:03:24PM -0500, Neal Murphy wrote:
> >The idea is to present information to the server that only the server can
> >decrypt, and that, in theory, only the authorized user could have
> > generated.
>
> Much like an authentication system. What's the point of all this over
> just authenticating via ssh? Sounds like a ridiculously complicated and
> error-prone method to reduce log entries. And realistically you'd want
> to log attempts to brute force this mechanism, right?
The point is to obscure the ssh server from everyone, including those who are
authorized to access it remotely. The point is to reduce brute-forace attacks
to the point of nearly total ineffectiveness. The point is to require a small
amount of pre-authentication before the server acknowledges the client's
attempt to connect. And because UDP packets are allowed, the server can log
brute-force attempts and firewall off attackers long before they have a
chance of hitting the right combination that lets them in.
Consider someone like Helen Keller. You could shout at her, sign at her,
sempahore her forever and she would never acknowledge you. Only by touching
her would you get her attention. Yet if she didn't recognize the touch, she
still needn't acknowledge you.
When you visit someone's home, do you knock on random parts of the house? I'm
betting you typically knock on the door or ring the doorbell, because those
are the obvious civilized ways of gaining access to the home. Similarly with
current ssh servers, the obvious place to knock is its door: the well-known
port 22; it's also the obvious place to find a lock to pick. Even changing
the port to something else isn't that good, because a port scan will
eventually find the port, just as walking around an ordinary house will make
the location of its door obvious.
> >Yes, allowing UDP packets in is, in a sense, an open port, but it's a
> > one-way port. UDP packets have a fixed maximum size and the information
> > carried in the packet is trivial in nature; UDP packets are generally
> > benign. It's a given that anyone who knows the server's public key can
> > generate an encrypted packet, but only an authorized user can correctly
> > generate the encrypted parts inside the encrypted packet.
>
> No, anyone can generate encrypted parts. IMHO, there's not much chance
> that the decryption routines in your magic udp parser are going to be
> less vulnerable than those in openssh itself. Having "two layers of
> Having "two layers of encryption" in this context is fairly pointless.
> Why not use three layers, or four? What analysis demonstrates a
> demonstrable return for that second layer, weighed against the cost of
> this kooky mechanism? If you really need multiple encryption layers, do
> it right and use an existing standard like ipsec rather than inventing a
> convoluted "secret method".
Are you saying that anyone can generate a data packet that will correctly
decode with *my* public key? That anyone can generate a data packet that can
be decoded with a server's private key using something other than the
server's public key? I was under the impression that the probability of
anyone being able to create either half of a key-pair that will work with an
existing other-half was pert near zero. If ssh's key-pair encryption scheme
is that weak, ssh needs to be retired.
Based on the strength of ssh's key-pair scheme, I concluded that the data
encrypted with the user's private key is reasonable assurance that the data
came from the the true source, not a forger. The reason for encrypting the
whole packet with the server's public key is to prevent eavesdropping, benign
or malicious. Thus the dual encryption is not pointless.
The point of this pre-authentication is to allow the server to decide whether
or not to talk to the client before any packets are sent to the client.
Remember, connecting to an ssh server involves setting up a TCP connection,
which involves bidirectional packet transmission before any ssh protocol data
are transferred. UDP eliminates that initial bidirectional transmission.
Integrating the firewall into the process almost completely prevents unwanted
ssh traffic.
N
Reply to: