[PLUG] another reason or two why IPv6 rocks

[Tim]

> 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