

Three locks for your SSH door - rlm
http://www.ibm.com/developerworks/aix/library/au-sshlocks/index.html

======
rlpb
There is a trade-off here. Weigh up the risks as you think is best and act
accordingly, but try not to let the coolness/hacker factor of the solution
affect your security decisions!

On one hand, it is clearly going to be harder for a random zombie machine to
find your ssh on a non-standard port that requires knocking and a particular
less usual username.

On the other hand, you're breaking from your distribution's standard
installation. You increase the risk of breaking on a future upgrade. You could
lock yourself out, perhaps, and there's a cost associated with this. In the
worst case a distribution upgrade will fix a security hole and you'll be left
with it (say for example because you modded the config file, dpkg queried it,
you rushed through the prompts and it got left alone).

I accept my scenario is unlikely, but it is also unlikely that someone will
crack your up-to-date machine using distribution standard ssh, a secure root
password and public keys for day-to-day access.

It is far more likely that someone will access your secure machine from an
insecure place with a keylogger running and get cracked that way.

~~~
dododo
1\. modifying the default configuration is fine: you do this for your web
server (right?) so why not sshd? in fact, sshd is simpler to configure and i
cannot think of one backward incompatibility in many years. disable what you
don't need, this includes bits of sshd. what's the point of a configuration
file if you can't change it?

2\. your point about "using distribution standard ssh, a secure root password
and public keys" is a little moot in light of the debian ssh keygen bug? in
this case you would have been better off with building ssh yourself (and
keeping it up to date).

3\. in any case, you are at most risk from your users. if they are
compromised, you are also (public key or not).

~~~
lmz
Wasn't the Debian bug in OpenSSL? Building OpenSSH yourself would not do you
any good there if you linked to the distribution's OpenSSL.

------
Dobbs
Wouldn't it be much easier to just restrict access to keyfiles and block
anyone who fails more than 3 attempts?

Not sure why but the idea of port knocking always seems over complex for
little benefit.

~~~
_delirium
Yeah, at least as far as my logs go, just disabling password login seems to
cover a superset of the attacks that changing ports would cover, so I don't
see much reason to avoid the default port. Every automated attack I've found
in my logs is: 1) on the default port; and 2) a password attempt. It seems the
recommendation here is to change #1, but to me just changing #2 is easier, and
has some other benefits as well. The main place I could see an argument for #1
is if you run a large multiuser server, where it's quite possibly easier to
explain to your users how to use a nonstandard ssh port, versus trying to
explain to them how to use ssh keys.

~~~
sprout
Hostgator's nonstandard port for hosting is my biggest complaint about their
service, especially because I cannot set up key-based authentication, and I
have to ad -e 'ssh -p 2222' to my rsync statements.

But if I'm being honest, back when I signed up with them keypairs would have
been a little more difficult than working out that option for rsync.

------
js2
Step 1) Setup OpenVPN. Step 2) Block ssh access using iptables or equivalent
from all but the VPN connections and one or two trusted IPs (the latter just
in case you need to do OpenVPN maintenance). Back in the day, you would have
had a separate network for administration. Simulate that with OpenVPN.

~~~
ant5
It's depressing that your post hasn't received more attention. Your control
systems should be on a private control network, not exposed to the wide
internet.

OpenVPN is capable of providing a much, much smaller attack surface than
OpenSSH (see <http://news.ycombinator.com/item?id=1665773>), and can be run
entirely chroot'd and setuid such that even if an attacker does compromise
OpenVPN, they can not necessarily gain further access.

There seems to be a prevailing lack of understanding that bad passwords are
not the only concern when using SSH. The daemon itself may be vulnerable to
exploit (and in the past, it has been).

------
danielrm26
For anyone who doubts the merits of obscurity for security:

<http://danielmiessler.com/study/security_and_obscurity/>

Hint: Why do we camouflage tanks?

~~~
amalcon
I don't think anyone argues that obscurity is worthless. The argument is more
that when it fails, it fails unpredictably and completely, so it's not
something to be relied on. In a situation where you need every advantage you
can get, go ahead and hide whatever will help.

If you're just opening up SSH on your personal computer, you don't need every
advantage you can get. Just make sure that your authentication is strong, and
you'll be fine.

~~~
danielrm26
You're missing the fact that when you remove the camo paint off of a tank you
haven't made the armor any weaker, just as putting SSH on a different port
doesn't mean you remove authentication.

~~~
thaumaturgy
And you're missing the fact that ssh is not a tank.

We could continue raping that metaphor, or we could just discuss whether or
not putting ssh on a different port actually accomplishes anything useful.

For example: it's generally a pretty safe assumption that most remote servers
have ssh running on them somewhere. If you are running scripts to find
vulnerable or misconfigured ssh hosts, then it makes sense to scan the
standard port and try stupid logins. In that case, if the sysadmin moves ssh
to a different port, then they "protect" themselves from the various scripts
out there, but then again simply having reasonable password policy
accomplishes the same thing and without the hassle of having to locate ssh on
a different port.

On the other hand, if you're a dedicated attacker and you want to compromise a
particular system, then moving ssh to another port does squat; nmap will find
it easily enough. Port knocking and/or denyhosts and/or iptables or pf will
stop that easily enough, but then again, a dedicated attacker probably won't
try ssh first anyway, since that's hard. Attacking something else like your
web app or any of your other services, would make a lot more sense.

So, either way, running ssh on a different port is completely superfluous.
While you haven't "made the armor any weaker", you also haven't made it any
stronger. At all.

Because ssh is not a tank.

------
swombat
1 and 2 seem to me to be par for the course when setting up a server that you
want to be secure... Only allow logins with keys, choose a high port that's
not usually scanned, and only allow specific users to log in (law of least
privileges).

Is 3 really that necessary? Are there often cases where an up-to-date ssh
daemon gets cracked even though it is on a high port and allowing only public
key logins of specified users with a small number of retries?

~~~
woodall
_Brute force_

Do not under estimate the zerg. Although ssh servers on different ports are
"harder" to find, they are still not invisible. Try changing your banner,
using 'port knocking', TCIP fingerprint spoofing, and other obfuscation
techniques. Nothing is 100%, but you can still have really secure boxes.
Proper admins are your best line of defense.

~~~
bostonvaulter2
Wouldn't something like fail2ban be enough?

~~~
jsz0
It helps but you can't always assume unwanted logins are going to be brute
force attacks. My biggest source of paranoia is a stolen/lost laptop with a
saved SSH password/key. I prefer ACLs to port knocking. Depending how
important a machine is there's no good reason to allow the entire Internet in.
If it means someone has to drive to the office or do some SSH hoping that's a
small price to pay.

------
astrodust
I'm not familiar with the bleeding-edge practices for securing a server, I
just use techniques like the ones in the article, but shouldn't there be a
more RFC-friendly approach to locking down a server?

For instance, instead of this irregular "knock" routine, which is a fuss to
implement, why can't there be a standard protocol for requesting firewall
access? There's a standard for punching holes in local firewalls to open
external ports, so why can't the same thing be applied in reverse to remote
hosts?

With a proper access control mechanism, ssh-key driven, LDAP-backed or
otherwise, it should be possible to send a packet to the remote firewall with
enough information to verify identity and open the port as required. That
would prevent scan attacks from working because none of the probes would be
properly signed and the host port would appear closed.

------
some1else
I made a clitd script I back when I had a box set up at highschool. If anyone
tried to connect to standard tcp services that I decided were not supported
(time/port 7 and such), I would add their subnet to hosts deny for a day. It
was pretty useful for fending off attacks that pre-empted with a port scan.

------
sbierwagen
Point and laugh: I just locked myself out of a production machine (a very,
very minor production machine that serves almost no traffic) by changing the
sshd port number without first poking a hole in the firewall.

Now I get to drive out to the datacenter. Whoops.

------
patrickgzill
LoginGraceTime can be greatly decreased to 5 seconds in most cases. I
recommend this unless you are connecting over extremely slow links.

------
revoltingx
I'd like to remind people too to use DenyHosts:
<http://denyhosts.sourceforge.net/>

It's awesome, gets rid of a bunch of brute forcing ips that you see in your
secure.log.

~~~
larrywright
Using a non-standard port for ssh eliminates the need for this altogether.
This is almost a no-brainer, and it's the first thing I do when standing up a
server.

~~~
ant5
_Using a non-standard port for ssh eliminates the need for this altogether.
This is almost a no-brainer, and it's the first thing I do when standing up a
server._

No, it doesn't. Running a port scan and finding your "hidden" SSH port takes
very little time.

Placing your SSH port behind a hosts.allow restriction ensures that you've
reduced your attack surface to only the hosts (or networks) you've permitted.

Better still, set up OpenVPN, use its HMAC[1] support to stop unknown users
early, and don't expose any other daemons to the internet.

[1] [http://openvpn.net/index.php/open-
source/documentation/manua...](http://openvpn.net/index.php/open-
source/documentation/manuals/69-openvpn-21.html) (See --tls-auth file option).

To quote:

The rationale for this feature is as follows. TLS requires a multi-packet
exchange before it is able to authenticate a peer. During this time before
authentication, OpenVPN is allocating resources (memory and CPU) to this
potential peer. The potential peer is also exposing many parts of OpenVPN and
the OpenSSL library to the packets it is sending. Most successful network
attacks today seek to either exploit bugs in programs (such as buffer overflow
attacks) or force a program to consume so many resources that it becomes
unusable. Of course the first line of defense is always to produce clean,
well-audited code. OpenVPN has been written with buffer overflow attack
prevention as a top priority. But as history has shown, many of the most
widely used network applications have, from time to time, fallen to buffer
overflow attacks.

So as a second line of defense, OpenVPN offers this special layer of
authentication on top of the TLS control channel so that every packet on the
control channel is authenticated by an HMAC signature and a unique ID for
replay protection. This signature will also help protect against DoS (Denial
of Service) attacks. An important rule of thumb in reducing vulnerability to
DoS attacks is to minimize the amount of resources a potential, but as yet
unauthenticated, client is able to consume.

\--tls-auth does this by signing every TLS control channel packet with an HMAC
signature, including packets which are sent before the TLS level has had a
chance to authenticate the peer. The result is that packets without the
correct signature can be dropped immediately upon reception, before they have
a chance to consume additional system resources such as by initiating a TLS
handshake.

~~~
larrywright
I don't find using hosts.allow terribly useful as the people that tend to want
to ssh into servers that I control are often mobile, with IP addresses that
change regularly.

The point I'm making, though, is that every instance of someone running a
dictionary attack against one of my servers was a script kiddie running a tool
against a range of IP addresses. Changing the port ssh runs on to something
high eliminates this entirely.

~~~
ant5
_The point I'm making, though, is that every instance of someone running a
dictionary attack against one of my servers was a script kiddie running a tool
against a range of IP addresses. Changing the port ssh runs on to something
high eliminates this entirely._

Those are the attacks you see. The script kiddie with a 0-day would be much
less obvious.

There are straight-forward ways to architect your infrastructure such that you
solve the dictionary attack problem AND the 0-day problem, none of which
require the hand-waving security (and user annoyance) of moving SSH to a non-
standard port.

The security provided by a non-standard port is laughable -- it's like putting
a child-proof lock on your front door.

If you're worried about dictionary attacks, turn off password authentication.
If you're worried about 0-day vulnerabilities in SSH, leverage defense-in-
depth (require well-secured VPN connectivity before allowing SSH access). If
you're worried about user's machines being compromised and their keys stolen,
leverage two-factor auth.

------
gregcmartin
Security by obscurity, thumbs down.

nmap -sV -p1-65000 ip

~~~
gregcmartin
Ok, maybe not so flippant comment this time...

I thumbs downed the article because as a security professional we try to
stress the importance of actual security rather than obscuring the problem for
_long term_ success.

Take port knocking for example, interesting idea but what a pain in the ass...
just disable root and set a strong password.

Changing the port from 22 will prevent all of the automated botnet driven SSH
brute force attacks, which do little more than messy up your log directories.

Best thing you can do is use SSH brute force blocking script which reports
attackers back to a webapp which the security community can use to track
infected hosts. example:
<http://danger.rulez.sk/projects/bruteforceblocker/blist.php>

Fail2ban is a nice one too as it supports many services including http-auth.

~~~
peterwwillis
this is how matasano got owned. an easily guessable account got broken into
and root priv escalation was used. if they were using port knocking an
attacker would have had to be in the middle, which is possible but adds an
extra 'auth' layer so increases overall intrusion hardness.

also, everyone keeps talking up these scripts to stop brute forcing... two
iptables rules will do this for you.

------
todd3834
Conclusion You've seen three ways of hardening SSH access to your machine:
modification of sshd configuration parameters, selecting which users can log
in by means of PAM, and use of port-knocking sequences to hide the existence
of SSH access. Although I mentioned that there is no way to secure fully any
machine, adding these three layers will make your server more than just a
little safer.

