Opening SSH port on router - security issue?

[Ogoshi]

I'm thinking of opening up port 22 on my router and forwarding to the pi so I can access it away from home, download stuff etc. so files are ready for when I need them. Just wondering what sort of security issues I would be letting myself in for?
If someone could/did get onto the pi then they could easily bounce of that to the rest of the LAN which is my main concern.

So I guess how safe/secure is it? Any precautions I should take?
Thanks

[RPiDevelopers]

Well expect to receive some Brute Force attacks so I recommend you to use a good password, some software that blocks brute force attacks (failtoban), and lastly I recommend you to use another random port and forward that to the Pi to ensure maximum security.

[Hairlocks]

Even better, you can generate a private public key pair and restirict ssh to not allow passwords. You then need the private key with you to log in.

[Ogoshi]

Thanks for the replies, I'm new to linux (as if you never guessed!) so will research all the points, hopefully I can combine both!

[nicknml]

In addition to the recommendation of using only key-based authentication would be to run it on a a port other than 22.

[obarthelemy]

First, the risk is lowish to start with, because there are very few Linux on ARM computers out there, and many vulernabilites are platform-specific. There are certainly Linux/ARM vulns, but hackers probably aren't bothering to try and exploit those.
This said, I would:
- not use a standard port
- use a key instead of a password
- put ssh on a schedule if you know when you'll want it beforehand
- fake the login message to mislead the snoopers

[Hairlocks]

First, the risk is lowish to start with, because there are very few Linux on ARM computers out there, and many vulernabilites are platform-specific. There are certainly Linux/ARM vulns, but hackers probably aren't bothering to try and exploit those.
This said, I would:
- not use a standard port
- use a key instead of a password
- put ssh on a schedule if you know when you'll want it beforehand
- fake the login message to mislead the snoopers

The risk is actually quite high. Opening ssh with an easy username and password will be compromissed soon enough, just check your log files if you have ssh open to see bots trying to log in. I have been out to fix "slow" linux boxes that have been owned like this.

None of the advice in this thread (that you also repeat/confirm) would do anything to protect against vulernabilites with ssh itself. That requires updating openssh when security update have been made is the most realisitc thing you can do. ( I am assuming reading the source code to spot bugs is above your abiltiy.)

[Hairlocks]

A quick check through the logs of a server at work has over 5000 failed password attempts in 1.5 days (mostly invalid usernames).

[gweijers]

I've been running an SSH server for years. You will see connection attempts. Using a random port number cuts down on those. To be safe make sure to not allow password or 'KeyboardInteractive' authentication, only public key. Also run the package updater once in a while.

I use a pfSense open source firewall as my router, which can log failed connection attempts and I see a regular stream of attempts, lots of them from the PRC, so it's necessary to pay attention. I'm now just allowing connections from the region where I live.

[empire]

I have set up my SSH with brute force protection set to scan for brute forcing every one minute (via cron).

I will be writing a guide on my blog for how to do it today

[Pirx-Danford]

If you have a bit of time to dabble around maybe you want to try out port knocking.

There are several implementations, but I suggest this project as starting point:
http://www.zeroflux.org/projects/knock

[shawnanastasio]

I just came across this thread, and didn't realize that this was much of a security issue. I currently have ssh running on my iMac (password authentication) and it has been running for years. Just today I checked the logs, and I saw a MASSIVE amount of failed login attempts. This is really starting to scare me. I am defiantly changing the port...

[stevepdp]

I've recently been getting into this myself as I took advantage of Linode's free credit offer a week ago and set up an Ubuntu server on it.

Might I advise folks interested in Raspberry Pi security also read over some of Linode's documentation? It's pretty indepth, very easy to follow and the Debian/Ubuntu guides should apply nicely to the Pi too.

This is really starting to scare me. I am defiantly changing the port...

That's a good idea, and it's kept my fail2ban logs down quite a bit since making the change.

[Joe Schmoe]

While it is hard to argue against security (and the obvious extension that if "X amount" of security is good, then "X+1 amount" is better - and this shows, inductively, that you never have enough), I wish to point out that MS (of all people...!) have published a white paper that shows (convincingly in my opinion) that security is a net productivity loss. I.e., that the number of incidents (and the total cost of these incidents) is low enough that it doesn't justify the very real cost in time, complexity, and staff training that security procedures entail.

It (the white paper) is worth Googling for and taking a look at.

[hayesey]

If you are using Debian or Raspbian then simply:

Code: Select all

apt-get install denyhosts

and that'll install a package that will monitor ssh failed login attempts and block the source IP address.

[jojopi]

I think that fail2ban, denyhosts, and numerous other workalikes are ill-conceived and do not increase security. They are easy to write, so everyone writes one and then wallows in a false sense of power.

They do not protect you against password brute-forcing; they only protect you against password brute-forcing by an adversary with limited IP resources (that is, with no botnet). They do not protect you at all against very weak or accidentally leaked passwords. Nor against any weaknesses in your SSH configuration. And they are potentially a denial-of-service vector as well.

They are (belatedly) effective against very ineffective attacks, but just moving SSH to a non-standard port seems to work better still.

I think most people would be better to restrict SSH access to specific netblocks, enforce good passwords, set up keys and disable password authentication, move SSH to another port, implement additional restrictions such as port-knocking or multi-factor authentication if they are really paranoid, (in roughly that order) and only then consider banning weak attackers if they are still present.

[EdwinJ85]

I think that fail2ban, denyhosts, and numerous other workalikes are ill-conceived and do not increase security. They are easy to write, so everyone writes one and then wallows in a false sense of power.

They do not protect you against password brute-forcing; they only protect you against password brute-forcing by an adversary with limited IP resources (that is, with no botnet). They do not protect you at all against very weak or accidentally leaked passwords. Nor against any weaknesses in your SSH configuration. And they are potentially a denial-of-service vector as well.

They are (belatedly) effective against very ineffective attacks, but just moving SSH to a non-standard port seems to work better still.

I think most people would be better to restrict SSH access to specific netblocks, enforce good passwords, set up keys and disable password authentication, move SSH to another port, implement additional restrictions such as port-knocking or multi-factor authentication if they are really paranoid, (in roughly that order) and only then consider banning weak attackers if they are still present.

Is they an easy way to set up key only authentication so that I can still use SFTP and SSH?

Thanks.

[bursar]

It's fairly easy - if I can do it....

I documented the steps I took here: http://mmm-pi.co.uk/?page_id=80

You can ignore the bit at the beginning about configuring QEMU, as that was written whilst I was still emulating a Pi.

[brentaar]

There have been a lot of things said that is advice on this topic, but one thing that is missing is to disallow Root login over SSH.

To do this change one line in the /etc/ssh/sshd_config
from

Code: Select all

PermitRootLogin yes

to

Code: Select all

PermitRootLogin no

Another thing to remember is that this is a home environment, not an enterprise system that needs to be withstand large threats and keep up time to 11 nines. Most of the scanners are just poking around and they usually go for the lowest hanging fruit, so if you can stop them from knocking they'll usually move on. If you are really concerned you'd implement an intrusion detection system.

To recap some some hi-lights

• Use Public Key authentication (I prefer RSA keys with 4096 bits)
  Disable password authentication
  Disable Root login over ssh
  Change your ssh port (I think it doesn't do much, if they are after you then they will scan until the ssh port is found, but it will probably turn away some traffic)
  Have something to block failed attempts (I use sshblacklist, because it is pretty lightweight)
  Restrict the incoming IPs that can login to ssh (only allowing your countries IP blocks would probably be sufficient

*Don't forget residential IPs are subject to change, so having a dynamic DNS service is very handy.

[DesignMongrel]

Another very useful post I see after carelessly exposing my RPi to the world.








That almost didn't come out right lol. Thanks for the useful information guys.