Secuirty: should SSH Service in Firewalld's external Zone be disabled by default?

Feedback
1

QUESTION/SUGGESTION

Hi, I notice that by default the SSH service (port 22) in enabled in the external Zone in FreedomBox’s firewall, Firewalld, configuration. I have done a bit of testing and it seems that this means that by default SSH access is available from the big bad internet, rather than just from machines on the local/home network. Is this an unnecessary security risk?

I have configured my home modem/router to set Freedombox in the DMZ, so I suppose my set up might not be a typical set up. I guess, typically, FreedomBox might be set up behind a home modem/router’s firewall and thus it this would required that the user explicitly forward port 22 in the home router’s admin settings. Thus mitigating the fact that port 22 on the FreedomBox is open to the internet by default.

However, SSH is a possible vector of attack for port scanning crackers on the internet, and because, typically SSH access is only required by FreedomBox for admin purposes, usually from the local/home network, from a security point of view, would it make sense to have external access to the SSH service disabled by default in Firewalld? Possibly with an explicit option in Plinth to enable external SSH access if required?

BACKGROUND

The following are the steps that I took to change FreedomBox’s firewall, Firewalld, configuration and test SSH access…

To view Firewalld’s Zones and associated enabled Services:

sudo firewall-cmd --list-all-zones

The command above reveals that FreedomBox’s default Firewalld setup has SSH service enabled in the following Zones: dmz, external and internal.

I was able to gain SSH access via my public IP running the following command and then entering my password:

ssh://username@my-public-IP:22

Having disabled SSH access for the external and dmz Zones, with the following commands, attempts to establish an SSH connection, using the previous command, now fail with the message: “no route to host”:

sudo firewall-cmd --permanent --zone=external --remove-service=ssh
sudo firewall-cmd --permanent --zone=dmz --remove-service=ssh
sudo systemctl restart firewalld

After disabling SSH access in the external and dmz Zones I can still establish an SSH connection to the FreedomBox from the local/home network connecting to it’s local IP.

I feel more comfortable knowing that I have to explicitly enable external SSH access if I require it.

Should this be the default set up?

My setup: Rasbian Buster on Raspberry Pi3B+ with Freedombox v2.7 installed from the repos.

2

It would be more secure to close it by default in the external zone. However:

  • We have fail2ban enabled by default which significantly reduces effectiveness of brute forcing for SSH passwords.
  • This is likely to cause issues with people not being able to machines at all. Most FreedomBox machines are headless and SSH is our last line of defense if something goes wrong.
  • During the initial setup, FreedomBox configures an interface as internal or external based on a number of factors. So, depending on many network interfaces one has and which one they are plugged into, a user many end up being on the harsh end of an ‘external’ zone. This could create a lot of support problems.
  • SSH service is optional now.
  • In future, we may allow through configuration for a service to be made internal only even it is external by default .
1 Like
3

So, I agree that ssh is our last way of connecting should the web connection go wrong and that it’s worth keeping as an option. Today, however, I’ve just discovered the Terminal utility in Cockpit. Its a functional terminal session in the web browser - very nice!

Yes, I’m keeping ssh just in case, and yes, this does rely on the higher level web services, but…

  • It’s available from the internet
  • It’s protected by your Let’s Encrypt certificates
  • It’s nice to use
  • I’m using this instead of ssh now

I think that the command line customer uncomfortable with leaving ssh open to be exposed to automated connection attempts as you and @luisgarcia have been discussing may be happy with this alternative. At some point we have to rely on the software stack - we trust ssh and fail2ban to keep the intruders out, and extend that same trust to Freedombox and Cockpit. Starting with that trust the Cockpit terminal is a credible ssh alternative for the command line user.

2 Likes
4

Thanks for the heads up :slight_smile:

My point was about whether SSH should be available on the external zone by default is because I would think most people deploying FreedomBox would be on the local network.

I take you point though :slight_smile: It’s a matter of judgment and balancing sort of “reach ability” with risk, and as you you say, the system is locked down, so it is a minimal risk :slight_smile:

1 Like