next up previous contents
Next: 8.2 Application Proxies Up: 8. Case Studies - Previous: 8. Case Studies -

Subsections

8.1 Packet Filters

This section will take the following form. We start with a formal introduction to ipfwadm. We then show the form of the rules and how they solve a posed problem.

Throughout this section we shall be working from the following policies:

8.1.1 Our Feature Packet Filter

Preparing to set a packet filtering host starts with allowing the option in the kernel. Below is a snapshot of the essential items that need to be set up.

*

* Networking options

*

Network firewalls (CONFIG_FIREWALL) [Y/n/?] Y

IP: firewalling (CONFIG_IP_FIREWALL) [Y/n/?] Y

IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) [Y/n/?] Y

After the kernel has been configured, compiled and tested to be running correctly, packet filtering is a few commands away. Let us take a look at the basic options ipfwadm provides that will be of use to us. ipfwadm allows us to set up packet filtering rules for inbound, outbound and other traffic types. We have already stated that we allow all external access. Our focus will therefore be mainly on inbound traffic.

[root@lucifer linux]# ipfwadm -h 

ipfwadm 2.3.0, 1996/07/30

Usage: ipfwadm -I command [options] (input firewall)

       ipfwadm -O command [options] (output firewall)

 

Commands:

  -a [policy]   append rule (no policy for accounting rules)

  -l            list all rules of this category

  -f            remove all rules of this category

  -p policy     change default policy (accept/deny/reject)

 

Options:

  -P            protocol (either tcp, udp, icmp, or all)

  -S address[/mask] [port ...]

                source specification

  -D address[/mask] [port ...]

                destination specification

  -k            match TCP packets only when ACK set

8.1.1.1 Example rules

Using the options above, we discuss an example set up. The steps followed in setting the following rules will set a trend that will be followed throughout the rest of the discussion. Our rules will set our default incoming policy to deny and allow telnet access from the outside to any host.

% Important first step - set the default policy 

[root]# ipfwadm -I -p deny

% Flush/discard any previous rules for incoming traffic

[root]# ipfwadm -I -f

% Allow telnet access. Protocol needed when using ports.

[root]# ipfwadm -I -P tcp -a accept -S any/0 -D any/0 telnet

The default policy for outgoing traffic is allow, since we have not expressly forbidden or set the default policy. It should be noted that if these are the only rules put into our packet filter, they will also indirectly block our own traffic. Returning packets from the servers to which we connect from within the network will be rejected by the filters. This solution can be remedied by adding the following rule.

[root]# ipfwadm -I -P tcp -k -a accept -S any/0 -D any/0 1024:65535
The above rule will only allow acknowledged packets (from connections we initiated) to be allowed through. By adding the above rule, we no longer block our own returning traffic. The above is not a complete solution but serves as a starting point for understanding how ipfwadm works.

8.1.1.2 Policies

So far we have not formally said what the policies that may be applied to packets are and what they mean. This section will attempt to bring light into this area. The Linux kernel allows for three policies to be applied, namely

The difference between allowing and denying/rejecting packets should be obvious. It should also be perceived as queer that two methods of denying access to traffic exist. As we mentioned when we introduced TCP/IP, ICMP is used to report error messages. When a packet is not allowed to get through a filter, it can either be dropped quietly or an ICMP message sent back to the source informing it of the problem. This is where the difference between the deny and the reject policy comes in. The deny policy silently drops the packet. The reject policy drops the packet and sends an ICMP Destination Unreachable message to the sender.

8.1.2 An example


 
Figure 8.1: An example of a Packet Filtering Network
\resizebox*{7cm}{6cm}{\includegraphics{packfil.ps}}


Figure 8.1 represents our network. The interface attached to our internal network is called ``in-face''. The interface attached to the outside world/ external network is called ``out-face''. The packet filter sits between the two networks as can be seen on the diagram. The default policy for traffic from the outside is deny. The default policy for traffic originating from our internal network is accept. The packet filter accepts and forwards certain packets destined for the internal network.

Our requirements for inbound (outside network -> inside network) traffic are as follows:

Our requirements for outbound traffic (inside network-> outside network) traffic are as follows:

Forwarding of traffic from and to the internal network is governed by the above-mentioned criteria for inbound and outbound traffic.

8.1.2.1 The Rules

The rules that fulfil these requirements are shown below and discussed later.

% Incoming rules

1: [root]# ipfwadm -I -p deny

2: [root]# ipfwadm -I -f

3: [root]# ipfwadm -I -a deny -V out-face -S 20.20.30.0/24

4: [root]# ipfwadm -I -a deny -V out-face -S out-face

5: [root]# ipfwadm -I -P tcp -k -a accept -S any/0 -D any/0 1024:65535

6: [root]# ipfwadm -I -P tcp -a accept -S any/0 22

7: [root]# ipfwadm -I -P tcp -a accept -S any/0 -D any/0 22

8: [root]# ipfwadm -I -P tcp -a accept -S any/0 -D mail smtp

9: [root]# ipfwadm -I -P tcp -a accept -S 192.82.142.0/24 -D mail telnet

10:[root]# ipfwadm -I -P tcp -a accept -S any/0 -D web http

11:[root]# ipfwadm -I -P tcp -a accept -S any/0 -D web 3128

12:[root]# ipfwadm -I -P udp -a accept -S any/0 -D web 3130

 

% Outgoing rules

13:[root]# ipfwadm -O -p deny

14:[root]# ipfwadm -O -f

15:[root]# ipfwadm -O -P tcp -a accept -S web http

16:[root]# ipfwadm -O -P tcp -a accept -S web 3128

17:[root]# ipfwadm -O -P tcp -a deny -V in-face -S any/0 -D any/0 80

18:[root]# ipfwadm -O -P tcp -a deny -V in-face -S any/0 -D any/0 3128

19:[root]# ipfwadm -O -p accept

 

% Forwarding rules

20:[root]# ipfwadm -F -p deny

21:[root]# ipfwadm -F -f

22:[root]# ipfwadm -F -P tcp -k -a accept -S any/0 -D 20.20.30.0/24 1024:65535

23:[root]# ipfwadm -F -P tcp -a accept -S any/0 22 -D 20.20.30.0/24 

24:[root]# ipfwadm -F -P tcp -a accept -S any/0 -D 20.20.30.0/24 22

25:[root]# ipfwadm -F -P -a deny -V out-face -S any/0 -D 20.20.30.0/24

26:[root]# ipfwadm -F -p accept

8.1.3 Explanation of the rules

8.1.3.1 Incoming rules

Lines 1 and 2 of the above rules are important first steps in the setting up of any firewall rules. Line 1 sets the policy to deny so that no unwanted traffic gets through while the rest of the rules are being inserted. Line 2 flushes the previously entered rules. Lines 3 and 4 are included to prevent blind IP spoofing. Line 3 denies traffic that is on out-face that has a source address from the internal network. The same is done for traffic with a source address of out-face coming back into out-face. Line 5 is protection against backdoors and trojans as seen in the network solutions section. Lines 6 and 7 allow any connections originating or destined for the ssh port. The theory is that since ssh is an encrypted and secure method of communication, it is safe to allow it. Line 8 allows access to the mail port only to the host mail. The host should be setup to reject spam and have a secure mail system. Telnet access is granted to the trusted network 192.82.142.0, but only to the mail host as can be seen in line 9. Lines 10 through 12 allow anyone to connect to our http port and squid proxy which is on host 'web'. The default policy of denying everything we haven't expressly allowed allows us to deny ICMP and other messages coming into the network. This prevents both ICMP tunnelling and ICMP redirections.

8.1.3.2 Outgoing rules

These are rules for traffic originating from our internal network going to the external network. Lines 13 and 14 deny everything and flush previous rules while we reconfigure the rules. Lines 15 and 16 allows http and squid proxy traffic through but only when it originates from the host 'web'. Lines 17 and 18 then deny all connections to the http and the squid proxy port from the internal interface to the outside world. The reason for doing this is to force users on the inside network to use the http proxy provided on host 'web' by squid. This is a common configuration at institutions dealing with the high cost of Internet bandwidth. Line 19 restores the accept all policy. At this point we have finished configuring the rules for outbound traffic, so the default policy can be modified to the required value.

8.1.3.3 Forwarding rules

The forwarding rules we use for forwarding traffic sourced from or destined for our internal network to and from the outside network respectively. Line 20 sets the default forwarding to deny, as was the practice for the last two rules we considered. Line 21 flushes previous rules. Line 22 is to allow packets that originated from our internal network to be forwarded back. This rule goes with line 5 which permits inbound traffic that originated from the inside network. Lines 23 and 24 allow ssh for the same reasons stated in our discussion of the incoming rules. Line 25 denies the forwarding of anything from the outside world to the internal that has not been expressly allowed. This is done as the default policy for the forwarding rules is acceptance. These rules allow traffic from the internal network unbounded access to the outside network but pose restrictions on traffic that can be forwarded to the internal network from outside.


next up previous contents
Next: 8.2 Application Proxies Up: 8. Case Studies - Previous: 8. Case Studies -
Shaun Bangay
1998-11-19