> And neither should be used. Instead, harden your sshd. Simple. > Effective. Having said that, I don't run sshd on port 22, and have not > seen *any* scanner hit my sshd in months, even though I was getting > routine (daily or hourly) attacks on 22. > > In other words, you don't need port knocking. Just be slighly uncommon, > and you're good to go.
I don't really want to reincarnate this thread, but I think we're talking at two completely different levels. What I mean is that I'm trying to discuss the theory of what you *could* do with a very large address space, while many of you want to discuss the concrete problem of protecting SSH. That's just one example of an application of one example protocol. You are right in that changing your default port typically accomplishes the goal of stopping most ankle-biters from guessing your SSH passwords. But really, you're far better off just requiring your users to use SSH key pairs and disable password auth. Or you'd be better off requiring them to use OTP. Unfortunately, all of these, including port knocking, require clients to do something different than what they are used to. They either require them to set up ssh keys (very good idea, but most people don't grok public key), use a different port, or have a list of passwords in their pocket. Port knocking requires some kind of special client. While the proposal I have made doesn't require any of this, (it simply requires knowing an obscure domain name) I'm not necessarily trying to focus on SSH alone here. There are many situations where you simply don't have the resources to properly harden a semi-vulnerable service (IPSEC, PPTP, etc), but that service doesn't necessarily need a whole extra layer of real authentication. You're merely trying to cut down on resource utilization or reduce the noise in your firewall logs. And then taking another step back, there are other fun things you can do with the huge address space. Embed part of the hash for your public key in the last bits of the IPv6 address to help clients automatically look up your IPSEC/other key. (Something like this is used in some proposed protocols that I'm not intimately familiar with.) tim _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
