Restricting Inbound SSH and Telnet Access | Basic Router Security and Access Control

Problem

You want to allow SSH and Telnet access to the router but you want to restrict the access to make the router more secure.

Solution

Add a term to an existing firewall filter that restricts SSH and Telnet access:

	[edit firewall filter protect-RE ]
	aviva@RouterF# set term ssh-telnet from source-address 10.0.8.0/24 
	aviva@routerF# set term ssh-telnet from destination-port [ ssh telnet ] 
	aviva@RouterF# set then accept

Also include a term at the end of the filter to reject access attempts from any other subnets:

	[edit 
firewall filter protect-RE ]
	aviva@RouterF# set term allow-nothing-else then count reject-counter 
	aviva@RouterF# set term allow-nothing-else then log 
	aviva@RouterF# set term allow-nothing-else then syslog 
	aviva@RouterF# set term allow-nothing-else then reject

For the filter to affect incoming traffic, apply it to the desired interfaces:

	[edit interfaces]
	aviva@RouterF# set lo0 unit 0 family inet filter input protect-RE

Discussion

SSH and Telnet are two very common ways to access the router. However, SSH brute-force attempts to guess passwords are a very common way to try to compromise routers, and Telnet connections are not very secure. To protect the router, you should restrict the systems from which people can use SSH and Telnet to the router. Even though Telnet is not a secure access method, you may want to allow it because your network management tools use Telnet to access routers, and it is more of a hassle to change the access method than to just allow restricted access. As much as possible, you should lock down access to all management services on the routers and on any other systems in your network to maintain tight security. You can never be sure that people are not using passwords that are easy to guess, and Telnet sends passwords over the network in clear text, so they could easily be sniffed. Restricting inbound access to the router also protects against potentially unknown vulnerabilities with SSH and Telnet.

You restrict Telnet access using a firewall filter. This recipe shows a single term in a firewall filter that acts on all TCP traffic whose destination port is the Telnet port (port 23), and it accepts Telnet connections only from the 10.0.0.0/8 subnet and rejects all other connection attempts. Each interface can have one inbound firewall filter, so you include the term shown in this recipe in the complete firewall filter that you apply on an incoming interface.

It's important to note that if you use the term in the recipe as the only filter on an interface, it will block all traffic to the Routing Engine except for Telnet from subnet 10.0.0.0/8. This means that SNMP, OSPF, IS-IS, PIM, and BGP will all be blocked. Make sure you include this term as part of a longer firewall filter.

You have to decide where in the filter to place the term. Because the terms in the firewall filter are evaluated in the order in which they appear, the placement affects the efficiency of the filter. Generally, terms for operations that need to be performed quickly, such as BGP peering and IGP and DNS traffic, are at the beginning of the filter. For operations that are less time-critical, including processing Telnet connections, place the term toward the end of the filter.

Then apply the filter to the desired interfaces. Here, we apply the filter to the lo0 interface because we want it to apply to all traffic destined to the router's management addresses, even traffic that is coming to the address of one of the network (PIC) interfaces.

The term in this recipe is just one of several terms in a single firewall filter. As a general point, you rarely just reject a firewall term without also either logging, syslogging, or running a counter on the rejections (which gives you data that you can graph). Tracking the rejections is useful for showing abuse of your router, attacks on the router, or even misconfigurations. For example, if you forget about an automated process that uses Telnet to read configuration information on your router that comes from 192.168.0.0/16 and you only permit 10.0.0.0/8, then the then syslog action (and appropriate syslog configuration statements) can be very handy for resolving issues.