[Samba] Locking down RPC services for a standalone server

[Andrew Bartlett]

On Sat, 2017-09-02 at 11:44 -0400, Maxim Khitrov via samba wrote:
> Hi all,
> 
> After CVE-2015-0240 (remote code execution in netlogon), I would feel
> more comfortable if my server wasn't providing any services that
> aren't strictly required, but I couldn't find much documentation for
> rpc_server, server services, and similar directives that explains
> which services are needed for various configurations.

I totally agree.  It was much later than I hoped, but for 4.7 I finally
made NETLOGON go away unless we are a DC.

> I'm running a standalone Samba 4.6 file server on FreeBSD 11.1. No
> domains, printing, DFS, or anything else like that. From my own
> testing, it looks like I can disable all RPC services except for
> srvsvc (Remote Server Services). Are there any others that might be
> required? Am I asking for trouble with such configuration (or just
> wasting my time)?

disable spoolss = yes

(I note your comments below)

> I also tried playing with the "server services" directive, but
> everything kept working even if I just specified "server services =
> s3fs" (no rpc), which seems odd. I'm guessing that rpc is enabled no
> matter what and the rest aren't needed?

Sadly that only applies to the AD DC at this time.

> My current configuration is below. Any other suggestions for improving
> security would be most welcome.

The tricky part is that really, what we need is to disable most of
SAMR, most of LSARPC etc, but not all of them.  The problem is, without
SAMR you can't change a password (as a user) to a standalone file
server, without LSA you can't lookup the SIDs of a security descriptor
into names.  But both of these protocols are large and complex, and
mostly used for the DC case.

The challenges then becomes proving a negative, that the elements being
disabled were not in use for the simple file server.  The reason the
netlogon disabling took so long is that I (rightly) got pushback about
changing it shortly before a release.  

I eventually used the proof that Apple didn't support it as my
justification, so we would only be as broken as a Mac.  

But we DO need to do this, and ideally at compile-time, not just to
make the binary smaller, but so that vendors can say hand-on-heart that
the future security issue was simply not compiled on their platform. 

Thanks,

Andrew Bartlett

> -Max
> 
> [global]
> 
> # Protocol settings
> client min protocol = SMB2
> host msdfs = no
> restrict anonymous = 2
> server min protocol = SMB2
> smb encrypt = required
> unix extensions = no
> workgroup = EXAMPLE
> 
> # Service defaults
> csc policy = disable
> directory name cache size = 0
> map archive = no
> store dos attributes = yes
> strict sync = yes
> 
> # max open files defaults to kern.maxfilesperproc, but has a hard-coded limit of
> # 65536 - FILE_HANDLE_OFFSET(4096) - MAX_OPEN_PIPES(2048).
> max open files = 59392
> 
> # Disable NetBIOS
> disable netbios = yes
> smb ports = 445
> 
> # Disable printing (keep spoolss enabled to avoid warnings on each connection)
> load printers = no
> printcap cache time = 0
> printcap name = /dev/null
> 
> # Disable unnecessary RPC services
> rpc_server:epmapper = disabled
> rpc_server:winreg = disabled
> rpc_server:lsarpc = disabled
> rpc_server:samr = disabled
> rpc_server:netlogon = disabled
> rpc_server:netdfs = disabled
> rpc_server:dssetup = disabled
> rpc_server:wkssvc = disabled
> rpc_server:spoolss = disabled
> rpc_server:svcctl = disabled
> rpc_server:ntsvcs = disabled
> rpc_server:eventlog = disabled
> rpc_server:initshutdown = disabled
> rpc_server:mdssvc = disabled
> 
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba