Re: Idea to secure ssh [was: howto block ssh brute-force]
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.
> - 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.
> - the client would wait a short period of time (perhaps a second), then try
> to access the normal TCP sshd port. Perhaps it can try three times in 10
> seconds before giving up.
> - as an added measure, if the daemon notices a brute-force attack in
> progress, it can request iptables to drop the attacker's UDP packets
> on the floor, too.
>
> The main advantage to this is that anyone trying to improperly access the
> system via SSH would never know if the system is actually running an SSH
> daemon - its port is firewalled off, and the daemon's only response to the
> UDP packet is either to let the client host in through the firewall, or not
> let the client in.
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.
> My idea is akin to a monastery that has no visible way in or out. If someone
> wants in, he has to know where to knock, using the Super Secret Squirrel
> coded knock. Then he has to wait a bit before he tries to pass his
> credentials and hand through the wall. If he still passes muster (ID is OK
> and his fingerprints match), he is then allowed to pass through the wall. If
> he doesn't know the coded knock to begin with, he'll pass right by the
> monastery, never seeing it.
If that's all you want, port-knocking is a simpler, easier
solution.
> 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...
> integrating sshd with iptables. Perhaps an iptables daemon is required, as
this makes it non-portable to other OS.
> 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?
-dsr-
Reply to: