Chapter 2. IPFW Operation
Table of Contents
So far, the initial lab setup should be that shown in the figure below except for IP addressing. All the examples in this book use "Special Use Addresses" for both IPv4 and IPv6. Address references used are described here for IPv4 Addresses (RFC 5737) and here for IPv6 Addresses (RFC 3849).
Configure both VMs to use the addresses shown in the figure below. Once these addresses are in place on the VMs, it is unlikely that the VMs will be able to access sites on the Internet. The 203.0.113.0/24 network is considered non-routable by Internet service providers and major telecom carriers on the Internet. However, this does not really matter, since all the communications for this book are local to the VMs running on the FreeBSD host. Bottom line - if the VMs need to access the Internet, leave them on DHCP, but for the examples in this book, use manual addressing as shown in the figure below.
An easy, efficient way to rapidly change IP addresses is to edit /etc/rc.conf and modify the address lines for the individual interfaces. After saving the file, run service netif restart to restart the interfaces with the new addresses. Check and reset the default route if needed. |
Figure 1. external1, and firewall VMs With Special Use Addresses
Setup instructions for the example:
% cd ~/ipfw-primer/ipfw/HOST_SCRIPTS % sudo /bin/sh mkbr.sh reset bridge0 tap0 tap1 % /bin/sh runvm.sh firewall external1
2.1. Firewall Server Scripts
To demonstrate the firewall capabilities of ipfw, the firewall runs one of four basic scripts. Recall that these are located in /root/bin:
tserv.sh (userv.sh): Script that opens one TCP (UDP) port and listens for incoming traffic.
tserv3.sh (userv3.sh): Script that opens 3 TCP (UDP) ports and listens for incoming traffic.
These scripts will listen for an incoming connection and print whatever is sent over during the connection. When the connection is closed, the script will continue to listen for the next connection.
These script provide the basic mechanism for receiving a TCP or UDP connection. Once ipfw is running and populated with a ruleset, the effect each rule has on a connection can be shown.
2.2. External VM Scripts
Likewise, there are other basic scripts the external1 (and later, external2 and external3) VMs use for initiating or establishing communications with or through the firewall VM. The TCP and UDP versions perform similarly:
tcon.sh (ucon.sh): Connect via TCP (or UDP). This script takes a single argument, a port number to use for the connection. The external VM host can change the port number at each prompt. If there is no script listening on the port on the firewall, the script will indicate a "connection refused" or timeout error.
tconr.sh (uconr.sh): Connection takes a random port number and a sleep value. The script randomly selects one of three ports for its connection in a loop, controlled by the sleep value. If there is a listener on the firewall active on the port, the connection succeeds - otherwise the connection is refused.
tcont.sh (ucont.sh): Connection takes a port number and sleep value. The communication uses the same port in a loop, controlled by the sleep value.
These are simple scripts, but they allow for independent activity by the external VMs, while the firewall VM admin creates and tests ipfw rulesets. Most of the examples in the first part of this book can be done with just these scripts, so it is a good idea to become familiar with their operation. Later scripts will use hping3(8) and iperf3(1), versatile tools used in network analysis.
By default, the external VMs and firewall VM scripts work on ports 5656, 5657, and 5658.
The randomized communication scripts also utilize port 5659, but in most cases, since no services are listening on that port on the firewall VM, the connection fails.
It is important to understanding the underlying network activity. If Internet protocols, network traffic, monitoring, and similar topics are unfamiliar, there are a number of excellent books, white papers, and tutorials, many free over the Internet. Check Appendix C for a modest selection.
2.3. Loading IPFW
ipfw can be built into the FreeBSD kernel directly, or it can be loaded as a kernel module. The ipfw.ko loadable kernel module is used for most of the examples in this book. Load ipfw as root with the command:
# kldload ipfw ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled
Notice the kernel display output - “ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled”. This gives a quick summary of this host’s ipfw capabilities. The most important to note is "default to deny" which indicates that, by default, the firewall has an immutable rule located at the end of the ruleset that denies all Internet Protocol (IP) traffic. This rule depends on how the kernel was configured when it was built. By default it is "default to deny". However, when working on a FreeBSD system where its provenance is unknown, use the ipfw list command to make sure:
# ipfw list 65535 deny ip from any to any #
Note that this does not mean it denies all network traffic, only traffic that is based on the Internet Protocol (RFC 791), and all of its derivatives (TCP, UDP, ICMP, etc). If a hacker had the capability to send and receive non-IP based traffic they could possibly still send and receive it. The firewall administrator would need special rules to deny all traffic, similar to the example later in this book.
To begin the next section, start with the ipfw firewall unloaded:
# kldunload ipfw IP firewall unloaded #
Unloading (kldunload ipfw) and loading (kldload ipfw) the ipfw kernel module is a handy way of completely re-initializing ipfw. This removes all rules, sets, queues, pipes, and other ipfw objects. See kldload(8), kldunload(8), and kldstat(8) for details. |
2.4. Initial Firewall Setup
This section introduces the operation of the scripts described above and demonstrates simple traffic filtering.
In the first example, the firewall host runs tserv.sh (in /root/bin) which opens TCP port 5656.
Figure 2. Simple Transmit with No ipfw In Place
The external1 VM runs tcon.sh, which repetitively opens a TCP connection and sends data to the firewall VM.
Since there is no firewall in place, all TCP connections succeed.
On the host machine, it is possible to run tcpdump(1) on the bridge0 device to see the traffic in real time. Shown below is one successful transfer, i.e there are no firewall rules preventing the connection.
It follows the basic TCP connection sequence: 3-way handshake setup, send data, and close the connection:
Figure 3. tcpdump(1) of Bridge Traffic During Transfer
Now load the ipfw firewall on the firewall VM and retry the communication.
# kldload ipfw ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled # # ipfw list 65535 deny ip from any to any #
Figure 4. Simple Transmit with Default Rule In Place
No communications were successful - the connections time out because the ipfw firewall has denied traffic with the default deny rule as described above.
The external1 VM host sends SYN packets to start the connection, but they never reach the firewall VM’s TCP service on port 5656.
The TCP 3-way handshake is never completed.
These same techniques are used throughout this book. They show how communications and data transfer operate and how firewall rules affect those communications.