Filtering Traffic Transiting the Router

Problem

For traffic transiting through the router, you want to accept packets only from trusted hosts and routers.

Solution

Create a firewall filter for all incoming traffic to the router that will be used on interfaces facing the Internet. The filter contains a number of terms for different types of packets and for specific addresses.

The first term discards unwanted traffic from specific addresses:

	[edit firewall incoming-to-me]
	aviva@RouterF# set term reject-addresses from source-address 172.68.0.0/16
	aviva@RouterF# set term reject-addresses from source-address 192.168.0.0/24
	aviva@RouterF# set term reject-addresses then discard

The second term accepts traffic from BGP peers:

	[edit firewall filter incoming-to-me]
	aviva@RouterF# set term bgp-peers from destination-address 10.0.31.0/24
	aviva@RouterF# set term bgp-peers from protocol tcp
	aviva@RouterF# set term bgp-peers from port bgp
	aviva@RouterF# set term bgp-peers from tcp-established
	aviva@RouterF# set term bgp-peers then accept

The third term accepts all ICMP traffic:

	[edit firewall filter incoming-to-me ]
	aviva@RouterF# set term icmp from protocol icmp 
	aviva@RouterF# set term icmp then accept 

The last term accepts all other packets:

	[edit firewall filter incoming-to-me ]
	aviva@RouterF# set term final-accept then accept 

For the filter to take effect, apply it to an Internet-facing interface:

	[edit interfaces t1-0/0/3 ]
	aviva@RouterF# set unit 0 family inet filter input incoming-to-me 

 

Discussion

There are two basic ways to design a firewall filter. One way is to block packets and traffic that the router shouldn't receive and accept everything else, which is how the filter in this recipe operates. This type of filter design is fairly intuitive and, as you can see from this recipe, these filters are reasonably short and fairly easy to configure. One downside to this approach is that if you forget to block a particular type of traffic, you are opening yourself up to security breaches. The second design philosophy, of accepting only desired traffic and blocking everything else, is discussed in Recipe 9.15.

This recipe is for an EBGP edge router that connects to the Internet. The filter is very straightforward, accepting all packets except for traffic coming from a few IP prefixes.

Firewall filter terms are evaluated in order, so place the terms at the beginning of the filter that you want executed first. The first term in this recipe, reject-addresses, looks for packets from two networks that you never want to accept traffic from and immediately discards them, dropping them without sending any notification to the sender. Placing this term at the top of the filter improves the packet-processing efficiency of the interface.

The second term, bgp-peers, accepts BGP traffic only from the specified peer. The conditions in this term look for TCP protocol traffic from the BGP port and match TCP connections that have been established. Again, all BGP traffic is accepted by the final term, so including a separate term for the router's BGP peer just speeds up the processing of traffic from the peer.

The final term, ospf, accepts all OSPF traffic. You might wonder why you need this term when the final term will also accept OSPF traffic. The only reason to do this is that you want OSPF traffic to be handled more quickly than the other remaining traffic. If other operations on your network are time-critical, include them early in the filter. If you are going to apply this filter to a high-speed interface or to traffic flowing at a high rate, you gain efficiency from this type of firewall filter design.

The last term in the filter accepts all other traffic. It is important to note that you must be very cognizant of what you are enabling and what the other protocols are that run on the router when you design firewall filters that, as a last term, accept all other traffic. While this example illustrates a way to design filters that is easy and intuitive, it is generally better practice to explicitly accept what you want and discard everything else. Recipe 9.15 illustrates this firewall filter design approach.

As the last step in the configuration, apply the filter to an interface, here the t1-0/0/3 interface. The set filter input command applies the filter to incoming traffic. To apply a filter to traffic going out of the interface, use the set filter output command.

Here's the entire configuration to show all the contents together:

	[edit firewall]
	aviva@RouterF# show
	filter incoming-to-me {
	 term reject-addresses {
	 from {
	 source-address {
	 172.68.0.0/16;
	 192.168.0.0/24;
	 }
	 then {
	 discard;
	 }
	 }
	 term ospf {
	 from {
	 protocol ospf;
	 }
	 then accept;
	 }
	 term bgp-peers {
	 from {
	 destination-address {
	 10.0.31.0/24;
	 }
	 protocol tcp;
	 port bgp;
	 tcp-established;
	 }
	 then accept;
	 }
	 term final-accept {
	 then accept;
	 }
	}
	[edit interfaces]
	t1-0/0/3 {
	 unit 0 {
	 family inet {
	 filter {
	 input incoming-to-me;
	 }
	 address 10.0.31.2/24;
	 }
	 }
	}

Use the show interfaces command to check that the filter is configured:

	aviva@RouterF> show interfaces t1-0/0/3.0 detail
	 Logical interface t1-0/0/3.0 (Index 70) (SNMP ifIndex 40) (Generation 24)
	 Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
	 Protocol inet, MTU: 1500, Generation: 31, Route table: 0
	 Flags: None
	 Filters: Input: incoming-to-me
	 Addresses, Flags: Is-Preferred Is-Primary
	 Destination: 10.0.31/24, Local: 10.0.31.2, Broadcast: 10.0.31.255,
	 Generation: 63

Looking at the logical interface, which is where information about the address family is displayed, you can see which firewall filters are applied to the interface.

See Also

Recipe 9.15