There are a large number of firewall implementations, both free and proprietary. In this section we will mention a few examples of these, focussing more on the free implementations. We discuss the packet filtering firewalls separately from the application proxies, as in the theoretical section.
A packet filtering firewall that is widely available and distributed with most, if not all, Linux implementations by default is called ``ipfwadm''. The packet filtering mechanism itself is built into the kernel. Programs such as ``ipfwadm'' on Linux and ``ipfw'' on FreeBSD provide a command-line based method of configuring the packet filtering mechanisms in the kernel. To be able to use packet filtering, the kernel has to be compiled with IP Firewall support enabled. The solutions requiring packet filtering that are presented in this section use ipfwadm.
Cisco Systems access routers commonly have software that allows the routers to perform a packet filtering role. The software is the operating system that the router runs on, commonly Cisco IOS (Internetworking Operating System). The packet filtering is done using access lists. Access lists are lists of rules specifying which traffic to allow and which to deny. These lists can then be bound to an interface for either inbound or outbound traffic. The access lists can either be inserted on a terminal connected to the router or downloaded from a remote location. The trivial FTP protocol is used for this transfer.
Trusted Information Systems (TIS) have one of the most commonly used free application proxying firewall software. The software is called the TIS Firewall ToolKit (FWTK). The software comes with proxies for such services as ftp, telnet and SMTP. There is also a proxy for use with services that do not have a custom proxy. TIS also distributes a proprietary firewall implementation called ``Gauntlet''. This software is derived from the publicly accessible FWTK. The FWTK design philosophy is to make it as simple as possible. FWTK is extensively documented and easy to install and configure. We will look at configuring services with FWTK in the next chapter.
SOS CORP distributes a proprietary version of an application proxying firewall called ``Firestone''. They also distribute freely a version of that firewall called ``Freestone''. Freestone adopts a different philosophy to the FWTK. Although the implementation of the firewall itself is simple, it makes use of software from other vendors and organizations. Our belief is that a chain is only as strong as its weakest link. It is also our belief that using software from other vendors and organizations introduces more weak links to the chain. The software is not clearly documented and a nightmare to install. After endless problems, we decided to abandon the testing of this firewall.
In our theoretical section, we pointed out that a blanket block on all connections to ports > 1024 would block our own services. A solution to this problem could be looked at from two different directions. They are :
[root@lucifer]# ipfwadm -I -p accept; ipfwadm -I -f
[root@lucifer]# ipfwadm -I -y -P tcp -a deny -S any/0 -D lucifer 1024:65535
[root@lucifer]# ipfwadm -I -p deny; ipfwadm -I -f
[root@lucifer]# ipfwadm -I -P tcp -a accept -S any/0 ftp-data -D lucifer 1024:65535
[root@lucifer]# ipfwadm -I -P tcp -a accept -S any/0 -D lucifer ftp
[root@lucifer]# ipfwadm -I -P tcp -a accept -S any/0 -D lucifer telnet
Experiments conducted in a packet switched environment showed packet sniffing to be useless in a packet switched environment. The sniffer logged none of the traffic as none of it was being broadcast but sent only to the destination.
Using some form of encryption on a connection was our other proposed solution to the problem of packet sniffing. An experiment conducted with the ssh software yielded the expected result. A packet sniffer was run on the host the ssh connection originated. All packets to the destination host were captured. The captured packets show that the encryption changed the keystrokes entered into garbage. The garbage shown below is what the packet sniffer captured when the command ps -auwx was entered.
......V.....3-...........a...6.....4......|w..14.j..\|..........x.(...z.0'.?.
The kernel patch (ktcpd-strobemaster1.4) was said to be a global and optimal solution to the problem of port scanning. Both normal and stealth scans were attempted, the kernel patch logging all attempts. Below is part of a log generated by the port scans. Things for noting are the number of connections logged, whether an attempt was accepted or rejected, rejection of hosts for amount of time and the fact that the current host is never rejected for any amount of time. Its packets may be rejected on an individual basis, but not for any amount of time. Port scans off the same host are therefore possible.
Nov 3 00:31:37 lucifer kernel: TCP connection rejected from 146.232.11.11, port 2
Nov 3 00:31:37 lucifer kernel: TCP connection rejected from 146.232.11.11, port 3
Nov 3 00:31:37 lucifer kernel: possible TCP strobe from 146.232.11.11, rejecting
for 10 seconds
Nov 3 00:35:08 lucifer kernel: TCP connection rejected from 146.231.128.1, port 5
Nov 3 00:35:08 lucifer kernel: TCP connection rejected from 146.231.128.1, port 6
Nov 3 00:35:08 lucifer kernel: TCP connection rejected from 146.231.128.1, port 7
Nov 3 00:35:08 lucifer kernel: TCP connection rejected from 146.231.128.1, port 8
Nov 3 00:35:08 lucifer kernel: TCP connection rejected from 146.231.128.1, port 9
Nov 3 00:35:08 lucifer kernel: TCP connection rejected from 146.231.128.1, port 10
Nov 3 00:35:08 lucifer kernel: TCP connection rejected from 146.231.128.1, port 11
Nov 3 00:35:21 lucifer kernel: TCP connection rejected from 146.231.128.1, port 1000
Nov 3 00:35:21 lucifer kernel: TCP connection accepted: ip=146.231.128.1 port=2003
uid=0 process=inetd[267]
After SYN flooding a host with the strobemasker kernel patch installed with SYN packets, even before the SYN cookies were activated, the patch had started rejecting packets from the host. The following is part of the log of the event.
[|] 0
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991 The Regents of the University
of California. All Rights Reserved.
% From the logs
Nov 3 00:48:54 lucifer kernel: TCP connection rejected from 1.1.1.1, port 1
Nov 3 00:48:54 lucifer kernel: ARP: arp called for own IP address
Nov 3 00:48:54 lucifer kernel: TCP connection rejected from 1.1.1.1, port 2
Nov 3 00:48:54 lucifer kernel: ARP: arp called for own IP address
Nov 3 00:48:54 lucifer kernel: TCP connection rejected from 1.1.1.1, port 3
Nov 3 00:48:54 lucifer kernel: ARP: arp called for own IP address
Nov 3 00:48:54 lucifer kernel: possible TCP strobe from 1.1.1.1, rejecting for
10 seconds
Nov 3 00:48:54 lucifer kernel: ARP: arp called for own IP address
Nov 3 00:48:54 lucifer last message repeated 37 times
To prevent ARP spoofing, we suggested that the solution was the hardcoding of ARP addresses. We ran an experiment to test the hypothesis. The solution was then shown to be effective when ARP addresses are hardwired. Let us illustrate how these addresses could be hardwired.
[root@lucifer]# arp -a
foo.ru.ac.za at 00:00:81:0E:4C:E8 [ether] PERM on eth0
[root@lucifer]#
Starting Hijacking demo - Brecht Claerhout 1996
------------------------
Takeover phase 1: Stealing connection.
% Could not proceed past this point
Let us consider how we would go about preventing blind spoofing from a host
based router using ipfwadm. To make the illustration easier, let us consider
the figure 7.7:
The route has two interfaces, each attached to a different network. If a packet that originates from the network interface 2 is attached to claims to have a source address that is part of the network interface 1 is attached to, the packet is a fake. The packet is then dropped and blind spoofing is prevented. The ruleset for implementing such an access list would look as follows:
[root@lucifer]# ipfwadm -I -a deny -V 10.20.30.1 -S 10.20.40.0/24
Exporting file systems as read only requires the editing of the /etc/exports file, then restarting the NFS daemon. To export the whole '/' filesystem as read only, the following would appear in the /etc/exports file.
The solutions for this are the same for ARP and NFS spoofing. They have already been demonstrated.
We present a table of example r* commands and show how they translate to ssh commands. From the table it should be noted that ssh commands are identical to the r* commands, except for the name change and the added security. We believe the added security is worth the name change. Those devoted to the r* family of commands could alias the ssh equivalents as r* commands.
| r* family command | ssh command equivalent |
| rsh -l root mymachine tail -f /var/log/syslog | ssh -l root mymachine tail -f /var/log/syslog |
| rlogin -l root myothermachine | ssh -l root myothermachine |
Again we will only consider ICMP-redirect messages for this section since they are the most widely used. The only way to stop route spoofing using ICMP-redirect messages through software is to block them. Here too, we will consider ipfwadm as our firewall solution.
A potential solution to DNS spoofing was said to be a mechanism of resolving addresses both in the forward and reverse direction. We noted that TCP Wrappers by Wietse Venema implement this check. When inconsistencies appear, they are logged in a similar manner to that below.
gethostbyname(desdemona.cs.ru.ac.za) failed
Apr 30 15:28:25 beta in.telnetd[10075]: refused connect from 146.231.26.115
Apr 30 15:34:33 beta in.ftpd[10080]: warning: can't verify hostname:
gethostbyname(desdemona.cs.ru.ac.za) failed
Apr 30 15:34:33 beta in.ftpd[10080]: refused connect from 146.231.26.115
Apr 30 16:07:42 beta in.telnetd[10105]: warning: can't verify hostname:
gethostbyname(helene.cs.ru.ac.za) failed
Apr 30 16:07:42 beta in.telnetd[10105]: refused connect from 146.231.26.124
Apr 30 16:07:59 beta in.telnetd[10106]: warning: can't verify hostname:
gethostbyname(helene.cs.ru.ac.za) failed
We noted that since there is no efficient way of checking the payload of ICMP packets, the best solution is to block all ICMP messages. This would be accomplished with ipfwadm in the following manner:
