johnklos

This is a bit pedantic, but x64 refers to Alpha, which existed long before 1999. 64 bit x86 (x86-64, or amd64) wasn't purchasable until 2003, although it was announced in 2000.

There were several additional shifts between 1978 and 2003:

• 8088 / 8086 has what's essentially bank switched 16 bit addressing which gives 1 MB, or 2^20 bytes
• 80286 has physical support for 16 megs, or 2^24 bytes
• 80386 has physical support 4 gigs, or 2^32 bytes
• Pentium Pro has PAE support for 64 gigs, or 2^36 bytes
• AMD Opteron from 2003 has support for 1024 gigs, or 1 terabyte, or 2^40 bytes
• Current AMD and Intel CPUs physically support anywhere between 2^48 and 2^57 bytes of physical hardware (256 terabytes to 128 petabytes)

But let's just use three points of data: 8086 / 8088, 80386, and let's say the first 64 bit AMD Opteron supports 64 bits:

• 8086 / 8088, 1978, 20 bits
• 80386, 1985, 32 bits
• AMD Opteron, 2003, 64 bits

1978 to 1985 is 7 years, with a change in addressing of 12 bits, or about .6 bits per year.

1985 to 2003 is 18 years, with a change in addressing of 32 bits, or about .56 bits per year. So far, pretty consistent.

How long would it take to go from 64 bits to 128 bits? At around .56 bits per year, that'd be about 114 years, and we've had twenty so far.

Check back in 94 years.

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.