Use these strategies to prevent attacks from within

It’s easy to focus so much on external threats to your network that you forget about the internal ones. However, there have been numerous studies indicating that the vast majority of security breaches come from within. Most good network administrators will cover the basics, such as requiring complex passwords, enabling auditing, and setting up firm policies and procedures, but that alone may not be enough. Here are some additional steps you can take to protect your network against your users.

Understanding the security threats
Before you can really protect your network, you need to understand exactly what the threats are. There are three basic ways that users can compromise your security. One way is through malicious activity. This includes intentionally hacking the system, whether to cause damage or to gain unauthorized access to a file or database. The next way is unintentionally. I have seen lots of cases over the years where users were simply trying to familiarize themselves with a system but wandered into an area they shouldn’t have. The third type of security threat is by unknowingly infecting the system with viruses, spyware, Trojans, etc.

Oddly enough, the techniques that you would use to protect against these three types of threats are very similar. For example, to prevent a user from accidentally wandering into an unauthorized area of the network, you need to constantly check to make sure that sufficient permissions are in effect. However, the same permissions that prevent accidental disclosure of information also protect against hackers and viral infections by unauthorized users.

Likewise, one way of preventing users from infecting the local system with a virus is to deny access to removable media. Doing so also guards against information theft and against users loading unauthorized software. My point is that as I share tips with you throughout this article, some tips may focus a little more toward one type of threat than another. Even so, each tip in some way protects against all three types of threats.

Terminal services
I could tell you to implement a terminal server and a bunch of thin client devices and end my article right now. That wouldn’t do a bit of good for those who are running a traditional PC environment, though. In almost every case, chucking the PCs in favor of thin client devices is the best way to protect your network from user damage. There are a couple of problems with doing this, however.

For starters, there is the cost. Although running a terminal services environment is usually cheaper in the long run, there are a lot of up-front expenses. These expenses may include software licenses, new hardware, and training for your support staff. The other problem with running the terminal services is that some software just won’t run very well in a terminal environment.

Securing the operating system
If you aren’t going with thin client devices, the first thing you should do to secure your network is to secure the operating system. I recommend moving all workstations to Windows XP with Service Pack 1. Although any operating system has security vulnerabilities, Windows XP has fewer than the other Windows desktop operating systems. Windows XP is also extremely easy to keep up to date with the latest security patches.

Simply running Windows XP, though, doesn’t mean that your users are secure. You must make sure to use the security features that Windows XP gives you. For example, if you upgrade to Windows XP from Windows ME, your hard disk will still likely be formatted with the FAT or FAT-32 file system. In order to secure the local file system, you need to convert the file system to NTFS by using the CONVERT command.

I also recommend taking a long hard look at which services are running on both your workstations and on the server. I recommend disabling any services that aren’t essential for your users. This will do two things for you. First of all, it will reduce the size of the code base that is running on your machine. There is a fundamental law of computing stating that the greater the amount of code running on a machine, the greater the chance that a security vulnerability exists within that code. Reducing the amount of code running on the machine reduces the chances of such vulnerabilities.

In addition to enhancing security, disabling unnecessary services increases performance. Remember that each running service consumes memory and processor cycles. Disabling the unnecessary services frees these resources.

One of the biggest challenges to securing a user’s machine is that security isn’t a one-time job. You can’t just set it and forget it. You have to keep checking back to make sure that a machine is still secure. From a services standpoint, one way of doing so is to implement WinTasks Professional from LIUtilities.

This software monitors the processes running on a machine (even the invisible ones) and allows you to set scripts and parameters for each process. For example, you could create a script so that if someone started an unauthorized service, the service would automatically be disabled. You can also set up a process-rule restore point. This allows you to create a template of which processes are allowed to run and how they are supposed to perform. At any time, you can restore the template and return the system to its authorized state.

Hardware devices
Another essential part of user security is to secure local storage devices. Earlier, I mentioned converting hard disk partitions to NTFS. However, you also need to take care of the local storage devices. Some people like to remove local storage devices, such as the floppy drive and CD-ROM drive. I prefer not to remove them because this only makes life difficult for the help desk when they have to work on the machine. Instead, I like using a local group policy to secure these devices.

If you open a machine’s local security policy through the group policy editor and navigate to Console Root\Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options, you will find settings for regulating local removable storage devices.

When securing local media, securing the hard disk, CD-ROM, and floppy drives are not enough. In my opinion, the piece of hardware that’s the biggest threat to security is the USB port. I say this because Windows XP automatically recognizes USB-based external storage devices. For example, when I connect my digital camera to the USB port on a machine that’s running Windows XP, the machine doesn’t prompt me for a driver, but rather automatically recognizes the camera as an external storage device. This means that it would be very easy for a user to plug a digital camera or any other USB storage device into a PC’s USB port and steal files or upload software to the machine. If you want to protect against this type of breach, disable the workstations’ USB ports.

I also recommend disabling firewire ports if the machines have them. However, at this time firewire ports aren’t as big a threat as USB ports because there are fewer firewire-based storage devices in existence.

Personal firewalls
Normally, firewalls are used to protect any machine that’s connected to an untrusted network, such as the Internet. However, personal firewalls can also be used to enhance security within a trusted environment. Think about it for a moment: You use a perimeter firewall to prevent people outside your organization from conducting port scans or from passing traffic across unauthorized ports.

However, unless you have server-level and workstation-level personal firewalls in place, there is no such protection within the organization. There is absolutely no reason why one employee couldn’t launch a port scan against another employee who is sitting in the next cube. However, personal firewalls can protect your employees from each other in the same way that a perimeter firewall protects your private network from the Internet. Keep in mind, though, that it’s equally important to place a firewall on your servers.

As you probably know, Windows XP comes with its own personal firewall. In general, the Windows XP firewall does a good job. There is just one thing that the Windows XP firewall doesn’t do that a commercial personal firewall will: The Windows XP firewall doesn’t give you much control over outbound packet filtering.

Most administrators do firewall configurations from the standpoint of not caring what goes out, as long as they are protecting against inbound traffic. However, there are certainly advantages to protecting against outbound traffic. First off, it makes it more difficult for an employee to launch a port level attack against another employee if you have blocked the outbound port on his or her machine. Second, if a Trojan or other form of adware or spyware does make it onto a user’s system, the Trojan will be unable to transmit and data from the PC unless it uses a port that you have specifically authorized.

Take advantage of user profiles
Technically speaking, group policies are what really lock down a system. Even so, I'm still a big fan of mandatory profiles. Using a mandatory desktop profile, you can remove desktop items that the user doesn’t need to access, such as the Run prompt, the Control Panel, and My Network Places.

Removing these items alone won’t completely secure the machine. However, it will be one more obstacle standing between the user and the unauthorized areas of the system. More importantly though, removing these desktop objects sends a message that your network is secure and that you don’t want the users messing with anything that they haven’t specifically been given an icon for.

Implement software restriction policies
In Windows 2000 and Windows XP, it’s possible to set up permissions to block a certain file from running. For example, if you wanted to stop someone from running REGEDIT.EXE, you could set an ACL entry that denies the Users group access to run it. Using ACL entries alone isn’t enough, though. Setting an ACL entry on REGEDIT.EXE prevents the user from running that copy of REGEDIT in that location. However, if the user can manage to copy the REGEDIT.EXE file to a floppy disk or some other non-NTFS partition, the ACL restrictions are removed. Likewise, if a user can copy REGEDIT.EXE from another machine (such as a home computer), then this copy will not have the ACL entries that prevent the Registry Editor from being run.

The solution is to upgrade your servers to Windows Server 2003. Windows Server 2003 allows you to set software restriction policies. These policies could be used to block any file named REGEDIT.EXE from being run, regardless of the file’s location.

Upgrade to Windows Server 2003
If you really want to protect against internal security breaches, then the best advice that I can give you is to upgrade all of your servers to Windows Server 2003. When designing Windows Server 2003, Microsoft claims to have made security a very high priority. There are a lot of really great security mechanisms in Windows Server 2003 that just don't exist in Windows 2000 Server.

For example, in Windows Server 2003, if a domain user does not have a password, he or she is allowed to authenticate, but he or she is not allowed to access network resources until after the account has been assigned a password. So, if a user logs on without a password, he or she will be able to access all of the normal stuff on the local machine. However, the user will not be able to map a network drive.

There are so many security enhancements in Windows Server 2003 that I could write an entire book on them. The reason I recommend performing the upgrade, though, is because so many of the security enhancements are enabled by default. For example, I already told you about the way that the system behaves when a blank password is used and how unnecessary services are disabled by default, but there is much more that you may not ever even know about unless you read all of the technical specs on the product.

In Windows 2000, for example, the network services load is followed by the security policy. This means that if you are running IPSec, then there is a period of a couple of minutes during boot up when the network services are functional, but when IPSec is not yet active. In Windows Server 2003, IPSec is initialized at the same time as the other networking services. This resolves this potential vulnerability.

Friend or foe?
It’s just as important to protect your network against attacks from within as from external attacks. While internal users may not always have the expertise of seasoned Internet hackers, they are usually at an advantage because they are already familiar with the system and have some level of access to it. This makes attacks from within just as dangerous if not more so than external attacks.

TechRepublic originally published this article on 18 September 2003.