Idea to secure ssh [was: howto block ssh brute-force]
On Monday 13 March 2006 01:24, fgeek wrote:
> > Hello,
> >
> > once in a while (say, every two weeks) I get a brute-force
> > login/password scan attempt in my server (i.e., a single ip tries
> > dictionary account names and passwords at random). SSH access is
> > needed by many users, and (RSA/DSA key)-only access is, at present
> > time, unwanted. So far none such attempt was lucky (to my knowlege),
> > but it always gives me creeps when I see unusually big logwatch
> > reports, and my contacts to sysadmins of originating networks are
> > usually ignored.
> >
> > Any ideas?
> >
> > Maybe there is a way to temporarily block ips upon such attempts (is
> > this a FAQ?), or maybe divert them like what portsentry does for
> > portscans?
>
> I suggest you should use long and 'safe' passwords. It helps you a lot,
> but as many of people have answered about using different port and so on..
> those are good ways too.
I had an idea flash through my head a while back. While this isn't necessarily
the right forum to discuss it, y'all have some sense of security, so I
thought I'd toss it out here.
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 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.
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.
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
integrating sshd with iptables. Perhaps an iptables daemon is required, as
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.
I only use 768- and 1024-bit DSA keys on my systems, but this scheme might
work with password-enabled access as well. As it combines
security-through-encryption, security-through-obscurity and firewalling, it
should result in a system that is fairly secure from unauthorized outside
access.
Whatd'y'all think?
You know, this does sound like an element or two of certain old computer
games, or even fantasy games and books. :) Or perhaps it illustrates the
difference between the CIA and the government black-ops service we don't know
exists.
Neal
Reply to: