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- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
