If the only goal is an open source file server (we call this a SAM-SD, there is a section of the forum just for that) then the most likely recommendations for an OS will be openSuse Tumbleweed or Fedora. CentOS and Ubuntu are fine choices too. FreeBSD is excellent, but less well known.
You make it sound as though the wise choice here would be to install OpenSuse etc direct to the hardware.
Hrm, fast-clone. Probably time to try out a Btrfs based file server at home.
It's good stuff.
Yeah, I know brtfs is the way to go, I just haven't tried it out yet myself. Starting out on IRIX with XFS back in the day makes me a too nostalgic.
I still use XFS for everything.
When will be the right time to switch to btrfs then? We know it's been stable for long enough that it's becoming the default in a number of distributions now, but has it really been battle tested well enough yet?
Also, should we maybe make another thread for the btrfs discussion?
The answer here is you do not switch. You install a distro letting it do its native thing by default and less you have an over arcing huge reason to override defaults. So you will get this when you install a new system that now has it as a default.
openSuse, for example, has had it as default for two years.
Really though, I prefer XFS for anything that isn't a storage machine. VMs need something mature, stable and light. XFS does that well.
But does your preference mean that you will override a default installs choice just because that is your preference?
Using anything but default should have very clear reasons because the first time somebody besides you have to troubleshoot it there will be big problems.
I would often, yes actually. XFS is not like an odd, unsupported option. It's just not the default. It's still completely core to openSuse's design. They simply had to pick which one they were going to use when someone did not choose one or the other and they opted for extra features over lean design for those that don't know which they want, which I think makes sense. Just like CentOS opts for the simplicity of using root for administration instead of sudo, but makes it super easy to enable sudo. It's not default, but it's fully supported. They just had to choose something as default.
The security vulnerabilities can be mostly categorised as man-in-the-middle or denial of service attacks.
Man-in-the-middle (MITM) attacks:
There are several MITM attacks that can be performed against a variety of protocols used by Samba. These would permit execution of arbitrary Samba network calls using the context of the intercepted user.
Impact examples of intercepting administrator network traffic:
Samba AD server - view or modify secrets within an AD database, including user password hashes, or shutdown critical services.
standard Samba server - modify user permissions on files or directories.
Denial-of-Service (DoS) attacks:
Samba services are vulnerable to a denial of service from an attacker with remote network connectivity to the Samba service.
Who is affected?
Affected versions of Samba are:
Earlier versions have not been assessed.
How can I fix my systems?
Please apply the patches provided by the Samba Team and SerNet for EnterpriseSAMBA / SAMBA+ immediately.
Patched versions are (both the interim and final security release have the patches):
4.2.10 / 4.2.11,
4.3.7 / 4.3.8,
4.4.1 / 4.4.2.
With the release of Samba 4.4.0 on March 22nd the 4.1 release branch has been marked DISCONTINUED (see Samba Release Planning). Please be aware that Samba 4.1 and below are therefore out of support, even for security fixes. There will be no official security releases for Samba 4.1 and below published by the Samba Team or SerNet (for EnterpriseSAMBA). We strongly advise users to upgrade to a supported release.
Some vendors may choose to ship 4.4.1, 4.3.7, and 4.2.10 versions and add regression patches on top of them, due to wide scale and complexity of this release. Some may also just backport the patches to older releases. Please contact your Samba supplier for details.
What further improvements after patching are suggested?
Mitigations for man-in-the-middle (MITM) attacks:
Network protections that could be used MITM attacks include DHCP snooping, ARP Inspection and 802.1x.
It is recommended that administrators set these additional options, if compatible with their network environment:
server signing = mandatory
ntlm auth = no
Without server signing = mandatory, Man in the Middle attacks are still possible against our file server and classic/NT4-like/Samba3 Domain controller. (It is now enforced on Samba's AD DC.) Note that this has heavy impact on the file server performance, so you need to decide between performance and security. These man in the Middle attacks for smb file servers are well known for decades.
Without 'ntlm auth = no', there may still be clients not using NTLMv2, and these observed passwords may be brute-forced easily using cloud-computing resources or rainbow tables.
Mitigations for denial-of-service (DoS) attack:
Apply firewall rules on the server to permit connectivity only from trusted addresses.
Will encryption protect against these attacks?
The SMB protocol, by default, only encrypts credentials and commands while files are transferred in plaintext. It is recommended that in security / privacy sensitive scenarios encryption is used to protect all communications.
Samba added encryption in version 3.2 in 2008, but only for Samba clients. Microsoft added SMB encryption support to SMB 3.0 in Windows 8 and Windows Server 2012. However, both of these types of encryption only protect communications, such a file transfers, after SMB negotiation and commands have been completed. It is this phase that contains the fixed vulnerabilities.
Samba/SMB encryption is good practice but is not sufficient for protection against these vulnerabilities. Network-level encryption, such as IPSec, is required for full protection as a workaround.
How bad is Badlock?
The severity of Badlock according to the Common Vulnerability Scoring System (CVSS):
It may be possible since we already have several PoC (none of them will be released in the near future).
What does "Badlock" stand for?
"Badlock" was meant to be a rather generic name and does not point to any specifics.
Yet Another Bug With A Logo?
What branded bugs are able to achieve is best said with one word: Awareness. Furthermore names for bugs can serve as unique identifiers, other than different CVE/MS bug IDs.
It is a thin line between drawing attention to a severe vulnerability that should be taken seriously and overhyping it. This process didn't start with the branding - it started a while ago with everyone working on fixes. The main goal of this announcement was to give a heads up. Vendors and distributors of Samba are being informed before a security fix is released in any case. This is part of any Samba security release process.
Who found the Badlock Bug?
Badlock was discovered by Stefan Metzmacher. He's a member of the international Samba Core Team and works at SerNet on Samba. He reported the bug to Microsoft and has been working closely with them to fix the problem.
So I figured it out. Just like most every other problem I've had, it was something stupid I did. I initially started with a user "john" and set up permissions but decided later to use "jhooks". I had accessed the shares with the "john" username first and that's why some worked. I never added the jhooks username to samba (must have forgot since some shares were working) and that's why I couldn't log into the other shares with that username.
That will teach me to try to do this stuff on Friday night when I'm tired.
Well worse things have happened, it could've been a client outage :)
You have two NASs at home mounted to a Linux box, that you are then sharing to CIFS so you can mount them on a Windows box?
Is the Windows box not on the local LAN? If not I guess that's why you have Pertino as part of this, because you are Pertino'ing from a non local Windows box to the Linux box which is offering a pass-through to the NASs?
If your Windows box is local to NASs, why bother going through the Linux box?
The Windows box and the Linux box are both on the same LAN as the NASes. This is more so I can access the NASes easily remotely on my Pertino network.