tpyo kingg
Posts: 616
Joined: Mon Apr 09, 2018 5:26 pm
Location: N. Finland

Re: Raspberry Pi Security

Mon Sep 02, 2019 7:08 am

jcyr wrote:
Mon Sep 02, 2019 3:38 am
Any Pi on public Internet will probably have ssh enabled for remote access. In that case the 1st thing to do is disable password based login. This and lots of good tips here https://securitytrails.com/blog/mitigat ... -practices
Yes, disabling password-based authentication is the first thing to do and probably the most effective.

As to the link above, points 4 (no root login), 6 (keys with strong passphrases), and 10 (SSHGuard, Fail2ban, or DenyHosts) are quite helpful. Points 1, 2, and to a certain extent also 3 are not up to date:

1. Putting SSH on a non-standard port is a bad idea in general, or an ineffective one at best. It will do a little to quiet the logs but otherwise running SSH on weird ports won't actually hide you from any one.

2. OpenSSH stopped supporting TCPd aka TCPwrappers a long time ago. TCPwrapper support was removed in OpenSSH 6.7, back in 2014, and Raspbian Buster is already on 7.9p1, in 2019. Almost all of its reason for existence has been replaced by ipchains^Wiptables^nftables now with rate limiting. However, since most attacks are distributed, classical rate limiting using iptables^nftables has almost no benefit.

3. It is silly to limit access to the Pi only to known IP addresses if remote access is a priority, especially if mitigations 4 (no root login), 6 (keys with strong passphrases), and 10 (SSHGuard, Fail2ban, or DenyHosts) have been implemented. Point 6 is especially important.

As far as I can tell, in regards to running OpenSSH on the Raspberry Pi, the single best mitigation tactic is to use SSH key-based or SSH-certificate based logins with password authentication disabled. Most bots seem to be able to determine this and back off on first contact, regardless of which port SSH is listening on.

User avatar
rpdom
Posts: 15180
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Raspberry Pi Security

Mon Sep 02, 2019 8:08 am

tpyo kingg wrote:
Mon Sep 02, 2019 7:08 am
As far as I can tell, in regards to running OpenSSH on the Raspberry Pi, the single best mitigation tactic is to use SSH key-based or SSH-certificate based logins with password authentication disabled. Most bots seem to be able to determine this and back off on first contact, regardless of which port SSH is listening on.
That is probably the safest option.

One other that I have used when I have occasionally had to log in from a device that I hadn't used before is One Time Passwords. There is a package in Debian/Raspbian that will let you set up a series of random passwords that can only be used once.
You run a command on the system to be accessed and that gives you a list of ten or so numbered passwords that are valid. There is also as keyword that you set up in advance.

Then when you log in you get a password prompt that is something like (sorry, a while since I used this and can't remember exactly)

Code: Select all

Password[12]:
which means you have to enter the keyword followed by the 12th password on the list.

If the keyword and password are correct you get logged in and that password is deleted. If not correct it gets left as it is.

I used to use this when I logged in from my phone which didn't support shared keys at the time.

epoch1970
Posts: 3658
Joined: Thu May 05, 2016 9:33 am
Location: Paris, France

Re: Raspberry Pi Security

Mon Sep 02, 2019 8:55 am

jcyr wrote:
Mon Sep 02, 2019 3:38 am
Any Pi on public Internet will probably have ssh enabled for remote access.
Certainly not. Your average router comes without SSH enabled (or any other service on the WAN port, for that matter), with good reason.

It is preferable to run a client VPN or something to the same tune that actively connects and “phones home” rather than having the ssh daemon waiting for connections. Within that safer zone you can have remote login enabled for maintenance.

An IDS like fail2ban, tripwire etc is only good as long as the machine is monitored by an admin. Otherwise it just adds load and thrashes logfiles. Active IDS like fail2ban are the absolute worst; attackers know and use the behavior of those tools and you end up causing your own denial of service... No monitoring, no IDS.

Google has authored a PAM module that goes along with the free Authenticator app, you can use that to setup 2 factor authentication if remote login has to be possible from the Internet. This one is useful.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

Return to “General discussion”