It has been a rough August for security professionals and network users alike. Cisco discovered and repaired a major vulnerability in their Internet Operating System, while MSBlaster and SoBig variants kept everyone busy with hype and substance as folks sought to reduce the damage from these attacks. At some points, even medium sized networks were experiencing thousands of attack attempts each day. In the case of SoBig, anti-virus email virus alerts caused as much disruption as the virus itself by further increasing the network traffic consumed by the attack. As I write this now, Microsoft is encouraging their users to update their systems for another RPC exploit, which could be as damaging as MSBlaster.
In the end, the success of the Microsoft attacks should not surprise anyone. In each case, Microsoft provides patches to their users that immunize their computers against these attacks. In each case, the majority of the public does not download and patch their systems. To those of us that do, we watch wave after wave of attacks break upon our firewalls and IDS's like waves against the rocks. These attacks can be so aggressive that many have begun to despair that patching systems on time is ultimately a futile approach towards security - users are either ill prepared to manage their own systems, unaware that the problem affects them, or unwilling to patch their systems after having been burned by a patch in the past.
This realization has led many in the security and networking field to suggest that ISP's shoulder a greater portion of the responsibility for responding to Internet attacks. On the surface, this would seem to make sense as Internet traffic is passed around by ISP's and these service providers presumably have the expertise to be able to filter Internet traffic beyond which we can expect from our average network user or administrator.
While on the surface, this seems like a simple solution, it is complicated by a number of factors - factors that would not only make it difficult to apply, but if it were applied, would run contrary to some of the major design goals of the Internet and negatively affect its operation. Even if these negative elements were overlooked, in a couple of years we will have engineered ourselves into a position where, after a brief period of quiet, all of the security problems that we are facing today will resurface. In short, requesting ISPs to filter IP traffic to improve security will not work.
Prior to discussing the pro's and con's of port filtering, we would do well to first review a couple of the philosophical design goals that have made the Internet what it is today - for good and for bad.
"Connectivity is its own reward." The primary value of the Internet is provided through connectivity. When there are only 20 people in the world that use a messaging system, be it email, ICQ, or AIM, the value of that messaging system is quite low. When the 21rst person joins the messaging system, the value to everyone increases. For every system that connects to the Internet, its value increases for all users. This connectivity is also why service providers have such an incentive to work with each other to ensure that full network connectivity is available. If ISP 1 provides limited connectivity to its customers, then it is not selling a very valuable product. If ISP 1 can provide connectivity to everyone in the world, that is something worth paying for. The conclusion is that connectivity increases the value of the network to everyone. Anything that breaks this connectivity reduces value.
"Rough consensus and running code." Designers of the Internet long ago decided to let market forces determine in which direction the Internet would evolve and this is reflected in their motto. This is a short hand way of saying that Internet standards are not subject to an official vote, but that the Internet Engineering Task Force (IETF) may publish sometimes-competing standards and let users and vendors determine which protocol becomes the ultimate standard. The IETF realizes that the politics that follow voting only complicate standards development, lead to long development times, and create standards that are filled with features and options that satisfied some constituency, but are rarely used in practice and complicated the protocol for everyone else. This philosophy has resulted in a number of efficient protocols that have developed at a remarkable rate. Allowing the market to drive the evolution of the Internet has in a large part been a key element in its overall success.
Let's keep these in mind as we examine the problems with ISP traffic filtering. First, we'll examine some of the technical hurdles that would make this filtering difficult to apply.
The first is straightforward. It would cost the ISPs quite a bit of money to implement this filtering. Consider what must be done to make such filtering work. Each ISP would need to determine which protocols should be filtered and which should be allowed. Unless there were some global consensus on what these ports should be, each ISP would invariably have customers that required exceptions to these rules. The ISP would then either tell the customer that no exceptions can be made and drive the customer to another ISP that allows exceptions, have to charge clients extra for custom access, or absorb the costs of managing custom access. Each of these solutions has a number of problems for the ISP but they all revolve around the idea is that the value of an ISP is to provide access and that when they limit access to their customers, they are reducing their own overall value to the same customers they are trying to serve.
But, assume that the ISPs should be held financially responsible for the actions of their customers and that cost is not a motivating factor. There are still the technical problems that must be overcome. The "core" of the Internet, the big powerful routers that forward our traffic at fantastic speeds are not built for filtering traffic. In fact, any type of filtering would severely impact the performance of these routers. To avoid this problem, it is recommended that filtering be pushed to the "edge" of the network where bandwidths are much lower. This compounds the management process in that there are many more edge devices than there are core devices. While the problem can be solved with new technologies, large ISPs don't switch out hardware like the ordinary person purchases a new VCR. Decisions like this can only be made over the course of years - first the technology needs to be developed, then vendors will compete for the ISPs attention, then the ISP must perform extensive testing to ensure that the vendor solution will not break existing services, and then, and only then can the product be deployed over the course of months and years. All of these steps must be taken to ensure that service providers can offer the services that their users expect. It is not acceptable for a service provider to shut down the network on Sunday and bring it back up the following Wednesday for a forklift hardware upgrade!
Even were this possible, in the end, this new technology would have to be paid for - raising connectivity prices and reducing the overall value of the network to everyone.
Assuming that the cost and complexity issue can or must be overcome, the second major issue is how to decide which ports should be filtered. In order to preserve the value of the network, we want to ensure that all ISPs are filtering traffic as consistently as possible to preserve as much connectivity as we can. There are two ways to do this. The first is to assume all traffic is "good" and unless specifically blocked, it is allowed. The second is to assume that all traffic is "bad" and unless specifically allowed, we block it. Either way, there needs to be some determination as to how to define "good" and "bad" traffic.
One school of thought is that there are certain protocols that should not be allowed on public Internets. This school gained a lot of popularity in August as MSBlaster was making the rounds. The ports used by the MSBlaster worm, 135- 139 and 445 were used to infect vulnerable systems. The theory is that these ports are typically only used in a LAN for communications between trusted systems and therefore should not normally be encountered on the Internet. Thus, there will be no harm done in filtering these ports as common practices does not see them being used over the general Internet.
A simple statement like this has a number of implications. The first question is who gets to determine the "good" ports and the "bad" ports? You may say that port 7777 (Unreal Tournament 2003) is a "bad" port for your business, but someone else may say that this is a good port and part of a multi-billion dollar Internet gaming Industry. Furthermore, people do use these the above mentioned Microsoft ports for legitimate applications - some people like to access Microsoft Exchange and all of its calendaring and scheduling features over the Internet. Is that a good use of a port or a bad use?
The second major implication is to consider what a system like this would do for innovation. We are only now beginning to understand what the connectivity of the Internet means for our culture for both good and bad. Imagine the Internet without the advent of the HTTP. After all, for those using Gopher or Archie, why was any other protocol required? Yet HTTP became a major driving force for the Internet through the 1990's. Any type of filtering is bound to affect the development of new protocols and would affect the long-term evolution of the Internet.
One proposal would be to set up a quasi-judicial body to review the port usage and then determine its relative degree of "goodness" or "badness." Surely that would be fair? In practice it of course would not be. Consider the Microsoft ports in question above. Is it realistic to think that Microsoft would not have the legal or financial muscle to ensure that the very ports that we are describing as bad would not be put in the good category? This approach also moves us away from one of the essential principles of the Internet, rough consensus and running code. It would no longer do to create the next killer app and release it to the public, but it the protocol the application used would not only require a technical review through normal channels, but would also require a stamp of approval by this judiciary body before anyone got to use it. The amount of money and horse- trading that would be tossed around would guarantee that only the largest, most well funded organizations had their protocols approved for Internet passage, possibly at the expense of their competitors.
If such a body were set up, it would then need some sort of enforcement power in a number of different jurisdictions around the world. Since the implementation and enforcement of these rules would be up the ISP, it is a sure bet that both are going to be inconsistent. This is going to lead to breaking the connectivity principle as some protocols will work on some parts of the Internet and don't work on other parts. In the end, this reduces the overall value of the network to all involved.
But let's assume that this hurdle was overcome as well. In this solution ISPs have solved the financial and management hurdles that prevented them from running traffic and in some way we have come up with a globally agreed upon list of the good traffic that was to be allowed. This still won't solve our security problems.
The port assignments that we currently use are considered "suggestions" for operation rather than hard and fast rules. The fact that all of us configure our web servers to listen on port 80 is really a matter of convenience. Deciding to use multiple ports makes our network design, including security, a lot easier. It also allows us to run multiple servers on a single machine. Thus one physical server can act as a mail server, a web server, and a DNS server - IP traffic can be multiplexed because the higher layer transport layer can sort the traffic out according the port it is destined for.
We use port information quite extensively in our firewall configurations. For the most part, we can assume that traffic heading out of our network destined for port 80 is heading to a web server out on the Internet. Thus we can allow our users to surf the web and send email while at the same time preventing them from using instant messaging and using peer-to-peer file sharing. This system is not perfect by any means. Many companies providing network services as well as hackers know that most organizations allow traffic out port 80 and thus configure their traffic to use that same port. This clearly lowers the effectiveness of our own port filtering and requires that we use more expensive application layer filtering to ensure that our users are acting appropriately.
Having our ISP filtering ports will have the same effect. As "bad" ports are shut off, the traffic that normally is sent over those bad ports will easily migrate to the remaining good ports. The result is that vendors and hackers alike will abandon the bad ports and the pool of "good" ports will be polluted by this migrating traffic. After all of our efforts to ensure that ISPs can cost effectively manage this port filtering, and after we negotiate, litigate, and implement a common body of good and bad ports worldwide - we will shortly be in the exact same situation that we are in now. Since the remaining good ports are being used to ferry all sorts of traffic it will be even more difficult for us to differentiate the good traffic from the bad. This will require more sophisticated and expensive security devices on all of our networks as we could no longer trust port information to give us any guidance as to what the payload of the traffic actually is. For the users that are apprehensive about security now, we will have only made the same level of security more complicated for them to implement in the future.
After all of that effort we will see that it is not the port that is good or bad, but the traffic that is being transported. Filtering ports will not solve that problem, but fixing the software that is vulnerable to this traffic will. The short-lived false sense of security will give software vendors and users alike one more reason not to code with security in mind, update their systems, and take responsibility for their connection to the Internet.
While port filtering is a bad idea that will not work, it is easy to understand the frustration of users whose systems are being affected by repeated attempts to hack their systems. Most of these attacks are coming from people that are unaware that they themselves have been hacked or are unable or unwilling to fix their systems. Despite this frustration, it is important not to jump what sounds like the quick and easy fix. Better education, more secure applications and operating systems, and systems that are easier to use for all involved is where we need to be focusing our efforts right now.
Clifford Riggs is Co-Founder and owner of Proteris Group. Proteris Group LLC
assists companies by evaluating their information systems, performing
comprehensive risk analysis, and aiding in the selection of appropriate security
solutions. The detailed technical knowledge of Proteris Group allows the firm to
lead in the implementation of even the most complex solutions. For more
information about Proteris Group LLC, visit their website at www.proteris.com.
Proteris Group's offices are located at 40 Dorset Lane Suite 101, Williston, Vermont.
Cliff is also author of the forthcoming book, Network Perimeter Security: Building Defense In-Depth.
Copyright (C) Clifford Riggs. All rights reserved. Used by permission.