Securing DSL

Without a well-thought out security strategy, “always on” DSL Internet connections can translate into “inherently vulnerable.”

BY RANDY DAY

 

 

[This article originally appeared in the January, 2000 issue of Information Security Magazine (see www.infosecuritymag.com). The hardcopy article includes a sidebar on firewall products.]

 

In his keynote speech at the DSLcon’99 convention in Amsterdam last November, Anthony Alles remarked, “As DSL becomes more widely deployed, increasing numbers of DSL subscribers

have reported attacks on their computers, sometimes leading to copying or destruction of

sensitive data.” For millions of would-be DSL users, Alles’s comments cut to the heart of one of the biggest uncertainties about broadband Internet connections: security.

The growth rate of DSL has been phenomenal. From an installed base of a few thousand at the start of 1998, DSL rollouts in the United States alone will reach about 600,000 by the end of 1999, according to DSL Prime. Though DSL is still a new kid on the block, it is quickly becoming an accepted connection technology for business and residential customers alike, with speeds up to and even slightly greater than T1 speeds. T1 connections, with their rapid service response time guarantees, are still preferred for mission-critical applications. But for most other broadband applications, DSL is an attractive solution.

           

What About Cable Modems?

Before we dive into the key issues involved in securing DSL, let me explain the intended focus of this article. While much of the following discussion is relevant to both DSL and cable modems, the emphasis is on DSL for a number of reasons. First, DSL is targeted to both consumers and businesses, while cable modems are more prevalent in consumer markets. Second, many cable modem implementations have high download speeds but rather limited upload speeds, which limits the usefulness for many business applications. Third, cable modems, because of the shared medium, have special security issues that are addressed (at least partially) by specific hardware solutions in cable modems. And finally, focusing in on one broadband technology makes it easier to use specific examples.

Even with this narrowed focus, it would be impossible to cover all security-related DSL issues in one article. Hence, the discussion here is limited to the security issues involved in the DSL connection itself as well as different network topologies used to hook up a DSL connection.

 

Security Risks

A DSL (or cable modem) connection to the Internet is a greater security risk than a plain old analog modem dialup connection. For one, the bandwidth is greater, allowing the possibility of more cracking to be done in the same period of time. More importantly, the connection is usually “always on,” which makes the host a much easier (and potentially more lucrative) target to find. Finally, depending on the DSL connection type, there may be a more porous door between the client and the ISP.

Let’s look at some traditional security risks to see how a DSL connection is susceptible to--as well as which risks we can diminish through proper engineering of a DSL network connection.

Eavesdropping. Eavesdropping risks arise when an outsider is able to listen in on your

local network traffic. This information-gathering may range from spying on file transfers around your network to gathering information about the network configuration itself, such as the names of users, computers and other system resources. Eavesdropping may directly compromise your network (e.g. spying on network file transfers), or may be the source of information that could aid further intrusion attempts (e.g. knowing the system resources to attack).  In the most pathological extreme, it’s possible (and it’s happened) to build a DSL-connection that forces all traffic, even intra-LAN local traffic, over the DSL connection.  With the higher speeds offered by DSL connections, the casual user might not even notice this situation. More sophisticated DSL connection techniques can dramatically reduce the eavesdropping threat.

Probing. Probing is a term that arises from the practice of examining a host and testing its response to various probes. A typical probe attack involves an automated program that scans a host’s TCP/UDP ports, looking for running services that respond to queries. The attacker can then attempt to exploit weaknesses in any responding services. For example, the infamous Internet Worm, developed by Robert Morris and unleashed Nov. 2, 1988, used a number of techniques to breach system security. One mechanism it used was to probe hosts, looking for running instances of the “finger” program; once found, the worm would try to exploit an unknown buffer overrun bug in many versions of the finger program, causing the worm’s code to be executed on the target host.

Common probing attacks today include probing for sendmail servers; spammers love to find sendmail servers that will send mail from any submitting host. Another common probe is for Microsoft Windows file and print servers, which are subsequently queried, looking for unprotected files.  A DSL-connected LAN, with it’s permanent connection, is an attractive target for a probing attack.  Porous DSL connections can leak a constant stream of information to outside probers, giving them the first toehold your LAN security walls.

Impersonation. Impersonation can take a number of different forms, but one example is IP

address stealing. For example, depending on your network configuration, it may be possible for another DSL subscriber to “steal” your IP address, causing all information addressed to your computer (including, say, the results of your online banking statement request), to pass instead to the attacker’s host. In reality, IP address stealing is usually an impractical attack, but it highlights two fundamental principles for security on the Internet: (1) Any security mechanism based on IP addresses is flawed; (2) Assume that any plain text sent over the Internet is open to prying

eyes.

            Unlike a PPP dialup connection, or a routed T1 connection, a bridged DSL connection is susceptible to IP address stealing, as we’ll see later.

Denial-of-service. DoS attacks don’t attempt to obtain private information or to

delete or corrupt files on attacked hosts. Rather, they attempt to make a host unusable by keeping it too busy performing useless functions.   Many simple DoS attacks don’t work well over a dialup connection because it’s just not possible to send enough traffic over an analogue modem to have a serious negative impact on a modern PC.  However, with a high-speed DSL connection, that’s always on, it becomes possible to generate serious DoS attacks.

Viruses. Virus attacks are familiar to many: they occur when a file, placed on a host and executed, performs harmful actions, including attempting to spread itself to other hosts on the network.

DSL connections, even with a secure network topology as discussed later, do not have any innate protection against virus attacks, and ISPs have started to recognize this opportunity. US West, for example, is reportedly offering a service to virus-check incoming e-mail with Trend Micro software, charging $1.50 a month for this value-added service. Good virus protection should be a primary concern for any network, especially a network with an Internet connection.

 

Connection Types

The first factor influencing the security of a DSL connection is the type of connection used by the provisioning ISP. For this discussion, the underlying DSL physical layer technology--SDSL, ADSL, RADSL, etc.--is immaterial. Regardless of the xDSL technology used, ISPs need to build a network topology on top of the DSL bit pipe. Options include a bridged connection, a routed connection, or a Point-to-Point Protocol (PPP) connection, either PPPoA (PPP over ATM) or PPPoE (PPP over Ethernet).

Bridged connection. The connection type with the least inherit security is a bridged connection. A bridged connection is a DSL modem with an Ethernet interface that logically acts as an Ethernet bridge between the client device and the ISP’s network. As such, the DSL modem in the bridged case acts exactly like a standard Ethernet bridge between two Ethernet segments: the client’s and the ISP’s.

A bridge is a Layer 2 device; a basic bridge passes all traffic from one Ethernet segment to the other Ethernet segment. With a bridging DSL modem plugged into a hub on the client site, potentially all traffic on that hub--including local PC-to-PC traffic--would pass over the bridge onto the ISP’s network.

In practice, all bridged DSL modems are “learning bridges.” A learning bridge listens to the Ethernet traffic to determine which MAC addresses are on which side of the bridge. A learning bridge does not pass traffic across the bridge if the destination MAC is on the same side as the source host. Consequently, a learning bridge would not pass local PC-to-PC traffic across the bridge, thereby reducing the amount of unnecessary traffic on the DSL link and improving the security of client-side LAN traffic.

Bridged connections of this type are infamous for their susceptibility to eavesdropping. Ethernet broadcast traffic passes across a learning bridge in both directions. If a DSL bridging modem is plugged into a LAN with multiple Windows hosts, and if those hosts have Windows networking turned on and file and print sharing enabled, and if the ISP is not filtering Windows networking ports (ports 137, 138 and 139), it is possible for the local hosts to appear in the “Network Neighborhood” of other customers on the same Ethernet segment at the ISP.

A bridged connection is also more susceptible to IP address stealing than other DSL connection types. Imagine the following scenario: Customer “Bob” has a bridging DSL connection to “AnyISP.” AnyISP has specified that its DSL customers should be using DHCP to get their IP configuration information. Bob sets his PC up correctly and obtains, via the DHCP protocol, the IP addresses 206.128.1.3.

Meanwhile, customer “Eve,” who also uses AnyISP and happens to be on the same logical Ethernet segment as Customer Bob, has decided (perhaps accidentally, perhaps maliciously) to manually configure her PC with the IP address 206.128.1.3. When traffic from the Internet comes into AnyISP addressed to Bob at 206.128.1.3, AnyISP has to determine which MAC address to send the traffic to. AnyISP will ARP for address 206.128.1.3, and if Eve replies first, then her MAC address will be entered into AnyISP’s ARP table as the proper endpoint. So, Eve will get Bob’s traffic. Of course, Bob will quickly figure out that he’s not getting any packets and call AnyISP to complain. If Eve was particularly smart, she could capture all of the traffic destined for Bob, read it, and then pass it on direct to Bob’s MAC address. Bob might never find out that Eve is eavesdropping on his traffic.

Routed connections. A routed connection is a DSL connection in which Layer 3 IP routing is used to connect the customer to the ISP. In other words, the DSL modem functions as an IP router. The DSL modem has its own IP address in this scenario, one of  subnet of addresses assigned to the customer For this reason, routed connection types are rare for residential customers.

The security characteristics of a routed connection are similar to those of the Internet at large. Local traffic, even LAN broadcasts, is not passed over the router to the ISP. A Windows Network will not show up on external “Network Neighborhood” lists unless special efforts are made to advertise its existence (e.g., sending information to an external WINS server). It’s also difficult for others to steal an IP address, since the ISP generally knows which IP subnet ranges are assigned to which customers and has his routers configured accordingly.

PPP connections. PPPoA and PPPoE are mechanisms to build a Point-to-Point Protocol logical link over ATM or Ethernet, respectively. The PPP was originally conceived for building an endpoint-to-endpoint data link layer over a simple construct like a serial line. As such, PPP is the standard data link layer for dial-up modems. PPPoA and PPPoE extend the PPP mechanism to more complex or shared networking constructs like ATM or Ethernet. Because they fit in with the existing administrative, billing and security infrastructure built around PPP, PPPoA and PPPoE are finding favor with many ISPs.

Their security characteristics of PPPoA and PPPoE are similar. Typically, as part of the PPP link establishment, some sort of ID/password is required. The ISP can use this credential set for authorization and billing purposes. Like the routed connection type, a Windows Network will not show up on external “Network Neighborhood” lists unless special efforts are made to advertise its existence. The IP address is typically assigned as part of the link establishment in such a way that the ISP knows which IP addresses are where. This makes IP address stealing a difficult task.

PPPoA has an additional twist: Since ATM is usually not extended to the PC environment, the DSL modem device itself establishes the PPP link. This means the DSL device has an IP address and is one end of a PPP link. If the ISP is providing only one IP address to the customer, the DSL modem must run a NAT server in order to service the customer’s PC(s): all customer access must pass through the NAT server. In addition, the NAT server must run in the DSL modem, meaning that customer has no choice over the NAT implementation used.

 

Security Techniques

There are three basic ways to hook up a LAN to a DSL connection: a direct connection, a multihomed gateway host, and a turnkey firewall solution. These connections also apply to a single PC hookup.

            Direct connection. One mechanism for sharing a DSL modem is to connect it directly to your local LAN hub and to use routable (nonprivate) IP addresses for each of your hosts. This can work for bridged connections, routed connections and PPPoE connections. Figure 1 depicts a shared bridging DSL modem; the routing DSL modem is similar. Figure 2 depicts the analogous shared hub for a PPPoE DSL connection.

 

Figure 1: Direct Hub Connection, Bridging DSL Modem

 

While this is a conceptually simple method for sharing a DSL connection, it requires a fair amount of diligence if you are concerned about the security of the local hosts. For example, in the bridging case, the only thing preventing your local LAN traffic from zipping around your ISP’s LAN is an Ethernet learning bridge. While a bridge will not forward traffic destined to local MAC addresses, it will forward multicasts and broadcasts. A malicious cracker could make use of this information to target your systems. If the ISP is using DHCP to assign IP addresses, it is possible (but unlikely) that each PC will be assigned an IP number on different IP subnets. If this happens, then even local PC to PC LAN traffic will be routed over the DSL bridge, to the ISP’s router, before returning back over the DSL line to the local LAN.  This is highly insecure to say nothing of slow and wasteful of the DSL link’s bandwidth.

In addition, if you are using more broadcast-chatty protocols on your local LAN, like NetBEUI, you are passing even more information onto the ISP’s system. A learning bridge is not a security device; it is a traffic-limiting device, designed to keep your local LAN traffic from swamping the rest of the network. Moreover, a configuration like this leaves every host equally open to attacks from the outside. Each host has to be secured independently and equally if you want to prevent a weak link in your system. Finally, some security techniques,such as firewalls, are not available in a configuration like this.

 

Figure 2: Direct Connection in PPPoE Environment

 

As Figure 2 demonstrates, each host in a PPPoE connection should be configured with multiple logical interfaces--one for the PPPoE link, one for the local Ethernet. The <dashed blue lines> in the figure represent the PPPoE link to the ISP, which has an IP address but is physically passed over the single Ethernet interface in each host. If only the PPPoE interface is configured, intra-LAN PC-to-PC traffic will be forced to flow over the PPPoE link to the ISP and back, which is both insecure and slow.

One alternative with a direct connection is to run two different networking protocols, for example TCP/IP and NetBEUI.  NetBEUI, while it is broadcast-chatty, is a non-routable protocol, so it will not be passed by the ISP’s router.  Each PC can then be configured to disable Windows file and print sharing on the TCP/IP protocol, which provides some protection.  However, the protection is incomplete, because it may still be possible for other clients of your ISP (but not other Internet users beyond your ISP) to access your file and print server over the NetBEUI protocol.

There is nothing inherently wrong with the direct hub configuration: it is a perfectly valid

configuration, depending on your security needs. However, most companies with a concern about the data on their local LAN would not use a configuration like this.

            Dual-homed host. In a dual-homed environment, a PC is configured as a gateway between the local LAN and the DSL modem. With a bridged or routed DSL connection, this gateway can be configured as either a router or a NAT/proxy server. With a PPPoE DSL connection, this gateway would have to be configured as a NAT/proxy server (because the PPPoE protocol won’t pass over

the gateway).

 

Figure 3: Dual-Homed Gateway

 

Figure 3 depicts the dual-homed host configuration with the gateway configured as a NAT/proxy server. The dual-homed host solution completely isolates your local LAN traffic from the ISP’s network. In addition, it provides a central point of control over the Internet connection. Any probing attacks have to pass through the gateway, where filters can be set to block various ports. Likewise, any traffic going out to the Internet has to pass through the gateway host, where it can be logged or filtered with the appropriate firewall software.

In addition, with a NAT/proxy server on the gateway, there is a reasonable level of protection to other hosts in the local LAN, which do not have to be watched/secured as tightly. A stateful NAT server provides a good level of protection to the interior LAN. By allowing most outgoing traffic, but blocking all incoming ports unless explicitly opened, a NAT server is the basis for most firewall implementations. With a NAT server blocking all incoming ports, most probing attacks fail. A NAT server also allows multiple interior hosts to share a single external routable IP address. This can reduce costs by eliminating the need for multiple IP addresses from the ISP, and it increases security by allowing private address space IP numbers (nonroutable IPs) on the interior network. A proxy server operates in a similar fashion on the application layer.

With a dual-homed gateway in a Windows environment, it is also possible to disable all Windows networking on the outside interface, which blocks a common attack point. To disable all Windows networking on the outside interface in NT, open the Control Panel, Network, Bindings and unbind the NetBIOS, Server and Workstation services from the WINS client (TCP/IP) for the outside Ethernet interface. This eliminates all Windows networking file access through the NIC connected to the DSL: you won’t have to worry about anyone making a Network Neighborhood connection to shares on your gateway or interior hosts. Moreover, unbinding file and printer services from the outside interface does not eliminate file and printer sharing through the local LAN side of your gateway machine.

The dual-homed solution also helps protects the LAN against denial-of-service attacks, since DoS attacks are often stopped by the NAT/proxy server. It’s hard for DoS attacks to proceed against unaddressable hosts on the local LAN.

One drawback to the dual-homed environment is that the gateway host, as the gendarme

protecting the LAN, becomes an especially attractive target for attackers. Remember, the firewall provided by the dual-homed host is only as secure as the host it runs on. As such, the gateway should be hosted by an operating system with security capabilities. For the Windows family, this means using Windows NT/2000; Windows 9x would not make a good gateway host.

 

Turnkey Firewall Solutions

The turnkey firewall solution is a variation on the dual-homed PC solution. However, instead of a PC with NAT/proxy software, a turnkey firewall device (e.g., the SonicWALL device from Sonic Systems) is used as the gateway device (see sidebar, p. XX). The major advantage to the turnkey solution is the ease of implementation: The device is just dropped in, with one side wired to the DSL and the other connected to the local LAN. These devices usually provide NAT or proxy capabilities as well as logging and reporting facilities. In addition, they often include content filtering capabilities, which allow the blocking of Web sites based on content. Turnkey solutions are usually robust (no moving parts), and the hassle-factor is low.

The downside to a turnkey solution is that they have a definite cost (a dual-homed host can often be established with existing equipment), and they are nonextensible. However, in a business environment, the equipment cost is usually minimal, while the payoff--including the ease of implementation and added logging/reporting and filtering capabilities--is high.

Conclusion

 

 

It’s clear that the level of security in DSL depends on several factors: the type of connection, the network topology, host and/or gateway configurations, and the use of third-party tools such as firewalls and proxies. As ISPs have grown their DSL rollouts, they have struggled with scalability problems with birdged DSL connection types.  For example, US West is converting their DSL offering from a bridged connection to a PPPoA connection.  This, combined with a maturing DSL equipment market probably means that future DSL connection devices will be more highly integrated devices, perhaps combining DSL signaling capabilities with some sort of turnkey firewalling capabilities.  DSL “modems”, as they reach wider audiences, will become more of a plug and play appliance, and part of the feature set of that appliance will be some base level of security for the DSL connection.

 

 

 

Randy Day (randyday@tuketu.com)  is the prime motivating force behind Tuketu.com, providing network and software development consultation and is currently based in Seattle, Wash.

 

 

(SIDEBAR ON FIREWALLS TO COME)

 

 

(BOX) FYI

 

DSL Info

 

DSL Prime [since they are mentioned in the article and it’s a good site]

www.dslprime.com

 

DSL Reports

www.dslreports.com

 

ADSL Forum

www.adsl.com

 

Avalon Trials

http://dsl.avalon.net

 

Computing Central Bandwidth Forum

http://computingcentral.com/forums/bandwidth

 

Dan Kegel’s ADSL Page

http://alumni.caltech.edu/~dank/isdn/adsl.htm

 

David Fannin’s ADSL for Linux

http://metalab.unc.edu/LDP/HOWTO/mini/ADSL.html

 

The DSL Source Book

Available free from Paradyne Corp:

www.paradyne.com/sourcebook_offer/sb_html.html

 

Everything DSL

www.everthingdsl.com

 

High Bandwidth Web Page

www.specialty.com/hiband/

 

Network World DSL Resources

www.nwfusion.com/dsl/

 

Randy Day’s xDSL Page

www.tuketu.com/dsl/xdsl.htm

 

Universal ADSL Working Group

www.uawg.com

 

xDSL Deployment Worldwide

http://conk.com/world/dsl

 

xDSL FAQ

http://homepage.interaceess.com/~jkristof/xdsl-faq.txt