QNAP's NFS configuration is absolutely insecure

Tell us your most wanted features from QNAP products.
Locked
User avatar
doktornotor
Ask me anything
Posts: 7472
Joined: Tue Apr 24, 2012 5:44 am

QNAP's NFS configuration is absolutely insecure

Post by doktornotor »

As documented here, this really is a bad joke. Not only you are shipping NFSv4 without utilizing a single security feature thereof, but you even turn off root squashing by default - of course with no configuration options to revert this. Terrible! Even simple things like setting per-machine access for given export are impossible via the GUI.

- Major improvements to the GUI NFS configuration are required to make it possible to share things via NFS in a more secure way.
- Implement NFSv4 Kerberos authentication!

Meanwhile, I suggest everyone to turn the feature off.
I'm gone from this forum till QNAP stop wasting volunteers' time. Get help from QNAP helpdesk instead.
Warning: offensive signature and materials damaging QNAP reputation follow:
QNAP's FW security issues
QNAP's hardware compatibility list madness
QNAP's new logo competition
Dear QNAP, kindly fire your clueless incompetent forum "admin" And while at it, don't forget the webmaster!
User avatar
schumaku
Guru
Posts: 43579
Joined: Mon Jan 21, 2008 4:41 pm
Location: Kloten (Zurich), Switzerland -- Skype: schumaku
Contact:

Re: QNAP's NFS configuration is absolutely insecure

Post by schumaku »

Can't agree more.

Just two minor ones to be corect:
doktornotor wrote:Not only you are shipping NFSv4 ..
Strongly doubt NFSv4 is supported and enabled by default. Of course, the Kernel is NFSv4-ready for a while - what has caused a lot of problems: NFSv4-enabled clients struggled to mount - simply because NFSv4 is not active by default. The workaround suggsted was always to force the mount type to nfsv3, at least from my side.
doktornotor wrote:...without utilizing a single security feature thereof, ...
Talking of the lack of the Kerbros. Something I have complained years ago already. Of course, first we must understand QNAP does not see NFSv4 to be a supported feature. I was reading the RFC at that time in any direction - RFC 5661, 1.7.1. RPC and Security describes the RPCSEC_GSS GSS-API option as an extension to the basic RFC security. So implementing the GSS-API part is just an option to extend the security for an NFSv4.1 server and mount - and Kerberos V5 is just an option to provide one security framework.

Again, no doubts: In my opinion, a NAS with NFS support must support v3 and v4.1 protocols, and shoud suppliy the possibilities to be integrsted in an existing Kerberos infrastructure (ie. an MIT v5 Kerberos server, or ie. Microsoft Active Directory). Alternate, as many users see thier NAS as basic infasructure, an easy-to-handle Kerberos authentication server should be added.

What is the adjustment of that? I'm an old dog in that business 8) ... Over the years, I had the pleasure of establishing a bunch of commercial Kerberos v5 servers in non-M$ environments, tweak the Microsoft Active Diectory structures to meet the requirements of the leading ERP system - so the authentication of the ERP users, many B2B communication channels, .... were converted to Kerberos security.

What is feasible? SAMBA v4 will bring everything required: The LDAP server with AD semantics, the Kerberos server with PAC support, Bind9 integration for Active Directory DNS support (ha, that's why I'm favouing Bind over dnsmasq btw.).

So the question is where to start. Adding yet another auth service by implementing ie. MIT Kerberos server? I doubt ...in the meantime, we need "just" more complete NFS RFC basic security options in the Web UI. Then the way is going straight ahead to SAMBA 4.
User avatar
doktornotor
Ask me anything
Posts: 7472
Joined: Tue Apr 24, 2012 5:44 am

Re: QNAP's NFS configuration is absolutely insecure

Post by doktornotor »

schumaku wrote:Strongly doubt NFSv4 is supported and enabled by default. Of course, the Kernel is NFSv4-ready for a while - what has caused a lot of problems: NFSv4-enabled clients struggled to mount - simply because NFSv4 is not active by default. The workaround suggsted was always to force the mount type to nfsv3, at least from my side.
Yeah, it is not enabled, just shipped without being used. Shame, if you ask me.

While implementing kerberos with NFSv4 might take a while, addressing the other issues mentioned is a matter of hours. The default config is simply unacceptable by any means, and there are basically no configuration options whatsoever to make it more secure without messing with SSH. What were they thinking with the root squash thing goes beyond me.

P.S. Samba v4 would be nice, meanwhile I have been waiting for over a month for a critical fix for the remote root execution bug, so... not anytime soon I am afraid. :roll:
I'm gone from this forum till QNAP stop wasting volunteers' time. Get help from QNAP helpdesk instead.
Warning: offensive signature and materials damaging QNAP reputation follow:
QNAP's FW security issues
QNAP's hardware compatibility list madness
QNAP's new logo competition
Dear QNAP, kindly fire your clueless incompetent forum "admin" And while at it, don't forget the webmaster!
glibdud
First post
Posts: 1
Joined: Sat Jul 14, 2012 10:50 pm

Re: QNAP's NFS configuration is absolutely insecure

Post by glibdud »

Ouch, I guess I needed to do a little more research before I bought the device. Thanks for pointing this out. Hopefully I can find workarounds for all the things I was hoping to do with this device without using NFS.

+1 for this request.

(Otherwise, I've been very impressed with what this little device can do so far.)
Pellaeon
New here
Posts: 3
Joined: Thu Jul 19, 2012 9:12 pm

Re: QNAP's NFS configuration is absolutely insecure

Post by Pellaeon »

Also +1 for this request.

The NFS configuration via the GUI is essentially braindead! My Netgear ReadyNAS Duo does this quite well. At least fix the GUI with respect to the per-machine access rights for NFSv3. The NFS implementation itself is perfectly capable of doing this (just edit /etc/exports as you would normally, then run exportfs -r), but the retarded way NFS settings are handled ensure that the /etc/exports file is regenerated at every reboot, overwriting the hand-made changes.

Not that I reboot all that much, but it's highly annoying to be constrained by a backward configuration system.

I wouldn't mind being able to use NFSv4 either, but it's not as high on my list of priorities at the moment as fixing the configuration system is.
User avatar
schumaku
Guru
Posts: 43579
Joined: Mon Jan 21, 2008 4:41 pm
Location: Kloten (Zurich), Switzerland -- Skype: schumaku
Contact:

Re: QNAP's NFS configuration is absolutely insecure

Post by schumaku »

Pellaeon wrote:I wouldn't mind being able to use NFSv4 either, ...
You can manually enable the (unsupported) NFSv4 and use the RFC 5661 standard NFSv4(.1) functionality. Be aware that additional security which can be integrated by RPCSEC-GSS, with Kerberos v5 shown as an example are optional, and not mandatory for a NFSv4.1 implementation.
Pellaeon
New here
Posts: 3
Joined: Thu Jul 19, 2012 9:12 pm

Re: QNAP's NFS configuration is absolutely insecure

Post by Pellaeon »

That's useful to know. I've been toying with the idea of switching from LDAP authentication to krb5 like I've been using at work for about 10 years now. Does the qnap support krb5 authentication for NFSv4? (I don't expect to be able to use krb5i or krb5p and see any sort of performance out of my qnap, but authentication would be nice to have.) I saw only a rather sparse krb5 template file on the box, though that might be my lack of familiarity with the system.
User avatar
schumaku
Guru
Posts: 43579
Joined: Mon Jan 21, 2008 4:41 pm
Location: Kloten (Zurich), Switzerland -- Skype: schumaku
Contact:

Re: QNAP's NFS configuration is absolutely insecure

Post by schumaku »

That's why I mentioned authentication is optional - it is and not an integral key part of NFSv4(.1). I'd say librpcsecgss is required on the server and the client side for example. And as for most NAS users the NAS it _the_ key infratructure, we would also need a Kerberos system ... and finally PAM suspport to bring the different authentication schemes under one hood - instead of many different poorly integrated systems LDAP, RADIUS, passwd, ...

In my opinion - considering the fact the QNAP NAS arethightly desgned and built around SAMBA - the ability to serve authoritative for a realm shold be skipped until we have SAMBA 4 on the table.

Before QNAP should consider addimg PAM (see the poll) and of course the NFSv4.1 with krb5 required libraries for the NFS server and the client.
Mathiau
New here
Posts: 2
Joined: Fri May 14, 2021 2:59 am

Re: QNAP's NFS configuration is absolutely insecure

Post by Mathiau »

So, 9 years later and not much has changed for NFS has it?
User avatar
OneCD
Guru
Posts: 12010
Joined: Sun Aug 21, 2016 10:48 am
Location: "... there, behind that sofa!"

Re: QNAP's NFS configuration is absolutely insecure

Post by OneCD »

* topic locked to prevent further necroposting *

ImageImageImageImageImageImageImageImageImageImageImageImageImageImageImageImageImageImage
Locked

Return to “Features Wanted”