| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1.3 Non-Essential Services and Protocols (Page 1 of 2) By simple math, the more services and protocols a host has running, the more targets an attacker have to aim at. As an example, if he cant find an exploit for Sulphur FTP Server v1.0, running on the host, he can move on to attacking Ravian SNMP Management Tool v2.3. An important question to ask is, if the host in question is simply a file and print server, are these extra services required? They may be installed by default as part of the operating system, but they provide potential routes into an organization by the unwary system administrator. Similarly, unnecessary open ports on boundary firewalls are inviting targets for attackers to probe. You can often reduce your networks vulnerability to both random and specifically targeted attacks, simply by disabling non-essential components and protocols. In the future a concept called port knocking may tighten up the essential services and protocols 61
When determining which services to run, and which to disable, there are two possible approaches you can take. First, you can choose the optimistic route. This involves leaving everything exactly as it is, and only removing services and closing access points (such as firewall ports), as they become an issue. An example of this involves the IIS.htr remote overflow exploit62. An optimistic system administrator may put a default installation of IIS onto the corporate network and hope for the best. Then, when the .htr advisory is released, the system administrator may choose to disable the .htr extension filter only. Unfortunately, because the administrator was on holiday and didnt read the advisory until 3 days later, the corporate web server was already broken into and Trojaned (see 1.4.2) before the hole was closed. Now, the administrator has a lot more than just an IIS extension filter to worry about. This is why the second approach is recommended: its proactive, rather than reactive. The second approach is the pessimistic route. You take the view that nothing on your network is required, and close every port, service and share before issues arise. This involves changing settings on servers (disabling unused services, removing shares) and on the routers and firewalls (setting up rules that restrict connections to and from ports on your organizations machines, allowing only those types of connections which are specifically needed). You then open only the ports that are specifically required and justifiable, while keeping firewall rules extremely tight. Lets look at some specific examples. A corporate web server that is publicly accessible from the Internet would only require port 80 inbound to be opened on the firewall a web server should never independently make a connection outward, and unless its running other services (for example, SSL, which uses port 443), it should never be on anything other than port 80. This methodology extends to services on servers themselves, as well. That is, unused options or subsystems of services should be disabled as well. For example, the IIS exploit mentioned above would be ineffective against this corporate web server if the system administrator had disabled unused IIS extensions prior to deploying it. __________________ 61. http://www.portknocking.org/ 62. http://www.eeye.com/html/Research/Advisories/AD20020612.html
Home - Table Of Contents - Contact Us CertiGuide for Security+ (http://www.CertiGuide.com/secplus/) on CertiGuide.com Version 1.0 - Version Date: November 15, 2004 Adapted with permission from a work created by Tcat Houser et al. CertiGuide.com Version © Copyright 2004 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||