please sanity-check my setup

  • Release Candidate 6
    Guest:
    We are at a “proposed final” true release candidate with nothing known remaining to be changed or fixed. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.

mappo

Member
Sep 25, 2021
14
1
Sweden
I'm just setting up a new server and network environment and I would love some feedback from the community of elder nerds.
Note: These are just plans for now.

At the center is a Ubiquiti Edgerouter Lite router.
On Lan1 is a switch connecting all devices in our house, including some APs.
On Lan2 is a RasPi4.

There are no ports open through the router (on either interface).
The Pi runs Wireguerd which gives it with a static public IP (v4) from my VPN provider.

Our Androids will run FolderSyncPro to upload images to the Pi. This is the reason I want it to have a static IP.
We will also use some kind of explorer app (possibly Cx) to view images from all phones - no secrets here!
(Of course this will be done with another user to prevent accidental file deletes).

On paper I'm pretty happy with this solution. It's nice and clean with only ssh and no servers running (instead relying on heavy clients).
One issue I'm aware of is that my VPN provider opens all ports by default, so I'll need something like UFW to close all but the ssh port.

Does anything scream bad idea at you?
Is it unsafe to expose ssh to WAN? Should I go for an "exotic" ssh-port?

In an earlier draft I looked at using Syncthing to upload from the Androids. The advantage of FolderSyncPro is advanced scheduling and limiting with respect to connection.
 
Is it unsafe to expose ssh to WAN? Should I go for an "exotic" ssh-port?

I personally am ok with exposing ssh. I only use certificate-based authentication, and I make sure to keep the ssh service up to date.

I do run on a nonstandard port but not because I think it enhances security, I do it just to keep my logs quieter. There are a lot of automated ssh scans so you'll get blasted with login attempts if you leave it at 22. (On my system they will all fail because they are not certificate-based auths, but I hate the noise in the logs.)

Some people also choose to run something like fail2ban which will set up firewall rules to block IP addresses for a time when too many failed login attempts are detected.
 
  • Like
Reactions: mappo
Is it unsafe to expose ssh to WAN? Should I go for an "exotic" ssh-port?
I agree with what @drwtsn32 posted above with a caveat. Exposing any software to potential attackers is a risk if that software might eventually be found to have a vulnerability. Since SSH still occasionally gets new mild to serious bugs found by times, make sure you stay on top of its maintenance. (OpenSSH offers a mailing list for this purpose, I believe.) Also, it would not hurt to be selective about who can potentially target you, using firewall rules. If you never go abroad, then it may be possible to restrict connections outside of your area.
 
"Should I go for an "exotic" ssh-port?" Security through obscurity.
Disallow root and password auth, use an SSH key and if possible white list. That seems appropriate.
 
  • Like
Reactions: mappo
Will you be having all devices utilize the same VPN system and the same VPN endpoint? If yes, it would seem whitelisting by IP might be a small pool to work with (assuming most device IP's would be dynamic with one static).
 
  • Like
Reactions: mappo
You have a static IP address, why not VPN or WireGuard/Tailscale to the Pi and avoid TCP/22 open to the Internet?
Also I assume this segregation is just VLANs? Have you left the tooling on the Pi for a potential hacker to go VLAN hopping.....?
 
I would certainly look at implementing fail2ban. I have it on my customer's servers and it routinely traps and blocks 10's of IP addresses every day. This is on a server which runs no publicly accessible services.
 
"Should I go for an "exotic" ssh-port?" Security through obscurity.
Disallow root and password auth, use an SSH key and if possible white list. That seems appropriate.
Disallow root - good advice, thank you!
I like to think of it as Security *and* obscurity :cool:
 
Will you be having all devices utilize the same VPN system and the same VPN endpoint? If yes, it would seem whitelisting by IP might be a small pool to work with (assuming most device IP's would be dynamic with one static).
This is a great idea! All devices (the "Androids" as it were) will have the same VPN provider but they will be assigned a dynamic IP.
 
Last edited:
You have a static IP address, why not VPN or WireGuard/Tailscale to the Pi and avoid TCP/22 open to the Internet?
Also I assume this segregation is just VLANs? Have you left the tooling on the Pi for a potential hacker to go VLAN hopping.....?
I was under the impression that it is a physically separate interface (until I read your question, that is).

Your short reply contains 3 question-marks, each of which will take me an hour of deep-googling to sort out. Coming here is a good exercise in humility, especially for us software devs who think we're done just because it "works"
 
OpenSSH offers a mailing list for this purpose
Incidentally I just got such an email from OpenSSH and they warn of a potential issue related to an integer overflow.

OpenSSH 8.9 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly.


Security Near Miss
==================

* sshd(8): fix an integer overflow in the user authentication path
that, in conjunction with other logic errors, could have yielded
unauthenticated access under difficult to exploit conditions.

This situation is not exploitable because of independent checks in
the privilege separation monitor. Privilege separation has been
enabled by default in since openssh-3.2.2 (released in 2002) and
has been mandatory since openssh-7.5 (released in 2017). Moreover,
portable OpenSSH has used toolchain features available in most
modern compilers to abort on signed integer overflow since
openssh-6.5 (released in 2014).

Thanks to Malcolm Stagg for finding and reporting this bug.