• Choose a category
• All
• Classic-Fiction

This behavior is the exact opposite of that of ipchains and ipfw, but in all of these systems the order of rules determines the actual functionality of the firewall. The Linux order is faster—match and go—whereas under FreeBSD, all rules are read and applied before the action is taken. The ipf paradigm makes it easy to implement conservative firewalls. If you make your first rule deny everything, you can then add additional rules to enable particular types of traffic.

Table 13.24 on the next page shows some of the possible conditions that can appear in an ipf rule. The conditions shown here are really just the tip of the iceberg. Consult the ipf man page for the messy details.

Table 13.24 ipf conditions

Let’s reimplement the filter specification on page 328 using ipf instead of ipchains. As before, we assume that interface ppp0 is the connection to the Internet and that interface eth0 is our internal Ethernet. To allow all local traffic and discard private addresses coming in from the outside world, we’d use the following rules:

pass in on eth0 all

pass in on lo all

block in quick on ppp0 from 192.168.0.0/16 to any

block in quick on ppp0 from 172.16.0.0/12 to any

block in quick on ppp0 from 10.0.0.0/8 to any

To block TELNET but allow mail and SSH, the rules would be:

block in proto tcp from any to any port = 23

pass in on ppp0 proto tcp from any to any port = 25

pass in on ppp0 proto tcp from any to any port = 22

The rules for mail and SSH should also include the flags and keep state clauses to guard against hijacking of TCP sessions. See the firewalls section starting on page 675 and the ipf(5) man page for more detail on what rules to include and how to format them. If you have access to an OpenBSD system, check out /usr/share/ipf. It contains many example files for both ipf and ipnat.

To make NAT work, we must tell the kernel what addresses to map from, what addresses to map to, and what port range to use to extend the address space. See page 279 for a general discussion of NAT and the mechanisms it uses to bridge from private to public address space.

The syntax of ipf rules is just about right for NAT, so the NAT rules should look familiar. Beware the following whammo: like ipf rules, ipnat rules are ordered. However, they have opposite precedence. Just to keep you on your toes, the first matching rule is selected, not the last.

Here are some examples of ipnat rules (these would go in the ipnat.rules file):

map ppp0 192.168.1.0/24 -> 128.138.198.0/26 portmap tcp/udp 20000:65000

map ppp0 192.168.1.0/24 -> 128.138.198.0/26

We have again assumed that ppp0 is our interface to the Internet and that our internal network is numbered with the private address space range. These rules map addresses from a /24 network into addresses from a /26 network. Since a /26 network can accommodate only one-quarter of the hosts that a /24 network can, it’s potentially possible to run out of target addresses in this configuration. But the portmap clause extends the address range by allowing each address to be used with 45,000 different source ports.

The first rule above covers all TCP and UDP traffic but does not affect ICMP; ICMP does not use the concept of a port. The second rule catches ICMP messages and tries to get them routed back to the right host. If the kernel can’t unambiguously determine who should receive a particular ICMP message, it sends the packet out as a broadcast; any machines that receive it out of context should just drop it.

On a home machine, you might be assigned just a single real IP address by your ISP or your ISP’s DHCP server. If you’re given a static address assignment, just give the target network in the map line a /32 designation and a large enough port range to accommodate the needs of all your local hosts. If you get a different dynamic address each time you connect, use the notation 0/32 in the map line; it will make ipnat read the address directly from the network interface. For