On Monday 13 March 2006 09:38, [EMAIL PROTECTED] wrote:
> On Mon, Mar 13, 2006 at 03:19:30AM -0500, Neal Murphy wrote:
> > It seems kind-of counterproductive to set up SSH for secure access, then
> > advertise to the universe that it's there. Thus my idea:
> >
> > Consider:
> > - sshd listens on a pre-shared UDP port for 'a knock on the door',
> > specifically a client requesting access.
> > - using the server's pre-shared public key, the client has encrypted a
> > packet that contains the user id in plaintext and the user's hostname
> > encrypted with the user's private key.
> If you don't put in a timestamp and require the server to reject
> packets with badly out-of-sync timestamps, you are vulnerable to
> a replay attack here. And leaving the user id in plaintext means
> that a packet sniffer can gather valid hostnames, so now any
> machine can construct a valid packet.
I was afraid my description would be less than clear. The timestamp is a good
point, but you missed the double encryption. Perhaps this will be clearer:
- the client builds a packet that contains the user id in plaintext, and
the hostname, IP address and a timestamp encrypted with the user's private
key.
- the client then encrypts the packet with the server's public key and
sends it to the server's UDP port.
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.
When the server receives the UDP packet, it decrypts it using its private key,
and then decrypts the hostname, IP address and timestamp using the user's
public key. Only if the user has allowed the hostname, the IP address
specified matches the address on the received packet, and the timestamp is
current, will the server then let the user in. And at this point, the user
still has to go through the normal SSH connection and authentication process.
> > - if the server can decrypt the packet, decrypt the hostname and match
> > the userid to the hostname, it would then request that iptables allow
> > that client host to access the normal SSH TCP port.
> A basic question of security: if everyone did it, would we be
> more or less secure?
>
> In this case, if everyone used this scheme, we wouldn't be any
> more or less secure.
We would be more secure, because the server will only listen to clients until
and unless they authenticate themselves. The server can selectively stop
listening to bothersome forgers. Hostname/IP addr spoofing won't work unless
the forger has obtained the correct matching username and private key. If you
aren't authorized to access a system, you'll never know if the system allows
remote access, because the server will never speak to you.
> > My idea is akin to a monastery that has no visible way in or out. If
> If that's all you want, port-knocking is a simpler, easier
> solution.
If all I wanted was security-through-obscurity, I wouldn't have bothered
communicating my thoughts. However, as I said, I want to integrate
security-through-obscurity, security-through-encryption,
security-through-authentication and security-through-firewalling.
Port-knocking (as defined in wikipedia) doesn't necessarily have
authentication built in. As a tangible example, I can observe someone using a
secret knock, then duplicate that knock. I may not get in on the first try,
but the knock causes the guard to open the little viewport to see who's
there. My scheme requires a degree of authentication before the viewport is
opened.
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.
> > Does this scenario make any sense at all? It is a minimal amount of extra
> > processing, yet would tighten security dramatically. But it would require
> I'm sorry, it doesn't tighten security specifically, and...
It does, but you missed the two layers of encryption.
> > integrating sshd with iptables. Perhaps an iptables daemon is required,
> > as
> this makes it non-portable to other OS.
Quite true. But I'd've thought that, when security is a concern, the rule
would be security first, portability second. Other OSen that don't have
firewalls just can't be secured as well as OSen with firewalls, can they?
> > I'd also like to have sendmail be able to tell iptables to lock known
> > spammers out of the system completely: no access whatever; even better
> > would be to have a multicast feed from trusted RBL maintainers to keep
> > known spammers locked out to begin with.
> It's probably better to have a standard method for applications
> to request additions to a blacklist. Why don't you work on that?
Thanks, but I already have four jobs that keep me too busy as it is.
N
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
