- Free Software Firewall Guide -
Advanced Firewalling Introduction
This section is designed as an immediate followup to the basic section. Contained below are both concepts for advanced firewall design, and advanced features contained only within ipfilter. Once you are comfortable with this section, you should be able to build a very strong firewall.
Rampant Paranoia; or The Default-Deny Stance
There's a big problem with blocking services by the port: sometimes they move.
RPC based programs are terrible about this, lockd, statd, even nfsd listens
places other than 2049. It's awfully hard to predict, and even worse to automate
adjusting all the time. What if you miss a service? Instead of dealing with
all that hassle, lets start over with a clean slate. The current ruleset looks
like this:
Yes, we really are starting over. The first rule we're going to use is this:
block in all
No network traffic gets through. None. Not a peep. You're rather secure
with this setup. Not terribly useful, but quite secure. The great thing is that
it doesn't take much more to make your box rather secure, yet useful too. Lets
say the machine this is running on is a web server, nothing more, nothing less.
It doesn't even do DNS lookups. It just wants to take connections on 80/tcp
and that's it. We can do that. We can do that with a second rule, and you already
know how:
block in on tun0 all
pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 80
This machine will pass in port 80 traffic for 20.20.20.1, and deny everything
else. For basic firewalling, this is all one needs.
Implicit Allow; The "keep state" Rule
The job of your firewall is to prevent unwanted traffic getting to point B
from point A. We have general rules which say "as long as this packet is
to port 23, it's okay." We have general rules which say "as long as
this packet has its FIN flag set, it's okay." Our firewalls don't know
the beginning, middle, or end of any TCP/UDP/ICMP session. They merely have
vague rules that are applied to all packets. We're left to hope that the packet
with its FIN flag set isn't really a FIN scan, mapping our services. We hope
that the packet to port 23 isn't an attempted hijack of our telnet session.
What if there was a way to identify and authorize individual TCP/UDP/ICMP sessions
and distinguish them from port scanners and DoS attacks? There is a way, it's
called keeping state.
We want convenience and security in one. Lots of people do, that's why Ciscos
have an "established" clause that lets established tcp sessions go
through. Ipfw has established. Ipfwadm has setup/established. They all have
this feature, but the name is very misleading. When we first saw it, we thought
it meant our packet filter was keeping track of what was going on, that it knew
if a connection was really established or not. The fact is, they're all taking
the packet's word for it from a part of the packet anybody can lie about. They
read the TCP packet's flags section and there's the reason UDP/ICMP don't work
with it, they have no such thing. Anybody who can create a packet with bogus
flags can get by a firewall with this setup.
Where does IPF come in to play here, you ask? Well, unlike the other firewalls,
IPF really can keep track of whether or not a connection is established. And
it'll do it with TCP, UDP and ICMP, not just TCP. Ipf calls it keeping state.
The keyword for the ruleset is keep state.
Up until now, we've told you that packets come in, then the ruleset gets checked;
packets go out, then the ruleset gets checked. Actually, what happens is packets
come in, the state table gets checked, then *maybe* the inbound ruleset gets
checked; packets go out, the state table gets checked, then *maybe* the outbound
ruleset gets checked. The state table is a list of TCP/UDP/ICMP sessions that
are unquestionadely passed through the firewall, circumventing the entire ruleset.
Sound like a serious security hole? Hang on, it's the best thing that ever happened
to your firewall.
All TCP/IP sessions have a start, a middle, and an end (even though they're
sometimes all in the same packet). You can't have an end without a middle and
you can't have a middle without a start. This means that all you really need
to filter on is the beginning of a TCP/UDP/ICMP session. If the beginning of
the session is allowed by your firewall rules, you really want the middle and
end to be allowed too (lest your IP stack should overflow and your machines
become useless). Keeping state allows you to ignore the middle and end and simply
focus on blocking/passing new sessions. If the new session is passed, all its
subsequent packets will be allowed through. If it's blocked, none of its subsequent
packets will be allowed through. Here's an example for running an ssh server
(and nothing but an ssh server):
block out quick on tun0 all
pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 22 keep state
The first thing you might notice is that there's no "pass out"
provision. In fact, there's only an all-inclusive "block out" rule.
Despite this, the ruleset is complete. This is because by keeping state, the
entire ruleset is circumvented. Once the first SYN packet hits the ssh server,
state is created and the remainder of the ssh session is allowed to take place
without interference from the firewall. Here's another example:
block in quick on tun0 all
pass out quick on tun0 proto tcp from 20.20.20.1/32 to any keep state
In this case, the server is running no services. Infact, it's not a server,
it's a client. And this client doesn't want unauthorized packets entering its
IP stack at all. However, the client wants full access to the internet and the
reply packets that such privledge entails. This simple ruleset creates state
entries for every new outgoing TCP session. Again, since a state entry is created,
these new TCP sessions are free to talk back and forth as they please without
the hinderance or inspection of the firewall ruleset. We mentioned that this
also works for UDP and ICMP:
block in quick on tun0 all
pass out quick on tun0 proto tcp from 20.20.20.1/32 to any keep state
pass out quick on tun0 proto udp from 20.20.20.1/32 to any keep state
pass out quick on tun0 proto icmp from 20.20.20.1/32 to any keep state
Yes Virginia, we can ping. Now we're keeping state on TCP, UDP, ICMP. Now
we can make outgoing connections as though there's no firewall at all, yet would-be
attackers can't get back in. This is very handy because there's no need to track
down what ports we're listening to, only the ports we want people to be able
to get to.
State is pretty handy, but it's also a bit tricky. You can shoot yourself
in the foot in strange and mysterious ways. Consider the following ruleset:
pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23
pass out quick on tun0 proto tcp from any to any keep state
block in quick all
block out quick all
At first glance, this seems to be a good setup. We allow incoming sessions
to port 23, and outgoing sessions anywhere. Naturally packets going to port
23 will have reply packets, but the ruleset is setup in such a way that the
pass out rule will generate a state entry and everything will work perfectly.
At least, you'd think so.
The unfortunate truth is that after 60 seconds of idle time the state entry
will be closed (as opposed to the normal 5 days). This is because the state
tracker never saw the original SYN packet destined to port 23, it only saw the
SYN ACK. IPF is very good about following TCP sessions from start to finish,
but it's not very good about coming into the middle of a connection, so rewrite
the rule to look like this:
pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 keep
state
pass out quick on tun0 proto tcp from any to any keep state
block in quick all
block out quick all
The additional of this rule will enter the very first packet into the state
table and everything will work as expected. Once the 3-way handshake has been
witness by the state engine, it is marked in 4/4 mode, which means it's setup
for long-term data exchange until such time as the connection is torn down (wherein
the mode changes again. You can see the current modes of your state table with
ipfstat -s.
UDP is stateless so naturally it's a bit harder to do a reliable job of keeping
state on it. Nonetheless, ipf does a pretty good job. When machine A sends a
UDP packet to machine B with source port X and destination port Y, ipf will
allow a reply from machine B to machine A with source port Y and destination
port Y. This is is a short term state entry, a mere 60 seconds.
Here's an example of what happens if we use nslookup to get the IP address
of www.3com.com:
$ nslookup www.3com.com
A DNS packet is generated:
17:54:25.499852 20.20.20.1.2111 > 198.41.0.5.53: 51979+
The packet is from 20.20.20.1, port 2111, destined for 198.41.0.5, port
53. A 60 second state entry is created. If a packet comes back from 198.41.0.5
port 53 destined for 20.20.20.1 port 2111 within that period of time, the reply
packet will be let through. As you can see, milliseconds later:
17:54:25.501209 198.41.0.5.53 > 20.20.20.1.2111: 51979 q: www.3com.com
The reply packet matches the state criteria and is let through. At that
same moment that packet is let through, the state gateway is closed and no new
incoming packets will be allowed in, even if they claim to be from the same
place.
IPFilter handles ICMP states in the manner that one would expect from understanding
how ICMP is used with TCP and UDP, and with your understanding of how keep
state works. There are two general types of ICMP messages; requests and
replies. When you write a rule such as:
pass out on tun0 proto icmp from any to any icmp-type 8 keep state
to allow outbound echo requests (a typical ping), the resultant icmp-type
0 packet that comes back will be allowed in. This state entry has a default
timeout of an incomplete 0/0 state of 60 seconds. Thus, if you are keeping state
on any outbound icmp message that will elicit an icmp message in reply, you
need a proto icmp [...] keep state rule.
However, the majority of ICMP messages are status messages generated by some
failure in UDP (and sometimes TCP), and in 3.4.x and greater IPFilters, any
ICMP error status message (say icmp-type 3 code 3 port unreachable,
or icmp-type 11 time exceeded) that matches an active state table entry
that could have generated that message, the ICMP packet is let in. For example,
in older IPFilters, if you wanted traceroute to work, you needed to use:
pass out on tun0 proto udp from any to any port 33434><33690 keep
state
pass in on tun0 proto icmp from any to any icmp-type timex
whereas now you can do the right thing and just keep state on udp with:
pass out on tun0 proto udp from any to any port 33434><33690 keep
state
To provide some protection against a third-party sneaking ICMP messages
through your firewall when an active connection is known to be in your state
table, the incoming ICMP packet is checked not only for matching source and
destination addresses (and ports, when applicable) but a tiny part of the payload
of the packet that the ICMP message is claiming it was generated by.
FIN Scan Detection; "flags" Keyword, "keep frags" Keyword
Lets go back to the 4 rule set from the previous section:
pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 keep
state
pass out quick on tun0 proto tcp from any to any keep state
block in quick all
block out quick all
This is almost, but not quite, satisfactory. The problem is that it's not
just SYN packets that're allowed to go to port 23, any old packet can get through.
We can change this by using the flags option:
pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 flags
S keep state
pass out quick on tun0 proto tcp from any to any flags S keep state
block in quick all
block out quick all
Now only TCP packets, destined for 20.20.20.1, at port 23, with a lone
SYN flag will be allowed in and entered into the state table. A lone SYN flag
is only present as the very first packet in a TCP session (called the TCP handshake)
and that's really what we wanted all along. There's at least two advantages
to this: No arbitrary packets can come in and make a mess of your state table.
Also, FIN and XMAS scans will fail since they set flags other than the SYN flag.†
† Some examples use flags S/SA instead of flags S. flags S actually equates to flags S/AUPRFS and matches against only the SYN packet out of all six possible flags, while flags S/SA will allow packets that may or may not have the URG, PSH, FIN, or RST flags set. Some protocols demand the URG or PSH flags, and S/SAFR would be a better choice for these, however we feel that it is less secure to blindly use S/SA when it isn't required. But it's your firewall.
Now all incoming packets must either be handshakes or have state already. If
anything else comes in, it's probably a port scan or a forged packet. There's
one exception to that, which is when a packet comes in that's fragmented from
its journey. IPF has provisions for this as well, the keep frags keyword.
With it, IPF will notice and keep track of packets that are fragmented, allowing
the expected fragments to to go through. Lets rewrite the 3 rules to log forgeries
and allow fragments:
pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 flags
S keep state keep frags
pass out quick on tun0 proto tcp from any to any keep state flags S keep frags
block in log quick all
block out log quick all
This works because every packet that should be allowed through makes it
into the state table before the blocking rules are reached. The only scan this
won't detect is a SYN scan itself. If you're truely worried about that, you
might even want to log all initial SYN packets.
Responding To a Blocked Packet
So far, all of our blocked packets have been dumped on the floor, logged or
not, we've never sent anything back to the originating host. Sometimes this
isn't the most desirable of responses because in doing so, we actually tell
the attacker that a packet filter is present. It seems a far better thing to
misguide the attacker into believing that, while there's no packet filter running,
there's likewise no services to break into. This is where fancier blocking comes
into play.
When a service isn't running on a Unix system, it normally lets the remote
host know with some sort of return packet. In TCP, this is done with an RST
(Reset) packet. When blocking a TCP packet, IPF can actually return an RST to
the origin by using the return-rst keyword.
Where once we did:
block in log on tun0 proto tcp from any to 20.20.20.0/24 port = 23
pass in all
We might now do:
block return-rst in log from any to 20.20.20.0/24 proto tcp port = 23
block in log quick on tun0
pass in all
We need two block statements since return-rst only works
with TCP, and we still want to block protocols such as UDP, ICMP, and others.
Now that this is done, the remote side will get "connection refused"
instead of "connection timed out".
It's also possible to send an error message when somebody sends a packet to
a UDP port on your system. Whereas once you might have used:
block in log quick on tun0 proto udp from any to 20.20.20.0/24 port = 111
You could instead use the return-icmp keyword to send a reply:
block return-icmp(port-unr) in log quick on tun0 proto udp from any to
20.20.20.0/24 port = 111
According to TCP/IP Illustrated, port-unreachable is the correct
ICMP type to return when no service is listening on the port in question. You
can use any ICMP type you like, but port-unreachable is probably your best bet.
It's also the default ICMP type for return-icmp.
However, when using return-icmp, you'll notice that it's not very
stealthy, and it returns the ICMP packet with the IP address of the firewall,
not the original destination of the packet. This was fixed in ipfilter 3.3,
and a new keyword; return-icmp-as-dest, has been added. The new format
is:
block return-icmp-as-dest(port-unr) in log on tun0 proto udp from any to
20.20.20.0/24 port = 111
It is important to note that the presence of the log keyword only
ensures that the packet will be available to the ipfilter logging device; /dev/ipl.
In order to actually see this log information, one must be running the ipmon
utility (or some other utility that reads from /dev/ipl). The typical
usage of log is coupled with ipmon -s to log the information
to syslog. As of ipfilter 3.3, one can now even control the logging behavior
of syslog by using log level keywords, as in rules such as this:
block in log level auth.info quick on tun0 from 20.20.20.0/24 to any
block in log level auth.alert quick on tun0 proto tcp from any to 20.20.20.0/24
port = 21
In addition to this, you can tailor what information is being logged. For
example, you may not be interested that someone attempted to probe your telnet
port 500 times, but you are interested that they probed you once. You can use
the log first keyword to only log the first example of a packet. Of
course, the notion of "first-ness" only applies to packets in a specific
session, and for the typical blocked packet, you will be hard pressed to encounter
situations where this does what you expect. However, if used in conjunction
with pass and keep state, this can be a valuable keyword for
keeping tabs on traffic.
Another useful thing you can do with the logs is to keep track of interesting pieces of the packet in addition to the header information normally being logged. Ipfilter will give you the first 128 bytes of the packet if you use the log body keyword. You should limit the use of body logging, as it makes your logs very verbose, but for certain applications, it is often handy to be able to go back and take a look at the packet, or to send this data to another application that can examine it further.
So now we have a pretty tight firewall, but it can still be tighter. Some of
the original ruleset we wiped clean is actually very useful. I'd suggest bringing
back all the anti-spoofing stuff. This leaves us with:
block in on tun0
block in quick on tun0 from 192.168.0.0/16 to any
block in quick on tun0 from 172.16.0.0/12 to any
block in quick on tun0 from 10.0.0.0/8 to any
block in quick on tun0 from 127.0.0.0/8 to any
block in log quick on tun0 from 20.20.20.0/24 to any
block in log quick on tun0 from any to 20.20.20.0/32
block in log quick on tun0 from any to 20.20.20.255/32
pass out quick on tun0 proto tcp/udp from 20.20.20.1/32 to any keep state
pass out quick on tun0 proto icmp from 20.20.20.1/32 to any keep state
pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 80 flags S
keep state
Improving Performance With Rule Groups
Let's extend our use of our firewall by creating a much more complicated, and
we hope more applicable to the real world, example configuration For this example,
we're going to change the interface names, and network numbers. Let's assume
that we have three interfaces in our firewall with interfaces xl0,
xl1, and xl2.
xl0 is connected to our external network 20.20.20.0/26
xl1 is connected to our "DMZ" network 20.20.20.64/26
xl2 is connected to our protected network 20.20.20.128/25
We'll define the entire ruleset in one swoop, since we figure that you
can read these rules by now:
block in quick on xl0 from 192.168.0.0/16 to any
block in quick on xl0 from 172.16.0.0/12 to any
block in quick on xl0 from 10.0.0.0/8 to any
block in quick on xl0 from 127.0.0.0/8 to any
block in log quick on xl0 from 20.20.20.0/24 to any
block in log quick on xl0 from any to 20.20.20.0/32
block in log quick on xl0 from any to 20.20.20.63/32
block in log quick on xl0 from any to 20.20.20.64/32
block in log quick on xl0 from any to 20.20.20.127/32
block in log quick on xl0 from any to 20.20.20.128/32
block in log quick on xl0 from any to 20.20.20.255/32
pass out on xl0 all
pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 80 flags S
keep state
pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 21 flags S
keep state
pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 20 flags S
keep state
pass out quick on xl1 proto tcp from any to 20.20.20.65/32 port = 53 flags S
keep state
pass out quick on xl1 proto udp from any to 20.20.20.65/32 port = 53 keep state
pass out quick on xl1 proto tcp from any to 20.20.20.66/32 port = 53 flags S
keep state
pass out quick on xl1 proto udp from any to 20.20.20.66/32 port = 53 keep state
block out on xl1 all
pass in quick on xl1 proto tcp/udp from 20.20.20.64/26 to any keep state
block out on xl2 all
pass in quick on xl2 proto tcp/udp from 20.20.20.128/25 to any keep state
From this arbitarary example, we can already see that our ruleset is becoming
unwieldy. To make matters worse, as we add more specific rules to our DMZ network,
we add additional tests that must be parsed for every packet, which affects
the performance of the xl0 <-> xl2 connections. If you
set up a firewall with a ruleset like this, and you have lots of bandwidth and
a moderate amount of cpu, everyone that has a workstation on the xl2
network is going to come looking for your head to place on a platter. So, to
keep your head <-> torso network intact, you can speed things along by
creating rule groups. Rule groups allow you to write your ruleset in a tree
fashion, instead of as a linear list, so that if your packet has nothing to
do with the set of tests (say, all those xl1 rules) those rules will
never be consulted. It's somewhat like having multiple firewalls all on the
same machine.
Here's a simple example to get us started:
block out quick on xl1 all head 10
pass out quick proto tcp from any to 20.20.20.64/26 port = 80 flags S keep state
group 10
block out on xl2 all
In this simplistic example, we can see a small hint of the power of the
rule group. If the packet is not destined for xl1, the head
of rule group 10 will not match, and we will go on with our tests.
If the packet does match for xl1, the quick keyword will short-circuit
all further processing at the root level (rule group 0), and focus the testing
on rules which belong to group 10; namely, the SYN check for 80/tcp.
In this way, we can re-write the above rules so that we can maximize performance
of our firewall.
block in quick on xl0 all head 1
block in quick on xl0 from 192.168.0.0/16 to any group 1
block in quick on xl0 from 172.16.0.0/12 to any group 1
block in quick on xl0 from 10.0.0.0/8 to any group 1
block in quick on xl0 from 127.0.0.0/8 to any group 1
block in log quick on xl0 from 20.20.20.0/24 to any group 1
block in log quick on xl0 from any to 20.20.20.0/32 group 1
block in log quick on xl0 from any to 20.20.20.63/32 group 1
block in log quick on xl0 from any to 20.20.20.64/32 group 1
block in log quick on xl0 from any to 20.20.20.127/32 group 1
block in log quick on xl0 from any to 20.20.20.128/32 group 1
block in log quick on xl0 from any to 20.20.20.255/32 group 1
pass in on xl0 all group 1
pass out on xl0 all
block out quick on xl1 all head 10
pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 80 flags S
keep state group 10
pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 21 flags S
keep state group 10
pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 20 flags S
keep state group 10
pass out quick on xl1 proto tcp from any to 20.20.20.65/32 port = 53 flags S
keep state group 10
pass out quick on xl1 proto udp from any to 20.20.20.65/32 port = 53 keep state
group 10
pass out quick on xl1 proto tcp from any to 20.20.20.66/32 port = 53 flags S
keep state
pass out quick on xl1 proto udp from any to 20.20.20.66/32 port = 53 keep state
group 10
pass in quick on xl1 proto tcp/udp from 20.20.20.64/26 to any keep state
block out on xl2 all
pass in quick on xl2 proto tcp/udp from 20.20.20.128/25 to any keep state
Now you can see the rule groups in action. For a host on the xl2
network, we can completely bypass all the checks in group 10 when we're
not communicating with hosts on that network.
Depending on your situation, it may be prudent to group your rules by protocol, or various machines, or netblocks, or whatever makes it flow smoothly.
Fastroute"; The Keyword of Stealthiness
Even though we're forwarding some packets, and blocking other packets, we're
typically behaving like a well behaved router should by decrementing the TTL
on the packet and acknowledging to the entire world that yes, there is a hop
here. But we can hide our presence from inquisitive applications like unix traceroute
which uses UDP packets with various TTL values to map the hops between two sites.
If we want incoming traceroutes to work, but we do not want to announce the
presence of our firewall as a hop, we can do so with a rule like this:
block in quick on xl0 fastroute proto udp from any to any port 33434 ><
33465
The presence of the fastroute keyword will signal ipfilter to
not pass the packet into the Unix IP stack for routing which results in a TTL
decrement. The packet will be placed gently on the output interface by ipfilter
itself and no such decrement will happen. Ipfilter will of course use the system's
routing table to figure out what the appropriate output interface really is,
but it will take care of the actual task of routing itself.
There's a reason we used block quick in our example, too. If we had
used pass, and if we had IP Forwarding enabled in our kernel, we would
end up having two paths for a packet to come out of, and we would probably panic
our kernel.
It should be noted, however, that most Unix kernels (and certainly the ones underlying the systems that ipfilter usually runs on) have far more efficient routing code than what exists in ipfilter, and this keyword should not be thought of as a way to improve the operating speed of your firewall, and should only be used in places where stealth is an issue.
Outside of the corporate environment, one of the biggest enticements of firewall technology to the end user is the ability to connect several computers through a common external interface, often without the approval, knowledge, or even consent of their service provider. To those familiar with Linux, this concept is called IP Masquerading, but to the rest of the world it is known by the more obscure name of Network Address Translation, or NAT for short.†
† To be pedantic, what IPFilter provides is really called NPAT, for Network and Port Address Translation, which means we can change any of the source and destination IP Addresses and their source and destination ports. True NAT only allows one to change the addresses.
Mapping Many Addresses Into One Address
The basic use of NAT accomplishes much the same thing that Linux's IP Masquerading
function does, and it does it with one simple rule:
map tun0 192.168.1.0/24 -> 20.20.20.1/32
Very simple. Whenever a packet goes out the tun0 interface with
a source address matching the CIDR network mask of 192.168.1.0/24††
this packet will be rewritten within the IP stack such that its source address
is 20.20.20.1, and it will be sent on to its original destination. The system
also keeps a list of what translated connections are in progress so that it
can perform the reverse and remap the response (which will be directed to 20.20.20.1)
to the internal host that really generated the packet.
†† This is a typical internal address space, since it's non-routable on the Real Internet it is often used for internal networks. You should still block these packets coming in from the outside world as discussed earlier.
There is a drawback to the rule we have just written, though. In a large number
of cases, we do not happen to know what the IP address of our outside link is
(if we're using tun0 or ppp0 and a typical ISP) so it makes
setting up our NAT tables a chore. Luckily, NAT is smart enough to accept an
address of 0/32 as a signal that it needs to go look at what the address of
that interface really is and we can rewrite our rule as follows:
map tun0 192.168.1.0/24 -> 0/32
Now we can load our ipnat rules with impunity and connect to the
outside world without having to edit anything. You do have to run ipf -y
to refresh the address if you get disconnected and redial or if your DHCP lease
changes, though.
Some of you may be wondering what happens to the source port when the mapping
happens. With our current rule, the packet's source port is unchanged from the
original source port. There can be instances where we do not desire this behavior;
maybe we have another firewall further upstream we have to pass through, or
perhaps many hosts are trying to use the same source port, causing a collision
where the rule doesn't match and the packet is passed untranslated. ipnat helps
us here with the portmap keyword:
map tun0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:30000
Our rule now shoehorns all the translated connections (which can be tcp,
udp, or tcp/udp) into the port range of 20000 to 30000.
Mapping Many Addresses Into a Pool of Addresses
Another use common use of NAT is to take a small statically allocated block
of addresses and map many computers into this smaller address space. This is
easy to accomplish using what you already know about the map and portmap
keywords by writing a rule like so:
map tun0 192.168.0.0/16 -> 20.20.20.0/24 portmap tcp/udp 20000:60000
Also, there may be instances where a remote application requires that multiple
connections all come from the same IP address. We can help with these situations
by telling NAT to statically map sessions from a host into the pool of addresses
and work some magic to choose a port. This uses a the keyword map-block
as follows:
map-block tun0 192.168.1.0/24 -> 20.20.20.0/24
Occasionally it is desirable to have a system with one IP address behind the
firewall to appear to have a completely different IP address. One example of
how this would work would be a lab of computers which are then attached to various
networks that are to be put under some kind of test. In this example, you would
not want to have to reconfigure the entire lab when you could place a NAT system
in front and change the addresses in one simple place. We can do that with the
bimap keyword, for bidirectional mapping. Bimap has some additional
protections on it to ensure a known state for the connection, whereas the map
keyword is designed to allocate an address and a source port and rewrite the
packet and go on with life.
bimap tun0 192.168.1.1/32 -> 20.20.20.1/32
will accomplish the mapping for one host.
Spoofing services? What does that have to do with anything? Plenty. Lets pretend
that we have a web server running on 20.20.20.5, and since we've gotten increasingly
suspicious of our network security, we desire to not run this server on port
80 since that requires a brief lifespan as the root user. But how do we run
it on a less privledged port of 8000 in this world of "anything dot com"?
How will anyone find our server? We can use the redirection facilities of NAT
to solve this problem by instructing it to remap any connections destined for
20.20.20.5:80 to really point to 20.20.20.5:8000. This uses the rdr
keyword:
rdr tun0 20.20.20.5/32 port 80 -> 192.168.0.5 port 8000
We can also specify the protocol here, if we wanted to redirect a UDP service,
instead of a TCP service (which is the default). For example, if we had a honeypot
on our firewall to impersonate the popular Back Orifice for Windows, we could
shovel our entire network into this one place with a simple rule:
rdr tun0 20.20.20.0/24 port 31337 -> 127.0.0.1 port 31337 udp
An extremely important point must be made about rdr: You cannot
easily† use this feature as a "reflector". E.g:
rdr tun0 20.20.20.5/32 port 80 -> 20.20.20.6 port 80 tcp
will not work in the situation where .5 and .6 are on the same LAN segment.
† Yes. There is a way to do this. It's so convoluted that I refuse to use it, though. Smart people who require this functionality will transparently redirect into something like TIS plug-gw on 127.0.0.1. Stupid people will set up a dummy loop interface pair and double rewrite.
The rdr function is applied to packets that enter the firewall on the specified interface. When a packet comes in that matches a rdr rule, its destination address is then rewritten, it is pushed into ipf for filtering, and should it successfully run the gauntlet of filter rules, it is then sent to the unix routing code. Since this packet is still inbound on the same interface that it will need to leave the system on to reach a host, the system gets confused. Reflectors don't work. Neither does specifying the address of the interface the packet just came in on. Always remember that rdr destinations must exit out of the firewall host on a different interface.††
†† This includes 127.0.0.1, by the way. That's on lo0. Neat, huh?
Transparent Proxy Support; Redirection Made Useful
Since you're installing a firewall, you may have decided that it is prudent
to use a proxy for many of your outgoing connections so that you can further
tighten your filter rules protecting your internal network, or you may have
run into a situation that the NAT mapping process does not currently handle
properly. This can also be accomplished with a redirection statement:
rdr xl0 0.0.0.0/0 port 21 -> 127.0.0.1 port 21
This statement says that any packet coming in on the xl0 interface
destined for any address (0.0.0.0/0) on the ftp port should be rewritten to
connect it with a proxy that is running on the NAT system on port 21.
This specific example of FTP proxying does lead to some complications when
used with web browsers or other automatic-login type clients that are unaware
of the requirements of communicating with the proxy. There are patches for TIS
Firewall Toolkit'sftp-gw to mate it with the nat process so that
it can determine where you were trying to go and automatically send you there.
Many proxy packages now work in a transparent proxy environment (Squid for example,
located at http://squid.nlanr.net, works fine.)
This application of the rdr keyword is often more useful when you wish to force users to authenticate themselves with the proxy. (For example, you desire your engineers to be able to surf the web, but you would rather not have your call-center staff doing so.)
Magic Hidden Within NAT; Application Proxies
Since ipnat provides a method to rewrite packets as they traverse
the firewall, it becomes a convenient place to build in some application level
proxies to make up for well known deficiencies of that application and typical
firewalls. For example; FTP. We can make our firewall pay attention to the packets
going across it and when it notices that it's dealing with an Active FTP session,
it can write itself some temporary rules, much like what happens with keep
state, so that the FTP data connection works. To do this, we use a rule
like so:
map tun0 192.168.1.0/24 -> 20.20.20.1/32 proxy port ftp ftp/tcp
You must always remember to place this proxy rule before
any portmap rules, otherwise when portmap comes along and
matches the packet and rewrites it before the proxy gets a chance to work on
it. Remember that ipnat rules are first-match.
There also exist proxies for "rcmd" (which we suspect is berkeley r-* commands which should be forbidden anyway, thus we haven't looked at what this proxy does) and "raudio" for Real Audio PNM streams. Likewise, both of these rules should be put before any portmap rules, if you're doing NAT.
Loading and Manipulating Filter Rules; The ipf Utility
IP Filter rules are loaded by using the ipf utility. The filter rules
can be stored in any file on the system, but typically these rules are stored
in /etc/ipf.rules, /usr/local/etc/ipf.rules, or /etc/opt/ipf/ipf.rules.
IP Filter has two sets of rules, the active set and the inactive
set. By default, all operations are performed on the active set. You can
manipulate the inactive set by adding -I to the ipf command
line. The two sets can be toggled by using the -s command line option.
This is very useful for testing new rule sets without wiping out the old rule
set.
Rules can also be removed from the list instead of added by using the -r
command line option, but it is generally a safer idea to flush the rule set
that you're working on with -F and completely reload it when making
changes.
In summary, the easiest way to load a rule set is ipf -Fa -f /etc/ipf.rules. For more complicated manipulations of the rule set, please see the ipf(1) man page.
Loading and Manipulating NAT Rules; The ipnat Utility
NAT rules are loaded by using the ipnat utility. The NAT rules can
be stored in any file on the system, but typically these rules are stored in
/etc/ipnat.rules, /usr/local/etc/ipnat.rules, or /etc/opt/ipf/ipnat.rules.
Rules can also be removed from the list instead of added by using the -r
command line option, but it is generally a safer idea to flush the rule set
that you're working on with -C and completely reload it when making
changes. Any active mappings are not affected by -C, and can be removed
with -F.
NAT rules and active mappings can be examined with the -l command
line option.
In summary, the easiest way to load a NAT rule set is ipnat -CF -f /etc/ipnat.rules.
There will come a time when you are interested in what your firewall is actually doing, and ipfilter would be incomplete if it didn't have a full suite of status monitoring tools.
In its simplest form, ipfstat displays a table of interesting data
about how your firewall is performing, such as how many packets have been passed
or blocked, if they were logged or not, how many state entries have been made,
and so on. Here's an example of something you might see from running the tool:
# ipfstat
input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0
output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0
input packets logged: blocked 99286 passed 0
output packets logged: blocked 0 passed 0
packets logged: input 0 output 0
log failures: input 3898 output 0
fragment state(in): kept 0 lost 0
fragment state(out): kept 0 lost 0
packet state(in): kept 169364 lost 0
packet state(out): kept 431395 lost 0
ICMP replies: 0 TCP RSTs sent: 0
Result cache hits(in): 1215208 (out): 1098963
IN Pullups succeeded: 2 failed: 0
OUT Pullups succeeded: 0 failed: 0
Fastroute successes: 0 failures: 0
TCP cksum fails(in): 0 (out): 0
Packet log flags set: (0)
none
ipfstat is also capable of showing you your current rule list.
Using the -i or the -o flag will show the currently loaded
rules for in or out, respectively. Adding a -h to this will provide
more useful information at the same time by showing you a "hit count"
on each rule. For example:
# ipfstat -ho
2451423 pass out on xl0 from any to any
354727 block out on ppp0 from any to any
430918 pass out quick on ppp0 proto tcp/udp from 20.20.20.0/24 to any keep state
keep frags
From this, we can see that perhaps there's something abnormal going on,
since we've got a lot of blocked packets outbound, even with a very permissive
pass out rule. Something here may warrant further investigation, or
it may be functioning perfectly by design. ipfstat can't tell you if your rules
are right or wrong, it can only tell you what is happening because of your rules.
To further debug your rules, you may want to use the -n flag, which
will show the rule number next to each rule.
# ipfstat -on
@1 pass out on xl0 from any to any
@2 block out on ppp0 from any to any
@3 pass out quick on ppp0 proto tcp/udp from 20.20.20.0/24 to any keep state
keep frags
The final piece of really interesting information that ipfstat
can provide us is a dump of the state table. This is done with the -s
flag:
# ipfstat -s
281458 TCP
319349 UDP
0 ICMP
19780145 hits
5723648 misses
0 maximum
0 no memory
1 active
319349 expired
281419 closed
100.100.100.1 -> 20.20.20.1 ttl 864000 pass 20490 pr 6 state 4/4
pkts 196 bytes 17394 987 -> 22 585538471:2213225493 16592:16500
pass in log quick keep state
pkt_flags & b = 2, pkt_options & ffffffff = 0
pkt_security & ffff = 0, pkt_auth & ffff = 0
Here we see that we have one state entry for a TCP connection. The output
will vary slightly from version to version, but the basic information is the
same. We can see in this connection that we have a fully established connection
(represented by the 4/4 state. Other states are incomplete and will be documented
fully later.) We can see that the state entry has a time to live of 240 hours,
which is an absurdly long time, but is the default for an established TCP connection.
This TTL counter is decremented every second that the state entry is not used,
and will finally result in the connection being purged if it has been left idle.
The TTL is also reset to 864000 whenever the state IS used, ensuring that the
entry will not time out while it is being actively used. We can also see that
we have passed 196 packets consisting of about 17kB worth of data over this
connection. We can see the ports for both endpoints, in this case 987 and 22;
which means that this state entry represents a connection from 100.100.100.1
port 987 to 20.20.20.1 port 22. The really big numbers in the second line are
the TCP sequence numbers for this connection, which helps to ensure that someone
isn't easily able to inject a forged packet into your session. The TCP window
is also shown. The third line is a synopsis of the implicit rule that was generated
by the keep state code, showing that this connection is an inbound
connection.
ipfstat is great for collecting snapshots of what's going on on the
system, but it's often handy to have some kind of log to look at and watch events
as they happen in time. ipmon is this tool. ipmon is capable
of watching the packet log (as created with the log keyword in your
rules), the state log, or the nat log, or any combination of the three. This
tool can either be run in the foreground, or as a daemon which logs to syslog
or a file. If we wanted to watch the state table in action, ipmon -o S
would show this:
# ipmon -o S
01/08/1999 15:58:57.836053 STATE:NEW 100.100.100.1,53 -> 20.20.20.15,53 PR
udp
01/08/1999 15:58:58.030815 STATE:NEW 20.20.20.15,123 -> 128.167.1.69,123
PR udp
01/08/1999 15:59:18.032174 STATE:NEW 20.20.20.15,123 -> 128.173.14.71,123
PR udp
01/08/1999 15:59:24.570107 STATE:EXPIRE 100.100.100.1,53 -> 20.20.20.15,53
PR udp Pkts 4 Bytes 356
01/08/1999 16:03:51.754867 STATE:NEW 20.20.20.13,1019 -> 100.100.100.10,22
PR tcp
01/08/1999 16:04:03.070127 STATE:EXPIRE 20.20.20.13,1019 -> 100.100.100.10,22
PR tcp Pkts 63 Bytes 4604
Here we see a state entry for an external dns request off our nameserver,
two xntp pings to well-known time servers, and a very short lived outbound ssh
connection.
ipmon is also capable of showing us what packets have been logged.
For example, when using state, you'll often run into packets like this:
# ipmon -o I
15:57:33.803147 ppp0 @0:2 b 100.100.100.103,443 -> 20.20.20.10,4923 PR tcp
len 20 1488 -A
What does this mean? The first field is obvious, it's a timestamp. The
second field is also pretty obvious, it's the interface that this event happened
on. The third field @0:2 is something most people miss. This is the
rule that caused the event to happen. Remember ipfstat -in? If you
wanted to know where this came from, you could look there for rule 2 in rule
group 0. The fourth field, the little "b" says that this packet was
blocked, and you'll generally ignore this unless you're logging passed packets
as well, which would be a little "p" instead. The fifth and sixth
fields are pretty self-explanatory, they say where this packet came from and
where it was going. The seventh ("PR") and eighth fields tell you
the protocol and the ninth field tells you the size of the packet. The last
part, the "-A" in this case, tells you the flags that were on the
packet; This one was an ACK packet. Why did I mention state earlier? Due to
the often laggy nature of the Internet, sometimes packets will be regenerated.
Sometimes, you'll get two copies of the same packet, and your state rule which
keeps track of sequence numbers will have already seen this packet, so it will
assume that the packet is part of a different connection. Eventually this packet
will run into a real rule and have to be dealt with. You'll often see the last
packet of a session being closed get logged because the keep state
code has already torn down the connection before the last packet has had a chance
to make it to your firewall. This is normal, do not be alarmed.†
† For a technical presentation of the IP Filter stateful inspection engine, please see the white paper Real Stateful TCP Packet Filtering in IP Filter, by Guido van Rooij. This paper may be found at <http://www.iae.nl/users/guido/papers/tcp_filtering.ps.gz>
Another example packet that might be logged:
12:46:12.470951 xl0 @0:1 S 20.20.20.254 -> 255.255.255.255 PR icmp len
20 9216 icmp 9/0
This is a ICMP router discovery broadcast. We can tell by the ICMP type
9/0.
Finally, ipmon also lets us look at the NAT table in action.
# ipmon -o N
01/08/1999 05:30:02.466114 @2 NAT:RDR 20.20.20.253,113 <- -> 20.20.20.253,113
[100.100.100.13,45816]
01/08/1999 05:30:31.990037 @2 NAT:EXPIRE 20.20.20.253,113 <- -> 20.20.20.253,113
[100.100.100.13,45816] Pkts 10 Bytes 455
This would be a redirection to an identd that lies to provide ident service
for the hosts behind our NAT, since they are typically unable to provide this
service for themselves with ordinary natting.
| << Previous section: Basic firewalling |