Security Protection Methods

HP CIFS Server provides a flexible approach to network security and implements the protocols to support more secure Microsoft Windows file and print services.

You can secure HP CIFS Server from connections that originate from outside the local network by using host-based protection. You can also use interface-based exclusion, so that SMBD binds only to specifically permitted interfaces. It is also possible to set specific share or resource-based exclusions: for example, you can set a specific denial on the IPC$ share.

You can also set access control entries (ACEs) in an access control list (ACL) on the shares to secure the HP CIFS Server.

Restricting Network Access

You can use host-based restrictions , interface-based protection, a firewall, or IPC$ share-based denials to restrict network access and secure your HP CIFS Server. This section documents the information on how to configure and use these protection methods.

Using Host Restrictions

In many installations, the threat to server security comes from outside the immediate network. By default, the HP CIFS Server accepts connections from any host, so you might want to set the hosts allow and hosts deny options in the smb.conf configuration file to only allow access to your server from a specific range of hosts.

An Example

The following configuration example allows SMB connections only from 'localhost' (your own computer) and from the two private networks, 192.168.2 and 192.168.3. All other connections are refused as soon as the client sends its first packet. The refusal message is displayed as a not listening on called name error:

hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24
hosts deny = 0.0.0.0/0

Using Interface Protection

By default, the HP CIFS Servers accepts connections on any network interface that it finds on your system. That means if you have a ISDN line or a PPP connection to the internet, then the HP CIFS server can accept connections on those links. You can use the interfaceconfiguration options to change the interface behavior.

Interface Protection Example

For example, you can change the interface behavior using options as the followings:

interface = lan* lo0
bind interface only = yes

In above example, the HP CIFS Server only listens for connections on interfaces with a name starting with lan such as lan0, lan1, plus on the loopback interface called lo0. The interface name you need to use depends on what OS you are using. If you use a LAN interface and someone tries to make an SMB connection to your host over a PPP interface called 'ppp0', he or she gets a TCP connection refused reply.

Using a Firewall

You can use a firewall to deny access to services that you do not want exposed outside your network. This can be a very good protection method, although the methods mentioned above can also be used in case the firewall is not active for some reasons.

When you set up a firewall, you need to know which TCP and UDP ports to allow. The HP CIFS Server uses the following ports:

UDP/137 - used by nmbd
UDP/138 - used by nmbd
TCP/139 - used by smbd 
TCP/445 - used by smbd

The port, 445, is important as you may not be aware of it with many older firewall setups, this port was only added to the protocol in recent years.

Using an IPC$ Share-Based Denial

You can also use a more specific deny on the IPC$ share. This allows you to offer access to other shares while denying access to a IPC$ share from potentially untrustworthy hosts.

For example, you can configure an IPC$ share as follows:

[ipc$]
hosts allow = 192.168.115.0/24 127.0.0.1
hosts deny = 0.0.0.0/0

This configuration tells the HP CIFS Server that it cannot accept IPC$ connections from anywhere but the two places listed: a local host and a local subnet. Because the IPC$ share is the only share that is always accessible anonymously, this provides some level of protection against attackers that do not know a valid user name and password for your host.

If you use this method, then clients receive an access denied reply when they try to access the IPC$ share. This means that those clients cannot browse shares and might also be unable to access some other resources

Protecting Sensitive Information

This section describes the security methods you can use to protect sensitive information.

Encrypting Authentication

You must set the encrypt password parameter to yes in the smb.conf file to ensure that encryption is used on passwords when they transmit across the network during authentication.

The HP CIFS Server accepts LM,NTLM and NTLMv2 encryption authentication methods based on client settings. NTLMv2 is the most secure. To useNTLMv2 authentication, you need to configure the following client registry keys:

[HKEY_LOCAL_MACHINE\SYSTEM\C	urrentControlSet\Control\Lsa]
"lmcompatibilitylevel"=dword:00000003

The value of 0x00000003 means to sendNTLMv2responses only.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"NtlmMinClientSec"=dword:00080000

The value0x00080000 means to permit only NTLMv2 session security. If either theNtlmMinClientSec or NtlmMinServerSec option is set to 0x00080000, the connection fails if NTLMv2 session security is not negotiated.

You can also use the Lightweight Directory Access Protocol (LDAP) for authentication. To prevent plain text password transfer with LDAP directories, you can configure Secure Socket Layer (SSL) on your systems and enable HP CIFS Server with SSL. For detailed information on how to enable SSL communication over LDAP, see Chapter 6 “LDAP Integration Support”.

The HP CIFS Server accepts the highly secure Kerberos tickets for Windows 2000 Active Directory configurations.

Protecting Sensitive Configuration Files

The default permissions for HP CIFS Server configuration files have been carefully selected to ensure security while providing appropriate accessibility. However, you need also to protect these configuration files from unauthorized access. Be especially careful if you decide to locate them in alternative directories.

Table 6-1describes a list of commonly used configuration files and their default locations. There are also many smb.conf configuration parameters which permit alternate locations for these files and many parameters that result in additional configuration files or scripts controlling run-time actions not mentioned here.

Configuration File

Table 10-1 Configuration Files

File	Description
`/etc/opt/samba/smb.conf`	Master configuration file
`/var/opt/samba/log.*`	Log files
`/var/opt/samba/locks/*.tdb`	Database files containing important internal run-time information
`/var/opt/samba/locks/*.dat`	Data files containing system name and addresses
`/var/opt/samba/locks/*.pid`	Master daemon process ID files used for starting, stopping, and clustering scripts
`/var/opt/samba/private/*.tdb`	Database files containg important internal run-time information
`/var/opt/samba/private/smbpasswd`	Data file containing user name and password information
`/var/opt/samba/private/passdb.tdb`	Data file containing user name and password information

You need to be aware that the smbpasswd -w command stores the LDAP administrator's user and password in the /var/opt/samba/private/secrets.tdb file in plain text.

Using %m Name Replacement Macro With Caution

The NetBIOS name of remote clients is substituted into the "%m" macro wherever it occurs in the smb.confconfiguration file. The use of contrived NetBIOS names may result in Samba using a file path outside of the intended Samba directories. This can be used to cause Samba to append data to important system files, which in turn can be used to compromise security on the server.

An immediate fix is to edit your smb.conf configuration file and remove all occurrences of the macro "%m". Depending on the requirements of each site, other smb.confmacros may be suitable replacements.

The log file option is the most vulnerable to this redefinition problem. The sample configuration file contains the path,/var/opt/samba/log.%m. Using this default path does not create a vulnerability unless there happens to exist a subdirectory in /var/opt/samba which starts with the prefix "log.".

If you choose to maintain the use of the "%m" macro in thelog file option, you should use the default value, /var/opt/samba/log.%m.

Restricting Execute Permission on Stacks

A common method of breaking into a system is by maliciously overflowing buffers on a program's stack, such as passing unusually long command line arguments to a privileged program that does not expect them. Malicious unprivileged users can use this technique to trick a privileged program into starting a superuser shell for them, or to perform similar unauthorized actions.

One effective way to reduce the risk from this type of attack is to remove the execute permission from the program's stack pages. This improves system security without impacting performance and has no negative effects on the majority of legitimate applications.

The HP CIFS Server does not require execution on the stack. While the HP CIFS Server attempts to prevent buffer overflow possibilities, you can set the HP-UX kernel tunable parameter, executable_stack , to disallow stack execution to provide a layer of protection from malicious attacks. For details, refer to man pages for chatr.

Restricting User Access

In addtion to authentication services, the HP CIFS Server provides the configuration parameters, valid users and invalid users, in the smb.conf file, which you can use to further restrict access to your CIFS server. You can configure the admin users parameter to provide administration capabilities only to the users listed with this parameter, to restrict its use.

For example, you can configure the valid users option in the smb.conf file as follows:

[global]
valid users = @smbusers, jack

This restricts all server access to either the user, jack, and to members of the system group, smbusers.