1 hour ago, NAS said:

I would like to suggest that we make the disabling of what we are calling SMBv1 via the GUI as a checkbox. This way we can inform the users of the downsides, why it should happen and the rarer cases where it shouldnt.

 

We do need to debate what the default should be. At some point SMBv2+ should be the default but I do not think that day has come yet.

 

Regardless this should be a point and click skill-free exercise for users and not a lengthy forum read should they happen upon it.

 

This exploit only affects windows.  Disabling SMBv1 in linux/unRAID does nothing except break legacy media players.

I would like to move beyond talking about Wannacary as it is too narrow a focus. Happy to fork the thread although all the right people are monitoring this one so if we can stay it would be better.

 

There are several protocol level problems with SMBv1 that cant and wont ever be fixed and it has been deprecated as a recommended protocol for quite some time now by all the relevant players.

 

A generic non exploit related example of SMBv1 failure is that there are known issues where legacy devices/OS will "fail low" and handshake below SMBv2 even when they are far more capable just because SMBv1 exists on the remote server.

 

I do not deny that universally disabling SMBv1 would break equipment and it is why i specifically did not suggest this but it is clear that there is a subsection of the userbase that do not need it, some that dont need it but unknowingly still use it and yet others who have no idea and will need some help with the topic as a whole.

 

Saying all that I can see that more compatibility is a simpler stance and has many benefits in itself but I definitely dont believe it is the most secure stance we could take.

 

Ultimately the decision is yours if we want to take a proactive approach to security vs ultimate compatibility.