Stateless firewalling

There are many types of firewalls out there, but they all tend to attempt to implement one basic function. To not allow certain packets or frames through them.

Firewalls can be implemented at layer 2 or layer 3, and can use any combination of layer 2/3/4/5/6/7 information in the packet or flow of packets to decide weather to drop a packet or not. Firewalls can choose to silently drop a packet, or to send back a ICMP "administratively prohibited message".

We are going to look at layer 3 stateless firewalling. We call this layer 3 firewalling as the device that does this is usually just a layer 3 device, working as a router, except that chooses to forward packets just as a router would, or block packets, based on layer 3/4 type information (sometimes even layer 2 information) within the packet.

We call this stateless as we judge each packet independently, and with no concern for packets that came before or after it (in most cases).

firewall criteria review

Firewall consist of rules applied to each interface on a router, and the rules can be applied to packets coming in the interface or going out the interface. In each rule you choose a attribute of the packet and based on that attributes content you either pass the packet, or you do not pass (IE drop) the packet.

Each interface might have a list of firewall rules that are applied in order. Each rule, if matched, will result in the packet being allowed through, or dropped. If the rule is not matched then the next rule in the list is checked. You might also specify a "default" policy for each interface, and this will apply if no other rule does. This could be pass or drop.

In addition to interface and input or output direction some other basic criteria most routers can use to block packets are:

	source IP (or CIDR range of source IP's)
	destination IP (or CIDR range of destination IP's)
	IP protocol (ICMP, UDP, TCP, others)
	source IP (TCP/UDP) port (or icmp type)
	destination IP (TCP/UDP) port (or icmp type)

While you can buy firewall "appliances" you can usually do your basic stateless firewalling functions in your routers as well. IOS, JunOS and Linux all have that capability.

When designing firewalls you will want to start by writing out a textual description of what you want to do.

For example, if you had a router with two interface eth0 and eth1. Eth0 faces the world and eth1 faces some servers you wish to protect. Lets say you want to prevent anyone from telnet'ing to those servers. Since telnet uses TCP protocol over tcp port 23 you could implement a firewall rule on that router which would look at all packets inbound on eth0 and would drop any tcp packet that had a tcp destination port of 23.

Lets say a second objective is to prevent the servers from sending mail out to the world. That would be a tcp connection from a ephemeral port on the servers to port 25 on hosts outside the server net. You could apply that rule to eth1 inbound (IE from the server network).

So on the firewall separating the two networks you would have the following structure:


	eth0 - inbound from internet
		Rule 1 - block tcp with destination port 23
		Rule 2 - Permit all 

	eth0 - outbound to internet
		Rule 1 - Permit all 

	eth1 - inbound from server network
		Rule 1 - block tcp with destination port 25
		Rule 2 - Permit all 

	eth1 - outbound to server network
		Rule 1 - Permit all 

In both the cases above we block the packets on the ingress. This saves the router/firewall from having to do any normal processing. In both cases we also work from a general rule (the default) as permit all.

You might want to choose to use a more restrictive policy of dropping traffic as the default. Again lets assume you have a server network (10.100.1.0/26) and on it you have some web servers. You have a router connecting that server network on eth0 to your management network (10.100.1.64/26) on eth1 and that management network connects to the internet in general. You want to allow http and https traffic to the server network. You also want to allow ssh traffic from your management network to the server network. You want to deny all other traffic. The text rules might look like this:


	eth0 - inbound from server network
		Rule 1 - permit ip with source address in 10.100.1.0/26
		Rule 2 - deny all

	eth0 - outbound to server network
		Rule 1 - permit all
		Rule 2 - deny all

	eth1 - inbound from management net and internet
		Rule 1 - permit tcp with destination port of 80 or 443 from any ip address
		Rule 2 - permit tcp with destination port of 22 from 10.100.1.64/26
		Rule 3 - deny all

	eth1 - outbound to management net and internet
		Rule 1 - permit all
		Rule 2 - deny all


CISCO ACL's

On cisco routers these firewall rules are called ACL's (for Access Control Lists). These access control lists are numbered 100-199 for basic extended access lists that allow you to specify both source and destination. the syntax looks like this

r2(config)#ip access-list extended 100 
r2(config-ext-nacl)#SEQUENCENUM (permit/deny) PROTO SRCIPADDRESS SRCWILDCARD [OPERATOR] [PORT] DESTIPADDRESS DESTWILDCARD [OPERATOR] [PORT]
r2(config-ext-nacl)#SEQUENCENUM (permit/deny) PROTO SRCIPADDRESS SRCWILDCARD [OPERATOR] [PORT] DESTIPADDRESS DESTWILDCARD [OPERATOR] [PORT]
r2(config-ext-nacl)#SEQUENCENUM (permit/deny) PROTO SRCIPADDRESS SRCWILDCARD [OPERATOR] [PORT] DESTIPADDRESS DESTWILDCARD [OPERATOR] [PORT]


The 100 on the ip access-list line is the access list number and needs 
to be between 100 and 199 for extended access lists.

SEQUENCENUM is the sequence number of the access list entry
permit / deny means to permit or deny the matching packets
PROTO is ip/tcp/udp or other ip protocol 
SRCIPADDRESS is the source ip address (or any to represent any ip address)
SRCWILDCARD is a wild card (inverse netmask) of the bits to ignore in the source address
OPERATOR is optional operator to use on the port (eq, gt,lt,neq)
PORT is a tcp or udp port
DESTIPADDRESS is the destination ip address (or any to represent any ip address)
DESTWILDCARD is a wild card (inverse netmask) of the bits to ignore in the destination address

Once you have defined the ACL, you apply it to an interface and specify that it applies on inbound or outbound packets.

	int eth0
	ip access-group 100 in
	exit
The access group number matches the access list number you defined above (100-199).

You can substitute the keyword "any" for the ip of 0.0.0.0 with wildcard of 255.255.255.255 (IE any host). You can also substitute "host W.X.Y.Z" for W.X.Y.Z with wildcard of 0.0.0.0.

Here is what you would do to add a rule to the end of the FORWARD chain that blocks all incoming telnet traffic (to tcp port 23) that arrives on eth0. Note this is entered in the new format with sequence numbers.

	!
	! we use acl 101 for inbound to eth0
	! 
	int eth0
	ip access-group 101 in
	exit

	ip access-list extendend 101
	  10 deny tcp any any eq 23

The IOS will display it (in a show run) as:

	access-list 101 deny tcp any any eq 23

Here is how you would create an access-list 102 that if applied on inbound packets to eth1 would allow tcp traffic with destination port of 21 and destination address of 10.4.5.128/25 to pass, and then block all other traffic destined to port 21.
	ip access-list extendend 102
	  10 permit tcp any 10.4.5.128 0.0.0.127 eq 21
	  20 deny tcp any any eq 21
          30 permit tcp any any
Every cisco access list has an implied DENY for all at the end of the list. So if a packet has not matched anything and been permitted by the end of the ACL, it is dropped. Also note that the masks used in cisco access-lists are wildcard masks (inverse of normal netmasks)

JunOS

To do firewalling on the JunOS boxes first you define a filter under the firewall section. Here is one that will discard any traffic from tcp port 23 to tcp port 21 if it comes from 10.1.1.0/24.

	juniper@br# edit firewall 

	[edit firewall]
	juniper@br# edit filter FILTERNAME 

	[edit firewall filter FILTERNAME]
	juniper@br# set term term1 from source-address 10.1.1.0/24 

	[edit firewall filter FILTERNAME]
	juniper@br# set term term1 from protocol tcp                      

	[edit firewall filter FILTERNAME]
	juniper@br# set term term1 from source-port 23

	[edit firewall filter FILTERNAME]
	juniper@br# set term term1 from destination-port 21      

	[edit firewall filter FILTERNAME]
	juniper@br# set term term1 then discard 
	juniper@br# show 
	term term1 {
	    from {
		source-address {
		    10.1.1.0/24;
		}
		protocol tcp;
		source-port 23;
		destination-port 21;
	    }
	    then {
		discard;
	    }
	}


Then apply it to an interface

	[edit interfaces]
	juniper@br#  edit fxp0  

	[edit interfaces fxp0]
	juniper@br# set unit 0 family inet filter output FILTERNAME 

	[edit interfaces fxp0]
	juniper@br# show 
	unit 0 {
	    description "connection to 10.1.0.0/24 core network for group 1";
	    family inet {
		filter {
		    output FILTERNAME; 
		}
		address 10.1.0.1/24;
	    }
	}

You can use name different values under the from clause of a term in a firewall filter. Here are some examples.

address              Match IP source or destination address
destination-address  Match IP destination address
destination-port     Match TCP/UDP destination port
destination-port-except  Do not match TCP/UDP destination port
destination-prefix-list  Match IP destination prefixes in named list
icmp-code            Match ICMP message code
icmp-code-except     Do not match ICMP message code
icmp-type            Match ICMP message type
icmp-type-except     Do not match ICMP message type
packet-length        Match packet length
packet-length-except  Do not match packet length
port                 Match TCP/UDP source or destination port
port-except          Do not match TCP/UDP source or destination port
prefix-list          Match IP source or destination prefixes in named list
protocol             Match IP protocol type
protocol-except      Do not match IP protocol type
source-address       Match IP source address
source-port          Match TCP/UDP source port
source-port-except   Do not match TCP/UDP source port
source-prefix-list   Match IP source prefixes in named list