Routers
| Implementing security with routers actually involves two different things: securing the routers themselves and using routers to secure the network. If you don't control the router, you might not be controlling the traffic; that makes controlling (securing) the router the first step. Securing routers is not just a matter of giving them a strong password. It means that all the paths into the router are under your control, and it means managing what someone (who is permitted access) can do after a successful login; we call that securing access. But that is not all that goes into securing a router: There is also securing what the router is allowed to dosecuring services and management protocols to be used. These are really two different things, so we cover them one at a time. Securing AccessBefore you can secure access to the router, you must know the paths into it:
All interactive connections are referred to as lines because they use the IOS TTY (originally "teletypewriter") abstraction. Local connections (those that are directly wired in, such as the console or aux ports) are called TTY lines (or just TTYs). Those that connect via the network (in- or out-of-band) are virtual TTY, or VTY lines (VTYs). Telnet, of course, is the protocol used to emulate a direct connection (like a console port) over the indirect connection, or VTY. You are "virtually" directly connected when you use Telnet over an indirect connection.
On a network of any size, most of the configuration updates will be done via VTYs. It is common to use Telnet connections for this (either in-band or OOB), but SAFE recommends the Secure Shell protocol (SSH) instead. You can configure this on a given line with the transport input ssh command. If you are connecting from a remote host, whether in-band or OOB, you might choose to require IPSec (because that is often applied on edge deviceswe cover it in Chapter 9, "Products in the Edge"). In addition to limiting the protocols that can be used on a given line, you should restrict which addresses can connect via that line: Use a standard IP access list (all you need is source addressesprotocols are handled with the transport input command) to specify the workstations allowed to connect. You might restrict this to a subset of your address block, or you might prefer to have the option to use any workstation inside your network. If so, however, someone inside the network (or someone able to spoof an inside address) could open VTY sessions on every line and lock you out of anything but a direct connection. Most devices that run the IOS have a limited number of VTYs (usually five). You might want to assign a more restrictive access list to the last of these; if you restrict the connections to line VTY 4 to only those that come from a single, designated administrative workstation, then if a hacker does manage to lock up the other VTYs, you should still be able to get in through that one. Preventing such a lock-up (at least, one that lasts for any extended period of time) can be done by establishing a timeout on idle lines with the exec -timeout command in line configuration mode. Other protocols that you might want to use include TFTP or FTP for backing up configuration files and for downloading software images. You should restrict those protocols to only the servers that you designate , via an extended IP access list. For that matter, access for all management protocols that you choose to use (you need not choose them all) should be restricted to your designated servers only, and you should log any denials. Next , we need to address two interrelated topics: passwords and AAA. Passwords should always be encrypted through the service password-encryption command, and you should always use an enable secret rather than an enable password. The passwords used for various TTYs and VTYs should be strong:
As a rule, every form of access to the router should be authenticated via AAA, if possible. The SAFE validation laboratory principally used TACACS+, although RADIUS was used with the VPN concentrator. However, it is possible (though hopefully unlikely ) that you might lose the AAA server or connectivity to it at the same time that you need to make a configuration change to a router. That is why the AAA implementation should contain a back doora protected back door, of course. To enable AAA, you must enter the command aaa new-model (if this is the first implementation of AAAif it is not and you want to start from scratch, first erase the existing AAA configuration with the command no aaa new-model ). The back door comes from an entry along the lines of aaa authentication login no_tacacs line , which is applied very carefully . Taking this command apart, you have the following:
If this command is applied to the console 0 TTY (with the command login authentication no_tacacs in line configuration mode), there is a means to be authenticated to the router based on the line password, and the incapability to reach the AAA server is not fatal. As part of your AAA implementation, you make needed authorizations, such as for execstarting up an exec shell (as in aaa authorization exec tacacs+ )and networkfor such Layer 2 network protocols as PPP, SLIP, and ARAP (as in aaa authorization network tacacs+ ). Of course, if someone does something to the router, you want to know who has been logged in, when, and what they did; you need to have turned on accounting, which, of course, does not use quite the same commands: aaa accounting { execnetwork...} start-stop tacacs+ . In this case, the initiation and termination of exec or network activity will be recorded by the accounting server portion of the TACACS+ server. The wait-start option (instead of start-stop ) requires the process to hold up until the accounting process signals that it has begun. Finally, you should configure a banner to be seen on logins. This should not welcome guests or anyone else. Instead, it should warn that this device is the property of the organization and is to be used only for the authorized activity of that entity. Securing Services and ManagementWith access and configuration on the router taken care of, you must control what the router is allowed to do: what services it will run, with whom it will exchange information, and how it will know to trust them. Likewise, you must be sure that the management protocols it exchanges information with are secured. Routers often have (possibly depending on the actual release of the IOS that is loaded) a number of services that are turned on by default. These services reflect the "good old days" when networks were small and everyone could trust each other. We all know that those days are long gone. Whether Cisco should change the default setting for these services is open to debate; the point for you to remember today is that these services should be turned off. The order in which you issue the commands does not matter much, although most people put these commands at the beginning of a configuration file, to be sure they are read first. Here, in alphabetical order, is a list of service-management commands that you should include in your configuration file on every router, regardless of its location:
What are these, and why should you care? We discussed the reconnaissance value of CDP in Chapter 5, "Management Protocols and Functions," and we stated then that Cisco recommends turning it off; if you don't turn it off everywhere, at least turn it off on all external-interface routers and on all interfaces (via no cdp enable in interface configuration mode) that connect to those routers. You might or might not be familiar with BOOTP, an older protocol for assisting diskless workstations. Because the servers to support them were centralized, router software was coded to forward BOOTPREQUEST and BOOTPREPLY message traffic (in the IOS, the ip helper-address { IP address } command in interface configuration mode enables such forwarding). This traffic ran over UDP ports 67 and 68, respectively. DHCP has replaced BOOTP in almost all instances; if you have diskless workstations (they are making a comeback in certain areas), DHCP can provide everything they need. The IOS still contains a default setting enabling the router to act as a BOOTP server. However, there is no need for any of your routers to do that: Turn off the BOOTP server. You might or might not agree with the next command, but remember, you are configuring routers, not servers or workstations. Using no ip domain-lookup means that commands to your router will require the use of IP addresses (which it knows how to reach, of course). Unless a stranger knows your addressing scheme and has set aside an address somehow for nefarious purposes, turning off name resolution on your routers means that they can't be reconfigured by pointing them to a named host. Similar to acting as a BOOTP server, what legitimate need is there for your router to act as an HTTP server? Disable that capability ( no ip http server ) to protect your router from accepting and perhaps operating on HTTP requests (which need not be Web page requests , of course). Source routing is a means of tracing the path that a packet took to get where it did (not the same as the traceroute command, although the purpose might be similar). Do you really think it wise to allow someone to be able to find a way to your router's interfaces reliably? Not in a secured network. Disable IP source routing ( no ip source-route ). The last three items on the list are services: no service finger, no service tcp small-servers , and no service udp small-servers . The finger service (which, by the way, is available at the Windows command line as well as Unix and its derivatives) is a means to learn who is logged on to a system. Even more dangerous, perhaps, than revealing usernames ( now I only have to crack the passwords! ) is that the finger service on a router reveals the processes running on the system, the line number, the connection name, the idle time, and the terminal location. That gives a hacker far too much information about your router and how to access it. The small servers are actually a cluster of services: echo, discard, chargen (character generator), and daytime. They, too, are relics of the early TCP/IP networks, and they do not need to run on your routers. You might want to disable other services and "features" on interfaces, such as no ip route-cache and no ip mroute-cache , plus no mop enable to disable the old Maintenance Operating Protocol (which is used on DECnet). Also on your interfaces, you should enable MD5 authentication of routing protocol updates, and you should restrict to whom you advertise those updates by applying a distribute list. That leaves you with the network-maintenance protocols that you do want to use, which should include NTP and might include SNMP. You want to use versions with authentication (v3, as it happens, in both cases). If you use SNMP, use a read-only community unless you actually need read-write capability. You should also set up logging, with the logs going to a dedicated server. For the logs to be useful, you should have turned on time stamping ( service timestamps log datetime localtime msec ). In all three of these cases (logging, NTP, and SNMP), be sure to use an access list that designates the specific host(s) for that purpose. When you read over the configurations used in the validation, you'll note an ACL for each of the functions rather than one ACL (even though often more than one management function resides on a single device). This provides flexibility in the configuration in case you need to move a function (but not all of the functions) from one host to another: Change the IP address in the permit statement of that particular ACL, and you are done. You should also note that all the access lists that permit management functions on the routers include a specific deny any log statement at the end. Even though there is an implicit deny at the end of every access list, the explicit denial enables you to log the failed attempts, which you would otherwise never know about.  |
EAN: 2147483647
Pages: 177