From wsantos@redhat.com Thu Aug 20 11:31:38 2015 From: Willy Santos To: scap-security-guide@lists.fedorahosted.org Subject: Re: [PATCH] Added more NFS prose. Date: Mon, 16 Jul 2012 09:06:44 -0400 Message-ID: <500411E4.9070500@redhat.com> In-Reply-To: <5001CF83.1040606@eclipse.ncsc.mil> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3004104301874031240==" --===============3004104301874031240== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That's correct. On 07/14/2012 03:58 PM, Jeffrey Blank wrote: > ACK. I believe this will pretty much round out the NFS guidance from > previous sources such as the NSA RHEL 5 Guide and also the DISA RHEL 5 > STIG, right? > > (There might be more that should be said, but this should ensure we've > included some relevant previous work.) > > > > On 07/13/2012 04:48 PM, Willy Santos wrote: >> Signed-off-by: Willy Santos >> --- >> RHEL6/input/services/nfs.xml | 50 ++++++++++++++++++++++++++++++++++++= +---- >> 1 files changed, 45 insertions(+), 5 deletions(-) >> >> diff --git a/RHEL6/input/services/nfs.xml b/RHEL6/input/services/nfs.xml >> index 1d20041..7f5e049 100644 >> --- a/RHEL6/input/services/nfs.xml >> +++ b/RHEL6/input/services/nfs.xml >> @@ -256,8 +256,8 @@ can leave your NFS configuration more open than intend= ed. Therefore, exercise ca >> the file. >>

>> The syntax of each line in /etc/exports is >> -
/DIR	ipaddr1(opt1,opt2) ipaddr2(opt3)
>> -where /DIR is a directory or filesystem to export, ipaddrN is an IP address, netblock, >> +
/DIR	host1(opt1,opt2) host2(opt3)
>> +where /DIR is a directory or filesystem to export, hostN is an IP address, netblock, >> hostname, domain, or netgroup to which to export, and optN is a= n option. >> >> >> @@ -280,20 +280,60 @@ Authorized hosts can be specified in several differe= nt formats: >> >> >> =20 >> + >> +Export Filesystems Read-Only if Possible >> +If a filesystem is being exported so that users can view the= files in a convenient >> +fashion, but there is no need for users to edit those files, exporting th= e filesystem read-only >> +removes an attack vector against the server. The default filesystem expor= t mode is ro, >> +so do not specify rw without a good reason. >> + >> + >> + >> + >> +Specify UID and GID for Anonymous Connections >> +When an NFS server is configured to deny remote root access, a selected UID and GID >> +are used to handle requests from the remote root user. The UID a= nd GID should be chosen from the >> +system to provide the appropriate level of non-privileged access. By defa= ult, the NFS server will >> +map remote root users to the nobody local account. Spec= ifying the anonymous UID and GID >> +as -1 ensures that the remote root user is mapped to a local acc= ount which has no permissions on the >> +system. >> +

>> +To specify the UID and GID for remote root users, edit the /= etc/exports file and add >> +anonuid=3D-1 and anongid=3D-1 to the options list for e= ach export. >> + >> + >> + >> >> Use Root-Squashing on All Exports >> If a filesystem is exported using root squashing, requests = from root on the client >> are considered to be unprivileged (mapped to a user such as nobody). Thi= s provides some mild >> protection against remote abuse of an NFS server. Root squashing is enab= led by default, and >> should not be disabled. >> - >> -Ensure that no line in /etc/exports contains the option no_r= oot_squash >> +

>> +Ensure that no line in /etc/exports contains the option no_r= oot_squash. >> >> -If the NFS server allows root access to local file systems fro= m remote hosts, this access could be used to compromise the system. >> +If the NFS server allows root access to local file systems fro= m remote hosts, this >> +access could be used to compromise the system. >> >> >> >> =20 >> + >> +Restrict NFS Clients to Privileged Ports >> +By default, Linux=E2=80=99s NFS implementation requires that= all client requests be made >> +from ports less than 1024. If your organization has control over machines= connected to its >> +network, and if NFS requests are prohibited at the border firewall, this = offers some protection >> +against malicious requests from unprivileged users. Therefore, the defaul= t should not be changed. >> +

>> +Ensure that no line in /etc/exports contains the option inse= cure. >> + >> +Allowing client requests to be made from ports higher than 102= 4 could allow a unprivileged >> +user to initiate an NFS connection. If the unprivileged user account has = been compromised, an >> +attacker could gain access to data on the NFS server. >> + >> + >> + >> + >> >> =20 >> --===============3004104301874031240==--