please sanity-check my setup

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. 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 please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

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.