Five ways to secure your Internal network on a low budget

When it comes to network security, we can safely assume that most of the companies make a conscious effort in securing their network perimeter. Modern network security appliances such as firewalls, IDS, IPS etc., do a good job in keeping an external attacker out, when configured in a secure manner. Having said that, two facts still stand:

1) Once physical security is breached, Internal network is usually wide open for someone to explore (explore being polite word for attack);

2) Physical security can be breached trivially, most of the times.

This blog will outline 6 configuration changes that you can make to your network in order to make it more secure. These changes are fairly straight-forward, take budget constraints into consideration and mostly apply to Windows-based environment.

1.1 Patch, but most importantly, Patch again & again

Fortunately, everyone knows that this is the first step and the most basic principal towards securing an asset on the network and in turn the network itself. Unfortunately, we still find unpatched hosts all over the network while performing an internal pentest.

Attackers most often exploit publicly known vulnerabilities and if your systems are patched appropriately, there would be nothing to exploit. Every organization must implement a patch management program and enforce it. You also wouldn’t want your critical servers to break because of a buggy patch; hence it is a good idea to create a lab environment in order to test newly released patches before rolling them out enterprise-wide.

Lastly, unlike New Year resolutions, patching is an ongoing process and must be performed at regular intervals. A good patch management policy should dictate monthly patching cycles. On a Windows-based environment, companies can make use of patch management tools such as Windows Server Update Services (WSUS), which is freely available.

1.2 Network Segregation

As already stated, most of the companies implement firewalls on their network perimeter; however we find, more than often, that the internal network is relatively flat — no segregation. This implies that if attackers compromise a host in development environment, they would be able to use it to pivot to the production environment. There is no reason for the R&D department to access the employee payroll servers or vice-versa.

A well segregated network will cut down on the potential for inside abuse and limit any potential damage if someone does gain unauthorized access to the internal network, since their access would be limited to only a small portion of the internal network. Additionally, it would be much easier to pinpoint a network event when multiple firewalls are used.

1.3 Implement Strong Password Policy

IT administrators should implement a strong password policy and enforce it. The following password complexity requirements may be considered:

• Password Length
• Minimum length of 10 characters
• Maximum length of no more than 24 characters for storage reasons
• Password Composition
• Case-sensitive passwords
• A minimum of one uppercase letter
• A minimum of one lowercase letter
• A minimum of one number
• A minimum of one special character, such as an exclamation mark
• No dictionary words or slight variants thereof, such as “P@ssword1”
• Do not allow any part of username to appear in the password.
• Password History
• Remember the last 5 passwords the user has entered.
• Require new passwords to include a minimum of one new character and disallow the use of passwords containing a fragment of the previous passwords.
• Password Expiration
• Temporary passwords should expire when a user logs in for the first time, and the user should be forced to change it immediately.
• Passwords should expire once every 45 days, with reminders issued within two weeks of expiration.

Additionally, all critical local or domain accounts should have passwords with length of 15 characters or more.

1.4 Disable LAN Manager (LM) Hash

When you set a password of less than 15 characters, Windows operating system generates both a LAN Manager hash (LM hash) and a Windows NT hash (NT hash) of the password. The LM hash is relatively weak compared to the NT hash, and is therefore prone to brute-force attacks. Once attackers have compromised a server and gained administrative privileges, they would have the ability to dump cached local and domain password hashes and crack them offline. If your enterprise also suffers from password reuse problem, which is a very common scenario, attackers would be able to compromise numerous hosts by leveraging the recovered password.

Long story short, disabling LM Hash will help your organization a long way in securing it and would make an attacker’s life relatively tough. You can trivially implement a NoLMHash policy by using a group policy or through registry edit. Straight from Microsoft’s website:

• In Group Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options.
• In the list of available policies, double-click Network security: Do not store LAN Manager hash value on next password change.
• Click Enabled, and then click OK.

1.5 Restrict Debug Programs Privilege

In addition to dumping cached Windows password hashes, it is also possible to extract clear-text passwords by leveraging LSA secrets. It involves DLL injection into the LSASS.exe process. Most of these actions require the user account to have “Debug Programs” privilege for successful exploitation.

Ideally, this privilege should be tightly controlled and only be granted to very small subset of domain users or no-one at all.

This change can be implemented organization-wide through a global security policy. The setting can be accessed through Local Security Policy à Local Policies à User Rights Assignment à Debug programs.

Other than the above-mentioned measures, it may be a good idea to invest in a disk encryption product such as BitLocker. It you are tight on budget, ensure that all the hosts on the internal network at least have a BIOS password set.

Finally, history has proved that service accounts can take down the entire empire. IT administrators must ensure that all the service accounts are configured using the principle of least privilege. They should never be part DOMAIN ADMINS group.