Contact:[email protected]
http://www.liquifried.com/securingospf.html
Securing OSPF
Jason Chan, version 1.1, 6 February 2001
OSPF Background
OSPF (Open Shortest Path First) is an open standard IP routing protocol.
Developed in the late 1980's in response to the need for a higher
performance, vendor neutral routing protocol, OSPF was first specified
in RFC 1131. The current OSPF RFC is 2328.
OSPF is a link-state routing protocol. Link-state routing protocols take
the actual state of the network link into account when creating routing
tables and calculating routing decisions (hence the name). This
basically means that factors like bandwidth and delay can be used when
calculating a route's best path, instead of the traditional metric of
hop count used by the distance-vector family of routing protocols.
A large number of network administrators choose OSPF as their interior
routing protocol. Its fast convergence time and high degree of
configuration control contribute to OSPF's popularity. However, the fact
that OSPF is an open standard may be the biggest reason for its
popularity. EIGRP (Enhanced Interior Gateway Routing Protocol) is one of
OSPF's counterparts in the world of interior routing protocols. Although
it is quite popular and performs well, EIGRP is a proprietary Cisco
protocol. Hence, it is an inappropriate choice for heterogeneous
networks.
Rather than focus on the details of OSPF (of which there are many), this
paper focuses more narrowly on some of the security aspects of OSPF.
Specifically, this article describes the secure configuration of OSPF in
a heterogeneous network environment. The network described will include
both a Cisco router and Unix machines running the popular gated routing
package. For further details on OSPF, gated, and other subjects
mentioned in this article, please consult the references provided.
Defense in Depth
The security of routing protocols doesn't get a lot of press. Most of
the security material you'll read will be about the more 'glamorous'
aspects of information security like firewalls, intrusion detection, and
VPNs. And, while all of these topics merit attention, I myself am an
advocate of what is often described as 'defense in depth.'
'Defense in depth' basically refers to the idea that security
(information or otherwise) should be provided at as many layers as
possible. This idea is seen often in everyday life. For example, a
deadbolt lock will do a good job of securing your house, but wouldn't an
alarm system in addition be even better? How about bulletproof glass or
armed guards? Probably out of the question for your normal home security
plan, but what about when it comes to securing your company's network?
With the speed of developments in both sides of the information security
field (the good guys and the bad guys) it is more important than ever to
provide defense in depth. Statements like "I have a firewall, so my
network is secure" or "I have an IDS installed so I'll be able to tell
when someone's breaking in" just aren't true. What about when the
firewall's been misconfigured or just plain fails? What about when there
is a new attack that your IDS signatures don't detect? For that matter,
what about when an employee decides to install a modem in his desktop PC
so he can dial in from home, potentially subverting both your firewall
and your IDS? All of these and more are reasons for the implementation
of defense in depth in any endeavor to provide information security.
Being proactive rather than reactive and thinking and designing in
layers are two of the best pieces of advice I could give about securing
networks and information. Now, enough rambling and propaganda, let's see
how securing your OSPF routing infrastructure can help you improve your
network's security posture.
Secure Routing?!?
Given that OSPF is an interior routing protocol, some people may
question the need for securing their routing environment given that
their OSPF infrastructure is entirely contained within their
organization and is untouched by the outside world. This may be true,
but in addition to providing an additional layer of defense, securing
your OSPF routing can do something that firewalls, IDS, and VPNs can't
always do: protect against internal threats. After all, I've read
sources that mention up to 70% of information security threats come from
within a network's perimeters (don't ask me for the reference, after
all, if you're reading this article, you've probably heard similar
claims).
Securing your OSPF networks will protect you from not only malicious
attacks, but also accidental misconfigurations. The friendly nature of
OSPF dictates that any router with coordinated configuration parameters
(network mask, hello interval, dead interval, etc.) can participate in a
given OSPF network. Because of this default behavior, any number of
accidental factors (misconfigurations, lab machines, test setups, etc.)
have the potential to adversely affect routing in an OSPF environment.
So, are you convinced that you should secure your OSPF environment?
Well, then read on.
A Brief Disclaimer
Before moving on, I'll clarify a few things. The items I'll be
discussing (Cisco IOS, routing, OSPF, gated, etc.) are very complex and
cannot be adequately covered in a paper of this length. For this reason,
please do not consider this paper a final authority for securing OSPF
but rather a suggestion based on one person's experience with the
subject. There will be issues I don't cover, so please feel free to
consult the provided references and other sources for clarification.
Also, if you plan on implementing any of the items listed in this paper,
please do so in a test environment first as no warranty is made to the
suitability, appropriateness, or correctness of the information provided
in this paper. Lastly, if you have any suggestions, questions, or
corrections, please email me at [email protected].
How-to
For the sake of brevity and clarity, concepts and instruction will be
illustrated through the configuration of a small network, although the
concepts can be applied to OSPF environments of any size. In fact, the
networks that I've personally implemented these concepts on have all
been very large (10,000+ nodes) sites. The following diagram describes
the network to be configured in this article.
The Cisco router serves as the access point to external networks (the
Internet). The OpenBSD machine serves as the firewall and gateway for
the Engineering networks. The Mandrake Linux machine serves as the
firewall and gateway for the Sales networks. These three devices will
all share routing information via OSPF.
Broadcast vs. Non-Broadcast
The first step to take in securing an OSPF routing environment is to
configure all participating devices as non-broadcast devices. In
non-broadcast, or directed, mode, OSPF devices need to be explicitly
configured to communicate with valid OSPF neighbors. This provides a
basic layer of security against misconfiguration, because valid OSPF
devices will only communicate with the OSPF devices they have been
configured to interoperate with. In a broadcast (actually, OSPF is a
multicast protocol) OSPF environment, any OSPF devices with the correct
configuration parameters for the network will be able to participate in
OSPF routing.
On Cisco routers, interfaces will use broadcast OSPF by default. To turn
on directed OSPF, use the following interface configuration statement:
ip ospf network non-broadcast
For our network, this command would be issued while at the Ethernet 0
interface configuration prompt. In addition, under the specific OSPF
process configuration, the router's OSPF neighbors must be explicitly
named. For our network, the following statements would be issued while
at the OSPF process configuration prompt:
neighbor 192.168.0.222
neighbor 192.168.0.123
In gated, as with Cisco IOS, non-broadcast OSPF is configured per
interface. The following configuration snippet is from the OpenBSD
machine's gated.conf file (the gated configuration file, found by
default in /etc):
interface 192.168.0.123 non-broadcast
Likewise, on the Mandrake machine, the following statement would be in
/etc/gated.conf:
interface 192.168.0.222 non-broadcast
As with Cisco routers, Unix machines running gated must also have their
OSPF neighbors explicitly configured. This is done with the routers
configuration directive. The routers configuration directive is an
interface specific directive. Thus, the following configuration would
appear under the 192.168.0.123 interface configuration on our OpenBSD
machine:
routers {
192.168.0.1 eligible;
192.168.0.222 eligible;
};
This configuration states that the routers at 192.168.0.1 (Cisco e0) and
192.168.0.222 (Mandrake eth0) are eligible to participate in our OSPF
routing environment.
On our Mandrake machine, the following configuration would appear under
the 192.168.0.222 interface section:
routers {
192.168.0.1 eligible;
192.168.0.123 eligible;
};
Authentication
To increase the security of an OSPF environment, authentication can be
enabled. Actually, all OSPF exchanges are authenticated. However, as the
gated documentation puts it,
By definition, all OSPF protocol exchanges are authenticated;
however, one method of authentication is "none."
OSPF authentication can be either none, simple or MD5. With simple
authentication, the password goes in clear-text over the network. Thus,
anyone with a sniffer on the OSPF network segment would be able to pull
the OSPF password, and the attacker would be one step closer to
compromising your OSPF environment. With MD5 authentication, the key
does not pass over the network. MD5 is a message-digest algorithm
specified in RFC1321. MD5 should be considered the most secure OSPF
authentication mode.
To turn on MD5 OSPF authentication on a Cisco router, use the following
configuration statement:
ip ospf message-digest-key 5 md5 foobar
This statement should be entered at the interface configuration prompt.
In this example, '5' is the key ID and 'foobar' is the MD5 key. On our
network, this command would be entered at the Ethernet 0 interface
configuration prompt.
In addition, authentication has to be turned on for the specific OSPF
process ID. This is done with the following statement, at the OSPF
process configuration prompt:
area 0 authentication message-digest
This command turns on MD5 authentication for the OSPF backbone area.
In gated, MD5 authentication is also configured per interface. On our
OpenBSD machine, the following statement would appear within the
192.168.0.123 interface configuration:
auth md5 key "foobar" id 5;
The same statement would exist under the 192.168.0.222 interface
configuration section on our Mandrake machine.
Testing and Troubleshooting
Once you've got everything configured, your OSPF environment should be
communicating in a directed manner with MD5 authentication. To verify
the Cisco's operation, the following commands should be helpful:
show ip route - to verify the routing table
show ip ospf neighbors - to verify the router's ospf neighbors
debug ip ospf ? - to turn on ospf debugging (careful, you can get a lot
of output depending on your selection)
To verify gated operation, use
netstat -rn
to verify the system routing table. Using the -v switch can give more
verbose output on some systems. Also, using the traceoptions
configuration directive in gated.conf will turn on gated tracing, which
can assist in debugging dynamic routing issues. The following statement
would be used in gated.conf to turn on full tracing with results being
stored in /var/gated.log:
traceoptions "/var/gated.log" all;
Restart gated with a
gdc restart
And run
tail -f /var/gated.log
to read the debugging output.
To see more detailed gated.conf configurations for this example, see
further snippets of the Mandrake and OpenBSD /etc/gated.conf files.
Other Issues
So, you've got your dynamic routing environment converted over to
directed and MD5 authenticated OSPF. Are you totally secure now? Of
course not, but you're further along than before.
One thing to keep in mind regarding the topics discussed thus far, the
MD5 authentication process does not provide encryption of routing data.
Instead, it verifies the sending and receiving parties. Thus, an
attacker with a sniffer on the wire would still be able to decode
routing update packets. Injecting false packets and compromising the
environment will just be a lot more difficult.
Also, issues can arise when keys are modified. If you're following best
security practices (you are, aren't you?) you'll change your OSPF
authentication keys regularly. When keys mismatch in authentication
mechanism, things can go wrong. Fortunately, OSPF has some built in
measures to assist in key changeover. For more information, please
reference the sources cited below.
Conclusion
Undoubtedly, converting an unauthenticated broadcast OSPF environment to
a directed and authenticated system will improve your organization's
security posture. While it's obviously not the only step you need to
take to secure your network, it is one effective component of defense in
depth.
References
RFC2328. OSPF Version 2. http://www.ietf.org/rfc/rfc2328.txt
Gated documentation. http://www.gated.org and
http://www.gated.org/gated-web/code/doc/manuals/config_guide/config_guid
e.html
Cisco documentation. http://www.cisco.com and
http://www.cisco.com/warp/public/104/2.html#6.0
RFC1321. The MD5 Message-Digest Algorithm.
http://www.ietf.org/rfc/rfc1321.txt
OSPF: Anatomy of a Routing Protocol. John T. Moy. Addison-Wesley. 1998.
Credits
To the guys who got me into this mess: Bob Acosta, Chris Williams, John
Weidley, Paul Kincaid.
Version Information
Version 1.1 - February 6, 2001 - Updated with configuration examples,
after putting an actual test network together. (Better than recalling
from memory).
Version 1 - August 18, 2000 - Original version.
Back to the Index