What's new

A huge surge in NAS, cloud and backups

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

System Error Message

Part of the Furniture
With the wannacry worm outbreak, people will be learning things the hard way. So theres going to be more demand for firewalls and backup solutions. I just hope that prices wont surge for any solutions and even drives.
 
Since the majority of Wannacry victims are people still running Windows XP, I doubt it will change anything.
 
but those that arent running it hear of the horrible news and will start backing up if they havent already. Many youtubers and writers are suggesting NASes.
 
but those that arent running it hear of the horrible news and will start backing up if they havent already. Many youtubers and writers are suggesting NASes.

NAS aren't fool proof. Lately, QNAP has been sending me notices about a malware remover. Some malware targeting their NAS will end up re-flashing them with a (potentially modified) version of 4.2.5... Funny timing actually, as I got these notices at about the same time WannaCry appeared.
 
Saw that same thing - has nothing to do with WannaCry...

Of course it doesn't, but it shows that even going with a NAS is no longer a fool proof way of avoiding the patch-or-be-pwned dance :(
 
Of course it doesn't, but it shows that even going with a NAS is no longer a fool proof way of avoiding the patch-or-be-pwned dance :(

We should all be practicing safe hex...

Which might be a way to remind folks...
 
People merely adding a simple NAS to their network is not what I would call a robust backup solution. Isn't this exactly why WannaCry was so devastating? Not only did it screw over their local PC but it also attacked their SMBv1 shares. Every consumer NAS I've seen has SMBv1 enabled by default.

@RMerlin I seem to remember there were some SMBv2 options you added to your firmware but for the life of me I can't find it now. Can you refresh my memory?
 
Every consumer NAS I've seen has SMBv1 enabled by default.

The problem isn't a flaw in SMBv1. It's Microsoft's code incorrectly handling 16/32 bit values.

Samba in SMBv1 is safe from this security issue.

@RMerlin I seem to remember there were some SMBv2 options you added to your firmware but for the life of me I can't find it now. Can you refresh my memory?

Tools -> Other Settings, Tweaks.
 
Thanks for the info @RMerlin.

The problem isn't a flaw in SMBv1. It's Microsoft's code incorrectly handling 16/32 bit values.

Samba in SMBv1 is safe from this security issue.
I quite like the style of this piece. :D

https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/
SMB1 isn’t good
Stop using SMB1. For your children. For your children’s children. Please. We’re begging you.

– Ned “and the rest of the SMB team at Microsoft” Pyle
 
I quite like the style of this piece.

My config on debian, where there are some options...

Code:
[global]
# uncomment the line below for better performance on some platforms
# on gigabit ethernet, with an untuned kernel we're seeing about 115MB/Sec on large files
# socket options = TCP_NODELAY
workgroup = WORKGROUP
netbios name = HOMESERVER
security = user
hosts allow = 192.168.1.0/24
restrict anonymous = 2
min protocol = SMB2
max protocol = SMB3

[share]
comment = Home File Server
path = /sharepoint
force user = fileserver901
force group = fileserver901
read only = no
browsable = yes
create mask = 0755
 
I quite like the style of this piece. :D

Considering virtually every router with USB ports is running Samba 3.0, doing so will break USB disk sharing for most people.

I suspect it's the same with a lot of entry-level NASes/network attached disks as well. The problem is you need Samba 3.6 or newer for SMBv2, and out of the box, Samba 3.6 takes multiple megabytes of flash space, making it unusable in many embedded applications. Someone backported various size reduction techniques to 3.6 for OpenWRT (which I use for my own firmware), but SMBv2 still carries a hefty performance penalty since we're CPU-bound, not network-bound.

As for Samba 4, nobody has managed to make it compile in any reasonable size. The Samba developers said it basically wasn't their problem, that someone else would have to come up with a way to make it compile to a smaller footprint, and to submit it to them for potential consideration.

And to top that, Samba 4 cross-compiling in itself is a PITA of its own, due to the weird build system they use.

What we need is either a standard way of compiling Samba 4 for embedded devices (with a smaller footprint), or for every manufacturers to start using at least 128 MB of flash space even for entry-level disk sharing devices.

Or for someone to fork Samba, and create an embedded-friendly version, one where they'd strip all the AD and Kerberos stuff, for instance, implement multicall binary support, and so on.
 
As for Samba 4, nobody has managed to make it compile in any reasonable size. The Samba developers said it basically wasn't their problem, that someone else would have to come up with a way to make it compile to a smaller footprint, and to submit it to them for potential consideration.

@RMerlin raises some very valid points - and we're getting to a place where it's going to be more useful to have something like an 16GB (or even 32GB, the price delta is less than one would think) eMMC's - all the code is getting bigger, we're pushing for more features and newer code to be integrated, and it does make it a challenge for a device that might only have 128MB of direct access NAND (or even less, some broadcom designs for AC1900 class devices are still running in 16MB of NAND, which is crazy).

As for Samba - considering the functionality, it's huge, and that's not counting the dependencies outside of the core Samba binaries...

This is what debian has in the current Jessie repos (which Rasbian, for example, uses)...

https://packages.debian.org/jessie/samba

Package: samba (2:4.2.14+dfsg-0+deb8u5)

Screen Shot 2017-05-19 at 2.34.01 PM.png
 
the emmc used is a different kind of flash many different flash are used in embedded devices and even phones, they differ by things like endurance, speed, IO, price. At times you ask wouldnt it be cheaper to just have sodimm slots and use sodimm ram instead of putting the ram on the board? Its the same for GPUs too as the ram chips used dont use the same timings and specs as we're used to in laptops and pcs.
Prexisting technology even older gets very cheap, hence the use of low density flash and ram.
a lot of videos on youtube are saying "look at my shiney new NAS behind me".
 
Given what Merlin said about NAS's, I'm curious how many "home" NAS's support SMBv2 or SMBv3.

The only thing a quick Google reveals is this page from Synology. They make a big thing about it in their management software, but when looking at the spec's of their hardware all I see is CIFS (aka SMBv1) support.
 
the emmc used is a different kind of flash many different flash are used in embedded devices and even phones, they differ by things like endurance, speed, IO, price. At times you ask wouldnt it be cheaper to just have sodimm slots and use sodimm ram instead of putting the ram on the board?

Because both NAND and eMMC serve a different purpose than RAM...

I was there on the transition of mobile phones when the switch from direct access NAND to eMMC basically happened - and performance went up, and failures went down - vendors do like the eMMC's, as they can also support secure boot access directly outside of the operating system, bootloader, or baseband processor (in mobiles) as this is all defined in the MMC specs...

The driver is already in the kernel, and from a bootloader perspective, it's a lot easier to work with when using uBoot, which also has direct support for MMC these days.
 
Because both NAND and eMMC serve a different purpose than RAM...

I was there on the transition of mobile phones when the switch from direct access NAND to eMMC basically happened - and performance went up, and failures went down - vendors do like the eMMC's, as they can also support secure boot access directly outside of the operating system, bootloader, or baseband processor (in mobiles) as this is all defined in the MMC specs...

The driver is already in the kernel, and from a bootloader perspective, it's a lot easier to work with when using uBoot, which also has direct support for MMC these days.
I was talking about the flash and ram used seperately. Such as routers only having megabytes of space while phones have gigabytes of flash space.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top