Restrict Access to Your Network

Restrict Access to Your Network

The restriction stage is where we get to throw switches and turn on security tweaks! This is where we can now start putting protective measures in place to mitigate the faults we discovered during the documentation stage and to enforce the segmentation we designed in the segmentation stage. There is a very simple rule here: If it is not required, turn it off. The network should present the smallest attack surface possible (the fewest features and systems needed to fulfill its function). This can be accomplished through a variety of means, including the following:

• Turning off unneeded functionality

• Removing users

• Restricting user privileges

• Removing security dependencies

• Removing permissions

• Setting very strong passwords

• Turning on security tweaks

• Filtering traffic

Each of these steps provides some measure of defense in depth. Appendix A, "How to Get Your Network Hacked in 10 Easy Steps," lists instructions for how to get your network hacked. The corollary to those steps is obviously to do the things that attackers do not want you to do. The things we do to mitigate the threats in our threat model generally fall into one of those 10 categories. It is important, however, that each of these steps corresponds to the threat model that we have just finished building. Simply making security changes without a threat model is much more likely to destabilize the system than it is to actually provide any improvement in security.

For example, we have reviewed a very large number of "security configuration guides." Most of these are just lists of security tweaks that some "expert" or group thereof thought were important. They have ranged from very good through mediocre, with most ending up somewhere in the " damaging " range. By way of example, one of the most commonly used guides for Windows 2000 recommends that you configure security on the config.sys file to prevent "untrusted' users from accessing it. What security do you gain from this? Well, config.sys is not actually used under Windows 2000, so it would seem to pose very little threat. In addition, the default permissions on it allow Administrators and Local System full control and users read permissions. Exactly what damage users are going to cause by reading this file is not immediately clear. Finally, there is no way for users to get to the file unless they are logging on interactively to the machine. Config.sys sits in the root directory of the boot partition, and users do not have any way to access that file remotely. When we pointed this out to the authors of the guide in question, we were told this was a "defense- in-depth " measure. Unfortunately, defense in depth has often come to be synonymous with "stuff we thought was a good idea but could not think of a credible threat for." That is not what it should be. Defense in depth, as discussed in Chapter 1, "Introduction to Network Protection," means that if one security mechanism fails, the threat it counters is still mitigated by some other mechanism. The config.sys file poses no threat. Why secure it? We strongly believe changes, modifications, tweaks made without some measurable threat are destined to cause more harm that good, if not from a usability position then from a support ability or system recovery position.

Deciding the actions to take are not easy. Each of the steps listed in Appendix A is discussed at some point in the book and all are demonstrated in Chapter 2. A few deserve special mention in this chapter, however. We start with security tweaks, not because it is the most important (it is not), but because it is one that many people recognize as the first critical step.

Security Tweaks

There are hardening guides out there which spend hundreds of pages discussing security tweaks that you "must" implement to be safe, such as the previously mentioned config.sys file. In actuality, only a few security tweaks are truly useful. In Chapter 12, "Server and Client Hardening," we discuss server and client hardening in depth and cover the things that really make a difference and that almost anyone can turn on with no ill effects. We also go through the ones with which you should be extremely careful.

Filtering Traffic

In contrast to security tweaks, one of the single most important steps you can take to protect your network is to filter the traffic going into and out of it as well as the traffic you allow inside. As you saw in Chapter 2, the first thing an attacker needs to do after he compromises a system is to get the appropriate tools onto the system. Unless the attack that was used to compromise the system provides a built-in way to get the tools onto the system, the attacker will need to either upload the tools directly or get the system to do it for him. If you properly filter the traffic into and out of the system, this becomes considerably harder. For instance, consider an SQL Server providing data to a Web server as in our earlier example. If the SQL Server will only accept inbound connections from one management system on TCP port 3389 and from the Web server on TCP 1433, and it can only initiate connections to the domain controller, how will an attacker get the tools onto it?

Filtering traffic can be done either on the server itself, using IPsec policies, or using some kind of intermediate device, such as a firewall or filtering router. The rule of thumb is "filter early, filter often." Ideally, traffic should be filtered using both methods . This provides additional defense in depth, and the additional management overhead from doing so is negligible after the policies have been developed and implemented. This way if the server itself is compromised and the attacker can run arbitrary code on it to turn off the filters, the router provides an additional layer of defense. If, on the other hand, the router is compromised, at least there is a better chance that the server will be able to defend itself.

What traffic should be filtered? All of it. You should not allow any traffic to and from a system that is not absolutely necessary for the operation of that system. On a server, that is usually a very limited set of protocols. Most servers are single-purpose systems, or at the very least, they should be single-purpose systems. Unfortunately, there is this "cost-savings" move called "server consolidation" in place right now. If done improperly, this means you have multipurpose servers which are almost impossible to protect. Server consolidation can be done in a way to minimize these problems though. One method is to use a very large server with multiple network interface cards (NICs) and a virtual machine software running on top of a bare-bones operating system. Then you can run different single-purpose virtual servers on top and bind each to a separate NIC or set of NICs. Although this does not provide the same level of protection as separate servers, it is considerably better than building multipurpose servers.

Workstations, or clients , are also important to consider here. Think back to any of the worms we have seen in the past several years . Most of them, such as Blaster, Sasser, Slammer, etc., spread through workstations. More specifically , they spread through workstations that were infected off the network and then spread the infection on the internal network after they were reconnected. Now think about how serious these outbreaks would have been had the workstations not been able to talk to each other. Workstations should speak to servers, but far too often they are free to connect to other workstations as well. Using IPsec policies, you can put together a security policy that turns workstations into proper clients, allowing them to send requests to servers and receive data back from those requests. A client should not respond to generic requests from other systems. If such policies had been in effect when Blaster came out, the impact of the worm would have been a fraction of what it was.

Using Windows Firewall Inside a Network

In Windows XP Service Pack 2, the built-in firewall was enhanced to make it a very nice firewall for use on internal networks. You should consider turning the firewall on even when client systems are on the internal network. This will still allow them to communicate with servers, but it will turn them into black holes as far as everyone else on the network is concerned . Of course, you still want to be able to manage them, so you would want to use the management exceptions. One very handy way to do that is to open up the authenticated IPsec bypass. It creates a hole in the firewall that allows any IPsec-authenticated traffic through. Then you configure the management systems to speak IPsec to the clients, and you can now manage them as if nothing had happened .

For more information on the enhanced firewall in Windows XP Service Pack 2, see http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/xpsp2man.mspx.

Having said all this, there are some things you need to consider. Generally, requiring IPsec for all traffic within a domain is unsupported because client-to-DC traffic using IPsec is not (yet?) supported. That does not mean it cannot be made to work, just that it is not a supported deployment scenario. (In other words, it is a much more exciting deployment scenario than what we usually recommend!) There are two problems with this scenario. The first is to determine what settings you need to configure to allow ordinary domain traffic to actually work. The second is to bootstrap (provision) these settings onto new clients. Obviously, if IPsec is used for all client-DC communication, it is pretty difficult to add a client to the domain because it will not yet have the requisite information to establish a security association with the DC. Table 9-1 will help you solve the first problem. It enumerates the traffic that normally needs to happen in a Windows domain and what its protocol needs are. Using this table as a baseline, you can develop an IPsec policy for your domain. Even if you follow the settings in Table 9-1, you will still have bootstrap problems. However, in some environments, you may want to accept the bootstrap problems in return for additional security. That decision can only be made in light of your threat model.

Table 9-1. Windows Domain Controller Traffic

Service	Purpose	Protocol	Source Port	Destination Port	Source Address	Destination Address	Action	Mirror
CIFS/SMB server	Windows file sharing, Group Policy download, other file-sharing services and remote management. Note here that you should only allow inbound SMB to systems that should act as servers from systems that should be able to usethose services. For instance, unless you really want clients to be able to communicate with each other, you should block CIFS from clients to clients, but allow CIFS from clients to servers and from management consoles to other clients. This can be done, for example, by deploying IPsec policies to require authenticated connections from a particular subnet or set of subnets and blocking traffic from all other networks. As long as the servers that need to communicate are clustered onto a small number of subsets , we can implement such a policy with a minimal number of rules.	TCP	Any	445	Any domain member	Me	Allow	Yes (if you want to allow systemto initiate outbound SMB traffic).
	Same	UDP	Any	445	Any domain member	Me	Allow	Yes (if you want to allow system to initiate outbound SMB traffic).
RPC server	RPC endpoint mapper. RPC is used for much domain traffic, including DC-DC replication.	TCP	Any	135	Any	Me	Allow	Yes (for systems that need to initiate RPC connections as clients). On sensitive systems, you may want to lock this down to only a few systems.
NetBIOS server	NetBIOS is, strictly speaking, not needed in a pure Windows 2000 or higher domain. It was used in prior versions for Windows file sharing. If you do not have any down-level systems, you may disable NetBIOS because all Windows file sharing should now take place over TCP/UDP 445 instead.	TCP	Any	137	Any	Me	Allow	Yes.
	Same.	UDP	Any	137	Any	Me	Allow	Yes.
	Same.	UDP	Any	138	Any	Me	Allow	Yes.
	Same.	TCP	Any	139	Any	Me	Allow	Yes.
Monitoring client	This traffic is needed if you use MOM to monitor your network. It allows the MOM server to see the clients.	Any	Any	ANY	Me	MOM server	Allow	Yes.
Terminal Services server	Open this hole only on systems that should serve as terminal servers.	TCP	Any	3389	Any	Me	Allow	Yes (if you want the system to be able to initiate Terminal Services connections).
Global Catalog server	All forest members need to reach the Global Catalog server at some point.	TCP	Any	3268	Any	Me	Allow	Yes.
	3269 is used for SSL-based Global Catalog traffic. If you do not use SSL on your domain, you will not need this hole.	TCP	Any	3269	Any	Me	Allow	Yes.
DNS server	Ports 53 TCP and UDP must be open on your DNS server to allow the clients to resolve host names .	TCP	Any	53	Any	Me	Allow	Yes.
		UDP	Any	53	Any	Me	Allow	Yes.
Kerberos server	All domain controllers must accept Kerberos traffic in order to authenticate clients.	TCP	Any	88	Any	Me	Allow	Yes.
		UDP	Any	88	Any	Me	Allow	Yes.
LDAP server	All searches and lookup traffic in Active Directory happens over one of the LDAP ports.	TCP	Any	389	Any	Me	Allow	Yes.
		UDP	Any	389	Any	Me	Allow	Yes.
	If you configure your domain to use LDAP over SSL, you need to also leave port 636 open because it is used for LDAP over SSL.	TCP	Any	636	Any	Me	Allow	Yes.
		UDP	Any	636	Any	Me	Allow	Yes.
NTP server	Time synchronization in a Windows domain is done via the Network Time Protocol, NTP.	UDP	Any	123	Me	Me	Allow	Yes.
		UDP		123		Me
Predefined RPC range	Windows heavily uses RPC and DCOM for client-server communications. Because RPC ports are allocated at runtime, RPC is an inherently unfriendly protocol to secure. However, you can make substantial progress by confining it to a smaller port range and then allowing access only to those ports in the firewall. See Knowledge Base article 300083 for more details.	TCP	Any	Some custom, small range of ephemeral ports. (Typically, you do not need more than 20 or 25 ports allocated.)	Any	Me	Allow	Yes.
DC comms	Because domain controllers all have the same basic security requirements, you may as well allow them unfettered communications. This prevents having to determine the minimum set of ports to open for DC communications.	Any	Any	Any	Me	Domain Controller 1	Allow	Yes.
DC Comms		Any	Any	Any	Me	Domain Controller 2	Allow	Yes.
ICMP	ICMP, particularly ICMP echo, is used for a number of things in Windows domains. You will need to allow ICMP to allow systems to get heartbeats on each other.	ICMP	Any	Any	Me	Any	Allow	Yes.
All inbound traffic	Everything that is not defined as good in the rest of the table is bad, and should be blocked.	Any	Any	Any	Any	Me	Block	Yes.

Preventing Outbound Connections to Protect the Network

One particular type of network filter is so important that it merits its own section. We must not ever lose sight of the fundamental fact that the vast majority of servers do not need to initiate outbound connections. For instance, a Web server does not need to make outbound Web connections. It is a server, not a workstation. If we do not allow using it as a workstation, we can block a lot of workstation functionality. This will be instrumental in containing an attacker because outbound connections to untrusted hosts are very frequently used to get attack tools onto a system. Preventing those outbound connections may very well be what stands between compromise of a single system and compromise of a complete network. You should never allow any traffic to emanate from a server that is not absolutely essential for that server to fulfill whatever role it serves. Your threat model should already document what traffic that includes. Your filters simply need to enforce it.

Another variant of these outbound filters involves filtering outbound traffic that should never under any circumstances be allowed to leave your network. In particular, most networks are not configured to block traffic from leaving the network unless it claims to have originated within the network. Many SYN-floods (DoS attacks using an extremely large number of TCP-connect requests) use spoofed source packets. If every network implemented egress filtering, such traffic would be traceable to the source, enabling law enforcement to much more easily track down offenders while simultaneously reducing the volume of DoS attacks.