Tables


PF can store long lists of network addresses (both hosts and netblocks) in tables. These tables can be defined in /etc/pf.conf or can be kept in external files.

For example, say you have a list of IP addresses of known spam sources that you don't want to allow to talk to your mail server. Such lists tend to be thousands of entries long and would be difficult to maintain inside /etc/pf.conf. Instead, you can create a table with a name like "spamhosts," load your list into this table, and keep your main pf.conf quite simple.

PF checks IP addresses in a table much more quickly than it handles checking against a list of IP addresses in braces. Tables are handled in a slightly different way than lists, however, and can actually be edited by using pfctl(8) while the firewall is running.

In general, you should use lists of hostnames for your standard network equipment such as your corporate web servers, and use tables for integration with other network programs such as spam-blockers or intrusion detection systems. (Of course, if your network has hundreds of web servers, you might want to use a table for those as well!)

Defining Tables

While you can create and edit tables entirely with pfctl(8), such usage is fairly advanced (and one we'll consider in Chapter 19). To define a table entirely within /etc/pf.conf put the name of the table in angle brackets, list the contents of the table in braces like so:

 table <1 rfc1918> {2 10.0.0.0/8, 176.16.0.0/12, 192.168.0.0/16} 

This creates a table called 1 rfc1918 that contains the 2 private IP addresses that should never appear on the public Internet. You can use this table name later in your ruleset much as you would use a macro.

If you have a long list of IPs to add to a table, you can just list them in an external file and direct /etc/pf.conf to pull the table from that file. Here's how we would specify that exact same list, using an external file:

 table <rfc1918> file "/etc/rfc1918list" 

In /etc/rfc1918list, list one IP address or network block per line. Any line with a leading pound sign is a comment. Here's a file containing the RFC1918 IP addresses:

 #rfc1918 addresses #These should never arrive at the outside of our firewall! 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 

This particular example is very simple, but you might have lists of IP addresses that you update on a regular basis, including spam blacklists and client IP addresses. You could simply download the new list to the firewall device, update the list, and reload the table without having to touch your carefully tuned /etc/pf.conf.

You can also specify multiple files in a single table statement like so:

 table <illegaladdresses> file "/etc/rfc1918list" file "/etc/weird-ip-list" 

This single table includes every IP and network listed in each file.

Note

If you list a hostname in the file, PF will do a DNS lookup and get all of the IP addresses for that host and enter them in the table. For example, www.yahoo.com has eight IP addresses; if you list www.yahoo.com in your file, all eight IP addresses will be added to the table.

Table Attributes

By default, tables can be dynamically edited, added, or even removed. This may well conflict with your desired use for the table. Fortunately, PF allows you to modify this behavior with the special attributes const and persist.

Some tables should never change. And since the RFC1918 address space is not going to increase or decrease any time soon, you wouldn't expect to see that table change. The const keyword prevents anything from changing the table via pfctl(8), and is used as follows:

 table <rfc1918> const {10.0.0.0/8, 176.16.0.0/12, 192.168.0.0/16} 

When you load a ruleset into PF, the system automatically parses the file and performs some optimization. Tables that are not referred to in any rules are deleted before they are fed to the kernel. You can tell PF to keep these tables even when rules refer to them by using the persist keyword:

 table <intruders> persist 

An empty table like this might be used by your intrusion detection system, allowing an OpenBSD firewall to dynamically block questionable traffic. (We'll discuss adding entries to these tables in Chapter 19, but getting your IDS to issue the proper commands will vary widely with the type of intrusion detection system you have.)

Exclusions

You can specifically exclude a section of network numbers from a table by using the negation (!) operator. This lets you make tables easily with entries such as "Every IP address beginning with 10, except for the 10.8.8.0/24 block."

 table <remote> {10.0.0.0/8, !10.8.8.0/24} 

You can also use a similar entry in a file:

 10.0.0.0/8 !10.8.8.0/24 

What's more, these can be cascaded, with increasingly smaller areas being negated and included:

 1 10.0.0.0/8 2 !10.0.0.0/16 3 10.0.0.0/24 4 !10.0.0.1 

In this example, the 1 first line puts IP address that begins with 10 into the table. We then deliberately 2 exclude any entry that begins with exactly 10.0, effectively making 10.1.0.0 the first entry in this table. Then we complicate things further by putting 3 any IP that begins with exactly 10.0.0 in the table, and removing the 4 specific IP 10.0.0.1. This sequential inclusion and exclusion lets us build very complicated lists of IP addresses in a few lines of text.

Using Tables in Rules

Tables can be used in rules just like macros, network numbers, or braces. When you define a table, specify the table name in angle brackets:

 block in from <intruders> to any 

You can also use multiple tables within braces, like so:

 block in from { <rfc1918>, <intruders> } to any 

And tables can be used for packet source or destination, for NAT rules, or for scrub rules. You cannot, however, use tables for routing rules or for the NAT redirection address.




Absolute Openbsd(c) Unix for the Practical Paranoid
Absolute OpenBSD: Unix for the Practical Paranoid
ISBN: 1886411999
EAN: 2147483647
Year: 2005
Pages: 298

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net