|
Cable Modem Security
Insulating your network while keeping your subscribers safe from each
other.
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created:
August 2, 2001
Note: For help implementing security
for your own cable system or
developing tools to help you find and lock down individuals who are
exploiting your system contact Birds-Eye.Net.
Security plays an important role in helping you build and maintain a
successful Internet service offering. Broadband’s last mile offers one of
the most challenging areas related to implementing security. This article
will provide you with the information you need to implement your own cable
modem security initiative that will help you insulate your network while
keeping your subscribers safe from one another.
The Internet is one big place and its full of people with little in
common with one another. Although there are people (e.g. hackers) out in
this space that can be dangerous to you and your subscribers, the biggest
threat to the security of your network comes from within its own confines –
your subscribers. This threat comes from the fact that most people are more
concerned/interested in what their neighbors are up to rather than what
someone in perhaps another country is up to. Some subscribers pose a threat
inadvertently (e.g. the result of installing some program that they are
unfamiliar). Others because they can’t help themselves for wanting to see
how far they can push the limit or your ability to detect what they are
doing. While a majority of your subscribers are law abiding and pretty much
use your service as it was intended, there are always a few that will test
the far reaches of your service as well as how it is explained within your
service agreement. Because of this, the best approach is to treat each
subscriber as if they represent the single largest threat. Only then will
you maximize your insulation between your network and your customers.
Figure 1.0 Network connectivity
with no Security in place on Cable Modem
With no security in place on Cable Modems (CM), your network appears much
like that pictured in Figure 1.0. Essentially, all network devices connected
to your broadband transport including Customer Premise Equipment (CPE)s and
CMs appear as they were all connected to one another. Most importantly, CMs
resemble a drop cord connecting subscribers’ CPE directly to the network.
Nothing prevents subscribers from interfering with the operation of your
broadband transport – lets just say that your trust in them in being a
“good” customer is extremely high as is your exposure to un/intentional
denial of service attacks.
Fortunately, there are several things you can do to significantly
insulate and protect your network from your subscribers. These things range
from relatively simple things that are easy to implement to significantly
more complex things that are equally complex to implement. I’ll review a
number of these along with explaining what they prevent.
DHCP Server Filter
Your subscriber CMs and CPEs require the services of Dynamic Host
Configuration Protocol (DHCP) server to provide them with an IP address.
DHCP is an automated means of assigning IP addresses to large numbers of
clients. However, if subscribers are all connected together (as in Figure
1.0) and they accidentally started their own DHCP server (which are widely
available) they could compete with yours in activating (or most likely
deactivating) subscribers. Note a subscriber based DHCP server will only
impact those subscribers connected to the same network as their rouge DHCP
server – all other networks (and their subscribers) will be unaffected. To
correctly handle this condition, port filters need to be set on the CM to
permit only DHCP client transactions through the CM (see Figure 2.0).
Figure 2.0 DHCP port filters
DHCP client activity requires the CM to permit inbound (to the CPE)
packets destine to port 68 on the DHCP client (located on the CPE) and
outbound packets destine to port 67 on the DHCP server. The DHCP filter must
block all other combinations of ports 67 and 68 to prohibit subscribers from
running their own DHCP server. Blocking these other combinations will permit
your subscribers to run their own DHCP server in their home without
interfering with your network.
Microsoft Networking Filter
Microsoft’s Windows operating system supports a Microsoft’s networking
protocol called NetBEUI that is great for “friendly” networks but
troublesome on public networks. NetBEUI enables a number of window’s
specific functions like “Network Neighborhood” and network printing where
its users can find other NetBEUI enabled CPEs on a network, attach to and
browse these CPEs, even print on them if they are configured to permit such
activity. To prevent this capability you must not allow NetBEUI traffic to
enter the broadband transport or vice versa.
Figure 3.0 Microsoft Networking
Filter
The way to prevent this (as shown in Figure 3.0) involves blocking ports
137 through 139 at the CM. Since network browsing and printing must use
these ports this should* take care of the problem. One additional note with
regards to blocking these ports is that it can also prohibit some earlier
versions of Virtual Private Networking (VPN) from working through the CM. To
address this you could potentially make this filter optional, however the
risk is generally to great to do this.
*Note there are settings for NetBEUI that will defeat this port filter
however the most obvious case is handled properly.
Network Isolation Filter
With the CM being an extension of your managed network connection, it
makes a lot of sense to protect or restrict its access. Within the CM
resides a wealth of information about your subscriber data traffic and what
type of network service they have subscribed. Information and control such
as this make the CM a target of a number of different types of attacks. The
best way to prevent subscribers from prying into this space is to deny them
network access to the CM.
Figure 4.0 Network Isolation
Filter
CMs are not typically provisioned with a working (routable) IP address.
Instead, they are provisioned with a private IP address in one of the
private IP ranges defined by RFC 1918 (http://www.csl.sony.co.jp/cgi-bin/hyperrfc?rfc1918.txt).
Since the CPEs are provisioned with routable IP address (e.g. 24.128.44.56)
you can easily shut off their access to the entire private network that the
modem resides by activating an IP filter. Blocking CPE access to 10.x.x.x
effectively prohibits all CPEs from accessing any CM on your network while
not restricting Internet routable IP addresses the CPE may want to visit.
This particular filter has some drawbacks operationally that impact some
self-service features. For example in some systems, CPEs are given a private
IP address during self-activation of services. During these times, it is
important that you address this filter’s functionality a different way so as
to allow the prospective subscriber to sign on with you
while achieving a restriction on the CPE’s ability to access the CM.
Up till now, the items we’ve discussed address well-known problems linked
to deployments of CMs. These items are relatively easy to implement and
reduce your risk of someone trying to steal service (by breaking into the
CM), breaking into their neighbors’ CPE, or bringing down a portion of your
service with their own DHCP server. However, there are still a number of
things subscribers can still do with all the above filters engaged. These
things include configuring unauthorized static IP addresses and sniffing
packets. Unfortunately, implementing measures that prevent more advanced
trouble making on your network require sacrifices in functionality to
enable. The most notable of these is elimination of some self-service
capability or perhaps the introduction of increased intelligence in your
DHCP server.
Static IP Address Filter
Most of your power subscribers would love nothing more than to have an IP
address on your network that never changes. Networking professionals call
this a static IP address and businesses pay handsomely for these gems.
However, in a large DHCP network, it is very easy to just claim an IP
address and begin using it – even if your DHCP server has specifically
assigned a different IP address for that CPE. IP address squatting (as it is
sometimes referred to) is very common, and can cause your DHCP server to
skip these addresses (if it is configured to validate each IP address before
it is assigned) or worst hand out an IP address that is already in use (if
it does not validate each IP address).
Figure 5.0 Static IP Address
Filter
There is a filter available in the CM that permits one to prevent the
customer from attempting to use a random static IP address (see Figure 5.0).
This filter permits you to stuff the IP address that is given to a CPE into
its associated CM boot file. By stuffing this IP address into the boot file,
the CM (associated with that CPE) will only permit data traffic to and from
the CPE’s IP address. If the subscriber changes their IP address on their
CPE to something different than what your DHCP server assigned them, they
will not work. While this does not prevent them from statically entering the
information provided to their CPE by your DHCP server, it does prevent your
network operations group from having to fight through these problems – that
likely impact a new subscriber. To provide this filter, however, you must
have a provisioning system that is capable of generating boot files on the
fly. In this system, your DHCP server must be tightly coupled with a dynamic
boot file generator and a Trivial Transfer Protocol (TFTP) server to permit
the IP address assigned by DHCP to find its way into the boot file created
for a specific CM.
Unfortunately, if the subscriber wants to connect a second CPE to their
CM they would not be able to automatically register this with your service.
This is because the CM becomes locked down upon stuffing information into
the boot file whereby preventing new devices from being easily added to the
subscribers’ account. If this subscriber wanted to add a new CPE to their
account, they would need to register it using their other CPE. This
functionality also complicates subscribers who purchase a new CPE and wish
to swap out their old one. If the CM boots with a new CPE it ‘should’ be
handled differently than if it boots with its previous CPE – so as to let
the subscriber automatically sign on with their new CPE. However, this
requires some intelligence in the DHCP server to recognize this new
combination and allow it rather than respond as it would to the previous
combination of CPE and CM. Only a few of today’s DHCP servers have this
figured out.
MAC Address Filter
Another way that power subscribers can hack into your network is to
change their Media Access Control (MAC) address. The MAC address is a unique
address assigned to each Network Interface Card (NIC) on the network.
Skilled power users with special machines can change their MAC address to
that of their router. By changing their MAC address to the router, they
receive a copy of every packet that flows through their network. Since the
default behavior of the CM is to learn the MAC of all NICs attached to it,
the CM supports this behavior without knowing the extent of the security
breach.
Figure 6.0 MAC Address Filter
Fortunately, you can also pack the MAC address just as you can pack the
IP address. In this way, the CM will only permit data traffic to and from
this MAC address that is assigned via the boot file rather than learned
during the booting cycle of the CM. Note that similar to the Static IP
address filter, the MAC address filter requires the same tightly integrated
DHCP/boot file generator/TFTP. Without these tightly integrated components
this security feature would not be possible.
Implementing all of these filters mentioned in this article will provide
you a very strong security policy against subscribers attempting to hack
their way into your CMs or read data traffic of their neighbors. I also
highly recommend you to regularly change your SNMP passwords that are used
to read and write information. All network hardware including routers,
switches, CMs, etc. use SNMP passwords. By default these passwords come from
the factory as “public” read and “private” write. Broadband operators that
have quickly gone from testing to deployment often forget to change these
but to be sure your power subscribers are already using this to their
advantage. I recommend you change them often (at least once a year), and
also whenever someone from your network operations group leaves – these
passwords should remain a company secrete.
Note implementing these security filters will insulate your last mile
network (raising its overall reliability) but will do little to protect your
customers from the remaining threats: subscribers hacking one another or
outsiders hacking your subscribers. These two subjects are beyond the scope
of this article but you should keep in mind that your work is only half
done.
Summary:
The filters defined in the DOCSIS specification are more than adequate in
providing good CM security. Implementing all the filters described in this
article will significantly reduce your “trust” in your subscribers to be
“good” users and provide your network with the insulation you’ve been
missing.
Once more, implementing these filters downplays
the role that the Baseline Privacy Interface (BPI) plays on the cable plant
side of the network. BPI is a feature that is run on the CMTS that forces
all the traffic between CMs and CMTS to be encrypted. However, if this
traffic is unreachable, why does it need to be encrypted? It would be like
encrypting traffic between two servers in your data center. If the traffic
is inaccessible, encryption becomes overhead and slows down both the
machines and the traffic between them. On the HFC, BPI becomes overhead when
subscribers are cut off from accessing traffic outside the modem.
Implementation of the filters described in this article isolate the ethernet
side of the modem from the HFC side whereby preventing subscribers from
being able to see traffic on the HFC "shared" network. The ONLY case that
BPI prevents when using these filters is that of the customer building a
hacked modem and attempting sniff these packets. However, the possibility of
this is extremely remote and it’s my feeling that if this person is smart
enough to do this, you've got bigger problems.
Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white
papers hot off
the presses by adding our RSS feed to your reader.
|
|