How to build a secure Enterprise Firewall?

Firewalls and their architecture are a critical part of sound network security, but they are only the beginning to a secure enterprise network. In this paper, we will cover the fundamentals of good firewall design using a single multi-homed firewall design with stateful failover. The end result will be a network that is simple to manage, high performance, high availability, high security, and budget saving.

What is the most important aspect?

There has been some fierce debate in design philosophy on whether it is best to have one brand of firewall or more. I personally subscribe to the idea that two are usually not better than one because firewall vulnerabilities are rarely the problem in vast majority of break-ins. Hackers typically don’t need to hack the firewall because they come in through the ports that are already open and exploit the weaknesses on the servers behind the firewall. Additionally, there usually is nothing there for the hacker to hack on the firewall, because any smart administrator will lock that firewall down to drop all connections to the firewall it self except for the designated firewall management stations. Even if for example there is a known vulnerability in Apache or SSH on your firewall, the threat can only come from the designated management stations which are well protected or even turned off

1. Human factors comprises 99% of all firewall compromises
2. The cost of running multiple vendor firewalls may even force you to give up on the very things you need to be most concerned about.
3. Finite resources are usually much better spent hardening a single platform.
4. The biggest problem in firewall security is poor maintenance, bad policy and bad network design

Firewall design goals:

A good firewall policy and network design can mitigate (but not eliminate) the following security risks:

• The Internet attacking your DMZ servers
• Any part of your network attacking the Internet
• Your users or servers attacking your DMZ servers
• Your DMZ servers attacking your users, servers or even further harming them selves
• Threats from business partners and extranets
• Threats from remote offices via WAN connections

The first point is rather obvious; simply by limiting the service port access from the Internet to your DMZ servers, you can greatly reduce the chances that they will be hacked. On an SMTP mail server for example, only TCP port 25 is permitted from the Internet. Therefore, if that SMTP server happened to have a vulnerability in it’s web server service or daemon, it would not be exposed to the Internet where worms and hackers are always on the prowl for port 80 vulnerabilities.

The next point may seem a bit odd, why would one be concerned about protecting the public Internet with one’s own network? While this may seem to be just a good exercise in Netizenship (Internet citizenship), it is also for the selfish purpose of protecting one’s own Internet connection. Take the recent SQL slammer worm for instance; it managed to decimate large segments of the Internet for an entire day. Had there been better firewall policies in place, you could have prevented the DoS (Denial of Service) effect on your Internet connection and also saved the Internet.

One of the least recognized dangers in security is the internal threat. The most expensive firewall on the planet cannot protect your network from “Sneaker net” with conventional designs, a phenomenon where your user walks in to your network with a laptop or disk infected with a virus or worm from home or some other source. A good network design and firewall policy would protect your DMZ servers from your servers and users the same way it protects them from the Internet.

The reverse situation of the above is also a potential threat. Since DMZ servers are exposed to the public Internet, there is a chance that they can be compromised by a hacker or worm. It is essential that you limit the damage that your DMZ servers can do to your internal servers or user stations. Additionally, a tight firewall policy can also prevent DMZ servers from further damaging them selves. If a server is compromised by a hacker through some known or unknown vulnerability, the first thing they will try to do is down load a “root kit”. The firewall policy should prevent the downloading of this deadly payload and make life harder on the attacker.

Additional threats from Extranet partners and Remote office WANs can also be mitigated. Routers that connect these networks using WAN technologies such as frame relay, ISDN, private lease line, or VPN tunnels can be secured by the firewall. Trying to implement security with firewall enabled routers on each and every one of those routers is expensive not only in terms of hardware/software costs, but setup and administration as well. An enterprise firewall can provide simple and centralized management of WAN and Extranet security with additional zones beyond the conventional triple homed design.

The bottom line is that firewalls can limit the flow of traffic between network zones which are broken down by logical organization and functional purposes. A firewall cannot however limit and protect hosts from other hosts within the same subnet because data never passes the firewall for inspection. This is why the more zones a firewall supports, the more useful it is in a well designed enterprise network. This is now easier than ever to accomplish since all of the major players like Cisco and Nokia support trunking of interfaces. A single gigabit port can easily support as many zones as you like and still perform much better than several fast Ethernet ports.

Implementing a good firewall policy:
1. The first critical component of secure firewall architecture is policy design.

In firewall policies, this simply means that unless there is a specific reason that a service needs to be used, that service should be blocked by default.

To implement this default service blocking policy, only one simple firewall rule needs to be implemented globally at the end of all policy sets, the any-any-any-drop rule. This simply means that the default behavior of the firewall will drop all packets from any source to any destination on any service. It is important that this rule is the last rule in any policy set because firewalls act from top to bottom.
==> The narrower these rules are made, the more secure the network is.

For example, users should be permitted outbound ports for common services like HTTP, FTP, media services, but nothing else should be permitted unless there is a special case to allow such traffic. When there is a special case based on a business need, tightly targeted rules should be added when approved. A very common error that administrators make is that they extend user rights to server and DMZ networks. Outbound rules that are appropriate for users are generally not appropriate for servers. When you really think about it, there is no reason that your Web server needs to surf the Web. Servers should serve and are rarely a client. The bottom line is, the DMZ or Server farm should almost always never be permitted to initiate traffic. Servers typically take in requests, but almost never request services from the public Internet except for XML and EDI applications with business partners. Other exceptions can be things like legitimate vendor sites that provide drivers and software updates, but all exceptions should be narrowly defined. Following these strict guidelines can vastly reduce server compromises, to the point that even the intra-subnet spread of worms like Code Red and NIMDA could have been prevented had such policies been in place even if the servers were not patched.

Implementing a good firewall network design:

Figure 1 illustrates a Pix 525 with 2 Gigabit Ethernet ports and 6 100-Mbit Fast Ethernet ports. This is a great way to achieve physical separation of the different subnets needed for an Enterprise network, provided that each port is plugged in to a physically different Ethernet switch. How ever, I can tell you that this is rarely done and is often impractical to deploy more than half a dozen physical switches in the data center for each subnet. More often than not, enterprises employ virtual LANs by segmenting a single physical switch in to multiple bridge groups, which is extremely easy to provision addition ports for any existing subnet or future ones. Because of this and the fact that all the enterprise firewall vendors have added 802.1q trunking support (Cisco came late in February 2003), one can easily use a single Gigabit port to connect the Layer 3 core switch, DMZ, extranet, guest subnet, and any other VLAN subnets that an enterprise needs. Therefore, one can do with out the second Gigabit Ethernet card and 4 port Fast Ethernet card in the PIX 525 shown in figure 1. This has how ever raised need for Layer 2 switch security against things like “VLAN hopping” which is rarely discussed even among experts, but we shall leave that for another piece. But even with the trunked Gigabit port, you should continue using the two built in Fast Ethernet ports for public Internet and stateful failover synchronization. Bottom line, two firewalls in the same class as a PIX 525 can provide enough flexibility and throughput for most enterprise networks.

Figure 2 illustrates the use of the two firewalls in a stateful failover configuration. Network connections were only drawn to the logical firewall to avoid messy connectors in the drawing, but in reality there would be a physical connection to each firewall for each subnet. Those connections could be physically separate cables or a single trunked cable over a single Gigabit connection in to your 802.1q VLAN capable switch. The two built in fast Ethernet ports in a PIX 525 are used for the public Internet connection and the stateful failover synchronizing, and the remaining internal subnets can share the Gigabit port. This configuration is much faster than a configuration with separate fast Ethernet ports that often get congested when trying to do network intensive tasks like tape backup between zones.

The internal side of the firewall can connect the following subnets:

• Core layer 3 switch
• DMZ
• Extranet and WAN
• Guest zone
• Others

The core layer 3 connection typically goes to your core switch with routing capability between VLANs. Those VLANs from that core switch may contain hundreds of user VLANs with tens of thousands of users, and server farm VLANs with hundreds of servers that do not get direct Internet exposure. You must understand how ever that there is no firewall between the server farm VLANs and the user VLANs in this example, because user to server traffic is routed by the core L3 switch and never passes through the firewall. There are companies that go to the extreme of putting all of their servers directly behind the firewall and separated from the users, but the management of that many internal servers behind a firewall with a lot of port requirements can be very difficult, so this is not often done.

DMZ is used for servers that need to be accessed from the public Internet. This is directly behind the firewall and is always filtered for traffic.

The Extranet and WAN zone is for the internal interfaces of routers that connect the remote WAN sites and partner sites. Using this configuration allows you to secure against WAN and Extranet sites without having to buy or configure firewall feature sets on the routers them selves. One can even go to the extreme of putting the external interfaces of the routers in a non-NAT zone on the firewall, this helps prevent hackers from compromising the router from the outside. This approach allows the high availability enterprise firewall to secure countless routers.

The guest zone is something new, but this is actually a security feature. Instead of guests connecting to your internal LAN when they need access to VPN or the Internet, have them connect to a guest network with access to the Internet but not your internal LAN. This new zone is extremely useful in the wireless environment. With new Wi-Fi infrastructure technology supporting VLANs and 802.1q trunking, a single wireless Wi-Fi infrastructure can support multiple VLANs, one internal VLAN running it’s own SSID and 802.1x/EAP security, and a guest VLAN that runs a simple WEP password for Internet only access.

Minimizing Windows network services - Win 2000 and XP

Jean-Baptiste Marchand
----[ Introduction ]----

A default Windows system comes with different network services, enabled by
default. Usually, it is wise to disable most of them and even all of them,
if the system does not offer network services to other systems.

In this document, we give a possible methodology to complete this task.
Technical details are described in a separate document entitled
_Windows network services internals_ and available at
http://www.hsc.fr/ressources/articles/win_net_srv/ .

The _Windows network services for Samba folks_ presentation, available at
http://www.hsc.fr/ressources/presentations/sambaxp2003/ , describes some
internals of Windows core network services.

Systems used as examples are Windows 2000 (server version) and Windows XP, as
installed by default (DHCP was disabled and IPv4 address 192.70.106.143 was
assigned to the unique network interface). Of course, the best solution is to
choose only required services at installation, even if it does not exempt you
from all the setup described here.

----[ Services identification ]----

A quick way to identify running network services is to list opened TCP and UDP
ports with the netstat command.

On a Windows 2000 system, the netstat -an command returns:

C:\WINNT>netstat -an

Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:25 0.0.0.0:0 LISTENING
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4983 0.0.0.0:0 LISTENING
TCP 192.70.106.143:139 0.0.0.0:0 LISTENING
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:1028 *:*
UDP 0.0.0.0:1029 *:*
UDP 0.0.0.0:3456 *:*
UDP 192.70.106.143:137 *:*
UDP 192.70.106.143:138 *:*
UDP 192.70.106.143:500 *:*

On a Windows XP system, the netstat -ano command returns:

C:\WINDOWS>netstat -ano

Active Connections

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 884
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 976
TCP 0.0.0.0:5000 0.0.0.0:0 LISTENING 1160
TCP 192.70.106.143:139 0.0.0.0:0 LISTENING 4
UDP 0.0.0.0:135 *:* 884
UDP 0.0.0.0:445 *:* 4
UDP 0.0.0.0:500 *:* 704
UDP 0.0.0.0:1026 *:* 1112
UDP 0.0.0.0:1027 *:* 976
UDP 127.0.0.1:123 *:* 976
UDP 127.0.0.1:1900 *:* 1160
UDP 192.70.106.143:123 *:* 976
UDP 192.70.106.143:137 *:* 4
UDP 192.70.106.143:138 *:* 4
UDP 192.70.106.143:1900 *:* 1160

_Warning_:

The netstat command does not exactly report TCP and UDP ports states. Instead,
it reports state of TDI transport addresses and connection endpoints, whereas
only TDI connection endpoints represent TCP or UDP sockets.

In particular, when a Windows system establishes an outgoing TCP connection
(active open), the local port used as source is reported as in the LISTENING
state.

In the following example, the local system has established a TCP connection from
source port 1367 to destination port 22 of a remote system.

The netstat command output, filtered to show only lines containing port number
1367 is:

C:\WINDOWS>netstat -anp tcp | find ":1367"
TCP 0.0.0.0:1367 0.0.0.0:0 LISTENING
TCP 192.70.106.142:1367 192.70.106.76:22 ESTABLISHED

The second line shows the established connection, from local port 1367 to remote
port 22. However, the first line is incorrect because it reports local port 1367
in the LISTENING state, whereas no TCP server is available on this port.

Thus, for each outgoing TCP connection, an additional line will appear in
netstat output, showing a TCP port in LISTENING state. It is important to make
the difference between an opened TCP port and one incorrectly reported by netstat
in the LISTENING state.

Note: this bug has been fixed in Windows Server 2003.

Once opened ports are identified, we present recipes to get them closed, step
by step.

----[ Disabling unused services ]----

To minimize opened ports, the first thing to do is to disable services. In our
examples, we will stop services (using the net stop command). However, to
prevent a service from starting at next system restart, startup mode of service must
either be set to manual or disabled. Some services have to be explicitly
disabled, otherwise they will be manually started by the system.

On Windows 2000, the service manager allows modification of startup type of a
service.

C:\WINDOWS>services.msc

The Startup Type (Automatic, Manual or Disabled) can be set under the General
tab of the Properties of each service.

On Windows XP, the sc command (also available in Windows 2000 Resource
Kit) can change the startup type of a service, with such a command:

C:\WINDOWS>sc config service_name start= disabled

(space between start= and disabled is mandatory).

The following command

C:\WINDOWS>sc config service_name start= manual

configures the startup mode of a service to manual.

--[ Windows 2000 ]--

-[ IIS 5 ]-

On Windows 2000, IIS 5 runs by default and is composed of SMTP, HTTP and IIS
administration services. To close TCP ports 25, 80, 443, UDP port 3456, one
port used by IIS administration website (4983 in our example) and two
ports, higher than 1023 for RPC services, these services must be stopped.

The quickest way to stop these services is to stop the iisadmin service (other
services depend on it):

C:\WINNT>net stop iisadmin
The following services are dependent on the IIS Admin Service service.
Stopping the IIS Admin Service service will also stop these services.

World Wide Web Publishing Service
Simple Mail Transport Protocol (SMTP)

Do you want to continue this operation? (Y/N) [N]: y
The World Wide Web Publishing Service service is stopping.
The World Wide Web Publishing Service service was stopped successfully.

The Simple Mail Transport Protocol (SMTP) service is stopping.
The Simple Mail Transport Protocol (SMTP) service was stopped successfully.

...
The IIS Admin Service service was stopped successfully.

Output of the netstat -an command shows that the number of opened ports has been
reduced:

C:\WINNT>netstat -an

Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING
TCP 192.70.106.143:139 0.0.0.0:0 LISTENING
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:1029 *:*
UDP 192.70.106.143:137 *:*
UDP 192.70.106.143:138 *:*
UDP 192.70.106.143:500 *:*


Finally, the easiest way to prevent IIS services to start next time is by
removing IIS components, via Add/Remove Programs in configuration panel.

-[ IPsec ]-

UDP port 500, used by IKE protocol (Internet Key Exchange) can be closed by
stopping IPsec services service.

C:\WINNT>net stop policyagent
The IPSEC Services service is stopping.
The IPSEC Services service was stopped successfully.

UDP port 500 then disappears from netstat -an output:

C:\WINNT>netstat -an

Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING
TCP 192.70.106.143:139 0.0.0.0:0 LISTENING
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:1029 *:*
UDP 192.70.106.143:137 *:*
UDP 192.70.106.143:138 *:*

-[ Distributed Transaction Coordinator ]-

Distributed Transaction Coordinator service is enabled by default on a Windows
2000 server and opens TCP port 3372, and one TCP port higher than 1023 (1025 in
our example).

Stopping this service closes two TCP ports:

C:\WINNT>net stop msdtc
The Distributed Transaction Coordinator service is stopping.
The Distributed Transaction Coordinator service was stopped successfully.

List of opened ports is now:

C:\WINNT>netstat -an

Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
TCP 192.70.106.143:139 0.0.0.0:0 LISTENING
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:1029 *:*
UDP 192.70.106.143:137 *:*
UDP 192.70.106.143:138 *:*


--[ Windows XP ]--

Services that can easily be disabled are:
IPsec services (PolicyAgent)
SSDP Discovery Service (SSDPSRV)
Windows Time (W32Time)

The following commands stop these services:

C:\WINDOWS>net stop policyagent
The IPSEC Services service is stopping.
The IPSEC Services service was stopped successfully.


C:\>WINDOWS>net stop ssdpsrv
The SSDP Discovery Service service is stopping.
The SSDP Discovery Service service was stopped successfully.


C:\>WINDOWS>net stop w32time
The Windows Time service is stopping.
The Windows Time service was stopped successfully.


netstat -ano command shows that the number of opened ports has been reduced (TCP
ports 5000 and UDP 123, 500 and 1900 have been closed):

C:\WINDOWS>netstat -ano

Active Connections

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 884
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 976
TCP 192.70.106.143:139 0.0.0.0:0 LISTENING 4
UDP 0.0.0.0:135 *:* 884
UDP 0.0.0.0:445 *:* 4
UDP 0.0.0.0:1026 *:* 1112
UDP 0.0.0.0:1027 *:* 976
UDP 192.70.106.143:137 *:* 4
UDP 192.70.106.143:138 *:* 4


---[ NetBIOS over TCP/IP (NetBT) ]---

NetBIOS over TCP/IP is typically used on Windows systems to transport the CIFS
protocol (also known as SMB). CIFS is the protocol behind resources sharing
(typically, file and printer sharing).

NetBIOS over TCP/IP uses UDP ports 137, 138 and TCP port 139. To close
these ports, NetBIOS over TCP/IP must be disabled on each network adapter.

For each network adapter in the Network and Dial-up Connection, select
Properties and choose Properties of Internet Protocol (TCP/IP). Click on
the Advanced button, select the WINS tab and check Disable NetBIOS over TCP/IP.
This will close UDP ports 137 and 138 and TCP port 139 on configured adapter.

The lmhosts service, used for NetBIOS name resolution can also be stopped and
disabled:

C:\WINNT>net stop lmhosts
The TCP/IP NetBIOS Helper service is stopping.
The TCP/IP NetBIOS Helper service was stopped successfully.

On Windows 2000, the list of opened ports becomes:

C:\WINNT>netstat -an

Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:1029 *:*

On Windows XP:

C:\WINDOWS>netstat -ano

Active Connections

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 884
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 976
UDP 0.0.0.0:135 *:* 884
UDP 0.0.0.0:445 *:* 4
UDP 0.0.0.0:1026 *:* 1112
UDP 0.0.0.0:1027 *:* 976

---[ CIFS over TCP ]---

Before Windows 2000, the CIFS protocol was typically transported in NetBIOS over
TCP/IP (NetBT), using TCP port 139. Starting with Windows 2000, CIFS can be
transported directly in TCP/IP, without an intermediary NetBT layer. In that
case, TCP port 445 is used (see http://www.ubiqx.org/cifs/SMB.html#SMB.1.2
for more information).

To disable listening on TCP port 445, two methods are possible:
1. disable the NetBT driver
2. add a value in the registry to disable transport of CIFS in TCP


-[ Disabling the NetBT driver ]-

The first method completely disables SMB on a system, i.e both client-side
(workstation service) and server-side (server service).

You first need to stop the workstation and server services (and all services
that depend on them and may still run):

C:\WINNT>net stop rdr
The Workstation service is stopping.
The Workstation service was stopped successfully.

C:\WINNT>net stop srv
The Server service is stopping.
The Server service was stopped successfully.

Once these services are stopped, the NetBT driver can be stopped:

C:\WINNT>net stop netbt
The NetBios over Tcipip service is stopping.
The NetBios over Tcipip service was stopped successfully.

To disable the NetBT driver, the following registry value must be changed:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\
Value: Start
Type: DWORD value (REG_DWORD)
Content: 4

On Windows XP, you can use the following command:

C:\WINDOWS>sc config netbt start= disabled


-[ Disabling the raw SMB transport without disabling NetBT transport ]-

In some cases, you might want to run the NetBT driver without using the raw SMB
transport, which uses TCP port 445.

In that case, you can set the following registry value:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
Value: SmbDeviceEnabled
Type: DWORD value (REG_DWORD)
Content: 0 (to disable)

After a reboot, TCP port 445 will no longer be opened by the NetBT driver.

The following ports remain opened on Windows 2000:

C:\WINNT>netstat -an

Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:1029 *:*

Under Windows XP:

C:\WINDOWS>netstat -ano

Active Connections

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 884
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 976
UDP 0.0.0.0:135 *:* 884
UDP 0.0.0.0:1026 *:* 1112
UDP 0.0.0.0:1027 *:* 976


---[ RPC services ]---

Remaining ports are used by RPC services (Remote Procedure Call). The RPC
portmapper and the COM service control manager (COM SCM) both use port 135.
Ports immediately higher than 1023 are used by RPC services and are reachable
via RPC or DCOM (ORPC). As these ports are dynamically allocated, a port mapping
service is needed, the portmapper, to give the port on which a given RPC service
can be reached.

If you want to identify which RPC services is using which TCP or UDP port on
your own system, you can use the rpcdump tool to obtain the list of registered
RPC services in the portmapper database
(http://razor.bindview.com/tools/desc/rpctools1.0-readme.html ).

-[ Windows 2000 ]-

With rpcdump, we can determine that, on our test system, UDP port 1029 is used
by RPC services started by the Messenger service. After disabling this service
(as explained in the Disabling unused services section) and rebooting the
system, this port will be closed.

Also, UDP port 135 will no longer be opened because:
- the last RPC service reachable via UDP has been disabled
- DCOM is not reachable via UDP by default, thus the COM SCM does not listen
on UDP port 135.

TCP port 1026 is used by RPC services started by the Task Scheduler service
(Schedule). It is thus possible to close this port after disabling this service
and rebooting.

Remote Access Connection Manager (RasMan) must also be disabled.

-[ Windows XP ]-

On our Windows XP system, UDP port 1027 is used by RPC services started by the
Messenger service. As in Windows 2000, this port and UDP port 135 will no longer
be opened after disabling this service and rebooting.

TCP port 1025 is used by RPC services of the Task Scheduler service. Again, as
in Windows 2000, this service must be disabled.

--[ Interfaces restriction on Windows 2000 ]--

_Warning_: the interfaces restriction technique described here currently only
works on Windows 2000 (i.e, not on Windows XP).

Until now, we have disabled services that start RPC services, in order to close
the dynamic ports they use. However, sometimes some services such as the Task
Scheduler are needed.

It is possible to restrict listening network interfaces for some RPC services,
more precisely, for those services that do not explicitly listen on all network
interfaces.

A registry value allows the system to configure the list of network interfaces
on which RPC services will listen. The value contains a list of integers that
correspond to network interfaces indexes.

Before Windows 2000, this value contained network devices names, as described in
the 'Configuring the Windows XP/2000/NT Registry Port Allocations and Selective
Bindings' entry in Microsoft Platform SDK documentation, available somewhere at
http://msdn.microsoft.com/ . Starting with Windows 2000, the systems expects
network interfaces indexes, starting at 1.

The two following keys, Rpc\ and Rpc\Linkage\, do not exist by default in the
registry and must be created under the following key:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\

The value to add is:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rpc\Linkage\
Value: Bind
Type: REG_MULTISZ
Content: list of network interfaces indexes

Microsoft released on 4/16/2003 a new version of the rpccfg tool, that can list
network interface indexes and configure interfaces restriction. This tool is
available at http://download.microsoft.com/ (search keyword: rpccfg).

The -q option of rpccfg gives the current settings of interfaces and ports
restrictions:

C:\>WINNT>rpccfg -q
RPCCFG: Listening on all interfaces (default configuration)

RPCCFG: Using default port settings

The -l option of rpccfg gives the mapping between network adapters and
interfaces indexes:

C:\WINNT>rpccfg -l
IF[2]: Ethernet: 3Com EtherLink PCI (Microsoft's Packet Scheduler)
IF[1]: Ethernet: MS TCP Loopback interface

On our system, the first index corresponds to the loopback interface (IPv4
address 127.0.0.1). Thus, to restrict RPC service to the loopback interface, we
use the -a option with 1 as argument:

C:\WINNT>rpccfg -a 1
RPCCFG: Listening on the following interfaces
IF[1]: Ethernet: MS TCP Loopback interface

We can verify with the -q option that the interface restriction is correctly
configured:

C:\WINNT>rpccfg -q
RPCCFG: Listening on the following interfaces
IF[1]: Ethernet: MS TCP Loopback interface

RPCCFG: Using default port settings


-[ The case of the portmapper ]-

By default, the portmapper RPC service binds to all network interfaces.

A registry value, ListenOnInternet, controls whether the portmapper RPC service
binds to all interfaces or not. By default, this value does not exist and has
implicitly a default value of "Y":

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs\
Value: ListenOnInternet
Type: REG_SZ
Content: "Y" or "N"

When set to "N", TCP port 135 will only listen on interfaces specified by the
Bind value described in the previous section.

-[ Limits of the interfaces restriction technique ]-

The interfaces restriction technique has some limitations:
- it only works for RPC services that do not explicitly listen on all interfaces.
- it is a global setting, i.e. restrictions can not be implemented on a per-RPC
service basis.
- it seems to work only for TCP transport of RPC services

Tests have shown that the interfaces restriction technique works on Windows 2000
for the TCP transport of the following services:

RPC service of the Distributed Transaction Coordinator service
RPC service of the Task Scheduler service
RPC service of the inetinfo service

It does not work with the UDP transport of the following services (in fact, it
probably does not work with UDP transport at all):

RPC service of the messenger service
RPC service of the inetinfo service


-[ RPC dynamic ports range restriction ]-

By default, TCP and UDP ports for RPC services are allocated in the dynamic
ports range, which starts at 1025 (port 1024 does not seem to be used on Windows
systems). This explains why most of the RPC services lauched at startup listen
on TCP and UDP ports immediately higher than 1023.

It is possible to configure a specific range for ports allocated to RPC
services. This is typically used to ease ports filtering on IP filtering
devices. It can also be used to make a clear distinction between dynamic ports
(typically used when the system is a TCP or UDP client) and ports allocated to
RPC services.

The -pi and -pe option of rpccfg allows to configure the range of ports
allocated to RPC services. To set the range to 4000-4100:

C:\WINNT>rpccfg -pi 4000-4100
The following ports/port ranges will be used for Intranet ports
4000-4100

Default port allocation is from Intranet ports


We can finally verify that our networks interfaces and ports restrictions are
correct:

C:\WINNT>rpccfg -q
RPCCFG: Listening on the following interfaces
IF[1]: Ethernet: MS TCP Loopback interface

The following ports/port ranges will be used for Intranet ports
4000-4100

Default port allocation is from Intranet ports

--[ DCOM ]--

The only remaining opened port is TCP port 135. It is opened by the Remote
Procedure Call (RpcSs) service and it is not possible to disable it because this
service contains the COM service control manager, used by local processes.

TCP port 135 remains opened because it is used to receive remote activation
requests of COM objects. A global setting exists to disable DCOM and can be set
in the registry:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
Value: EnableDCOM
Type: REG_SZ
Content: "Y" (to enable) or "N" (to disable)

This registry value corresponds to the 'Enable Distributed COM on this computer'
setting that appears in the dcomcnfg tool:

C:\WINDOWS>dcomcnfg

This procedure is now documented in the #825750 Microsoft knowledge base
article (http://support.microsoft.com/?id=825750 ).

Disabling DCOM is probably a good idea, as it will at least protect systems from
the recent vulnerabilities affecting DCOM, discovered by the Last Stage of
Delirium Research Group (http://www.lsd-pl.net/special.html ) and by the
Xfocus team (http://www.xfocus.org/advisories/200307/4.html ).

When DCOM is disabled, the COM framework returns the E_ACCESSDENIED error code
(0x80700005) when receiving remote activation requests. Thus, exploitation of
the aforementionned vulnerabilities fail.

Disabling DCOM does not close TCP port 135. To close it, one solution
is to remove IP-based RPC protocols sequences from the list that can be used by
DCOM. In our case, the sequence ncacn_ip_tcp (transport on TCP/IP) can be
removed.

The simplest solution for this is to use the dcomcnfg tool and to remove
'Connection-oriented TCP/IP' in the 'Default Protocols' tab.

Under Windows 2000, dcomcnfg directly shows the DCOM properties of the local
system, in particular, the 'Default Protocols' tab. Under Windows XP, dcomcnfg
launches an MMC console showing three nodes. The 'Default Protocols' tab appears
in the properties of the My Computer node, under the Computer node.

The list shown in the 'Default Protocols' tab is stored in the registry, under
the following value:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc
Value: DCOM Protocols
Type: REG_MULTI_SZ

Thus, it is also possible to directly edit the registry and remove ncacn_ip_tcp
from the DCOM Protocols value.

After a reboot, all ports should be reported as closed, except one UDP port on
Windows XP, which we study in the next section.


--[ caching DNS service (Windows XP) ]--

Starting with Windows 2000, Windows systems include a caching DNS service
(dnscache), that keeps in memory results of DNS requests.

On Windows 2000, this service sends DNS requests on UDP, using a different UDP
source port for each request. On Windows XP, the same port is always used: it is
allocated at the first DNS request and remains the same, as long as the dnscache
service is running.

On our Windows XP system, the port used by the dnscache service is UDP port
1026. If we stop the dnscache service, this port will be closed.

It is possible to disable the socket caching mechanism used by the Windows XP
dnscache service, adding a registry value under the service key:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\
Value: MaxCachedSockets
Type: REG_DWORD
Content: 0

With this setting, the Windows XP dnscache service will behave as under Windows
2000, i.e, different UDP sockets are used for each DNS requests.

--[ RPC services started when using the system ]--

Some RPC services can be started when starting some programs. For instance,
using the Component Services component under Windows XP seems to open two TCP
ports, used by RPC services.

Thus, it is always useful to use IP filtering, in addition to minimization
techniques presented here.

----[ Summary ]----

Minimization of network services can be realized in three steps:
- disabling of unused services
- disabling of NetBIOS over TCP/IP and CIFS over TCP
- minimization of RPC services

Services to disable are:
Windows 2000:
- IIS 5: iisadmin, w3svc, smtpsvc
- Others: messenger, msdtc, policyagent, schedule
Windows XP:
- messenger, policyagent, schedule, ssdpsrv, w32time

Disabling of NetBIOS over TCP/IP is specific to each network interface. To
globally disable CIFS over TCP (port 445), the SmbDeviceEnabled registry value
must be added and set to 0 in the registry.

Minimization of RPC services starts by disabling services that register RPC
services.

The removal of the 'Connection-oriented TCP/IP' protocol sequence in the dcomcnfg
utility allows to close TCP port 135.

If necessary, listening interfaces restriction can be configured for some RPC
services on Windows 2000, using the rpccfg tool.

----[ Conclusion ]----

A default installation of a Windows system has many network services. It is
possible and wise to minimize them, leaving only services that are strictly
necessary.

----[ Greetings ]----

Thanks to Jacqueline J. for proofreading this document and suggesting many
improvements.

Minimizing Windows Server 2003 network services

by Jean-Baptiste Marchand (25/03/2005)


-[ Minimizing Windows Server 2003 network services ]-


1. Introduction

This document is an evolution of the document

Minimizing Windows network services - Examples with Windows 2000 and Windows XP

published for the first time in September 2002

http://www.hsc.fr/ressources/breves/min_srv_res_win.en.html

and explains how the same methodology can be applied to minimize network services
of Windows Server 2003 systems.

Windows network services are presented in details in the _Windows network
services internals_ paper, available at

http://www.hsc.fr/ressources/articles/win_net_srv/


2. Target

The hardening recommendations presented in this document will only be used for
isolated Windows Server 2003 systems (systems that are not part of an Active
Directory domain).

Depending on the target environment, only a subset of the recommendations will
be implemented.

Yet, it is possible to apply all recommendations on hardened systems (such as
servers used in DMZ).


3. Overview of default Windows Server 2003 network services

The netstat command can be used to enumerate running network services on a
default Windows Server 2003 system:

C:\>netstat -ano

Active Connections

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 680
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 508
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING 992
TCP 192.70.106.144:139 0.0.0.0:0 LISTENING 4
UDP 0.0.0.0:445 *:* 4
UDP 0.0.0.0:500 *:* 508
UDP 0.0.0.0:1027 *:* 992
UDP 0.0.0.0:1029 *:* 912
UDP 0.0.0.0:4500 *:* 508
UDP 127.0.0.1:123 *:* 992
UDP 192.70.106.144:123 *:* 992
UDP 192.70.106.144:137 *:* 4
UDP 192.70.106.144:138 *:* 4


When the -o netstat option is used, the PID column contains the process
identifier of the process that bound a socket.

The tasklist command displays the translation between process identifiers and
executable names:

C:\>tasklist

Image Name PID Session Name Session# Mem Usage
========================= ====== ================ =========== ============
System Idle Process 0 Console 0 16 K
System 4 Console 0 212 K
smss.exe 372 Console 0 456 K
csrss.exe 428 Console 0 3 656 K
winlogon.exe 452 Console 0 1 988 K
services.exe 496 Console 0 3 052 K
lsass.exe 508 Console 0 8 284 K
svchost.exe 680 Console 0 2 732 K
svchost.exe 728 Console 0 3 748 K
svchost.exe 912 Console 0 3 792 K
svchost.exe 964 Console 0 1 868 K
svchost.exe 992 Console 0 17 352 K
spoolsv.exe 1220 Console 0 4 876 K
msdtc.exe 1248 Console 0 3 944 K
svchost.exe 1340 Console 0 1 748 K
svchost.exe 1372 Console 0 1 304 K
dfssvc.exe 1568 Console 0 3 116 K
wmiprvse.exe 1932 Console 0 4 564 K
explorer.exe 1816 Console 0 17 012 K
ctfmon.exe 560 Console 0 2 304 K
msiexec.exe 204 Console 0 3 168 K
wpabaln.exe 1004 Console 0 2 460 K
cmd.exe 280 Console 0 1 468 K
wmiprvse.exe 276 Console 0 4 744 K
tasklist.exe 1268 Console 0 3 244 K



4. TCP and UDP ports used by Windows Server 2003 default network services

4.1 IPSEC Services (PolicyAgent)

The IPSEC Services service opens two UDP sockets:

- one UDP socket bound to UDP port 500 (ISAKMP support)
- one UDP socket bound to UDP port 4500 (NAT-T support)

These two UDP ports appear in netstat's output:

UDP 0.0.0.0:500 *:* 508
UDP 0.0.0.0:4500 *:* 508
^^^

508 corresponds to the PID of lsass.exe (the PolicyAgent service runs inside
the LSA process):

C:\>tasklist /svc /fi "pid eq 508"

Image Name PID Services
========================= ====== =============================================
lsass.exe 508 PolicyAgent, ProtectedStorage, SamSs

Stopping the PolicyAgent service immediately closes the two UDP sockets:

C:\>net stop policyagent
The IPSEC Services service is stopping.
The IPSEC Services service was stopped successfully.


To set the startup mode of the PolicyAgent service to manual instead of
automatic (default configuration), use the following command:

C:\>sc config policyagent start= demand
[SC] ChangeServiceConfig SUCCESS


4.2 Windows Time service (w32time)


The Windows Time service opens one UDP socket bound to UDP port 123 for each
network adapter present on the system, plus the loopback IPv4 address
(127.0.0.1):

UDP 127.0.0.1:123 *:* 992
UDP 192.70.106.144:123 *:* 992
^^^

svchost.exe 992 Console 0 17 352 K
^^^^^^^^^^^ ^^^

992 corresponds to the svchost.exe instance that hosts the w32time service.

Stopping the w32time immediately closes all sockets bound to UDP port 123:

C:\>net stop w32time
The Windows Time service is stopping.
The Windows Time service was stopping successfully.

To set the startup mode of the w32time service to manual instead of
automatic (default configuration), use the following command:

C:\>sc config w32time start= demand
[SC] ChangeServiceConfig SUCCESS


4.3 NetBIOS over TCP/IP driver (NetBT support)

By design, the NetBIOS over TCP/IP driver binds 3 sockets on the IP address of
each network adapter.

These 3 sockets correspond to the 3 NetBIOS over TCP/IP services:
- 137/UDP : NetBIOS name resolution service
- 138/UDP : NetBIOS datagram service
- 139/TCP : NetBIOS session service

In our example, 3 sockets are bound to the network adapter:

TCP 192.70.106.144:139 0.0.0.0:0 LISTENING 4
UDP 192.70.106.144:137 *:* 4
UDP 192.70.106.144:138 *:* 4
^

4 corresponds to the System process and confirms that these sockets are bound by
the NetBIOS over TCP/IP driver (netbt.sys), running in kernel-mode.

NetBIOS over TCP/IP is not needed if all systems of the environment are running
Windows 2000 or later.

Disabling NetBIOS over TCP/IP support on all network adapters (choose
Disable NetBIOS over TCP/IP in the WINS tab of the network adapter's Advanced
TCP/IP Settings window) closes sockets bound to 137/udp, 138/udp and
139/tcp.


4.4 NetBIOS over TCP/IP driver (raw SMB support)

Starting with Windows 2000, the SMB protocol (Windows protocol behind Windows
resource sharing and remote administration capabilities) can be carried directly
into TCP, using TCP port 445.

Thus, the netbt.sys driver of recent Windows systems (including Windows Server
2003) binds two sockets, one on TCP port 445 and one on UDP port 445.

The purpose of the UDP socket is, to the best of our knowledge, not documented.

These two sockets are bound to all network adapters (0.0.0.0):

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
UDP 0.0.0.0:445 *:* 4


To close these two sockets, it is possible to either:
- stop the NetBT driver
- set the SmbDeviceEnabled registry value to 0

The NetBT driver can be stopped with the following command:

C:\>net stop /y srv

The following services are dependent on the Server service.
Stopping the Server service will also stop these services.

Distributed File System
Computer Browser

The Distributed File System service was stopped successfully.

The Computer Browser service is stopping.
The Computer Browser service was stopped successfully.

The Server service is stopping.
The Server service was stopped successfully.

C:\>net stop rdr

The Workstation service is stopping.
The Workstation service was stopped successfully.

The netbt driver can then be stopped with the following command:

C:\>net stop /y netbt

The following services are dependent on the NetBios over Tcpip service.
Stopping the NetBios over Tcpip service will also stop these services.

TCP/IP NetBIOS Helper

The TCP/IP NetBIOS Helper service was stopped successfully.


The NetBios over Tcpip service was stopped successfully.


Because of services dependencies, if the NetBT driver is disabled, the startup
mode of the following services must be set to manual or disabled:
- Computer Browser service (Browser)
- Distributed File System service (Dfs)
- Server service (lanmanserver)
- Workstation service (lanmanworkstation)
- TCP/IP NetBIOS Helper (lmhosts)

To prevent the netbt.sys to be started at the next system startup, its startup
mode must be set to manual:

C:\>sc config netbt start= demand
[SC] ChangeServiceConfig SUCCESS


Startup modes of all services that depend on it must also be modified:

C:\>sc config lmhosts start= demand
[SC] ChangeServiceConfig SUCCESS

C:\>sc config dfs start= demand
[SC] ChangeServiceConfig SUCCESS

C:\>sc config browser start= demand
[SC] ChangeServiceConfig SUCCESS

C:\>sc config lanmanserver start= demand
[SC] ChangeServiceConfig SUCCESS

C:\>sc config lanmanworkstation start= demand
[SC] ChangeServiceConfig SUCCESS

In addition, the Remote Registry service (RemoteRegistry) can be disabled
because it is not possible to remotely access the registry when the server
service is not started:

C:\>sc config remoteregistry start= demand
[SC] ChangeServiceConfig SUCCESS


4.5 DNS Client service (Dnscache)

The Windows Server 2003 DNS Client service is a caching DNS resolver used by
applications that need a DNS resolution service.

When started, the Dnscache service binds a UDP socket to communicate with DNS
servers on UDP port 53.

The UDP socket used by the Dnscache service appears in netstat's output:

UDP 0.0.0.0:1029 *:* 912
^^^

912 corresponds to the svchost.exe instance that hosts the Dnscache service:

C:\>tasklist /svc /fi "pid eq 912"

Image Name PID Services
========================= ====== =============================================
svchost.exe 912 Dhcp, Dnscache
^^^^^^^^

Stopping the Dnscache service closes the dynamic UDP port:

C:\>net stop dnscache
The DNS Client service is stopping.
The DNS Client service was stopped successfully.


4.6 RPC services listening on TCP

Windows Server 2003 LSA runs several RPC services that can be reached via a
dynamic TCP port:

TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 508
^^^

As seen earlier, 508 corresponds to the LSA process (lsass.exe):

C:\>tasklist /svc /fi "pid eq 508"

Image Name PID Services
========================= ====== =============================================
lsass.exe 508 ProtectedStorage, SamSs


The Task Scheduler service runs several RPC services and also opens a dynamic TCP
port:

TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING 992

Finally, the MSRPC portmapper and COM SCM, started by the RpcSs service both use
TCP port 135:

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 680

680 corresponds to the svchost.exe instance that hosts the RpcSs service:

C:\>tasklist /svc /fi "pid eq 680"

Image Name PID Services
========================= ====== =============================================
svchost.exe 680 RpcSs
^^^^^


In Windows Server 2003, the netsh rpc context can be used to specify that RPC
services listening on TCP ports (ncacn_ip_tcp protocol sequence) should only
bind to a specific network adress.

Using netsh, it is possible to restrict these three RPC services so that they
only bind to the loopback IPv4 address (127.0.0.1):


C:\>netsh -c rpc

netsh rpc>show interfaces

Subnet Interface Status Description

127.0.0.0 127.0.0.1 Enabled MS TCP Loopback interface

192.70.106.128 192.70.106.144 Disabled AMD PCNET Family PCI Ethernet Adapter

netsh rpc>show settings
Default

netsh rpc>add 127.0.0.0

netsh rpc>show settings
Add List
127.0.0.0


After a reboot, the three RPC services only bind to 127.0.0.1, as shown below:

Proto Local Address Foreign Address State PID
TCP 127.0.0.1:135 0.0.0.0:0 LISTENING 740
TCP 127.0.0.1:1025 0.0.0.0:0 LISTENING 788
TCP 127.0.0.1:1026 0.0.0.0:0 LISTENING 516


4.7 Setting a port range for dynamic ports used by RPC services

By default, dynamic (TCP or UDP) ports opened by RPC servers are allocated in
the Windows default range of dynamic ports: 1025-5000.

It is possible to use a dedicated port range for these RPC services, so that it
is is easier to identify running RPC services.

The rpccfg tool, part of Windows Server 2003 Resource Kit tools, can be used to
setup a port range (5050-5070 in the following example):

C:\>rpccfg /pe 5050-5070
The following ports/port range will be used for Internet ports
5050-5070

Default port allocation is from Intranet ports

C:\>rpccfg /d 0
The following ports/port range will be used for Internet ports
5050-5070

Default port allocation is from Internet ports


Finally, the complete configuration of the RPC runtime can be displayed with the
/q option of rpccfg:


C:\>rpccfg /q
Admit List
Subnet Description
1 127.0.0.0 1 MS TCP Loopback interface


The following ports/port ranges will be used for Internet ports
5050-5070

Default port allocation is from Internet ports


After a reboot, the three remaining RPC services only bind to 127.0.0.1 and the
two RPC services that previously used dynamic ports from the default range
(1025-5000) now use the first two ports from the range for Internet ports (5050
and 5051):

Proto Local Address Foreign Address State PID
TCP 127.0.0.1:135 0.0.0.0:0 LISTENING 752
TCP 127.0.0.1:5050 0.0.0.0:0 LISTENING 844
TCP 127.0.0.1:5051 0.0.0.0:0 LISTENING 516


5. Windows Server 2003 SP1

In Windows Server 2003 SP1, a new netstat option, -b, can be used to directly
display the Windows service or process that open sockets.

The output of the netstat -anb command on a default Windows Server 2003 SP1
system is shown below:

Active Connections

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1244
RpcSs
[svchost.exe]

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
[System]

TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 856
[lsass.exe]

TCP 192.70.106.144:139 0.0.0.0:0 LISTENING 4
[System]

UDP 0.0.0.0:4500 *:* 856
[lsass.exe]

UDP 0.0.0.0:500 *:* 856
[lsass.exe]

UDP 0.0.0.0:445 *:* 4
[System]

UDP 0.0.0.0:1026 *:* 1296
Dnscache
[svchost.exe]

UDP 127.0.0.1:123 *:* 1344
W32Time
[svchost.exe]

UDP 192.70.106.144:137 *:* 4
[System]

UDP 192.70.106.144:123 *:* 1344
W32Time
[svchost.exe]

UDP 192.70.106.144:138 *:* 4
[System]


It seems that in Windows Server 2003 SP1, the Task Scheduler service no longer
opens a TCP port for its RPC services.

Thus, compared to a default Windows Server 2003 system, there is one less
listening TCP socket on a default Windows Server 2003 SP1 system.

Otherwise, opened sockets are the same as the one found on a default Windows
Server 2003 system and the same methodology can be used.

6. Conclusion

Depending on the role and the environment, only a subset or all Windows Server
2003 network services will be minimized.

An isolated Windows Server 2003 system can be configured so that no listening
TCP port appear when scanned remotely with a network scanner.

However, when dealing with network services minimization, the most important
thing is not necessarily to close all ports but instead to determine which
network communications are needed, analyze the risks associated to the network
services and decide which network services are needed, must be hardened,
filtered or disabled.


7. List of TCP and UDP ports used by Windows Server 2003 network services

TCP:
135/tcp: Remote Procedure Call (RPC) service (RpcSs)
139/tcp: NetBIOS over TCP/IP driver (netbt.sys)
445/tcp: NetBIOS over TCP/IP driver (netbt.sys)
One dynamic TCP port (LSA RPC services): lsass.exe
One dynamic TCP port (RPC services): Task Scheduler service (schedule)
-> not in Windows Server 2003 SP1

UDP:
123/udp: Windows Time service (w32time)
137/udp, 138/udp: NetBIOS over TCP/IP driver (netbt.sys)
445/udp: NetBIOS over TCP/IP driver (netbt.sys)
500/udp, 4500/udp: IPSEC Services service (PolicyAgent)
One dynamic UDP port: DNS Client service (Dnscache)


For further information, see the list of network ports used by Windows systems
found in the #832017 Microsoft knowledge base article:

http://support.microsoft.com/?id=832017

Because the RpcSs service can not be disabled nor the lsass.exe process stopped,
a Windows Server 2003 system will, at a minimum, always have two listening TCP
sockets, that can be bound only to 127.0.0.1 if the rpc subsystem has been
configured explictly with netsh, as shown earlier:

Proto Local Address Foreign Address State PID
TCP 127.0.0.1:135 0.0.0.0:0 LISTENING 740
TCP 127.0.0.1:5050 0.0.0.0:0 LISTENING 788

$Id: min_w2k3_net_srv.tip,v 1.10 2005/04/07 08:16:18 marchand Exp $