Identifying exploitable security flaws is the first step in conducting a security audit of your network. My previous article showed how to assess your network security and included examples of some tools that can help you test for vulnerabilities. Now, I will show you how to fix some of the common flaws and shortcomings you probably discovered during your security assessment.
In the assessment article, I mentioned using a tool called L0phtCrack to test the strength of the passwords on your Windows systems. If, during your assessment, you made use of this and/or similar tools and found out that a bunch of your users use “password” as their password to Windows, NetWare, and/or UNIX servers, you obviously have a major security problem on your hands—especially if these users access internal services from outside the network. A potential attacker would literally need just three seconds to crack that password and obtain valid user credentials.
First, it’s important to keep in mind that security is made up not only of technology but also of organizational policies. If you don’t have a password policy in place, now’s the time to implement one. Your policy should define its purpose to the organization, explain the password requirements to users, provide examples of both good and bad passwords, and discuss the actions that will be taken if the policy is ignored.
Honestly, some users won’t like the fact that it seems like they’re being told what to do. I recently implemented a new password policy at my organization and endured a bit of push back and joking about it. But in the end, I had already secured the sign-off of the executive officer and CFO, so the policy was going to be put into place. It’s always important to make sure that you have the support of senior management on issues such as this that directly affect users. Here is an example of how to create a password policy, and here are some tips for password combinations that are secure and easy to remember.
To implement a secure password policy, you should ensure that your operating system requires secure passwords. Using a Windows NT system, this means installing Passfilt.dll functionality, which will allow you to enforce strong passwords at the user level. If a user attempts to create a new password that does not meet the requirements, he or she will be forced to choose a new one.
In Windows 2000, this functionality is built into the operating system and is accessible by use of a group policy object. You can manage this by choosing Start | Programs | Administrative Tools | Active Directory Users And Computers. Right-click on the domain object and choose Properties. Double-click Default Domain Policy and then choose Default Domain Policy | Windows Settings | Security Settings | Account Policies | Password Policy and make any changes to match your password policy. Make sure that you enable this group policy when you are done.
On UNIX, you can replace the passwd program with an enhanced version that enforces a password policy. One such utility is called epasswd. To audit UNIX user passwords, you can use a utility like Crack, which performs a function similar to L0phtCrack.
Get rid of the defaults
One common security hole is created by the sample scripts and default passwords that come with many devices and software. The problem is simple: People keep the samples and the defaults and never change them! For example, Microsoft’s Internet Information Server software comes with a sample site as well as an administration site. Both of these can create potential problems, and they should be removed before a Web server is put on the Internet.
Likewise, any hardware or software service that comes packaged with a default administrative password is ripe for exploitation if the administrator fails to change it. Consider making it a standard business practice to change passwords on new hardware and software before it is put into use.
Cut unneeded access and harden servers
As a part of your security assessment, you should have run a comprehensive scan of your firewall (or even blatantly attacked it during nonproduction hours) to see what is allowed through. If you scanned with a tool such as ISS’s Internet Scanner, you may have a report that details exactly what is open on your firewall. Compare this to your firewall configuration to be sure that it makes sense and then carefully map out what every open port is used for. For example, maybe you have a port open to a mail server for SMTP traffic. On your security report, note that and move on to the next one. For any TCP or UDP holes you can’t identify, close the port using your firewall’s management tools.
Beyond that, consider carefully limiting what type of traffic is allowed at the server level. Many organizations have implemented excellent firewalls but keep their servers wide open since they reside behind the firewall and appear to be safe from attacks. Although they may be safe from outside attacks, networks are becoming more interconnected every day, so it is important to protect from internal attacks as well. This article from CNET News illustrates why it is becoming more important to consider the internal network as untrusted territory.
A variety of tools can help you harden your servers against an attack from the outside or the inside, including iptables for UNIX and the IIS Lockdown Tool for Windows Web servers. The iptables tool providesa firewalling service to UNIX machines and can make them extremely difficult to attack, assuming that other services are appropriately configured.
Windows system administrators should also take advantage of the Microsoft Baseline Security Analyzer (MBSA) tool, which looks at Windows servers and certain applications to determine whether they need to be patched. MBSA checks Windows NT 4.0, Windows 2000, Windows XP, Internet Information Server (IIS) 4.0 and 5.0, SQL Server 7.0 and 2000, Internet Explorer (IE) 5.01 and later, and Office 2000 and 2002. Personally, I wish that Microsoft would consider adding Exchange Server to this list, since it is the source of a great many problems for Windows admins.
Disable dangerous services
Many systems come with a set of basic services installed that the vendor thinks most users will need. For example, the ‘r’ services on UNIX, including rsh, rexec, rwho, and rlogin, come to mind. If you are running a public server, such as an Apache Web server, these services can be very dangerous since they provide system interaction and command execution from a remote host. They may be convenient, but for a public server, they are dangerous and usually not needed or easily replaced with more secure tools. You should consider removing them from your system.
To disable UNIX services that interact with the network, you can modify the contents of the inetd.conf or xinetd.conf file, depending on what UNIX variant you are using. Simply comment out the lines of services you are certain you don’t need.
On Windows 2000, IIS is a default installation option. If you don’t plan to use the Windows server with a service that requires IIS (such as Web services or Microsoft Exchange), don’t install it. If it is already installed, remove it using the Control Panel.
It’s advisable to go through every service on your systems to determine whether it is needed. Remember: Every service that is running is another potential point of attack.
This security lockdown review is certainly not comprehensive, but it should give you some ideas about where to begin to clean up after your security assessment. Much of this information is likely to be familiar to people who have been working in security or administration for some time. But those new to the fields or those looking for ways to decrease the work related to security should find these tips quite useful.