
Some of the main topics in this chapter are
Securing Internet TCP/IP applications Connecting your network or Windows NT Server to the Internet offers many benefits, but it also can place your corporate data at risk. Malicious users might be able to gain access to confidential data or even wreck havoc upon your network. This chapter explores some potential areas of concern when connecting Windows NT to the Internet and addresses methods of protecting your network and Windows NT Server.
There are many ways you can secure your network and Windows NT server from Internet attacks. The particular methods you use will depend on your particular scenario. Because various individuals' and companies' reasons for connecting to the Internet vary, the level of required security will also vary. For instance, one company might be connecting Windows NT to the Internet to provide information to customers via the World Wide Web (WWW), whereas another customer might want to use the Internet to transfer files from other locations.
If the WWW server is secured to only enable the sending and receiving of network packets related to the HTTP protocol used for WWW data, then files would not be able to be transferred to the server throughout the Internet. Therefore, the company wanting to use the Internet to transfer files would have to implement a different security scheme to enable the proper data to be sent or received. In short, proper security is a balance between restricting unwanted access and allowing authorized use of the system.
Because each application might require a different security method, this chapter looks at a wide variety of ways to secure your network and data. It will be up to you to determine which method or combination of methods is best suited for your particular application.
Basically, there are two areas of concern when discussing the security of Windows NT Servers on the Internet. Applications such as FTP, Gopher, WWW, and Telnet are typical TCP/IP applications that are used across the Internet. The protocols that these applications use are recognized by most systems attached to the Internet, including Windows NT Servers that have these services running, and are the first area of concern.
Windows NT also recognizes a protocol called Server Message Blocks (SMB). The SMB protocol, which was developed jointly by Microsoft, Intel, and IBM, defines a series of commands used to pass information between networked computers. This protocol is used for the native file and print service offered by Windows NT Server and is the second area of concern for security considerations. The SMB protocol was initially designed to work over the NetBEUI protocol but has been adapted to work over TCP/IP. NetBEUI running over TCP/IP is sometimes referred to as NBT, which is short for NetBEUI over TCP/IP. NBT enables Windows NT native file and print services to be used over a private TCP/IP network or over the public Internet. It also opens up new potential security hazards that are not present in other operating systems, such as UNIX.
The SMB protocol is used not only for file and print services but also for accessing resources such as a remote Windows NT Server Registry. Without proper security methods in place, any operating system that uses SMB as its native protocol, such as Windows for Workgroups or Windows 95, has the capability to communicate with your server by using SMB over the Internet if your server is directly attached to the Internet.
Firewalls are an important part of Internet security. Although there are many variations of firewalls, they can basically be divided into two categories: Network layer and Application layer. To understand how these two types of firewalls operate, you must first examine the OSI Reference Model, as shown in Figure 53.1.
The International Organization of Standards (ISO) developed the OSI Reference Model in 1978 to specify a standard that could be used to develop an open communications standard between dissimilar systems. Today, the ISO Reference Model is often used when comparing the operating differences between protocols and when breaking down a protocol into lower-level functions to better understand how the protocol works.
It is important to understand the TCP/IP protocol and how it relates to the OSI Reference Model when examining the operation of different firewall technologies. Figure 53.2 shows the OSI layers at which each TCP/IP protocol operates.
The OSI Reference Model is used as a standard reference against which to compare networking protocols.
This diagram shows TCP/IP's relation to the OSI Reference Model.
The screening router is considered a Network layer firewall, and the proxy server is considered an Application layer firewall. Keep in mind that many modern-day firewalls contain both of these technologies.
The screening router is classified as a Network layer firewall, but it usually operates on the IP (Internet Protocol), UDP (User Datagram Protocol), and TCP (Transmission Control Protocol), which reside in the Network and Transport layers of the OSI Reference Model. A screening router is connected between an untrusted network--the Internet--and a trusted network--the corporate LAN--as shown in Figure 53.3.
A screening router connects the corporate LAN and the Internet.
Most mid-level and high-level routers being manufactured can be configured to operate as a screening router. A screening router simply allows or denies transmission of a TCP/IP packet based on any combination of the source address, destination address, source network, destination network, TCP port, and UDP port. For example, assume that the screening router has been configured with the following rules:
2. Allow packets originating from the Internet that are in response to packets originated by a local host.
3. Allow packets that have a destination address of 204.57.118.201 and a destination TCP port of 23.
4. Deny packets that do not match any of the above.
The proxy server operates at the Application layer of the OSI Reference Model. This server enables Internet packets to be completely isolated from packets on the local network. Figure 53.4 shows an example of how a proxy sever might be placed on the network.
The proxy server acts as an agent for any workstations on the local network. For example, if a workstation wants to access a WWW page at www.microsoft.com, the workstation passes the request to the proxy server. The proxy server then makes the request to www.microsoft.com and returns the resulting data to the workstation. Because the proxy server is actually making the request, the WWW server sees the TCP/IP address of the proxy server for the source of the request and never communicates directly with the original workstation that made the request.
The proxy server isolates Internet packets from the local network.
There are many different proxy servers, and all have slightly different features. Some features of Microsoft's Proxy Server are listed here; other proxy servers might not have all features listed or might have additional features:
It might seem that a proxy server is the perfect solution for all your needs. There are some points to consider, however, before making a decision to install a proxy server. Some of the disadvantages that you might experience when using a proxy server include:
Windows NT 4.0 now includes a TCP/IP Security option that enables limited protocol screening for incoming TCP/IP packets. If Windows NT is being used to route packets from the Internet to the local network, this feature can be used to set up Windows NT as a screening router.
To configure TCP/IP Security, follow these steps:
2. Select the Protocols tab, TCP/IP Protocol, and click Properties.
3. Select the IP Address tab, and click Advanced.
4. The Advanced IP Addressing dialog box appears (see Figure 53.5). Select the Enable Security check box.
5. Click Configure to display the TCP/IP Security dialog box.
This figure shows the Advanced IP Addressing dialog box.
The TCP/IP Security dialog box (see Figure 53.6) enables custom settings to restrict the type of packet that the server accepts. You have the option to allow only certain packets that are addressed to specified UDP or TCP ports. You also have the option to allow only certain IP protocols to be accepted.
You control the protocols that the server uses via the TCP/IP Security dialog box.
After you select the Permit Only item for TCP Ports, UDP Ports, or IP Protocols, you must specify the appropriate packet types to accept. Packets that do not appear on the list are rejected. See Table 53.1 for common UDP and TCP ports and Table 53.2 for IP protocol numbers.
| Decimal | Keyword | Description |
| 07/tcp | echo | Echo |
| 07/udp | echo | Echo |
| 11/tcp | systat | users |
| 13/tcp | daytime | Daytime |
| 13/udp | daytime | Daytime |
| 17/tcp | qotd | Quote of the Day |
| 17/udp | qotd | Quote of the Day |
| 19/tcp | chargen | Character Generator |
| 19/udp | chargen | Character Generator |
| 20/tcp | ftp-data | FTP Data |
| 21/tcp | ftp | FTP Control |
| 23/tcp | telnet | Telnet |
| 25/tcp | smtp | |
| 37/tcp | time | timserver |
| 37/udp | time | timserver |
| 39/udp | rlp | resource |
| 42/tcp | name | nameserver |
| 42/udp | name | nameserver |
| 43/tcp | whois | NIC name |
| 53/tcp | domain | Domain Name Server |
| 53/udp | domain | Domain Name Server |
| 67/udp | bootp | BOOTP Server |
| 69/udp | tftp | Trivial File Transfer Protocol |
| 79/tcp | finger | Finger |
| 80/tcp | http | World Wide Web |
| 87/tcp | link | ttylink |
| 103/tcp | x400 | X400 ISO Mail |
| 110/tcp | pop3 | Post Office Protocol 3 |
| 119/tcp | nntp | Network News Transfer Protocol |
| 123/udp | ntpd | Network Time Protocol |
| 137/udp | nbname | NetBios Name Service |
| 138/udp | nbdatagram | NetBios Datagram Service |
| 139/tcp | nbsession | NetBios Session Service |
| 161/udp | snmp | snmp |
| 162/udp | snmp-trap | SNMP Trap |
| 177/udp | xdmcp | X Display Manager Control Protocol |
| 179/tcp | bgp | Border Gateway Protocol |
| Decimal | Keyword | Protocol |
| 1 | ICMP | Internet Control Message Protocol |
| 3 | GGP | Gateway-to-Gateway Protocol |
| 6 | TCP | Transmission Control Protocol |
| 8 | EGP | Exterior Gateway Protocol |
| 12 | PUP | PARC Universal Packet Protocol |
| 17 | UDP | User Datagram Protocol |
| 20 | HMP | Host Monitoring Protocol |
| 22 | XNS-IDP | Xerox NS IDP |
| 27 | RDP | Reliable Datagram Protocol |
| 66 | RVD | MIT Remote Virtual Disk |
Because users can access native Windows NT services over the Internet, precautions must be taken to avoid unauthorized access to these services. The following sections show you some services that are at risk for unauthorized access. For more information about securing native SMB services, see Chapter 26, "Securing NT Server."
The user account database must be protected at all times. Because all Windows NT installations create several default accounts such as the Administrator and Guest account, a hacker already knows half of the information needed to gain access. All a hacker needs to gain access to the system is to guess the Administrator password. Furthermore, on Windows NT systems prior to 4.0, the Guest account is enabled by default with no password set. This problem has been corrected with version 4.0, and the Guest account is disabled by default.
One of the best ways to secure the Administrator account is to rename the account to something obscure. You should also make sure the password is set to an alphanumeric password with at least eight characters.
The Windows NT Registry is a vital piece of the Windows NT operating system. Because an invalid Registry entry can cause Windows NT to operate improperly or even not operate at all, you must take care when making direct changes within the Registry. This sensitive data in the Registry must be protected from all unauthorized changes.
A default Windows NT installation gives the Everyone group write access to much of the Registry. In versions prior to 4.0, this was a big problem because it gave remote users the capability to manipulate the Registry on any Windows NT Server or Workstation on which the user had an account or the Guest account was enabled. Windows 4.0 introduces a fix to this problem by adding the following Registry key:
The presence of this key in the Registry enables only an administrator to edit the Registry from a remote workstation.
NOTE: This Registry key is present by default in Windows NT Server 4.0 but is not present by default in Windows NT Workstation 4.0. To disable remote editing of the Registry on Windows NT Workstation 4.0, you must create the key manually.
On FAT partitions, files can be secured only by setting share permissions. On NTFS partitions, files can be secured by using share permission and/or NTFS security permissions. By default on NTFS volumes, most directories and files are set with the Everyone group having full-control permissions. It is important to examine all permissions for shared directories and set the minimum access required for your particular applications.
It can be very easy to get file permissions set to something other than what you expected. For example, copying a file causes the file to inherit permissions from the directory into which the file is copied (unless you use SCOPY), while moving a file preserves existing permissions on the file.
It might be useful to use a third-party utility such as Somarsoft DumpAcl (http://www.somarsoft.com) to produce a report of the security on each directory. It can be very impractical to manually examine each directory and file permission. DumpAcl only lists file or directory permissions that vary from the permissions in the parent directory. This makes it easy to see which directories or files for which you might need to change permissions.
If your Windows NT Server provides only traditional TCP/IP services, such as World Wide Web Services, you can elect to completely prevent access to all SMB services over TCP/IP. This can be accomplished by configuring your Internet router to prevent all SMB traffic or by configuring your server to reject all SMB traffic.
Blocking SMB Traffic by Using a Router. If your router to the Internet supports protocol filters such as those discussed in the section on screening routers, the router can be configured to block all SMB traffic to the local network. This will prevent anyone on the Internet from accessing any systems on your local network that use SMB protocol.
NOTE: When disabling the SMB protocol over TCP/IP, other TCP/IP services such as FTP and WWW are still accessible even though SMB services are not.
To configure your router to block SMB traffic, you must configure the router to discard packets with the following ports:
These ports are used for NetBIOS over TCP/IP. Disabling these ports prevents any SMB over TCP/IP packets.
Blocking SMB Traffic at the Server. You also can disable native SMB traffic at the Windows NT Server by disabling certain network bindings. To access the Bindings information, Open the Network Properties dialog box, and click the Bindings tab. The Bindings configuration dialog box appears (see Figure 53.7).
Bind protocols to adapters by using the Network Bindings configuration dialog box.
There are three ways to list the network binding information: By using the Show Bindings For pull down menu, select All Services, All Protocols, or All Adapters. If you have multiple network adapters, it might be best to select to show bindings for all adapters. This way, if you only want to disable bindings on the network interface that is connected to the Internet, you can do so without disabling SMB services on the other network interfaces.
To disable SMB services over TCP/IP, you should disable the bindings to WINS Client (TCP/IP). Accomplish this from the Bindings Configuration dialog box with the following steps:
2. Double-click the network adapter for which you want to disable SMB services.
3. Click WINS Client (TCP/IP) and then click Disable.
4. Click OK.
These steps disable all SMB services for that adapter. This prevents access to services such as native file and print services but still enables access to Internet services such as WWW.
When a Windows NT Server has Internet TCP/IP services installed, it becomes open to many of security problems that are associated with those services. There are several things to keep in mind when running these services, as well as some steps that can be taken to reduce the chance of unauthorized access. The following sections address these for the most common services.
All data that is sent over FTP is sent in unencrypted format. This can be a problem if users log on to the FTP server with their Windows NT username and password. Anyone who can intercept the transmitted packets can decode the packets and find the user's name and password. Fortunately, there is an easy solution to this. If you designate an account for the FTP service to use and restrict users to only using anonymous login, then a potential intruder won't be able to decode the username or password. The FTP service can be configured to allow anonymous logon under any predefined account. The user will log on to FTP by using anonymous and will never have to know the real account and password in which the FTP service is running.
Another potential problem area is file permissions. It is important to set the appropriate file permissions for FTP users. To access the FTP file permissions:
2. Double-click your server name to the left of the FTP Service.
3. Select the Directories tab and double-click the directory on which you want to set permissions.
If the FTP area resides on a FAT partition, only two file permissions can be enabled or disabled--Read and Write--as depicted in Figure 53.8.
You can only enable Read and Write permissions on the FTP Directory Properties dialog box if you're using FAT.
The settings shown in Figure 53.8 are global settings that apply to all FTP users. If the FTP area resides on an NTFS partition, then standard NTFS security permissions apply in addition to those set with the FTP Directory Properties dialog box.
NOTE: In versions of Windows NT prior to 4.0, users were initially placed in the specified home directory but were able to change to other directories, including parent directories of the home directory. In Windows NT 4.0, users cannot access the parent directory of the specified home directory.
A WWW server is a complex application. By installing a WWW service on your Windows NT system, you open up a rather large hole through which a malicious user can try to gain unauthorized information or perform actions of a destructive nature.
Many people have found and will continue to find security holes in different WWW server services. To maintain a secure WWW server, always check with the company responsible for your particular WWW service. For example, if you run Microsoft IIS, make sure you frequently check Microsoft's Technical database and its FTP site for any new IIS patches. When a new security hole is found, there is usually a published workaround or an available patch that can be applied to fix the problem.
Here are several suggested configuration options to set to help secure your Microsoft IIS service:
© Copyright, Macmillan Computer Publishing. All rights reserved.