![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
Security Principles Windows 2000 A lot of the same security principles for Windows NT 4 also apply to Windows 2000. A few that we would want to add: 1. Active Directory administration delegation. Give administrators the proper rights. If you want to delegate the ability to reset passwords, you don't need to grant "Enterprise Admin" rights. 2. Shut down services. Though we discussed turning off unnecessary services in the Windows NT 4 section, there are many new services to be explored in Windows 2000, and many of them need to be shut off. For one, some components of Internet Information Server are standard options, meaning that if you don't opt to not install them during setup, you get them. Be sure to check them out in the services control applet and turn off what you don't need. Also, a new service called the Remote Registry service has popped up, giving you the ability to remotely manage the registry of remote computers. Turn this bad boy off if you know you're not using an application or utility that takes advantage of it. 3. EFS Recovery Agents. By default, the first administrator in a Windows 2000 domain (Enterprise Admin is the user) is the EFS Recovery Agent, giving him the ability to recover files encrypted via the Encrypted File System. In a domain setting, a domain policy needs to be established to enable EFS. Give out the password to the Enterprise Admin CAREFULLY. Users have the ability to encrypt their files on a file-by-file basis, and giving access to the enterprise administrator account gives the holder of that account the ability to decrypt anyone's files. Give only to your most trusted administrators. 4. Filtering and IPSec. New to Windows 2000 are some great features called TCP/IP filtering and IPSec. TCP/IP Filtering allows you to block or allow specific TCP/UDP ports to your system. IPSec allows you to block ports as well, but it also gives you the ability to restrict communications only to computers that run IPSec and secure data by encrypting it on the wire. Doing this in Windows 2000 takes a lot of CPU horsepower; however, there are now "smart" NICs that can perform the IPSec calculations onboard, leaving your CPU cycles for something much more useful. 5. Group Policy. No discussion about Windows 2000 security would be complete without a glance at Group Policy. Administrators can use Group Policy to lock down machines, distribute software, and more. It's a wonderful feature, but extremely complex. Planning GPOs for efficiency and workability is a tedious process. Coupled with Group Policy and my first topic, Administrative Delegation, is a concept called Roles Based Access Control. In a nutshell, the concept is to define roles (rights, responsibilities, access levels throughout the network) and assign those roles to employees. Designing a helpdesk type of role might include delegating the authority to reset passwords and add machines to the domain or giving an administrator the ability to manage security group memberships. A tier-two helpdesk role might consist of all of the previous rights plus the ability to stop/start some network services. A variety of great tools exist for this, including Quest ActiveRoles and Fazam 2000. 6. Terminal Services. Terminal Service is now available in Windows 2000 as an installation option. Be careful to limit the access users will have when attached to the console--remember, even though users are working at their desks, it is like they are actually on the server's console. Solaris Though most unices are much more secure by default than Windows servers, vulnerabilities still do exist that can grant a hacker root level access. On top of that, there are several services that need to be turned off, just like in the Windows world. 1. Turn off unused services. Just like Windows machines, a standard Solaris installation will have a plethora of ports listening for activity. Most people only need 5-10 of these services and ports actually listening. For non-NIS environments, it's even less. Most of the time, you'll really only want ftp and telnet available. If you have a large environment, you may want to leave shell, login, and exec open for remote administration. We'll talk about how to lock these down later. 2. Uninstall unused packages. Bloatware. It's everywhere--even in the Unix world. There are a couple of packages distributed with Solaris that are installed by default, even though they have a long history of compromise. You'll want to get rid of SUNWsadmi and SUNWsacom right off the bat. 3. Use TCP Wrappers to lock down your system. TCP wrappers is a great utility that allows you to allow/deny only IP addresses and networks that you specify. It's comparable to adding an ACL to your server. TCP Wrappers has a database of hosts/networks that are either allowed or disallowed access to your server, based on service type (in.ftpd for FTP, in.telnetd for Telnet, etc). When a host contacts a server runnign TCP wrappers, TCP wrappers intercepts the socket call and evaluates the source address and port against its database of allowed/denied hosts. If the source host is allowed, TCP Wrappers encapsulates your services (exec, login, shell, ftp, telnet, ssh) and then allows communication over that specific port. 4. Use SSH to replace Telnet and SFTP to replace FTP. Telnet and FTP are great services. However, they are extremely insecure. Both Telnet and FTP pass data in clear text, meaning that someone on the network can intercept packets and read them without having to perform any data decryption. Everything in a Telnet/FTP session is sent clear text--the handshake, passwords, commands, and output. Secure Shell (SSH) and Secure FTP (SFTP) are secure, encrypted replacements for these clear-text services. Using DES or 3DES (or another cryptographic algorithm), SSH encrypts ALL data exchanged between hosts. There are several versions of SSH available, both commercial and non-commercial. Commercial users will probably want to check out http://www.ssh.com, the leading provider of commercial Secure Shell. Non-commercial (home, hobby, or educational users) may want to look at http://www.ssh.org. Another free provider is http://www.openssh.org, but their software requires much in the form of additional libraries and packages to be installed. |
website design: © www.aaronguilmette.com