Guide for Securing File Server

How hardened is your organization’s file server to protect data from unauthorized access? Every organization running a file server needs to have a way of protecting sensitive information from unauthorized access, especially from outside.

The fact that your server may be in a physically secure place does not mean the security configurations within the operating system should be ignored and the system left at the mercy of anyone with an access to the building.

The file server being the most visible and central network device with critical information should be secured using some of the approaches this guide proposes. System administrators should use the hacker’s point of view when reviewing security policies to help them find a better approach to server security settings.

The Guide

Securing a file server ensures that the organization enjoys the fill benefits of a server in its opium working condition. Here are some of the steps one needed to enforce server security settings.

1. The configuration of the operator group
Instead of using the default Administrators group, another group of people (user accounts) authorized to access the server using different access levels should be created. The default administrator account should be used as the final resort.

Operator Group can be defined by different tasks users are assigned as far as modifications of security settings are concerned. To perform this task, open the Organizational Unit and remove unwanted groups, but retain the default Domain Administrators. Create the Operators Group and give Full Control to both Domain Administrators and Operators group.

2. Create A Security Template
By the time you sit down to secure the File Server, you must already be having security settings that can be used on the network or in a standalone environment. Security setting templates can be created and then be imported into group policy to be implemented across the entire network.

The security templates need to be flexible in that when more than one is applied to the same server, there should never be a conflict.

Setting Account Policies
Account policies are settings that have to do with Passwords, Account Lockout, and Kerberos Policy. All policies should be applied at the domain level. For a standalone file server, the local accounts are used to access it, therefore security settings of these accounts need to be set up.

Other settings include:

• Increasing the minimum password length – long passwords mean that the hacker longer time to crack local account passwords.
• Decreasing maximum password age – reducing the aging date of a password means more frequent password changes, therefore, increasing the integrity of local user accounts.
• Account lockout duration – this setting determines the lockout period a person has to wait to re-enter the password. A ‘0’ setting means the user logged out until password reset and a ’30’ means attackers will have to wait longer to key in more attempts.

Setting the Local Policies
Under local policies, system administrators need to look at the Audit policies, user rights, and security options.

• Audit Policy
  Turing on the Audit Policy setting is an indication that the files, registry, folders, and printers can be tracked. This gives the administrators the freedom to choose which objects to log and the level of monitoring to use. In a high-security environment, knowing who is responsible for what activity is paramount, therefore auditing privileges is required when securing the File Server.
• User Rights
  When setting user properties on a local machine, rights such as “Act as part of the operating system” should be disabled.
• Security Options
  Some default settings under this option can be used to tighten the security levels of a file server. Some of these defaults may not work with all Server Operating Systems, therefore testing before implementation is recommended.

Settings on Services
Services not installed should be disabled and a person responsible for starting, stopping, and disabling them identified. There are two specific services that can be applied in specific scenarios: Distributed File System (DFS) and File Replication Service (NTRFS).

The DFS works on local disks, shared across networks, therefore in such a scenario, disabling DFS means that users must know the names of the shared resources and servers on the network. NTRFS controls the automatic maintenance of files across multiple servers and it must be on Active Directory and Domain Controllers.

3. Determine the Template Application Strategy
Security templates can be imported to Group Policies and the domain so that they can be shared across multiple workstations and can be refreshed as needed. When dealing with workstations, security policies can be set using the /secedit/ command and the batch files re-written to refresh the settings.

4. Set up Restricted Groups
Make use of the Local Group Policy to restrict group activities. Local Administrators and any group that was created can be restricted. New users can be added to the restricted groups. Restricting administrators who can change system settings prevents unauthorized access.

5. Write IPsec Policies
Setting IPsec rules that block certain or all ports by applying specific filters to allow only communication from specific computers will guarantee File Server security. When left open, File Servers share information through various protocols that would-be attackers will find useful.

6. Set the Correct System
The correct time is critical for many reasons. Some authentication protocols need the client and server clocks to be synchronized. Synchronizing events between computers on a network will not take place due to time differences. When reading logs, the time stamp is important for auditing purposes.

7. Set Specific Account Restrictions
Restrictions can be implemented on individual accounts by limiting the hours, restricting which workstation a particular user an use, prevent account delegation, etc.

8. Setting the Local Server Security Settings
Settings that cannot be automated in a domain such as Guest user account and Guest group have unique identifiers that make it difficult to have an automated security setting. In such scenarios, setting local policies is necessary.

9. Track Attack Indicators
Events with warnings such as ‘Logon Failure’ and an increasing number of similar events should be treated as unauthorized attempts.

10. Using the Network File System (NTFS)
Setting the Access Control List (ACL) and the System Access Control List (SACL) on FAT volumes is not possible. File Server security depends on its ability to have security settings done as file permissions.

11. Use of Administrative Template Settings
Some security settings are not available in security template settings. They can only be set via the Administrative Templates within the Group Policy. Disabling error reporting at this stage is recommended because some error logs contain sensitive information that can be intercepted by hackers.

12. Documenting and Maintaining the Security Settings
When server security settings need to be altered, previous settings can be used as a reference point. Third-party tools such as Security Configuration Analysis can be used to verify the compliance of the security settings in place.

Conclusion

The security settings above are supposed to make the File Server secure. However, when doing so, make sure the settings do not interfere with server’s normal operations. Since every network setup is unique, it is recommended that File Server security setting is set up according to the needs and expectation of the organization.

Are your Windows folders secure, too?

Protect yourself and your clients against security leaks and get your free trial of the easiest and fastest NTFS Permission Reporter now!