Tape. You’ll thank yourself in the long run.

Ask that question about anything, and ask these same questions about the same:

Do you want to learn? Do you have a reason to want to have understanding and control over it? Do you have the time, resources, energy and aptitude?

You’ve just answered your own question :)

Some people have a deep distain for the idea of self-hosted email, but there’s literally no good technical reason you can’t do it yourself. I think people react so strongly and insist it shouldn’t be self-hosted because they couldn’t hack it ;)

(yes, I’m poking them for fun)

Seriously, the only compelling reason they mention isn’t compelling: if you’re worried about deliverability, pay a reputable service for smarthosting through them. Problem solved, and you still get to 100% control your own filtering, logging, storage and access.

That’s not exactly true. You may be stopping file transactions, but the filesystem handler code should still run until it has flushed its state, and if it doesn’t, then that’s a huge bug and isn’t normal.

Because they’re being silly. There is no other public facing service more secure than a relatively modern OpenSSH.

In some instances, yes, it’s best to disable the ssh that comes with whatever NAS OS you’re running, because they often ship old code and don’t care about updates and security.

But if you’re running a relatively up to date OpenSSH and you’re using keys, not passwords, then you are as secure as you can reasonably be. There’s no math suggesting otherwise. Moving to a different port will reduce the frequency of attack, but that will have zero impact on the possibility of intrusion.

Put it this way: if relatively recent OpenSSH has a remotely exploitable vulnerability, you’ll see it on the news on TV. You’ll see it and hear about it literally everywhere. The world will stop for 24 hours and there will be widespread panic. You’ll know.

If your NAS has an exploit, you might read about it on The Register a few months later.

NAS vendors aren’t known for understanding security. Opening ssh to the world is no problem, because ssh is everywhere, it’s constantly attacked, and half the world would know if an exploitable vulnerability was found.

If NAS vendor ABC has a vulnerability in the login code written by a programmer who hasn’t done much more than CSS, it would surprise nobody, and you wouldn’t hear about it on any IT news sites. It would just be exploited until all the machines were exploited or until they’re all patched.

It really is a world of difference between something known and secure and some random login page.

If, as you write, it will be over sftp, then why are you forwarding port 21? Port 21 is FTP, plus you need your NAT router to also be able to negotiate the data channel on a separate port.

If you don’t know you need this, then you may be in for a big surprise when you go down that rabbit hole and try to implement it.

It’s much easier to forward port 22 and use sftp. It’s also much more secure, particularly if you use ssh keys instead of passwords.

See this post:

https://www.reddit.com/r/Sysadminhumor/s/FHa5qvzc0G

Just as a POC, I set up an old Radio Shack bulk tape eraser next to a drive (don’t worry - it was in SMART pre-fail already) to see what’d happen. Just turning it on for a split second made the drive completely stop being able to access anything.