Creating a Simple Firewall Filter that Matches Packet Contents

Problem

The default router interface behavior is to allow connections from anywhere on the network, but you want to restrict access so connections can be made only from known subnetworks.

Solution

Use firewall filters to control which packets an interface allows to enter the router. You know that connections to the router use Telnet or SSH, so create a filter that checks for these packets. First, create the firewall filter:

	[edit firewall]
	aviva@router1# set filter incoming-to-me term restrict-telnet-ssh from protocol tcp
	aviva@router1# set filter incoming-to-me term restrict-telnet-ssh
 from destination-port[ telnet ssh ]
	aviva@router1# set filter incoming-to-me term 
restrict-telnet-ssh

from source-address 10.0.0.0/8 aviva@router1# set filter incoming-to-me term restrict-telnet-ssh then accept

Then, apply the filter to the router's interface:

	[edit interfaces]
	aviva@router1# set fe-0/0/0 unit 0 family inet filter input incoming-to-me

Here's what the firewall filter looks like in the configuration:

	[edit]
	aviva@router1# show
	firewall {
	 filter incoming-to-me {
	 term restrict-telnet-ssh {
	 from {
	 protocol tcp;
	 destination-port [ telnet ssh ];
	 source-address {
	 10.0.0.0/8;
	 }
	 }
	 then accept;
	 }
	 }
	 }
	}
	interfaces {
	 fe-0/0/0 {
	 unit 0 {
	 family inet {
	 filter input incoming-to-me;
	 }
	 }
	 }
	}

 

Discussion

Placing firewall filters on the router's interfaces is one of the most critical actions you can take to protect the security of the router and the integrity of traffic received and sent by the router. Firewall filters also provide a mechanism for counting different types of packets received or sent over an interface. What happens if you don't configure a firewall filter? By default, interfaces accept all incoming traffic and transmit all outgoing traffic.

Unlike routing policy, which is part of RPD running on the Routing Engine and which looks at routing-protocol traffic, firewall filters look at all traffic on router interfaces, working as part of the PFE.

The firewall filter in this recipe has the same basic structure and components as a routing policy. It uses the same JUNOS policy language, and you can read through the show command output to understand what the firewall filter does.

The configuration creates a filter named incoming-to-me that has one term named restrict-telnet-ssh. This term accepts TCP packets if the IP packet header has a destination port or either Telnet (port 23) or SSH (port 22) and a source address that falls in the subnetwork 10.0.0.0/8. By default, this filter rejects all other packets. This recipe applies the filter to all IPv4 traffic on one of the router's physical interfaces, fe-0/0/0.

It's important to remember that this recipe shows only one term in a longer firewall filter as a way of illustrating how to configure a firewall filter. (Recipe 9.15 shows a complete filter.) If you were to apply only this filter to an interface, you would be able to use the interface only for Telnet and SSH connections from subnet 10.0.0.0/8, and all other incoming traffic would be dropped. Although it's possible that this is what you might want to do, it's not likely that you would want to do exactly this. However, this recipe does illustrate the point that you need to very carefully design and construct firewall files so that they do what you want and what you expect.

Because firewall filters apply to logical interfaces, not physical interfaces, each address family on an interface can have one filter for incoming traffic and one for outgoing traffic. This means you can have different filters for different logical interfaces. For this recipe, it also means that if this is the only interface on which you restrict SSH and Telnet access, using them to access the router through any other interfaces is unrestricted. This might be exactly the action you want. However, if your intent is to restrict SSH and Telnet access for all interfaces on the router, you must apply this firewall filter to all the router's interfaces. Again, you have a design choice to make here. You can certainly apply the filter to all the interfacesor to any number of interfaces. Another option in this case is to associate this filter with the router's loopback interface, lo0, which filters traffic going to the Routing Engine:

	[edit interfaces]
	aviva@router1# set lo0 unit 0 family inet filter input incoming-to-me

Because SSH requests are handled by the Routing Engine, instead of applying the filter to many or all of the router's physical interfaces, you can effect the same filtering by setting it on the loopback interface.

As defined, this filter works only on IPv4 traffic, because you configure it at the [edit firewall] level. To have it work for IPv6 traffic, you need to configure the filter at the [edit firewall family inet6] hierarchy:

	[edit firewall family inet6]
	aviva@router1# set filter incoming-to-me term restrict-telnet-ssh from protocol tcp

Then apply the filter to IPv6 traffic when configuring the interface's IPv6 address family:

	[edit]
	aviva@router1# set interfaces fe-0/0/0 unit 0 family inet6 filter input incoming-to-me

If your router has filters for both IPv4 and IPv6 traffic, you should define the IPv4 firewall filters at the [edit firewall family inet] hierarchy so it will be clear to someone reading through the configuration which filters apply to IPv4 and which apply to IPv6:

	[edit firewall family inet]
	aviva@router1# set filter ipv4-incoming-to-me term restrict-telnet-ssh from protocol tcp
	[edit firewall family inet6]
	aviva@router1# set filter ipv6-incoming-to-me term restrict-telnet-ssh from protocol tcp

The first three commands in the recipe, which form the from clause, set the filter's match conditions, defining which fields in the packet headers to examine. Firewall filters can match various fields in the headers (see Table 9-5).

Table 9-5. Header match conditions used in firewall filters

Match term

Match description

Address matches

 

address prefix

IP address in the source or destination field.

destination-address prefix

IP address in the destination field.

source-address prefix

IP address in the source field.

destination-prefix-list prefix-list

IP destination address of one of the prefixes in the prefix list.

source- prefix-list prefix-list

IP source address of one of the prefixes in the prefix list.

prefix-list prefix-list

IP source or destination address of one of the prefixes in the prefix list.

Port matches

destination-port number

destination-port name

TCP or UDP destination port field, specified as a number or name. Use with the protocol match condition to determine the protocol being used on a port.

Port names and numbers: afs, bgp, biff (512), bootpc (68), bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443), ident, imap, kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513), mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-dgm, netbios-ns, netbios-ssn, nfsd (2049), nntp, ntalk (518), ntp pop3, pptp, printer (515), radacct, radius, rip (520), rkinit (2108), smtp (25), snmp, snmptrap, snpp (444), socks, ssh (22), sunrpc, syslog (514), tacacs-ds (65), talk (517), telnet(23), tftp (69), timed (525), who (513), xdmcp, zephyr-clt (2103), zephyr-hm (2104)

source-port number

source-port name

TCP or UDP source port field, specified as a number or name. Use with the protocol match condition to determine the protocol being used on a port.

Port names and numbers same as those listed for destination-port.

Protocol and packet matches

icmp-type number

icmp-type name

ICMP packet type field, specified as a number or name. Use with the protocol match condition to determine the protocol being used on a port.

Type names and numbers: echo-reply (0), echo-request (8), info-reply, info-request, mask-request, mask-reply, parameter-problem, redirect (5), router-advertisement (9), router-solicit, source-quench (4), time-exceeded, timestamp, timestamp-reply, unreachable (3)

packet-length bytes

Length of the IP portion of the packet, including the header but excluding Layer 2 encapsulation overhead.

protocol number

protocol name

IP protocol field, specified as a number or name.

Names and numbers: ah, egp (8), esp (50), gre (47), icmp, igmp (2), ipip (4), ipv6 (41), ospf (89), pim, rsvp (46), tcp (6), udp

Packet field matches

fragment-flags number

IP fragmentation flag field, specified as a number or name.

Flag names and numbers: dont-fragment (0x4000), more-fragments (0x2000), reserved (0x8000)

fragment-offset number

Fragment offset from the beginning of the original packet, in 8-byte units. Use to identify all fragmented packets. The More Fragments (MF) flag is set for all fragmented packets except the last. To identify fragments, set fragment offset != 0 (or more fragments=1).

ip-options number

IP option field, specified as a number or name.

Option names and numbers: loose-source-route, record-route (7), router-alert, strict-source-route, timestamp (68)

tcp-flags number

TCP flag field, specified as a number or name. Use with the protocol match condition to determine the protocol being used on a port.

Flag names and numbers: ack (0x10), fin (0x01), push (0x08), rst (0x04), syn (0x02), urgent (0x20)

first-fragment

First fragment of a fragmented packet.

is-fragment

Packet fragment other than the first one.

tcp-established

TCP packets other than the first one in a connection (equivalent to "(ack | rst)"). Use with protocol tcp to match TCP packets.

tcp-initial

First packet of a TCP connection (equivalent to "(syn & !ack)"). Use with protocol tcp to match TCP packets.

Packet field operators

& or +

| or ,

!

( )

Logical AND

Logical OR

Negation

Grouping

The fourth command in the recipe is the then clause, which specifies the action to take when a route matches the condition (or conditions) in the from clause, which is to accept the packet (then accept). Table 9-6 lists the actions you can use in a firewall filter.

Table 9-6. Actions to take on matching packets

Action term

Description

accept

Accept the packet and send it to its destination. This is the default action.

reject

Do not accept the packet and send an ICMP unreachable message. Rejected packets can be logged.

discard

Discard a packet silently, without sending an ICMP unreachable message. Discarded packets can be counted but not logged.

next term

Evaluate the next term in the filter.

counter name

Count the packet, keeping track of the count in the named counter.

log

Log the packet's header.

policer name

Rate-limit traffic on an interface.

syslog

Keep a record of the packet in a system logfile.

As with routing policy, the JUNOS software evaluates a firewall filter term by term, and, when a term matches, the action is taken and evaluation ends. If the packet matches none of the terms, the default action is to discard the packet, which is equivalent to the following:

	aviva@RouterF# set term last-term then discard

The default firewall action, to discard packets, is the opposite of the default policy action of accepting routes. You would not be alone in thinking that this behavior is counterintuitive. However, understanding this behavior is critical in designing filters and tracing problems if the router stops receiving certain types of traffic. Be especially careful when implementing filters that limit access to the router to ensure that you don't lock yourself out of the router. A common mistake is to block Telnet access to the router. One way to protect against lockout is to use the commit confirmed command.

The default time to revert to the previous configuration is 10 minutes. Choose a rollback time of one minute to minimize how long you have to wait to reconnect to the router if you lock yourself out:

	[edit firewall]
	aviva@RouterF# commit confirmed 1
	commit confirmed will be automatically rolled back in 1 minutes unless confirmed
	commit complete

When using the commit confirmed command, especially with firewall filters, another good practice is to include a comment, which is saved to the router's commit logfile:

	[edit firewall]
	aviva@RouterF# commit confirmed 1 comment "added filter to discard remaining 
packets"
	commit confirmed will be automatically rolled back in 1 minutes unless confirmed
	commit complete

Use the show system commit command to see the comments:

	aviva@RouterF> show system commit
	0 2005-11-07 20:31:03 UTC by aviva via cli
	 added filter to discard remaining packets
	1 2005-11-02 23:42:38 UTC by root via cli
	2 2005-11-02 23:35:11 UTC by root via cli

Adding a comment is a handy way to keep track of reasons for commits if for some reason you lock yourself out of the router.

Another counterintuitive behavior of JUNOS firewalls is that filters do not have a then clause to accept packets that match the from conditions. To verify this, create a one-term filter with no action:

	[edit firewall]
	aviva@RouterF# set filter one-term-filter term bgp-peers
 from destination-address 10. 0.31.1/24

Look in the file /var/etc/filters/dfwc.out to see the actions taken by the term:

	aviva@RouterF> file show /var/etc/filters/dfwc.out
	rule "bgp-peers" matches 3
	 match destination-port unreferenced type range
	 ranges 1
	 179
	match source-address unreferenced type addrmask
	 number of address-masks: 1
	 10.0.8/24
	match action unreferenced type action
	 accept

The output shows the filter (or rule) bgp-peers matched and accepted three packets.

See Also

The firewall match conditions and how you specify them are far too numerous to include in this book. For a complete list, see the JUNOS Policy Framework Configuration Guide at http://www.juniper.net/techpubs; Recipes 1.5, 1.16, and 9.12.


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