Protecting the Local Routing Engine

Problem

You want to protect the Routing Engine by ensuring that it accepts traffic only from trusted network systems.

Solution

Protecting the Routing Engine involves filtering incoming routing protocol traffic on the router's lo0 interface. The first step is to create the filter:

[edit firewall] aviva@RouterF# edit filter protect-RE

This filter contains terms for the different protocols running on the router. The first terms allow the router to accept routing-protocol traffic from BGP peers and OSPF neighbors:

[edit firewall filter protect-RE] aviva@RouterF# edit term bgp-peers [edit firewall filter protect-RE term bgp-peers] aviva@RouterF# set from source-address 10.0.8.0/24 aviva@RouterF# set from source-address 10.0.13.0/24 aviva@RouterF# set from destination-port bgp aviva@RouterF# set then accept aviva@RouterF# up [edit firewall filter protect-RE] aviva@RouterF# edit term ospf-neighbors [edit firewall filter protect-RE term ospf-neighbors] aviva@RouterF# set from source-address 10.0.8.0/24 aviva@RouterF# set from source-address 10.0.13.0/24 aviva@RouterF# set from protocol ospf aviva@RouterF# set then accept

The next term allows TCP traffic:

[edit firewall filter protect-RE ] aviva@RouterF# edit term tcp-traffic [edit firewall filter protect-RE term tcp-traffic ] aviva@RouterF# set from source-address 10.0.0.0/8 aviva@RouterF# set from protocol tcp aviva@RouterF# set then accept

The following term allows DNS traffic:

[edit firewall filter protect-RE ] aviva@RouterF# edit term dns-servers [edit firewall filter protect-RE term dns-servers ] aviva@RouterF# set from source-address 10.0.0.0/8 aviva@RouterF# set from protocol udp aviva@RouterF# set from port domain aviva@RouterF# set then accept

The next two terms allow RADIUS, SSH, and Telnet connections to the router:

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

Two terms accept traffic from SNMP NMS systems:

[edit firewall filter protect-RE ] aviva@RouterF# edit term xnm-from-nms [edit firewall filter protect-RE term xnm-from-nms ] aviva@RouterF# set from source-address 10.0.0.1/32 aviva@RouterF# set from source-address 10.0.5.1/32 aviva@RouterF# set from protocol tcp aviva@RouterF# set then accept aviva@RouterF# up [edit firewall filter protect-RE ] aviva@RouterF# edit term allow-snmp-from-nms [edit firewall filter protect-RE term allow-snmp-from-nms ] aviva@RouterF# set from source-address 10.0.0.1/32 aviva@RouterF# set from source-address 10.0.5.1/32 aviva@RouterF# set from protocol udp aviva@RouterF# set from destination-port snmp aviva@RouterF# set then accept

Two terms accept traffic from the network's NTP servers and from ICMP:

[edit firewall filter protect-RE ] aviva@RouterF# edit term allow-ntp [edit firewall filter protect-RE term allow-ntp ] aviva@RouterF# set from source-address 10.10.0.1/32 aviva@RouterF# set from source-address 10.10.5.1/32 aviva@RouterF# set from port ntp aviva@RouterF# set then accept aviva@RouterF# up [edit firewall filter protect-RE ] aviva@RouterF# edit term allow-icmp [edit firewall filter protect-RE term allow-icmp ] aviva@RouterF# set from protocol icmp aviva@RouterF# set from icmp-type [ echo-request echo-reply unreachable time-exceeded source-quench ] aviva@RouterF# set then accept

The last term explicitly rejects all other traffic:

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

Create a system logfile for the messages that will be generated by the set then syslog command:

[edit system syslog] aviva@RouterF# set file messages firewall any

Finally, apply the filter to the router's loopback interface:

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

Discussion

This recipe illustrates the second broad firewall filter design philosophy mentioned in Recipe 9.11that of creating a filter that allows only the desired traffic and blocks everything else. This design requires more planning than the reverse strategy of blocking traffic that the router should not receive first and then allowing everything else, but it ensures maximum security. You need to spend time up front looking at your network and router configurations and analyzing the flow of traffic through your network to determine the types of traffic the router should expect to receive and the addresses and ports from which it should receive the traffic. Another factor working in favor of improving the security of this design is that, by default, if a packet does not match any term in a firewall filter, it is discarded.

This "allow known, block everything else" design is good practice for protecting the router's Routing Engine. Because the JUNOS routing-protocol software runs on the Routing Engine, you want to make sure that all the traffic it receives is from known and trusted sources.

This recipe is for a router running the routing protocols BGP and OSPF. The router can be accessed by SSH and Telnet, and by DNS, RADIUS, and NMS servers. The firewall filter has a term that handles each type of protocol traffic. A design decision you have to make is the order of the terms in the filter. As with routing policy, the terms in the firewall filter are evaluated in the order in which they appear in the configuration, so the placement affects the efficiency of the filter. You need to decide which packet-filtering operations need to be performed quickly and which are not so time-critical. Generally, protocol packets and possibly address resolution should be handled quickly so that the actual process of routing traffic occurs efficiently. The terms for other less important or background tasks, such as user connections to the router and SNMP polling, are placed towards the end of the filter.

The first terms in this firewall filter accept BGP and OSPF protocol traffic. The AS has two subnetworks, 10.0.8.0/24 and 10.0.13.0/24, so the filter allows protocol traffic only from these specific addresses. For OSPF, we can match on the protocol, but there is no BGP protocol option, so you need to match packets destined for a BGP port. The third term accepts TCP traffic. Because BGP runs over TCP, this term ensures that TCP connections can be set up.

The term dns-servers filters DNS traffic for resolving hostnames and addresses. DNS runs over UDP and uses the domain source port, and the filter uses this information to identify DNS traffic. DNS traffic can come from any server on the 10.0.0.0/8 subnetwork. The terms radius and ssh-telnet accept traffic from the network's RADIUS servers and from SSH and Telnet connections. Both these filters identify packets by looking at their destination port. The RADIUS servers are on two subnet-works, 10.1.0.1/32 and 10.3.0.1/32, and SSH and Telnet sessions are allowed on the 10.0.8.0/24 and 10.0.13.0/24 subnetworks.

The terms xnm-from-nms and allow-snmp-from-nms allow the network's two management systems, 10.0.0.1/32 and 10.0.5.1/32, to access the router. These two servers are both running JUNOScript software, which establishes TCP-based SSL connections to the router, and SNMP. The xnm-from-nms term accepts SSL connections from the JUNOScript software, and the second term accepts SNMP queries.

The final term in the filter, allow-nothing-else, drops all other packets. In this case, we want to know how many packets are dropped, so nonmatching packets are counted in the counter named reject-counter. The set then log command logs these packets to the firewall counter, and the set then syslog command logs them to a system logfile. The recipe configures the system logfile messages to contain the system log messages, using the firewall facility to capture firewall-related messages.

Use the show firewall log command to see how many packets are being rejected or look in the logfile with the show low messages command. You can also look in the file /var/etc/filters/dfwc.out to see the actions taken by the different terms in the filter. The following is some of the output for the protect-RE filter:

aviva@RouterF> file show /var/etc/filters/dfwc.out ************************************************************** * filter "protect-RE" protocol ip: 8 rules, 24 matches * Stage: after match reduction and useless match elimination * Optimizations: max-reduction,skip,flatness,level-compress, * max-level-compress,branch,action-elimination ************************************************************** rule "ospf-neighbors" matches 3 match protocol unreferenced type range ranges 1 89 match source-address unreferenced type addrmask number of address-masks: 2 10.0.8/24 10.0.13/24 match action unreferenced type action accept rule "dns-servers" matches 4 match protocol unreferenced type range ranges 1 17 match port unreferenced type range ranges 1 53 match source-address unreferenced type addrmask number of address-masks: 1 10/8 match action unreferenced type action accept

The header shows the name of the filter and the number of rules (terms) it has, along with the number of packets that have matched:

* filter "protect-RE" protocol ip: 8 rules, 24 matches

Again, because the firewall filter is fairly complicated, here is the complete configuration so you can see the structure:

[edit firewall] aviva@RouterF# show filter protect-RE { term bgp-peers { from { source-address { 10.0.8.0/24; 10.0.13.0/24; } destination-port bgp; } then accept; } term ospf-neighbors { from { source-address { 10.0.8.0/24; 10.0.13.0/24; } protocol ospf; } then accept; } term tcp-traffic { from { source-address 10.0.0.0/8; protocol tcp; } then accept: } term dns-servers { from { source-address { 10.0.0.0/8; } protocol udp; port domain; } then accept; } term radius { from { source-address { 10.1.0.1/32; 10.3.0.1/32; } destination-port radius; } then accept; } term ssh-telnet { from { source-address { 10.0.8.0/24; 10.0.13.0/24; } destination-port [ ssh telnet ]; } then accept; } term xnm-from-nms { from { source-address { 10.0.0.1/32; 10.0.5.1/32; } protocol tcp; } then accept; } term allow-ntp { from { source-address { 10.10.0.1/32; 10.10.5.1/32; } port ntp; } then accept; } term allow-icmp { from { protocol icmp; icmp-type [ echo-request echo-reply unreachable time-exceeded source quench ]; } then accept; } term allow-snmp-from-nms { from { source-address { 10.0.0.1/32; 10.0.5.1/32; } protocol udp; destination-port snmp; } then accept; } term allow-nothing-else { then { count reject-counter; log; syslog; reject; } } } [edit interfaces] lo0 { unit 0 { family inet { filter input protect-RE; address 192.168.16.1 } } }