| [ Team LiB ] |
|
6.4 Protecting Your KDCSince the KDC contains the secret encryption keys for all of the users as well as all of the services in your administrative realm, it is obviously very important that the KDC be well protected. It is both an advantage and a disadvantage of Kerberos that all key information is centralized; on one hand, it is easier to heavily secure one machine than to try to heavily secure a lot of distributed machines, but on the other hand, a compromise of the KDC machine compromises all authentication information in the realm. Therefore, the machines that run KDC software should be specially prepared and dedicated solely to this purpose. During the operating system install, the machine should be physically separated or firewalled from the network to prevent exposure to the outside world. The machine is most vulnerable to outside attack during the installation of the operating system and KDC software, since the safeguards protecting the machine have not been set up yet. For example, automated worms such as Code Red have exploited unpatched Windows boxes running IIS within less than 10 minutes of exposure to the outside world. No other server software should be installed on the KDC, especially servers that have high public visibility such as mail, web, and database servers. Remote login, if required, should be limited to a very small subset of administrative users who have local login passwords separate from their Kerberos passwords. Passwords for the administrator or root account on the KDC machines must be tightly controlled and changed periodically to prevent compromise. Finally, physical security of the KDC machines is paramount. Physical access to any machine implicitly gives an attacker administrator-level access to that machine. Since the KDC contains all of your Kerberos realm's secret keys, physical access to the KDC would compromise all of those keys. Therefore, KDCs should be located in a locked room with limited access, preferably with some type of entry/exit logging. And remember to always log out of the console of the KDC after performing any necessary administrative tasks. 6.4.1 Protecting a Unix KDCFirst, choose a Unix operating system that you are intimately familiar with. Good selections for a dedicated KDC machine include the free Unix systems, such as FreeBSD, OpenBSD, and Linux. These operating systems can be downloaded for free, include full source code, and are well supported by the online community, which addresses security issues quickly. Other Unix operating systems such as Solaris are also good choices, but more care must be taken in preparing commercial operating systems, as they usually ship with more network services enabled by default. When installing the operating system, choose the smallest distribution of software possible. Since there will not be any users directly logging into this machine's console, do not install X Window System servers or clients, or desktop environments such as CDE, Gnome, and KDE. The only optional component that should be installed is a C compiler to compile the KDC software, if you are going to use one of the open source Kerberos implementations. After operating system installation, download and install all recommended security patches applicable to your operating system.
An important factor in the security of your KDC is its network visibility. It is important to disable all network-based services on your KDC other than the KDC software itself, as well as a Secure Shell server if remote login is required. To determine what network services are installed, use the netstat command from a shell prompt. Let's take a look at an example output from a Linux machine: % netstat -an Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 192.168.1.83:749 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:749 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 192.168.1.83:88 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:88 0.0.0.0:* LISTEN tcp 0 0 192.168.1.83:4444 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:4444 0.0.0.0:* LISTEN tcp 0 180 192.168.1.83:22 192.168.1.20:61096 ESTABLISHED udp 0 0 192.168.1.83:464 0.0.0.0:* udp 0 0 127.0.0.1:464 0.0.0.0:* udp 0 0 192.168.1.83:88 0.0.0.0:* udp 0 0 127.0.0.1:88 0.0.0.0:* udp 0 0 192.168.1.83:4444 0.0.0.0:* udp 0 0 127.0.0.1:4444 0.0.0.0:* Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 1353 /dev/gpmctl unix 5 [ ] DGRAM 948 /dev/log unix 3 [ ] STREAM CONNECTED 1459649 unix 3 [ ] STREAM CONNECTED 1459648 unix 2 [ ] DGRAM 1376 unix 2 [ ] DGRAM 1085 unix 2 [ ] DGRAM 957 % The netstat command outputs the state of the system's networking stack. It has a variety of options depending on your particular flavor of Unix, and each vendor's may produce different output. In order to see the full list of options available for your operating system, pull up the manual page for netstat. Another tool that is useful for enumerating network ports and the programs that are listening on those ports is lsof; it is available from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/lsof.tar.gz. The above machine only has OpenSSH and Kerberos servers listening to the network. This is a recommended configuration; it minimizes the network visibility of your KDC as much as possible. See the following section, Section 6.5, for a full list of the port numbers that the Kerberos protocol uses for communication between KDCs and clients. Once a clean port configuration has been established, it is recommended that you produce a file that contains a netstat, ps, and preferably an lsof listing, so that any differences between your clean configuration and possible backdoors (installed as part of an intrusion) can be easily spotted later. These files, as well as a copy of the tools that were used to generate these files, should be placed on a CD-ROM or other write-protected, removable media to prevent modification by an attacker.
6.4.2 Protecting a Windows Domain ControllerEvery Windows domain controller in your network also acts as a KDC, and needs to be secured appropriately. The general advice that pertains to Unix KDCs also applies to a Windows domain controller. Just like a Unix KDC, the Windows domain controller contains all of the authentication information (and much more). To properly secure a Windows domain controller, first disable all unnecessary services, disallow logins to the server except for a small number of administrative users with secure passwords, and apply the latest set of service packs from Microsoft. Unfortunately, a default installation of Windows 2000 Server will install and enable Internet Information Services (IIS), which, unpatched, contains several security vulnerabilities that allow an attacker to gain administrative control of your server. Therefore, it is recommended to keep the machine disconnected from the network until IIS is disabled or removed. To remove IIS, open the Add/Remove Programs item in the Control Panel, choose Add/Remove Windows Components, and uncheck Internet Information Services.
With IIS out of the way, a good next step is to apply the latest batch of service packs from Microsoft. Doing this as early as possible in the process reduces the chances of a strange conflict arising that renders some critical service unusable. The easiest way to accomplish this is to use the Windows Update tool; updates are also available at Microsoft's site at http://www.microsoft.com/windows2000/downloads/servicepacks/default.asp. Finally, we'll set some restrictive policies on the domain controller itself. Fortunately, Windows provides for a special set of policies that apply to the domain controllers separate from the rest of the machines in the domain. Those policies can be found in the Domain Controller Security Policy snap-in, located in the Microsoft Management Console application. First, let's
restrict login privileges to a small set of users. Inside of the
Domain Controller Policy window, open the Windows Settings
Next, we'll tweak some settings in the Security
Options folder (which is also located inside of the Windows Settings
Finally, we'll tweak the following setting, located
in the Windows Settings
Just like with a Unix KDC, it is recommended that you generate a "clean" network port listing and process listing and keep a copy in a safe place, such as on floppy. A good tool that can be used to generate a network port listing similar to lsof on Unix is Active Port, available from http://www.webattack.com/get/activeports.shtml. These are good first steps for securing a Windows domain controller. Further information is available from Microsoft, including the Microsoft Solutions for Securing Windows 2000 Server located at http://www.microsoft.com/technet/security/prodtech/windows/secwin2k/default.asp and the Windows 2000 Hardening Guide, located at http://www.microsoft.com/technet/security/prodtech/Windows/Win2kHG/default.asp. 6.4.3 Continual MaintenanceThe focus on securing the KDC should not end with the successful implementation of a Kerberos network authentication system; the administrator must continue to monitor security mailing lists, such as Bugtraq, and vendor-specific mailing lists that announce the latest security patches for both the operating system and the Kerberos KDC software. While keeping the KDC up-to-date with security patches may cause occasional downtime and service outage, it saves days of lost productivity caused by reinstalling the KDC, re-keying all services, and resetting all user passwords in the aftermath of an intrusion.
In particular, a continual maintenance policy should include periodic reviews of the KDC event or system logs, as we'll discuss later in Section 6.6. Also, a periodic review of the open network ports and active processes against the clean configuration you generated in the previous section should be performed to detect any changes. Changes that have occurred due to documented maintenance and software updates must be integrated into your clean configuration port and process dumps. Other changes should be investigated, as they may be signs of attack. While the above discussion outlines the basics involved in securing your KDC machines, more detailed information about securing Unix and Windows hosts can be found in Securing Windows NT/2000 Servers for the Internet by Stefan Norberg (O'Reilly), as well as Practical Unix and Internet Security by Simson Garfinkel, Gene Spafford, and Alan Schwartz, also available from O'Reilly.  |
| [ Team LiB ] |
|
Security Settings