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
	 }
	 }
	}



Router Configuration and File Management

Basic Router Security and Access Control

IPSec

SNMP

Logging

NTP

Router Interfaces

IP Routing

Routing Policy and Firewall Filters

RIP

IS-IS

OSPF

BGP

MPLS

VPNs

IP Multicast



JUNOS Cookbook
Junos Cookbook (Cookbooks (OReilly))
ISBN: 0596100140
EAN: 2147483647
Year: 2007
Pages: 290
Authors: Aviva Garrett

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net