February, 2000 Volume 18.2
Netwatcher (ISSN 0890-5800) is a monthly publication of CIMI Corporation. Subscription information is available here. Copyright © 2000, CIMI Corporation. All rights reserved. No publication or reproduction of this document is permitted without the express written consent of CIMI Corporation.
 |
Management Briefing |
We’ve had a running debate over the last five years on whether networks would be “smart” or “dumb”. Some have held that a completely stupid network, a simple transport web, could be exploited by end systems in any way they choose, and would thus be more generally useful. Others believe that adding intelligence to the network raises the level of capability the providers can offer, making this kind of network profitable where dumb ones would not be.
There’s a good chance that the issue is being resolved by market forces, and that the resolution will be influencing purchase decisions by late this year. Not surprisingly, the answer isn’t either “smart” or “dumb”, but somewhere in between. We’re calling the trend “focused intelligence”.
We’ve noted in the past that familiar networks like the Internet and the PSTN are examples of a network in which service features and transport features are intertwined. The user joins such a network as a kind of restricted member, not strictly as a consumer, and obeys the rules of the devices.
Multi-service networks can be built in a similarly interwoven way, as long as one uses a protocol that’s suitable for all the services—both in terms of long-term fulfillment of user needs, and in terms of facility of migration from existing network investments. The concept of IP convergence was based on the assumption this would happen as a result of the Internet craze.
What we’re now seeing is that the process of network evolution is much more complex, particularly when the “network” we’re talking about is really hundreds of independent networks from different providers, each driven largely by their owners’ objectives, and each regulated (or not regulated) in a different way.
It’s clear that networks are generally going to divide up into two classes—access and service. An access network is one whose mission is to connect to end users. A service network is one whose mission is to create a geographically delineated community of users who agree on a common set of procedures. Some service providers may offer both, but most will probably focus on only one of these types.
If the access and service networks all happened to select the same protocols, we’d have a universal network based on a single strategy—convergence. If they don’t (and they won’t), we have to examine how the diversity impacts users.
Private network users could be expected to adapt easily to a service model in which multiple access and service network types exist. A given private network would presumably fit best with a particular access/service combination, and the user would simply pick a player or players who could provide it.
Public network service users have a tougher problem. The nature of public networking is community-building, and that makes it highly undesirable to have users fragmented by network type. Thus, we would have to assume that a common public network model would be introduced to this mix of networks, in one or more of the following ways:
1. The public network service could be created at a higher layer than any of the access or service networks operate, so this higher layer could provide a unified system of communications to users even though they have a different set of network technologies supporting them. To a degree, the cellular/PCS relationship with the wire-line PSTN is an example of creating a voice service model this way.
2. The services of each access/service network could be “gated” with each other through mediation devices. This would require that each network to be linked had some sort of procedure for providing the target service (voice, for example), and that the risk of not having uniform services across all combinations of technology was acceptable.
In the first case above, the ideal place to provide the higher-level service intelligence would be at the edge, where each consumer linked to the network. If this were done, each user would have a service dialog with an agent device, which could then mediate on behalf of the user with the network resources actually available.
In the second case, the ideal place to provide the intelligence would be somewhere inside the network, at the boundaries between administrative jurisdictions or technologies. Each mediation device would then be a proxy for the users of the foreign network it served, making them virtual members of the other network for purposes of addressing services to them.
This model suggests that the diversification of service provider missions we’ve seen in the last five years will bring about a focusing of technology in two places—the point of user attachment and the points of provider boundaries’ touching one another. That, it turns out, fits well with some of the specific technology trends.
In the access networking space, we’ve got a battle between the incumbent LECs and everyone else. The ILECs are all planning an ATM-centric infrastructure consisting of fiber remotes and short-run copper or fiber loops. This structure, as we’ve said in prior issues (see October and November, 1999, in particular) is largely driven by recent regulatory changes. The competitors are apparently looking more at pure fiber, with “metro networks” targeting delivery of speeds as high as OC-48 to users.
The primary issue with access networks is the profitability of a pure access play. Service providers, like everyone else, need high margins to succeed, and access networking doesn’t provide users with anything but…well…access. “To what?” one might ask, and the answer would be a service of some sort. It seems clear that a pure access play would be profitable only if one focused on high-volume, high-value, sites. That would limit the access player to no more than the top 25,000 to 50,000 locations, which sounds like a lot but is less than one percent of business sites. In some metro areas, there are no companies who would qualify.
The basic problem is that there are only about 200,000 business site locations in the US that employ more than 100 people. Without a fairly large worker population, a site can’t be expected to consume large amounts of bandwidth. Worse yet, this figure includes a huge number of essentially non-information-consuming sites. Most are manufacturing sites, where the typical worker isn’t an information consumer at all.
In an access network, the infrastructure you deploy tends to be directly proportional to the number of customers you decide to target, unless you target very small firm sizes to achieve high density. That would reduce the revenue per customer and increase the scope of the build-out. Big customers mean essentially a one-off provisioning approach. Small customers mean efficient but high-cost infrastructure. All of this means that it would be very challenging to be an access player alone, unless you have a means of penetrating deeper into the population base. That’s why the RBOC initiatives for widespread digital broadband infrastructure are so important.
The problem, then, with the access network play is that the assumptions we’ve made to justify it don’t hold. Most of the projections on access bandwidth growth are assuming that the current levels of growth in broadband connections (which are largely due to creation of an Internet presence) can be projected across the entire base of businesses. That simply isn’t true, and so there is a major question of whether a significant high-speed access market exists at all. If it doesn’t, then the access business is a mass market, and only ILECs, cable TV firms, and possibly public electric/gas/water utilities could play there.
Service networks are the other extreme, in many ways. Services can command margins as high as 85% (some voice custom calling services and transactional VPN data services fall into this range). Service networks can expect to have customers aggregated by the access infrastructure, which lowers the number of facilities they have to deploy per customer, and increases the range of customer sizes that a single infrastructure can accommodate.
The question is, what’s a service network? Services could range from what might be called raw transport (leased lines), through statistically multiplexed transport (frame, cell), to packet networking (IP). In fact, all of these choices are already available today.
We think that the nature of a given service network business will depend on the extent to which the provider has access to right-of-way and fiber. A national pipeline company (Williams) can sell bandwidth because their base cost is low, so they can survive and prosper on a service type that doesn’t allow much differentiation and thus will be price competitive. A player who has to acquire fiber assets from someone else will have to climb the ladder to a higher layer of service to get a reasonable margin.
Scale will also have something to do with it. A carrier that can cover the whole country (or continent, or world) has more base revenue and thus returns a large profit even on a small margin. A metro or regional player can’t expect the total revenue base to be high, and must command a large margin to cover fixed costs like advertising.
Since users won’t generally buy only one of the two technical flavors of networks, let’s relate the two.
Access will tend to be service-independent, with the ILECs deploying ATM and the competitors deploying ATM or TDM. For large customers, this type of access will be connected through to bandwidth-oriented service networks to create traditional private network trunks. For these networks, intelligence will be concentrated at the edge.
For the broader community, service networks will be IP-based or PSTN-based. The very smallest users (residential users) will be too small to allow for much on-prem intelligence, so these players will require a service concentrator inside the access network, at the point where the service network handoff takes place. That’s the Service Point of Presence, or SPOP, we often talk about. Larger users will have mostly on-prem intelligence, and small businesses will have a combination of CPE intelligence and SPOP intelligence.
Today’s networking marketplace isn’t building toward this model, at least not in an explicit sense. We believe that’s because the media can’t deal with something this complex, and because the VC community, ever mindful of the role of buzz in getting them a profit, are promoting a more simplistic view where “metro” carriers vie with “regional” carriers. We’re simply building body count.
The current trend toward a greater range of service provider types, and a greater number of providers overall, seems likely to continue for as long as Wall Street is willing to capitalize new entrants and as long as there is enough differentiation possible to sustain reasonable margins. Over time, though, we expect to see the number of providers contract under margin pressure, with only the best and brightest in each class remaining to serve an expanding market.
There will probably be some technology convergence at this point as well, but based more on whatever combination of access and service, data and voice, seems to be optimum for sustaining profit margins and customer loyalty. We think, though, that the convergence may be different for access and service, with the former stabilizing on something like ATM and the latter on IP.
None of this will happen quickly, though. Expect to see the same basic set of service choices available for nearly a decade. But the first changes to appear, which we can expect within two to three years, will impact the service price relationships among the various technical options. We’ll explore that topic in a later issue. |
In the Know |
There’s broad market consensus that the profits and revenues of service providers in the future will be dependent on growth in IP services. There’s even general agreement that VPN services will play a major role. But there’s little consensus on just how such services will be presented to the user for sale.
We need to know that, because the range of service models we can support for VPNs will have a major impact on sales targeting, early deployment, and equipment investment. Thus, as a continuation of our effort to demystify VPNs (our August and September, 1999, issues and our update last month), we’ll now examine the VPN service model and its impact on premises networking.
Applications consume network-layer (Level 3) services, and so enterprise networks have to produce those services from a combination of carrier services and capital equipment like routers. When a service provider’s offering is at a lower OSI layer, as frame relay would be, the offering is integrated into the private network by linking it to the routers. Normal router behavior then integrates the destinations reached by the new link with the rest of the enterprise network.
When a service is introduced at Level 3, that service cannot just be linked with a router as a path—it has to be linked to a router as a virtual device. In short, a Level 3 service appears as a node, and node interactions with other nodes may involve control messages and other goodies, not just transport of data.
In most cases, and particularly with IP, there are a number of ways in which routers/nodes could be interconnected. This means that there are a number of ways that IP VPN services could be “virtualized” to appear as a connection to a user network. Some of these ways have been summarized, at least implicitly, in our fall VPN discussion. Others we’ve not covered. We plan to examine them all in detail here, but we first have to deal with the issues.
When a router (including a virtual one representing a VPN) enters a network (which we’ll call the “existing network”), it represents a path to users of that network from whatever users happened to be connected to it, and also a path to those connected users from users of the existing network. The two sets of paths are exchanged through topology updates when the new router is added.
These topology exchanges are critical to operation, because without them no entry representing the new paths, or the new users reachable on them, will be made in routing tables. Without those entries, packets addressed to the new users won’t be forwarded as expected. We pointed this out last year, and used that point to justify a VPN requirement that the VPN network advertise its capabilities to the enterprise when it’s activated.
But this is necessary only if the user subnets are linked to routers installed in the premises network. If the subnets are linked to the VPN access device (if it serves as the default gateway), no router advertisements are needed, since the systems downstream of the access router are reached at Level 2 via LAN.
A similar, but more complex, route topology problem can arise if the new VPN is designed not to provide the only route between a community of existing users and some new partners, but rather a better route for some applications. This better route can be used effectively only if the routing architecture of the existing network can route based in part on QoS (which is very unusual for networks today), and if the new service advertises its “better” route in a way consistent with the QoS routing capability available. If either isn’t true, we’ll need special accommodations—a topic we’ll cover later on.
The problem becomes even more complex if we assume that the VPN’s special capabilities are not uniformly available to users of the existing network. Routing protocols and procedures today are primarily based on destination address, not source address. While there are QoS standards to introduce source/destination combination awareness to routers (RSVP, for example), those standards assume that the default path for data and the priority path are the same, and that the process of creating QoS involves asking the resources that would have handled the traffic anyway to do a better job.
The final complexity is related to the concept of authorization. It is possible that some VPNs may require “permission” to join, meaning that not only would membership have to be based on the user’s IP address (which, in most cases, would only authenticate the client system and not its operator), but on the identity of the real human using the system.
Service models could answer most of these problems, or at least present the relationship between WAN service and enterprise network components in an organized way. Thus, the fact that VPN service models are virtually ignored by everyone (vendors, media, etc.) creates potential problems for uses who are contemplating VPN relationships.
A good way to open the specific service model discussion is to explore a popular “VPN” approach and define why it might not only not be a viable service model, it might not even be an IP VPN!
Tunneling over the Internet is the VPN approach that gets the most press, largely because it’s a model that the user could adopt without any service provider capabilities in the VPN space. With the tunneling model, the user establishes site-to-site tunnels using a protocol like PPTP or L2TP. These tunnels emulate physical links, providing the user with a router-to-router path that arbitrages the fixed-price nature of Internet access.
The obvious problem with this picture is that the “VPN” isn’t really an IP service at all, but rather a Level 2 service. The concept of Internet tunneling works only between a pair of devices whose relationship would normally be created by some sort of connection. A client system could, for example, “virtually dial” into a corporate information system through an Internet tunnel. Likewise, a bunch of enterprise routers could be linked through tunnels, as opposed to a service like frame relay.
The simplest real IP VPN service model is the virtual default gateway model. In this service model, each site on the VPN supports a single subnet, and the subnet’s members “see” the VPN edge as their default gateway. Since all off-net traffic is routed to that gateway, there is no problem “advertising” routes and reachability to the clients.
The default gateway model also solves a problem of integration new network paths. The gateway represents the only path to the WAN, so any WAN traffic (whether perceived as “private” or as part of something like the Internet) would go there by default (literally, as in “default gateway”). This would simplify the integration of the service into small businesses, branch offices, and other sites where there is a good chance that there is no routed network on premise already.
If there are routers on premises already, the default gateway service model won’t work, and some form of virtual router model will be required. The question is what form that model should take.
The obvious virtual router service model is based on having a virtual router somewhere in the network. We can call this the star router model. This router appears to the partner sites as a star-connected central resource with a one-hop path to the other site. The virtual router must advertise its routes using the network’s topology protocol.
The problem with this approach is its collision with the issues we described in the last section. Even if the VPN network advertises the subnets it can reach, the following risk factors will always exist:
1. There may be a private network route in place whose hop count or weight is better than the one offered by the VPN, in which case the traffic won’t go to the VPN.
2. The private network may contain static routing entries that defeat the adaptive advertising of the VPN.
3. The traffic targeted to the VPN may be a QoS-specific subset of a single host or subnet address, and the private portion of the network may not provide for any form of QoS routing, including RSVP.
4. The route through the VPN may be targeted to be selected by an RSVP request, but it may be on a different path than the “default” route to the destination. In this case, either the high-quality packets will never get to the VPN at all, or even low-quality packets will go there.
We’ll cover some ways to try to control the problems associated with this service model in the next section.
There are variant service models based on a number of these basic approaches. While none of them completely change the nature of the approach, and they thus have problems/benefits similar to the baseline approach, each may have some merit under some conditions.
One useful variant of the Internet tunnel model is the transparent LAN model. Like an Internet tunnel, a transparent LAN is a virtual Level 2 connection, but a transparent LAN is a multiplexed connection so separate tunnels to all destinations are not required. There are other properties of this approach that are interesting as well, and to expose them we have to delve for a moment into the operation of a transparent LAN service.
The most convenient transparent LAN service model is that of a bridged LAN. Each site on the TLAN would have a LAN interface to the DMARK device, and would see that device as a bridged LAN on which the partner sites were located.
To apply this model to an IP VPN, one might do one of the following:
1. Let the virtual LAN link user routers as if it were a backbone LAN. QoS could still be offered on an IP address basis if the internal logic of the VPN devices examined the IP addresses and other header fields, rather than the 802.x addresses. This creates an Ethernet VPN rather than an IP one, but if we call Internet tunneling an IP VPN, this is one too. Internet access could be created by having a virtual router join the TLAN and publish reachability to the Internet addresses, or by having a default route (0/0 entry) in each user routing table directing non-private-network addresses to this virtual router.
2. Change the subnet masks of the client systems on each site’s LAN to a broad mask covering all the subnets at all the sites on the VPN. The clients would now ARP to reach any site, making this a pseudo-IP-VPN again. Access to Internet destinations could be provided by having a virtual router join the LAN as a default gateway, with the only off-net addresses being the Internet.
3. Attach a virtual router to the VLAN as the default gateway to all sites, keeping them as separate subnets. The clients now direct their out-of-subnet traffic to the virtual router, which redirects it back onto the LAN to the real subnet user. Internet traffic would exit the virtual router onto the Internet without being routed back through the transparent LAN.
A variation on the virtual router model could be created by using the TCP/IP facility of redirect, an ICMP datagram type. In this model, the central virtual router handles minimal traffic; it serves as a default path for the user’s edge routers, connected onto a TLAN. When it receives a packet it sends it onward to the destination, but also issues a redirect to update the routing table of the issuing device, reflecting the direct path to the real endpoint. It’s not clear how much benefit this could offer over standard strategies unless the purpose was to reduce dependency on dynamic discovery.
Central virtual routers create traffic concentration, and if the core network is capable of meshing sites at the scale of the VPN, it may be best to consider a model where each site has a virtual router (or a subset of a real one) linking it to a mesh or to a Level 2 TLAN. Now the edge devices spoof the behavior of a central virtual router process, but the real network operates at Level 2.
The problem the virtual router models create is the problem of traffic concentration at the virtual handling point, which could easily become overloaded. The location of this virtual router will also have to be determined based on a combination of network topology and site traffic, and the calculations may be complex.
The problems not having a virtual router create are related to the efficiency of handling of large VPNs, and multicasting. Meshing is clearly a problem in large VPNs because of the N2 issues, and using a TLAN as the core still requires a form of routing at the 802.x layer, which means you’ve only moved the problem from one OSI layer to another.
Overall, we’d have to say that none of the models or their variations are perfectly adaptable to the private network augmentation applications of VPNs.
Solving the problem of VPN integration, in short, is likely to involve something being done to the private network configuration itself. This means that VPN prospects should be structuring their private network in terms of future VPN introduction, and any user of private networking or the Internet should be considering themselves a VPN prospect.
A quick review of the problems associated with VPN introduction will show that most are related to, or impacted by, the decision of an enterprise to provide more than one WAN path off a given site. If there is a single device that serves as the Level 3 service gateway from a site, all traffic off-site must go to it. That opens a number of convenient loopholes in our issue set:
1. Because adding a VPN to the network will impact only the exit path options available to the Level 3 service gateway device, it isn’t necessary to update the topology maps of interior routers or switches to reflect the changes in addressing the VPN may bring. In fact, it would be possible to use static routing internally on each site.
2. Because most congestion problems will occur at the LAN-to-WAN boundary, application of VPN QoS can start with the Level 3 service gateway device. Because this device is both on the default path for packets leaving the facility, and also on the high-QoS path (it’s the only exit, remember?), there is no need to worry about how RSVP or QoS routing would be applied.
3. It isn’t critical that the VPN advertise routes in any particular way, using any particular path cost conventions, because the network path changes only at the gateway device level.
This does indicate that the requirements for a Level 3 service gateway device might be a tad different from the requirements of a traditional router, though. Since users probably wouldn’t replace an existing site access router, we’d assume that the VPN gateway device would be interior to the current router, as before, and would behave according to one of our service models. Thus, the convention of routing all off-site traffic to a common exit point would be a user accommodation to the issues, not a specific requirement of the service model.
We would point out that “all off-site traffic must go through it” would mean Internet traffic as well. This doesn’t necessarily mean that some behemoth device has to be the gateway for all leased lines, frame relay, and IP, but rather that the interconnection between the WAN environment and the enterprise network (on a per-site basis) must be through a single device. We could accomplish this by setting up a single private network router that linked to each level 2 service, and also to a “Level 3 DMZ” where Internet and VPN traffic entered. This would allow the VPN traffic to get the same security/firewall services that the Internet traffic would receive. The model is already in use at most sites where Internet access is the only significant off-site network connection.
This may explain why the uptake of VPN services is a bit faster in companies who have more of an Internet commitment than a private network commitment. The Internet companies already have an Internet, single-DMARK-dominated, service model with proper firewall in place. But since much of the Internet VPN activity is rate arbitrage, it’s hard to build a convincing case.
Where it isn’t possible to set up a single exit point per site, other measures may be required to insure that VPNs appear available to the clients or servers they’re intended to support. One way to do that is through the use of tunneling.
If a client system or server initiates a tunnel to a VPN edge, that tunnel can be used to convey application traffic on a specific route to the VPN even if the normal routing of the application’s packets wouldn’t bring them to the correct exit point. The tunnel can be created to terminate at the VPN exit point, if that device has the ability to terminate the tunnel protocol used. If not, it could be continued through the VPN to the destination. In either case, source routing would be required to direct the tunnel. Source routing, of course, could also be used on the application packets to force them to follow the correct route. In either case, software in the client and server would be required to determine the route to the VPN portal and tunnel/route the packets accordingly.
If the premises network supports what could be called “application enclaves” as a part of a Level x switching strategy (where “x” is greater than three), it’s possible that the switch could link an application enclave with the correct VPN portal by developing a tunnel or source routing the packets, both without specific application support. This type of feature, which would go a long way toward justifying higher-level LAN switches, has yet to be called out by the switch vendors in their marketing material; we’re interested in whether they have it, and invite comment from vendors.
If VPN services evolve as extensions of the Internet model of e-business (to use IBM’s term), and if VPNs were assumed to include only public IP addresses (as they would were they all extranets), we could assume that the process of establishing a VPN would be the process of augmenting the Internet DMARK. That would minimize the need to alter premises routing practices to insure VPN traffic could be routed to and from the VPN gateway device.
If VPN services augment private networking, or even replace it, we must consider a broader model of services where multiple exit paths from the site virtually insure that VPN admission policy and premises routing policy will occasionally work at cross purposes. Thus, it appears that it would be helpful to restructure the premises network to a pure LAN hierarchy, with the WAN gateway at the top of the pyramid and supporting both VPNs and circuit-mode (frame, leased-line) paths.
The addition of a security or admission control function to normal VPN handling suggests that it would be helpful to integrate the concept of a VPN with the concepts of high-level (particularly Level 7) LAN switching. Application awareness in the LAN is a step toward efficient support of application-oriented VPNs.
That, of course, is the key issue. To the extent to which VPNs develop out of the Internet experience, they’re likely to be VPNs focused on a particular application. Private network VPNs may well involve traffic from multiple applications, as private networks do. Which of these models should guide premises network evolution will depend on both the attitudes and priorities of the individual users, and the sales success of the ISPs or facility carriers.
 |
Strategies |
Security has been a boogie-man of the Internet for years. Vendors have launched ad campaigns for their firewall products based on the tried-and-true scare tactics, and many users have simply gotten overexposed to the issue.
The recent attacks on key web sites has shown that there is an organized group of people who are (for whatever reason) trying to bring down aspects of e-commerce. There are other individuals with less lofty goals, but equal determination. The truth is, users today are probably somewhat exposed to security faults in general, and some users are quite significantly exposed.
We’ve found that most security material available to users doesn’t really start at the level the typical reader could understand, and so we’re going to do a primer of our own, relating our own experiences with security as we go.
In IP networking, applications are typically linked to network resources through the mechanism of “sockets”, which represent logical conduits through which information flows between the network and the application. The “sockets” API of BSD fame provides the baseline programming interface to these sockets.
The application’s use of sockets is linked to the network’s datagram flow through the mechanism of ports, which are the Level 4 transport connections through which information is delivered. TCP sessions and UDP sessions are linked to a port, and the port identifies the traffic, forming the Level 4 address used for local delivery of the data.
In a typical application of this system, we can classify partners as “clients” or “servers”. The former initiate requests to the latter, who respond to those requests. This means that the client systems bind applications to a particular port to send data, then expect a specific response from the partner. The servers “listen” for a request on one or more ports, and provide their service when a message (with whatever authentication the server application applies) appears there.
This structure opens the key issue in IP security. Client systems are not generally responsive to outside messages. If there are no applications listening to any ports at a given point in time, no message to the system will result in anything happening. There are exceptions to this, which we’ll cover later on. Servers, by their nature, must be responsive to incoming requests, however, and servers represent the greatest security threat.
Let’s recap and expand a bit, now. In order for a security breach to occur, there must be an application listening to the port. The intruder must know the port number, and must also know the way to frame a request for service so the application listening will respond correctly. The vulnerability that exists, for that port/application combination, will be determined by the range of behaviors that the application can be made to support, and the risk or damage associated with each. The probability of risk is determined by the chance that the port can be found by an intruder.
There are a number of ways that an intruder can try to hit your system, and each has its own risk metrics. Good practice dictates you address them all, but we’ll focus on three primary strategies.
The first way is to simply exploit a known public service offered by an application. There have been recent examples of users employing search engines to gather confidential data by selecting search words carefully. For a user, that means making sure that whatever information your public channels will distribute to others, is vetted to insure it doesn’t expose confidential data or further information resources. One user we know had a link to an internal intranet page in a document, and when that document was published on the Internet, the link was also published. There was no firewall to prevent access to it, and an internal report was accidentally published on the Internet.
A second way to enter a system is through what is called a “well-known port”. TCP/IP systems often provide a range of basic services, from file/print server and sharing facilities to file transfer, operator login, etc. In effect, there are system applications listening to these well-known ports. If an intruder can pass through any authentication mechanism associated with these system applications, the intruder gains access. A good example of this is so-called “anonymous ftp”, which allows file transfer without a password. Some systems have this enabled as a default, and many times confidential information is stored on these systems without recognizing the back door that’s in place. It’s a good idea to disable any well-known port applications that aren’t actually supposed to be there, and to review the status of such applications every time the server is used to store additional information.
The third way to enter a system is through a Trojan Horse. This is an application that attaches itself to a port (usually one with an odd, unassigned, number) and becomes a receptor for an activation command sent by the hacker. The Trojan Horse enters the system in a variety of ways; it may be part of a legitimate application (some developers deliberately leave themselves these back doors), it may be loaded by someone with access to the system, or it may be a virus. This kind of thing has to be guarded against in two dimensions; firewall blocking of ports that aren’t supposed to be used, and security procedures to prevent the loading of the Trojan Horse in the first place.
Finding the address of the target system is a requirement in all of these potential entry strategies, and that may be easy or difficult. There are three ways to get the IP address of a potential target:
1. The target may advertise its name, by providing a URL that DNS will convert to an address. Public servers, corporate servers, etc. will register in the DNS server, for example, and URLs may be published in other areas, such as in ads or on emails.
2. The target system may “contribute” its address by visiting a site. IP packets contain the source address, and so when you surf the web you leave your identity behind.
3. The intruder may randomly search an address range for systems, hitting each only by random chance.
Dealing with a risk can be viewed as trying to prevent the intruder from finding the system (address denial), or by preventing the intruder from reaching the target port/application (port denial). How each can be done depends on the specific type of system to be protected, so we’ll take it a system type at a time.
A stand-alone Internet client system is at the lowest risk level. In an ideally structured client, there are no applications listening to ports at any given time, except the browser—and the browser is listening in a very specific context. Client systems that are dialed onto the network also lack a permanent address, making it difficult to target one. But, as they say, “we have ways!”
Address denial for client systems is mostly a matter of control of client behavior. First, the client system should not be registered in a DNS, nor should its IP address be published anywhere that might be compromised outside the company. Using DHCP for automatic client address assignment is a good strategy to build security.
To prevent client systems from contributing its address to visited sites, there are a number of measures to consider:
1. Restrict the Internet access of the clients to legitimate sites. While it’s true that hackers might be able to get the IP addresses visiting a legitimate server, most address compromises come from random surfing and searching. The hacker simply sends an email inviting the target to visit a given web site, or makes a search engine entry that will hit a popular query. Visiting addresses are then saved.
2. Assign client systems “private” IP addresses from the RFC 1918 range, and allow them access to the Internet through an address conversion firewall. The client’s internal address is now not valid on the Internet, and the firewall-provided IP address is the address of the firewall, which will enforce security measures for the client.
3. Try to control the use of HTML in email readers; an intruder can send you an email which causes you to hit his website for content, thus revealing the client system address at which you pick the mail up.
Denying ports on a client system is primarily a matter of controlling the applications run there. We recommend each of the following be done:
1. Insure that personal server applications like Microsoft’s Personal Web Server are not run. These applications make the “client” into a “server”, increasing vulnerability to break-ins. Administrators can remove these applications from client systems if they’re a part of standard software, but users may still download server applications, so more will be needed.
2. Don’t allow client addresses to be published in a DNS, linked with a logical name. This reduces the chance a user will try to act as an impromptu server by making his target clients enter a real IP address—which is harder to remember.
3. Insure that the browser security levels are set so that ActiveX controls, Java applets, or scripting is run only from trusted sources. These applications can, under some conditions, create a Trojan Horse.
4. Insure that there is a client firewall in place. If the client systems are behind a corporate firewall, be sure that all ports not normally used by the client are blocked by the firewall. If the client isn’t firewalled at the company level, install a security product on each client. We’ll talk more about this one in a bit.
5. Insure that there is a good virus shield on the system, and that the virus data files are kept up-to-date. This will maintain a degree of security against virus-borne Trojan Horses.
6. Maintain physical security on client systems to prevent the introduction of a Trojan Horse via local disk.
In our view, the only measure with a good chance of killing client systems’ security risks is the installation of a local Internet security software shield on the client. We did an evaluation of the products available, and settled on Symantec’s Norton Internet Security 2000 product. We purchased this retail, and have no ties to the company, so this is a clean endorsement. We found, having installed the product, that it was even better than we thought. We’ll describe our experiences in a moment.
LAN-connected client systems have a greater-than-average level of risk, particularly if they’re sharing an always-on Internet connection like a cable modem or xDSL line. These systems have the same risk factors as stand-alone clients, but an added one of great significance.
The problem is that most LANs today use Microsoft’s resource sharing among the systems in the workgroup. If an always-on Internet access technology is installed on the LAN, bringing each of these systems on line with it will normally enable resource sharing over the IP network—the Internet! Our own cable modem installation did this, and we had to check the systems after installation and remove file/print sharing from the IP protocol.
If you plan to do resource sharing on the LAN, and also share always-on Internet, we recommend that you use NETBEUI as your file/print sharing protocol, and that you then disable resource sharing on TCP/IP. You’ll also want to firewall NETBEUI from your Internet connection (as you should in any case).
File sharing on the LAN provides a nice way to spread Trojan Horses and viruses, so you’ll need to redouble your vigilance on these issues if you have multiple LAN-based Internet clients. The spread of these evil artifacts on the LAN is one reason we believe it’s crucial to have per-system software firewalls on clients; you may get something from a neighbor who’s inside the hardware firewall. Per-client software also protects you from intrusion through a dial-up Internet connection someone on the LAN makes.
Many LANs contain servers as well as clients, and that creates a much more complex problem of security management. When you have servers, it may be time for professional security help.
There are two kinds of LAN-based servers, ones that provide for public access and ones that provide only on-LAN access. We’ll cover each.
LAN-only servers means that the company/workgroup doesn’t plan to supply services to outsiders. If that’s the case, we recommend that the clients and servers use RFC 1918 addresses and that there be an address conversion firewall between LAN and Internet. If that firewall is strong, it may be sufficient for all security measures for the LAN, eliminating the need for per-client software.
If the servers must offer public access, we recommend you establish a “Demilitarized Zone” or DMZ for your public servers. The Internet connects to the DMZ, and the public servers reside on that DMZ, which is a small LAN segment. These use public IP addresses, of course. The private LAN, separate from the DMZ, is linked to the DMZ with an address conversion firewall, and it uses RFC 1918 addresses. To protect the public servers, it will probably be necessary to install another firewall between the DMZ and the Internet.
When we got always-on cable modem service here for our client systems, we didn’t really think too much about security issues because we knew that our clients didn’t listen to any ports, and because we had a pretty aggressive virus control policy. Nevertheless, the lack of a firewall was enough of a concern to lead us to decide to follow our own advice and install a per-client software firewall.
We selected Norton Internet Security 2000 based on published reviews and web site content analysis, and we installed the product on a weekend, expecting to see pretty much nothing at all. The Norton package provides raw statistics on security activity, and also an event log that provides details on each security event. After a couple of days’ use, we reviewed the logs.
To our surprise, we found that our systems were regularly hit by suspicious access attempts; on the average, four to five per week. This didn’t count the attempts of our cable provider to read status, which we also blocked.
We took each security event and ran a “lookup” on the IP address, reverse coding it to a domain name, and got a mixture of offshore addresses (usually .edu suffixes), dial-up user ports, cable modem and xDSL customers, and a few unassigned addresses. Most of the attempts were to access well-known ftp or telnet ports, assuming our system to be a standard UNIX-type server. There were also some attempts to contact known Trojan Horses, and a series of attempts (from five different addresses) to contact the same unassigned TCP port, which we believe to be another Trojan Horse not yet reported.
Interestingly, one of the systems is rarely used to surf the web, and this system experienced a quarter the attempts of the others. This demonstrates that the addresses being hit were “contributed” by surfing the web…and something else.
We discovered that some addresses were apparently coming through the process of using HTML email. The hacker sends an email to a bunch of email addresses, which he realizes are probably the addresses of hosted email and not of the client. The email contains a reference to a small (perhaps invisible) image on a server, and the attempt of the HTML mail reader to retrieve that address lets the system there collect the client address for a penetration attempt. Our thanks to Steve Gorrell, a senior program manager for Symantec’s product, for helping interpret this.
We also noted that some of these helpful snatching attempts included an attempt to read our email address as well. The Norton package lets you block outgoing information containing specified data, and we included our email address (since anyone sending us mail should have it). Sure enough, we got a privacy violation when someone who sent out a bulk email to a broad community of addresses tried to get our specific email address to associate it with our IP address, obtained through the file access mechanism described above.
We notice no degradation of performance with the new firewall software installed, and the product continues to report attempted break-ins. As this report was being written, the log showed two Trojan Horse contact attempts, one to “Deep Throat” and one to “Backdoor SubSeven”, each originating at an offshore dial-in site. While it is true that as long as we don’t have the Trojans on our system these attempts would fail even without the software, it is also true that if that particular Trojan were planted, we’d have been hacked.
The popularized distributed denial of service (DDoS) attacks were probably launched from unsuspecting systems through a planted Trojan Horse that received instructions to synchronize the attack. Don’t assume that you aren’t an unwitting part of this public and annoying trend. Your security flaws may well make it possible.
There’s a moral to this, folks. If you have a system permanently on the Internet, you are getting probed…period. If that probe coincides with an available application reading the probed port (because you forgot and left your personal web server running, or because you got Trojaned) you’re going to pay some price—just what you’ll pay depends on the hacker.
Things on the Internet need to get better, from a security perspective, but there’s little chance that will happen any time soon. The ISPs believe that a hacking customer is still a customer, and generally don’t cooperate with tracing these attempts. We’re going to submit our log to the cable provider, and we’ll report in a later issue on our progress. In the meantime, take matters into your own hands and do something about security.
 |
Down the Line |
Next month, we’ll review some of the issues associated with broadband network services, from what the applications will be to what the impact might be on the nature of the TCP/IP protocol set. We’ll continue our VPN vendor submissions a bit longer this spring, then publish the entire group and our three-part “requirements” piece as a PDF.