path: root/share/examples/ipfilter/ipf-howto.txt

              IP Filter Based Firewalls HOWTO

              Brendan Conoboy <synk@swcp.com>
            Erik Fichtner <emf@obfuscation.org>
            $FreeBSD$

                Fri Apr 20 09:31:14 EDT 2001






     Abstract:  This document is intended to introduce a new
     user to the IP Filter firewalling package and,  at  the
     same  time,  teach  the user some basic fundamentals of
     good firewall design.












1.  Introduction

     IP Filter is a great little firewall package.  It  does
just   about   everything  other  free  firewalls  (ipfwadm,
ipchains, ipfw) do, but it's also  portable  and  does  neat
stuff  the  others don't.  This document is intended to make
some cohesive sense of the  sparse  documentation  presently
available  for ipfilter.  Some prior familiarity with packet
filtering will be useful, however too much  familiarity  may
make this document a waste of your time.  For greater under-
standing of firewalls, the authors recommend reading  Build-
ing Internet Firewalls, Chapman & Zwicky, O'Reilly and Asso-
ciates; and TCP/IP Illustrated, Volume 1, Stevens,  Addison-
Wesley.





1.1.  Disclaimer

     The  authors  of  this document are not responsible for
any damages incurred due to actions taken based on this doc-
ument. This document is meant as an introduction to building
a  firewall  based  on  IP-Filter.   If  you  do  not   feel









                             -2-


comfortable  taking responsibility for your own actions, you
should stop reading this document and hire a qualified secu-
rity professional to install your firewall for you.


1.2.  Copyright

     Unless  otherwise  stated,  HOWTO  documents  are copy-
righted by their respective authors. HOWTO documents may  be
reproduced  and  distributed  in  whole  or  in part, in any
medium physical or electronic, as  long  as  this  copyright
notice  is retained on all copies. Commercial redistribution
is allowed and encouraged; however, the authors  would  like
to be notified of any such distributions.

     All  translations, derivative works, or aggregate works
incorporating any HOWTO documents must be covered under this
copyright notice.  That is, you may not produce a derivative
work from a HOWTO and impose additional restrictions on  its
distribution. Exceptions to these rules may be granted under
certain conditions; please contact the HOWTO coordinator.

     In short, we wish  to  promote  dissemination  of  this
information  through  as many channels as possible. However,
we do wish to retain copyright on the HOWTO  documents,  and
would  like  to be notified of any plans to redistribute the
HOWTOs.


1.3.  Where to obtain the important pieces

     The     official     IPF      homepage      is      at:
<http://coombs.anu.edu.au/~avalon/ip-filter.html>

     The  most  up-to-date  version  of this document can be
found at: <http://www.obfuscation.org/ipf/>




2.  Basic Firewalling

     This section is designed to familiarize you with ipfil-
ter's  syntax, and firewall theory in general.  The features
discussed here are features you'll find in any good firewall
package.   This  section  will give you a good foundation to
make reading and understanding  the  advanced  section  very
easy.   It must be emphasized that this section alone is not
enough to build a good firewall, and that the advanced  sec-
tion  really  is  required  reading for anybody who wants to
build an effective security system.












                             -3-


2.1.  Config File Dynamics, Order and Precedence

     IPF (IP Filter) has a config file (as opposed  to  say,
running  some  command  again  and again for each new rule).
The config file drips with Unix:  There's one rule per line,
the  "#" mark denotes a comment, and you can have a rule and
a comment  on  the  same  line.   Extraneous  whitespace  is
allowed, and is encouraged to keep the rules readable.


2.2.  Basic Rule Processing

     The  rules  are  processed from top to bottom, each one
appended after another.  This quite simply means that if the
entirety of your config file is:

    block in all
    pass  in all

The computer sees it as:

    block in all
    pass  in all

Which is to say that when a packet comes in, the first thing
IPF applies is:

    block in all

Should IPF deem it necessary to move on to the next rule, it
would then apply the second rule:

    pass  in all

     At  this  point,  you might want to ask yourself "would
IPF move on to the second rule?"  If  you're  familiar  with
ipfwadm  or  ipfw,  you  probably  won't  ask yourself this.
Shortly after, you will become bewildered at the  weird  way
packets  are  always  getting  denied  or  passed  when they
shouldn't.  Many packet filters stop  comparing  packets  to
rulesets  the moment the first match is made; IPF is not one
of them.

     Unlike the other packet filters, IPF keeps  a  flag  on
whether  or  not  it's going to pass the packet.  Unless you
interrupt the flow, IPF will go through the entire  ruleset,
making  its  decision  on whether or not to pass or drop the
packet based on the last matching rule.  The scene: IP  Fil-
ter's  on  duty.   It's  been  been scheduled a slice of CPU
time.  It has a checkpoint clipboard that reads:

    block in all
    pass  in all










                             -4-


A packet comes in the interface and it's time to go to work.
It  takes a look at the packet, it takes a look at the first
rule:

    block in all

"So far I think I will block  this  packet"  says  IPF.   It
takes a look at the second rule:

    pass  in all

"So far I think I will pass this packet" says IPF.  It takes
a look at a third rule.  There is no third rule, so it  goes
with  what  its  last  motivation  was,  to  pass the packet
onward.

It's a good time to point out that even if the  ruleset  had
been

    block in all
    block in all
    block in all
    block in all
    pass  in all

that  the packet would still have gone through.  There is no
cumulative effect.  The  last  matching  rule  always  takes
precedence.

2.3.  Controlling Rule Processing

     If  you  have experience with other packet filters, you
may find this layout to be confusing, and you may be  specu-
lating  that  there are problems with portability with other
filters and speed of rule matching.  Imagine if you had  100
rules  and  most  of  the applicable ones were the first 10.
There would be a terrible overhead for every  packet  coming
in  to  go through 100 rules every time.  Fortunately, there
is a simple keyword you can add to any rule  that  makes  it
take action at that match.  That keyword is quick.

Here's  a  modified  copy  of the original ruleset using the
quick keyword:

    block in quick all
    pass  in       all

In this case, IPF looks at the first rule:

    block in quick all

The packet matches and the search is over.   The  packet  is
expunged  without a peep.  There are no notices, no logs, no
memorial service.  Cake will not be served.  So  what  about









                             -5-


the next rule?

    pass  in       all

     This  rule is never encountered.  It could just as eas-
ily not be in the config file at all.  The sweeping match of
all  and  the  terminal keyword quick from the previous rule
make certain that no rules are followed afterward.

     Having half a config file laid to  waste  is  rarely  a
desirable  state.   On  the other hand, IPF is here to block
packets and as configured,  it's  doing  a  very  good  job.
Nonetheless,  IPF  is also here to let some packets through,
so a change to the ruleset to make this possible  is  called
for.

2.4.  Basic filtering by IP address

     IPF  will match packets on many criteria.  The one that
we most commonly think of is the IP address.  There are some
blocks of address space from which we should never get traf-
fic.  One such  block  is  from   the  unroutable  networks,
192.168.0.0/16 (/16 is the CIDR notation for a netmask.  You
may  be  more  familiar  with  the  dotted  decimal  format,
255.255.0.0.   IPF  accepts  both).   If you wanted to block
192.168.0.0/16, this is one way to do it:

    block in quick from 192.168.0.0/16 to any
    pass  in       all

Now we have a less  stringent  ruleset  that  actually  does
something  for  us.   Let's  imagine  a packet comes in from
1.2.3.4.  The first rule is applied:

    block in quick from 192.168.0.0/16 to any

The packet is from 1.2.3.4, not 192.168.*.*, so there is  no
match.  The second rule is applied:

    pass  in       all

The  packet from 1.2.3.4 is definitely a part of all, so the
packet is sent to whatever it's destination happened to  be.

     On  the other hand, suppose we have a packet that comes
in from 192.168.1.2.  The first rule is applied:

    block in quick from 192.168.0.0/16 to any

There's a match, the packet is dropped, and that's the  end.
Again,  it doesn't move to the second rule because the first
rule matches and contains the quick keyword.











                             -6-


     At this point you can build a fairly extensive  set  of
definitive  addresses  which  are  passed or blocked.  Since
we've already started blocking private  address  space  from
entering our firewall, let's take care of the rest of it:

    block in quick from 192.168.0.0/16 to any
    block in quick from 172.16.0.0/12 to any
    block in quick from 10.0.0.0/8 to any
    pass  in       all

The  first  three  address blocks are some of the private IP
space.

2.5.  Controlling Your Interfaces

     It  seems  very  frequent  that companies have internal
networks before they want a link to the outside  world.   In
fact, it's probably reasonable to say that's the main reason
people consider firewalls in the first place.   The  machine
that  bridges the outside world to the inside world and vice
versa is the router.  What separates  the  router  from  any
other machine is simple: It has more than one interface.

     Every  packet  you  receive comes from a network inter-
face; every packet you transmit goes out  a  network  inter-
face.   Say  your  machine has 3 interfaces, lo0 (loopback),
xl0 (3com ethernet),  and  tun0  (FreeBSD's  generic  tunnel
interface  that PPP uses), but you don't want packets coming
in on the tun0 interface?

    block in quick on tun0 all
    pass  in               all

In this case, the on keyword means that that data is  coming
in  on  the  named interface.  If a packet comes in on tun0,
the first rule will block it.  If a packet comes in  on  lo0
or in on xl0, the first rule will not match, the second rule
will, the packet will be passed.

2.6.  Using IP Address and Interface Together

     It's an odd state of affairs when one decides  it  best
to  have the tun0 interface up, but not allow any data to be
received from it.  The more criteria  the  firewall  matches
against,  the  tighter  (or looser) the firewall can become.
Maybe you want data from tun0, but not from  192.168.0.0/16?
This is the start of a powerful firewall.

    block in quick on tun0 from 192.168.0.0/16 to any
-----------
            See             rfc1918             at
<http://www.faqs.org/rfcs/rfc1918.html>        and
<http://www.ietf.org/internet-drafts/draft-man-
ning-dsua-06.txt>









                             -7-


    pass  in       all

Compare this to our previous rule:

    block in quick from 192.168.0.0/16 to any
    pass  in       all

The  old way, all traffic from 192.168.0.0/16, regardless of
interface, was completely blocked.  The new  way,  using  on
tun0 means that it's only blocked if it comes in on the tun0
interface.  If a packet arrived on the  xl0  interface  from
192.168.0.0/16, it would be passed.

     At  this  point you can build a fairly extensive set of
definitive addresses which are  passed  or  blocked.   Since
we've  already  started  blocking private address space from
entering tun0, let's take care of the rest of it:

    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 quick on tun0 from 0.0.0.0/8 to any
    block in quick on tun0 from 169.254.0.0/16 to any
    block in quick on tun0 from 192.0.2.0/24 to any
    block in quick on tun0 from 204.152.64.0/23 to any
    block in quick on tun0 from 224.0.0.0/3 to any
    pass  in       all

You've already seen the first  three  blocks,  but  not  the
rest.   The  fourth is a largely wasted class-A network used
for loopback.  Much software  communicates  with  itself  on
127.0.0.1  so  blocking it from an external source is a good
idea.  The fifth, 0.0.0.0/8, should never  be  seen  on  the
internet.   Most IP stacks treat "0.0.0.0/32" as the default
gateway, and the rest of the 0.*.*.*  network  gets  handled
strangely  by  various systems as a byproduct of how routing
decisions are made.   You should treat 0.0.0.0/8  just  like
127.0.0.0/8.    169.254.0.0/16 has been assigned by the IANA
for use in auto-configuration when systems have not yet been
able  to  obtain  an  IP address via DHCP or the like.  Most
notably, Microsoft Windows will use addresses in this  range
if  they  are  set  to  DHCP  and cannot find a DHCP server.
192.0.2.0/24 has also been reserved for use as an example IP
netblock  for documentation authors.  We specifically do not
use this range as it would cause confusion when we tell  you
to   block   it,   and  thus  all  our  examples  come  from
20.20.20.0/24.  204.152.64.0/23 is an odd netblock  reserved
by  Sun  Microsystems for private cluster interconnects, and
blocking  this  is  up  to  your  own  judgement.    Lastly,
224.0.0.0/3  wipes out the "Class D and E" networks which is
used mostly for multicast traffic, although further  defini-
tion of "Class E" space can be found in RFC 1166.










                             -8-


     There's  a very important principle in packet filtering
which has only been alluded  to  with  the  private  network
blocking  and  that  is  this: When you know there's certain
types of data that only comes from certain places, you setup
the  system  to  only  allow  that  kind  of data from those
places.  In the case of the unroutable addresses,  you  know
that  nothing  from  10.0.0.0/8  should  be arriving on tun0
because you have no way to reply to it.  It's  an  illegiti-
mate  packet.   The  same  goes for the other unroutables as
well as 127.0.0.0/8.

     Many pieces of software  do  all  their  authentication
based  upon  the  packet's originating IP address.  When you
have an internal network, say 20.20.20.0/24, you  know  that
the  only traffic for that internal network is going to come
off the local ethernet.  Should a packet from  20.20.20.0/24
arrive  over a PPP dialup, it's perfectly reasonable to drop
it on the floor, or put it in a dark room for interrogation.
It  should by no means be allowed to get to its final desti-
nation.  You can accomplish this  particularly  easily  with
what you already know of IPF.  The new ruleset would be:

    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 quick on tun0 from 0.0.0.0/8 to any
    block in quick on tun0 from 169.254.0.0/16 to any
    block in quick on tun0 from 192.0.2.0/24 to any
    block in quick on tun0 from 204.152.64.0/23 to any
    block in quick on tun0 from 224.0.0.0/3 to any
    block in quick on tun0 from 20.20.20.0/24 to any
    pass  in       all

2.7.  Bi-Directional Filtering; The "out" Keyword

     Up  until  now,  we've been passing or blocking inbound
traffic.  To clarify, inbound traffic is  all  traffic  that
enters  the firewall on any interface.  Conversely, outbound
traffic is all traffic that leaves on any interface (whether
locally  generated  or  simply passing through).  This means
that all packets coming in are not  only  filtered  as  they
enter  the  firewall,  they're  also  filtered as they exit.
Thusfar there's been an implied pass out all that may or may
not  be  desirable.  Just as you may pass and block incoming
traffic, you may do the same with outgoing traffic.

     Now that we know there's a way to filter outbound pack-
ets  just  like inbound, it's up to us to find a conceivable
use for such a thing.  One possible use of this idea  is  to
keep spoofed packets from exiting your own network.  Instead
of passing any traffic out the  router,  you  could  instead
limit   permitted   traffic   to   packets   originating  at










                             -9-


20.20.20.0/24.  You might do it like this:

    pass  out quick on tun0 from 20.20.20.0/24 to any
    block out quick on tun0 from any to any

If a packet comes from 20.20.20.1/32, it gets  sent  out  by
the  first  rule.  If a packet comes from 1.2.3.4/32 it gets
blocked by the second.

     You can also make  similar  rules  for  the  unroutable
addresses.   If some machine tries to route a packet through
IPF with a destination in 192.168.0.0/16, why not  drop  it?
The worst that can happen is that you'll spare yourself some
bandwidth:

    block out quick on tun0 from any to 192.168.0.0/16
    block out quick on tun0 from any to 172.16.0.0/12
    block out quick on tun0 from any to 10.0.0.0/8
    block out quick on tun0 from any to 0.0.0.0/8
    block out quick on tun0 from any to 127.0.0.0/8
    block out quick on tun0 from any to 169.254.0.0/16
    block out quick on tun0 from any to 192.0.2.0/24
    block out quick on tun0 from any to 204.152.64.0/23
    block out quick on tun0 from any to 224.0.0.0/3
    block out quick on tun0 from !20.20.20.0/24 to any

In the narrowest viewpoint, this doesn't enhance your  secu-
rity.   It  enhances everybody else's security, and that's a
nice thing to do.  As another viewpoint, one  might  suppose
that because nobody can send spoofed packets from your site,
that your site has less value as a relay for  crackers,  and
as such is less of a target.

     You'll  likely  find a number of uses for blocking out-
bound packets.  One thing to always keep in mind is that  in
and  out directions are in reference to your firewall, never
any other machine.

2.8.  Logging What Happens; The "log" Keyword

     Up to this point, all blocked and passed  packets  have
been silently blocked and silently passed.  Usually you want
to know if you're being attacked rather than wonder if  that
firewall  is  really buying you any added benefits.  While I
wouldn't want to log every passed packet, and in some  cases
every blocked packet, I would want to know about the blocked
packets from 20.20.20.0/24.  To do this, we add the log key-
word:

    block in     quick on tun0 from 192.168.0.0/16 to any
-----------
 This can, of course, be changed by using -DIPFIL-
TER_DEFAULT_BLOCK  when compiling ipfilter on your
system.









                            -10-


    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     quick on tun0 from 0.0.0.0/8 to any
    block in     quick on tun0 from 169.254.0.0/16 to any
    block in     quick on tun0 from 192.0.2.0/24 to any
    block in     quick on tun0 from 204.152.64.0/23 to any
    block in     quick on tun0 from 224.0.0.0/3 to any
    block in log quick on tun0 from 20.20.20.0/24 to any
    pass  in       all

So far, our firewall is pretty good at blocking packets com-
ing to it from suspect places, but there's still more to  be
done.   For one thing, we're accepting packets destined any-
where.  One thing we ought to do is  make  sure  packets  to
20.20.20.0/32  and 20.20.20.255/32 get dropped on the floor.
To do otherwise opens  the  internal  network  for  a  smurf
attack.  These two lines would prevent our hypothetical net-
work from being used as a smurf relay:

    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

This brings our total ruleset to look something like this:

    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     quick on tun0 from 0.0.0.0/8 to any
    block in     quick on tun0 from 169.254.0.0/16 to any
    block in     quick on tun0 from 192.0.2.0/24 to any
    block in     quick on tun0 from 204.152.64.0/23 to any
    block in     quick on tun0 from 224.0.0.0/3 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  in       all

2.9.  Complete Bi-Directional Filtering By Interface

     So far we have only presented fragments of  a  complete
ruleset.   When  you're  actually creating your ruleset, you
should setup rules for every direction and every  interface.
The  default state of ipfilter is to pass packets.  It is as
though there were an invisible rule at the  beginning  which
states  pass  in  all and pass out all.  Rather than rely on
some default behaviour, make everything as specific as  pos-
sible,  interface by interface, until every base is covered.

     First we'll start with the lo0 interface,  which  wants
to  run  wild and free.  Since these are programs talking to
others on the local system,  go  ahead  and  keep  it  unre-
stricted:









                            -11-


    pass out quick on lo0
    pass in  quick on lo0

Next, there's the xl0 interface.  Later on we'll begin plac-
ing restrictions on the xl0 interface, but  to  start  with,
we'll  act  as  though  everything  on  our local network is
trustworthy and give it much the same treatment as lo0:

    pass out quick on xl0
    pass in  quick on xl0

Finally, there's the tun0 interface, which we've been  half-
filtering with up until now:

    block out quick on tun0 from any to 192.168.0.0/16
    block out quick on tun0 from any to 172.16.0.0/12
    block out quick on tun0 from any to 127.0.0.0/8
    block out quick on tun0 from any to 10.0.0.0/8
    block out quick on tun0 from any to 0.0.0.0/8
    block out quick on tun0 from any to 169.254.0.0/16
    block out quick on tun0 from any to 192.0.2.0/24
    block out quick on tun0 from any to 204.152.64.0/23
    block out quick on tun0 from any to 224.0.0.0/3
    pass  out quick on tun0 from 20.20.20.0/24 to any
    block out quick on tun0 from any to any

    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     quick on tun0 from 0.0.0.0/8 to any
    block in     quick on tun0 from 169.254.0.0/16 to any
    block in     quick on tun0 from 192.0.2.0/24 to any
    block in     quick on tun0 from 204.152.64.0/23 to any
    block in     quick on tun0 from 224.0.0.0/3 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  in     all

This  is  a  pretty significant amount of filtering already,
protecting 20.20.20.0/24 from being spoofed  or  being  used
for  spoofing.   Future  examples will continue to show one-
sideness, but keep in mind that it's for brevity's sake, and
when  setting  up  your  own ruleset, adding rules for every
direction and every interface is necessary.


2.10.  Controlling Specific Protocols; The "proto" Keyword

     Denial of Service attacks  are  as  rampant  as  buffer
overflow  exploits.   Many denial of service attacks rely on
glitches in the OS's TCP/IP  stack.   Frequently,  this  has
come  in  the  form  of  ICMP  packets.   Why not block them









                            -12-


entirely?

    block in log quick on tun0 proto icmp from any to any

Now any ICMP traffic coming in from tun0 will be logged  and
discarded.

2.11.   Filtering ICMP with the "icmp-type" Keyword; Merging
Rulesets

     Of course, dropping all ICMP isn't really an ideal sit-
uation.   Why  not drop all ICMP?  Well, because it's useful
to have partially enabled.  So maybe you want to  keep  some
types  of  ICMP  traffic  and drop other kinds.  If you want
ping and traceroute to work, you need to let in ICMP types 0
and  11.   Strictly speaking, this might not be a good idea,
but if you need to weigh security against  convenience,  IPF
lets you do it.

    pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0
    pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11

Remember that ruleset order is important.  Since we're doing
everything quick we must have our passes before our  blocks,
so we really want the last three rules in this order:

    pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0
    pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11
    block in log quick on tun0 proto icmp from any to any

Adding  these  3  rules  to the anti-spoofing rules is a bit
tricky.  One error might be to put the new ICMP rules at the
beginning:

    pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0
    pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11
    block in log quick on tun0 proto icmp from any to any
    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     quick on tun0 from 0.0.0.0/8 to any
    block in     quick on tun0 from 169.254.0.0/16 to any
    block in     quick on tun0 from 192.0.2.0/24 to any
    block in     quick on tun0 from 204.152.64.0/23 to any
    block in     quick on tun0 from 224.0.0.0/3 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  in       all

The  problem  with  this  is that an ICMP type 0 packet from
192.168.0.0/16 will get passed by the first rule, and  never
blocked  by the fourth rule.  Also, since we quickly pass an









                            -13-


ICMP ECHO_REPLY (type 0) to 20.20.20.0/24, we've just opened
ourselves  back  up  to  a  nasty smurf attack and nullified
those last two block rules.  Oops.  To avoid this, we  place
the ICMP rules after the anti-spoofing rules:

    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     quick on tun0 from 0.0.0.0/8 to any
    block in     quick on tun0 from 169.254.0.0/16 to any
    block in     quick on tun0 from 192.0.2.0/24 to any
    block in     quick on tun0 from 204.152.64.0/23 to any
    block in     quick on tun0 from 224.0.0.0/3 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  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0
    pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11
    block in log quick on tun0 proto icmp from any to any
    pass  in       all

Because  we  block spoofed traffic before the ICMP rules are
processed, a spoofed packet never makes it to the ICMP rule-
set.   It's  very  important to keep such situations in mind
when merging rules.

2.12.  TCP and UDP Ports; The "port" Keyword

     Now that we've started blocking packets based on proto-
col, we can start blocking packets based on specific aspects
of each protocol.  The most frequently used of these aspects
is  the port number.  Services such as rsh, rlogin, and tel-
net are all very convenient  to  have,  but  also  hideously
insecure  against  network sniffing and spoofing.  One great
compromise is to only allow the services to run  internally,
then  block  them  externally.   This  is easy to do because
rlogin, rsh, and telnet use specific TCP  ports  (513,  514,
and 23 respectively).  As such, creating rules to block them
is easy:

    block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 513
    block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 514
    block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 23

Make sure all 3 are before the pass in all  and  they'll  be
closed  off  from  the  outside  (leaving  out  spoofing for
brevity's sake):

    pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0
    pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11
    block in log quick on tun0 proto icmp from any to any
    block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 513
    block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 514









                            -14-


    block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 23
    pass  in     all

You might also want to block 514/udp  (syslog),   111/tcp  &
111/udp  (portmap),  515/tcp  (lpd),  2049/tcp  and 2049/udp
(NFS), 6000/tcp (X11) and so on and so forth.  You can get a
complete  listing  of  the  ports being listened to by using
netstat -a (or lsof -i, if you have it installed).

     Blocking UDP instead of  TCP  only  requires  replacing
proto tcp with proto udp.  The rule for syslog would be:

    block in log quick on tun0 proto udp from any to 20.20.20.0/24 port = 514

IPF  also  has  a shorthand way to write rules that apply to
both proto tcp and proto udp  at  the  same  time,  such  as
portmap or NFS.  The rule for portmap would be:

    block in log quick on tun0 proto tcp/udp from any to 20.20.20.0/24 port = 111




3.  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.

3.1.  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  ser-
vice?   Instead of dealing with all that hassle, let's 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.  Let's









                            -15-


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.

3.2.  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 tel-
net session.  What if there was a way to identify and autho-
rize  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 peo-
ple do, that's why Ciscos have an "established" clause  that
lets  established  tcp sessions go through.  Ipfw has estab-
lished.  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









                            -16-


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 mid-
dle 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 run-
ning 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 cir-
cumvented.  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  fire-
wall.  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 rule-
set.  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










                            -17-


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  any-
where.   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 nor-
mal 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.

3.3.  Stateful UDP

     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 X.  This is a short  term  state
entry, a mere 60 seconds.









                            -18-


     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.

3.4.  Stateful ICMP

     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 resul-
tant 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  mes-
sages  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:









                            -19-


    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 connec-
tion is known to be in your state table, the  incoming  ICMP
packet  is checked not only for matching source and destina-
tion addresses (and ports, when applicable) but a tiny  part
of the payload of the packet that the ICMP message is claim-
ing it was generated by.

3.5.  FIN Scan Detection; "flags" Keyword, "keep frags" Key-
word

Let's 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.  Now all incoming packets must either be handshakes or
have state already.  If anything else comes in, it's  proba-
bly  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
-----------
 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 pack-
ets 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.









                            -20-


keep frags keyword.  With it, IPF will notice and keep track
of  packets that are fragmented, allowing the expected frag-
ments to to go through.  Let's 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.

3.6.  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 desir-
able 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 nor-
mally 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 proto tcp from any to 20.20.20.0/24 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 some-
body sends a packet to a UDP port on your  system.   Whereas
once you might have used:









                            -21-


    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 for-
mat is:

     block return-icmp-as-dest(port-unr) in log on tun0 proto udp from any to 20.20.20.0/24 port = 111

3.7.  Fancy Logging Techniques

     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 actu-
ally 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 situa-
tions  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









                            -22-


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.

3.8.  Putting It All Together

     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     quick on tun0 from 0.0.0.0/8 to any
    block in     quick on tun0 from 169.254.0.0/16 to any
    block in     quick on tun0 from 192.0.2.0/24 to any
    block in     quick on tun0 from 204.152.64.0/23 to any
    block in     quick on tun0 from 224.0.0.0/3 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

3.9.  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 fig-
ure 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     quick on xl0 from 0.0.0.0/8 to any
    block in     quick on xl0 from 169.254.0.0/16 to any
    block in     quick on xl0 from 192.0.2.0/24 to any
    block in     quick on xl0 from 204.152.64.0/23 to any
    block in     quick on xl0 from 224.0.0.0/3 to any









                            -23-


    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  addi-
tional  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.









                            -24-


    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     quick on xl0 from 0.0.0.0/8 to any       group 1
      block in     quick on xl0 from 169.254.0.0/16 to any  group 1
      block in     quick on xl0 from 192.0.2.0/24 to any    group 1
      block in     quick on xl0 from 204.152.64.0/23 to any group 1
      block in     quick on xl0 from 224.0.0.0/3 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.

3.10.  "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  appli-
cations  like  unix  traceroute  which uses UDP packets with
various TTL values to map the hops between two sites.  If we









                            -25-


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.




4.  NAT and Proxies

     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  famil-
iar  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.

4.1.  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
-----------
  To be pedantic, what IPFilter provides is really
called NPAT, for Network and Port Address Transla-
tion,  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.









                            -26-


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.

     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 discon-
nected 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.



-----------
 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.









                            -27-


4.2.  Mapping Many Addresses Into a Pool of Addresses

     Another use common use of NAT is to take a small stati-
cally  allocated  block  of addresses and map many computers
into this smaller address space.   This is  easy  to  accom-
plish  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

4.3.  One to One Mappings

     Occasionally  it is desirable to have a system with one
IP address behind the firewall to  appear  to  have  a  com-
pletely 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.

4.4.  Spoofing Services

     Spoofing services?  What does that have to do with any-
thing?   Plenty.  Let's 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









                            -28-


We can also specify the protocol here, if we wanted to redi-
rect 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.   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 filter-
ing,  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.

4.5.  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  accom-
plished 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.

-----------
 Yes. There is a way to do this.  It's  so  convo-
luted that I refuse to use it, though.  Smart peo-
ple who require this functionality will  transpar-
ently  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.
 This includes 127.0.0.1, by the way.   That's  on
lo0.  Neat, huh?









                            -29-


     This specific example of FTP proxying does lead to some
complications  when  used  with  web browsers or other auto-
matic-login type clients that are unaware  of  the  require-
ments  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  use-
ful  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.)

4.6.  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 fire-
walls.  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.



5.  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









                            -30-


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  gener-
ally  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.

6.  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 typi-
cally  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  gener-
ally  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.

7.  Monitoring and Debugging

     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 monitor-
ing tools.

7.1.  The ipfstat utility

     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









                            -31-


     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  abnor-
mal  going on, since we've got a lot of blocked packets out-
bound, even with a very permissive pass out rule.  Something
here  may warrant further investigation,  or it may be func-
tioning perfectly by design.  ipfstat can't tell you if your
rules  are right or wrong, it can only tell you what is hap-
pening 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 ipfs-
tat 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









                            -32-


            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 connec-
tion.  The output will vary slightly from  version  to  ver-
sion,  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 sec-
ond 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 rep-
resents  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.

7.2.  The ipmon utility

     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









                            -33-


    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 ear-
lier?   Due to the often laggy nature of the Internet, some-
times  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  dif-
ferent  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 fire-
wall.  This is normal, do not be alarmed.   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

-----------
 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_filter-
ing.ps.gz>









                            -34-


This  is an 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 pro-
vide ident service for the hosts behind our NAT, since  they
are  typically unable to provide this service for themselves
with ordinary natting.




8.  Specific Applications of IP Filter - Things  that  don't
fit, but should be mentioned anyway.

8.1.  Keep State With Servers and Flags.

     Keeping  state  is a good thing, but it's quite easy to
make a mistake in the direction that you want to keep  state
in.    Generally,  you  want to have a keep state keyword on
the first rule that interacts with a packet for the  connec-
tion.  One  common  mistake  that  is made when mixing state
tracking with filtering on flags is this:

     block in all
     pass in quick proto tcp from any to 20.20.20.20/32 port = 23 flags S
     pass out all keep state

That certainly appears to allow a connection to  be  created
to  the  telnet server on 20.20.20.20, and the replies to go
back.  If you try using this rule, you'll see that  it  does
work--Momentarily.   Since we're filtering for the SYN flag,
the state entry never fully gets completed, and the  default
time to live for an incomplete state is 60 seconds.

We can solve this by rewriting the rules in one of two ways:

1)

          block in all
          pass in quick proto tcp from any to 20.20.20.20/32 port = 23 keep state
          block out all

or:

2)

          block in all
          pass in quick proto tcp from any to 20.20.20.20/32 port = 23 flags S keep state









                            -35-


          pass out all keep state

Either of these sets of rules will result in a fully  estab-
lished state entry for a connection to your server.

8.2.  Coping With FTP

     FTP is one of those protocols that you just have to sit
back and ask "What the heck were they  thinking?"   FTP  has
many  problems that the firewall administrator needs to deal
with.  What's worse, the  problems  the  administrator  must
face  are different between making ftp clients work and mak-
ing ftp servers work.

     Within the FTP protocol, there are two  forms  of  data
transfer,  called  active and passive.  Active transfers are
those where the server connects  to  an  open  port  on  the
client  to  send  data.   Conversely,  passive transfers are
those where the client connects to  the  server  to  receive
data.

8.2.1.  Running an FTP Server

     In  running an FTP server, handling Active FTP sessions
is easy to setup.  At the same time,  handling  Passive  FTP
sessions  is a big problem.  First we'll cover how to handle
Active FTP, then move on to Passive.  Generally, we can han-
dle  Active  FTP  sessions like we would an incoming HTTP or
SMTP connection; just open the ftp port and let  keep  state
do the rest:

     pass in quick proto tcp from any to 20.20.20.20/32 port = 21 flags S keep state
     pass out proto tcp all keep state

These  rules will allow Active FTP sessions, the most common
type, to your ftp server on 20.20.20.20.

     The next challenge becomes handling Passive FTP connec-
tions.   Web browsers default to this mode, so it's becoming
quite popular and as such it should be supported.  The prob-
lem with passive connections are that for every passive con-
nection, the server starts listening on a new port  (usually
above  1023).   This  is  essentially  like  creating  a new
unknown service on the server.   Assuming  we  have  a  good
firewall  with  a default-deny policy, that new service will
be blocked, and thus Active FTP sessions are broken.   Don't
despair!  There's hope yet to be had.

     A  person's  first  inclination to solving this problem
might be to just open up all ports above  1023.   In  truth,
this will work:

     pass in quick proto tcp from any to 20.20.20.20/32 port > 1023 flags S keep state
     pass out proto tcp all keep state









                            -36-


This  is somewhat unsatisfactory, though.  By letting every-
thing above 1023 in, we actually open  ourselves  up  for  a
number  of  potential  problems.  While 1-1023 is the desig-
nated area for server services  to  run,  numerous  programs
decided to use numbers higher than 1023, such as nfsd and X.

     The good news is that your FTP server  gets  to  decide
which  ports  get  assigned to passive sessions.  This means
that instead of opening all ports above 1023, you can  allo-
cate ports 15001-19999 as ftp ports and only open that range
of your firewall up.  In wu-ftpd, this is done with the pas-
sive  ports option in ftpaccess.  Please see the man page on
ftpaccess for details  in  wu-ftpd  configuration.   On  the
ipfilter side, all we need do is setup corresponding rules:

     pass in quick proto tcp from any to 20.20.20.20/32 port 15000 >< 20000 flags S keep state
     pass out proto tcp all keep state

If  even  this  solution doesn't satisfy you, you can always
hack IPF support into your FTP server, or FTP server support
into IPF.

8.2.2.  Running an FTP Client

     While  FTP server support is still less than perfect in
IPF, FTP client support has been working well  since  3.3.3.
As  with  FTP  servers,  there  are  two types of ftp client
transfers: passive and active.

     The simplest type of client  transfer  from  the  fire-
wall's  standpoint is the passive transfer.  Assuming you're
keeping state on all outbound tcp sessions,  passive  trans-
fers  will  work already.  If you're not doing this already,
please consider the following:

    pass out proto tcp all keep state

The second type of client transfer, active, is  a  bit  more
troublesome,  but  nonetheless  a  solved  problem.   Active
transfers cause the server to open up  a  second  connection
back  to  the client for data to flow through.  This is nor-
mally a problem when there's a firewall in the middle, stop-
ping  outside  connections  from  coming  back in.  To solve
this, ipfilter includes an  ipnat  proxy  which  temporarily
opens  up  a hole in the firewall just for the FTP server to
get back to the client.  Even if you're not using  ipnat  to
do  nat,  the proxy is still effective.  The following rules
is the bare minimum to add to the ipnat  configuration  file
(ep0  should  be  the interface name of the outbound network
connection):

     map ep0 0/0 -> 0/32 proxy port 21 ftp/tcp











                            -37-


For more details on ipfilter's internal proxies, see section
3.6

8.3.  Assorted Kernel Variables

     There  are some useful kernel tunes that either need to
be set for ipf to function, or are just generally  handy  to
know  about for building firewalls.  The first major one you
must set is to enable IP Forwarding, otherwise ipf  will  do
very little, as the underlying ip stack won't actually route
packets.

IP Forwarding:

openbsd:
     net.inet.ip.forwarding=1


freebsd:
     net.inet.ip.forwarding=1


netbsd:
     net.inet.ip.forwarding=1


solaris:
     ndd -set /dev/ip ip_forwarding 1

Ephemeral Port Adjustment:

openbsd:
     net.inet.ip.portfirst = 25000


freebsd:
     net.inet.ip.portrange.first  =  25000  net.inet.ip.por-
     trange.last = 49151


netbsd:
     net.inet.ip.anonportmin = 25000 net.inet.ip.anonportmax
     = 49151


solaris:
     ndd -set /dev/tcp tcp_smallest_anon_port 25000
     ndd -set /dev/tcp tcp_largest_anon_port 65535

Other Useful Values:

openbsd:
     net.inet.ip.sourceroute = 0
     net.inet.ip.directed-broadcast = 0









                            -38-


freebsd:
     net.inet.ip.sourceroute=0
     net.ip.accept_sourceroute=0


netbsd:
     net.inet.ip.allowsrcrt=0
     net.inet.ip.forwsrcrt=0
     net.inet.ip.directed-broadcast=0
     net.inet.ip.redirect=0


solaris:
     ndd -set /dev/ip ip_forward_directed_broadcasts 0
     ndd -set /dev/ip ip_forward_src_routed 0
     ndd -set /dev/ip ip_respond_to_echo_broadcast 0

In addition, freebsd has some ipf specific sysctl variables.

     net.inet.ipf.fr_flags: 0
     net.inet.ipf.fr_pass: 514
     net.inet.ipf.fr_active: 0
     net.inet.ipf.fr_tcpidletimeout: 864000
     net.inet.ipf.fr_tcpclosewait: 60
     net.inet.ipf.fr_tcplastack: 20
     net.inet.ipf.fr_tcptimeout: 120
     net.inet.ipf.fr_tcpclosed: 1
     net.inet.ipf.fr_udptimeout: 120
     net.inet.ipf.fr_icmptimeout: 120
     net.inet.ipf.fr_defnatage: 1200
     net.inet.ipf.fr_ipfrttl: 120
     net.inet.ipf.ipl_unreach: 13
     net.inet.ipf.ipl_inited: 1
     net.inet.ipf.fr_authsize: 32
     net.inet.ipf.fr_authused: 0
     net.inet.ipf.fr_defaultauthage: 600




9.  Fun with ipf!

     This section doesn't necessarily teach you anything new
about ipf, but it may raise an issue or two that you haven't
yet  thought  up  on your own, or tickle your brain in a way
that  you  invent  something  interesting  that  we  haven't
thought of.

9.1.  Localhost Filtering

     A  long  time ago at a university far, far away, Wietse
Venema created the tcp-wrapper package, and ever since, it's
been  used  to add a layer of protection to network services
all over the world.  This is good.  But,  tcp-wrappers  have









                            -39-


flaws.  For starters, they only protect TCP services, as the
name suggests.   Also, unless  you  run  your  service  from
inetd, or you have specifically compiled it with libwrap and
the appropriate hooks, your service isn't protected.    This
leaves  gigantic  holes in your host security.   We can plug
these up by using ipf on the local host.   For  example,  my
laptop  often gets plugged into or dialed into networks that
I don't specifically trust, and so, I use the following rule
set:

     pass in quick on lo0 all
     pass out quick on lo0 all

     block in log all
     block out all

     pass in quick proto tcp from any to any port = 113 flags S keep state
     pass in quick proto tcp from any to any port = 22 flags S keep state
     pass in quick proto tcp from any port = 20 to any port 39999 >< 45000 flags S keep state

     pass out quick proto icmp from any to any keep state
     pass out quick proto tcp/udp from any to any keep state keep frags

It's  been  like  that for quite a while, and I haven't suf-
fered any pain or anguish as a result of having  ipf  loaded
up all the time.  If I wanted to tighten it up more, I could
switch to using the NAT ftp proxy and I could  add  in  some
rules to prevent spoofing.   But even as it stands now, this
box is far more restrictive about what it  presents  to  the
local  network and beyond than the typical host does.   This
is a good thing if you happen to run a machine that allows a
lot  of  users on it, and you want to make sure  one of them
doesn't happen to start up a service  they  wern't  supposed
to.   It won't stop a malicious hacker with root access from
adjusting your ipf rules and starting a service anyway,  but
it  will keep the "honest" folks honest, and your weird ser-
vices safe, cozy and warm even on a malicious  LAN.   A  big
win, in my opinion.   Using local host filtering in addition
to a somewhat less-restrictive "main firewall"  machine  can
solve  many  performance  issues as well as political night-
mares like "Why doesn't ICQ work?" and "Why can't  I  put  a
web  server  on  my  own workstation! It's MY WORKSTATION!!"
Another very big win.  Who says you can't have security  and
convienence at the same time?

9.2.  What Firewall?  Transparent filtering.

     One  major  concern  in  setting  up  a firewall is the
integrity of the firewall itself.  Can somebody  break  into
your  firewall,  thereby  subverting its ruleset?  This is a
common problem administrators must face,  particularly  when
they're  using  firewall  solutions  on top of their Unix/NT
machines.  Some use it as an arguement for blackbox hardware
solutions,  under  the flawed notion that inherent obscurity









                            -40-


of their closed system increases their security.  We have  a
better way.

     Many network admins are familiar with the common ether-
net bridge.  This is a device  that  connects  two  separate
ethernet  segments  to make them one.  An ethernet bridge is
typically used to connect separate buildings, switch network
speeds,  and extend maximum wire lengths.  Hubs and switches
are common bridges, sometimes they're just 2 ported  devices
called   repeaters.   Recent  versions  of  Linux,  OpenBSD,
NetBSD, and FreeBSD include code to convert $1000  PCs  into
$10  bridges,  too!  What all bridges tend to have in common
is that though they  sit  in  the  middle  of  a  connection
between two machines, the two machines don't know the bridge
is there.  Enter ipfilter and OpenBSD.

     Ethernet bridging takes place  at  Layer2  on  the  ISO
stack.   IP  takes  place on Layer3.  IP Filter in primarily
concerned with Layer3, but dabbles in Layer2 by working with
interfaces.   By  mixing  IP  filter  with  OpenBSD's bridge
device, we can create a firewall that is both invisible  and
unreachable.   The  system  needs  no IP address, it doesn't
even need to reveal its ethernet address.  The only telltale
sign that the filter might be there is that latency is some-
what higher than a piece of cat5 would normally make it, and
that  packets  don't seem to make it to their final destina-
tion.

     The setup for this sort of ruleset is surprisingly sim-
ple,  too.   In  OpenBSD,  the  first bridge device is named
bridge0.  Say we have two ethernet cards in our  machine  as
well,  xl0 and xl1.  To turn this machine into a bridge, all
one need do is enter the following three commands:

    brconfig bridge0 add xl0 add xl1 up
    ifconfig xl0 up
    ifconfig xl1 up

At ths point, all traffic ariving on xl0 is sent out xl1 and
all  traffic  on xl1 is sent out xl0.  You'll note that nei-
ther interface has been assigned an IP address,  nor  do  we
need assign one.  All things considered, it's likely best we
not add one at all.

     Rulesets behave essentially the  as  the  always  have.
Though  there  is a bridge0 interface, we don't filter based
on it.  Rules continue  to  be  based  upon  the  particular
interface  we're  using,  making  it important which network
cable is plugged into which network card in the back of  the
machine.   Let's  start  with some basic filtering to illis-
trate what's happened.  Assume the network used to look like
this:











                            -41-


  20.20.20.1 <---------------------------------> 20.20.20.0/24 network hub

That  is,  we  have  a router at 20.20.20.1 connected to the
20.20.20.0/24 network.  All packets from  the  20.20.20.0/24
network  go  through  20.20.20.1 to get to the outside world
and vice versa.  Now we add the Ipf Bridge:

  20.20.20.1 <-------/xl0 IpfBridge xl1/-------> 20.20.20.0/24 network hub

We also have the following ruleset loaded on  the  IpfBridge
host:

    pass in  quick  all
    pass out quick  all

With  this ruleset loaded, the network is functionally iden-
tical.  As far as the 20.20.20.1 router is concerned, and as
far  as  the 20.20.20.0/24 hosts are concerned, the two net-
work diagrams are identical.  Now let's change  the  ruleset
some:

    block in quick on xl0 proto icmp
    pass  in  quick all
    pass  out quick all

Still,  20.20.20.1  and  20.20.20.0/24  think the network is
identical, but if 20.20.20.1 attempts to ping 20.20.20.2, it
will  never get a reply.  What's more, 20.20.20.2 won't even
get the packet in the first place.  IPfilter will  intercept
the  packet before it even gets to the other end of the vir-
tual wire.  We can put a  bridged  filter  anywhere.   Using
this  method  we can shrink the network trust circle down an
individual host level (given enough ethernet cards:-)

     Blocking icmp from the world seems kind of silly, espe-
cially  if  you're a sysadmin and like pinging the world, to
traceroute, or to resize your MTU.  Let's construct a better
ruleset  and  take  advantage of the original key feature of
ipf: stateful inspection.

    pass  in quick on xl1 proto tcp  keep state
    pass  in quick on xl1 proto udp  keep state
    pass  in quick on xl1 proto icmp keep state
    block in quick on xl0

In this situation, the 20.20.20.0/24 network  (perhaps  more
aptly  called  the  xl1  network)  can now reach the outside
world, but the outside world can't reach it,  and  it  can't
figure out why, either.  The router is accessible, the hosts
are active, but the outside world just can't get  in.   Even
if  the  router  itself were compromised, the firewall would
still be active and successful.











                            -42-


     So far, we've been filtering by interface and  protocol
only.   Even  though  bridging  is  concerned layer2, we can
still discriminate based on IP address.  Normally we have  a
few services running, so our ruleset may look like this:

    pass  in quick on xl1 proto tcp  keep state
    pass  in quick on xl1 proto udp  keep state
    pass  in quick on xl1 proto icmp keep state
    block in quick on xl1 # nuh-uh, we're only passing tcp/udp/icmp sir.
    pass  in quick on xl0 proto udp from any to 20.20.20.2/32 port=53 keep state
    pass  in quick on xl0 proto tcp from any to 20.20.20.2/32 port=53 flags S keep state
    pass  in quick on xl0 proto tcp from any to 20.20.20.3/32 port=25 flags S keep state
    pass  in quick on xl0 proto tcp from any to 20.20.20.7/32 port=80 flags S keep state
    block in quick on xl0

Now  we  have  a  network where 20.20.20.2 is a zone serving
name server, 20.20.20.3 is  an  incoming  mail  server,  and
20.20.20.7 is a web server.

     Bridged  IP Filter is not yet perfect, we must confess.

     First,  You'll note that all the rules are setup  using
the  in  direction  instead  of a combination of in and out.
This is because the out direction is presently unimplemented
with  bridging in OpenBSD.  This was originally done to pre-
vent vast performance drops using multiple interfaces.  Work
has  been  done  in  speeding it up, but it remains unimple-
mented.  If you really want this feature, you might try your
hand at working on the code or asking the OpenBSD people how
you can help.

     Second, using IP Filter with bridging makes the use  of
IPF's  NAT features inadvisable, if not downright dangerous.
The first problem is that it would give away that there's  a
filtering  bridge.   The  second  problem  would be that the
bridge has no IP address to masquerade with, which will most
assuredly  lead  to  confusion and perhaps a kernel panic to
boot.  You can, of course, put an IP address on the outbound
interface to make NAT work, but part of the glee of bridging
is thus diminished.

9.2.1.  Using Transparent Filtering to  Fix  Network  Design
Mistakes

     Many  organizations  started  using IP well before they
thought a firewall or a subnet would be a  good  idea.   Now
they  have class-C sized networks or larger that include all
their servers, their  workstations,  their  routers,  coffee
makers,  everything.   The  horror!  Renumbering with proper
subnets, trust levels, filters, and so are in both time con-
suming and expensive.  The expense in hardware and man hours
alone is enough to  make  most  organizations  unwilling  to
really  solve  the  problem,  not  to  mention  the downtime
involved.  The typical problem network looks like this:









                            -43-


    20.20.20.1   router               20.20.20.6   unix server
    20.20.20.2   unix server          20.20.20.7   nt workstation
    20.20.20.3   unix server          20.20.20.8   nt server
    20.20.20.4   win98 workstation    20.20.20.9   unix workstation
    20.20.20.5   intelligent switch   20.20.20.10  win95 workstation

Only it's about 20 times larger and messier  and  frequently
undocumented.   Ideally, you'd have all the trusting servers
in one subnet, all the work- stations in  another,  and  the
network  switches  in a third.  Then the router would filter
packets between the subnets, giving the workstations limited
access  to  the servers, nothing access to the switches, and
only the sysadmin's workstation access to  the  coffee  pot.
I've never seen a class-C sized network with such coherence.
IP Filter can help.

     To start with, we're going to separate the router,  the
workstations,  and  the  servers.  To do this we're going to
need 2 hubs (or switches) which we  probably  already  have,
and  an  IPF  machine with 3 ethernet cards.  We're going to
put all the servers on one hub and all the  workstations  on
the  other.   Normally  we'd  then  connect the hubs to each
other, then to the router.  Instead, we're going to plug the
router  into IPF's xl0 interface, the servers into IPF's xl1
interface, and the workstations into  IPF's  xl2  interface.
Our network diagram looks something like this:

                                                 | 20.20.20.2  unix server
    router (20.20.20.1)              ____________| 20.20.20.3  unix server
     |                              /            | 20.20.20.6  unix server
     |                             /xl1          | 20.20.20.7  nt server
     ------------/xl0 IPF Bridge <
                                    xl2         | 20.20.20.4  win98 workstation
                                    ____________| 20.20.20.8  nt workstation
                                                 | 20.20.20.9  unix workstation
                                                 | 20.20.20.10 win95 workstation

Where  once there was nothing but interconnecting wires, now
there's a filtering bridge that not a single host  needs  to
be  modified to take advantage of.  Presumably we've already
enabled bridging so the network is behaving  perfectly  nor-
mally.  Further, we're starting off with a ruleset much like
our last ruleset:

    pass  in quick on xl0 proto udp from any to 20.20.20.2/32 port=53 keep state
    pass  in quick on xl0 proto tcp from any to 20.20.20.2/32 port=53 flags S keep state
    pass  in quick on xl0 proto tcp from any to 20.20.20.3/32 port=25 flags S keep state
    pass  in quick on xl0 proto tcp from any to 20.20.20.7/32 port=80 flags S keep state
    block in quick on xl0
    pass  in quick on xl1 proto tcp  keep state
    pass  in quick on xl1 proto udp  keep state
    pass  in quick on xl1 proto icmp keep state
    block in quick on xl1 # nuh-uh, we're only passing tcp/udp/icmp sir.
    pass  in quick on xl2 proto tcp  keep state









                            -44-


    pass  in quick on xl2 proto udp  keep state
    pass  in quick on xl2 proto icmp keep state
    block in quick on xl2 # nuh-uh, we're only passing tcp/udp/icmp sir.

Once again, traffic coming from the router is restricted  to
DNS,  SMTP,  and  HTTP.   At the moment, the servers and the
workstations can exchange traffic freely.  Depending on what
kind of organization you are, there might be something about
this network dynamic you don't like.  Perhaps you don't want
your  workstations  getting  access  to your servers at all?
Take the xl2 ruleset of:

    pass  in quick on xl2 proto tcp  keep state
    pass  in quick on xl2 proto udp  keep state
    pass  in quick on xl2 proto icmp keep state
    block in quick on xl2 # nuh-uh, we're only passing tcp/udp/icmp sir.

And change it to:

    block in quick on xl2 from any to 20.20.20.0/24
    pass  in quick on xl2 proto tcp  keep state
    pass  in quick on xl2 proto udp  keep state
    pass  in quick on xl2 proto icmp keep state
    block in quick on xl2 # nuh-uh, we're only passing tcp/udp/icmp sir.

Perhaps you want them to just get to the servers to get  and
send their mail with IMAP?  Easily done:

    pass  in quick on xl2 proto tcp from any to 20.20.20.3/32 port=25
    pass  in quick on xl2 proto tcp from any to 20.20.20.3/32 port=143
    block in quick on xl2 from any to 20.20.20.0/24
    pass  in quick on xl2 proto tcp  keep state
    pass  in quick on xl2 proto udp  keep state
    pass  in quick on xl2 proto icmp keep state
    block in quick on xl2 # nuh-uh, we're only passing tcp/udp/icmp sir.

Now  your  workstations  and  servers are protected from the
outside world, and the servers are protected from your work-
stations.

     Perhaps the opposite is true, maybe you want your work-
stations to be able to get to the servers, but not the  out-
side  world.   After all, the next generation of exploits is
breaking the clients, not the servers.  In this case,  you'd
change the xl2 rules to look more like this:

    pass  in quick on xl2 from any to 20.20.20.0/24
    block in quick on xl2

Now  the  servers  have free reign, but the clients can only
connect to the servers.  We might want to  batten  down  the
hatches on the servers, too:

    pass  in quick on xl1 from any to 20.20.20.0/24









                            -45-


    block in quick on xl1

With  the  combination of these two, the clients and servers
can talk to each other, but neither can access  the  outside
world  (though the outside world can get to the few services
from earlier).  The whole ruleset would look something  like
this:

    pass  in quick on xl0 proto udp from any to 20.20.20.2/32 port=53 keep state
    pass  in quick on xl0 proto tcp from any to 20.20.20.2/32 port=53                                                              flags S keep state
    pass  in quick on xl0 proto tcp from any to 20.20.20.3/32 port=25                                                              flags S keep state
    pass  in quick on xl0 proto tcp from any to 20.20.20.7/32 port=80                                                              flags S keep state
    block in quick on xl0
    pass  in quick on xl1 from any to 20.20.20.0/24
    block in quick on xl1
    pass  in quick on xl2 from any to 20.20.20.0/24
    block in quick on xl2

So  remember,  when  your  network  is  a  mess of twisty IP
addresses and machine classes, transparent filtered  bridges
can  solve  a problem that would otherwise be lived with and
perhaps someday exploited.

9.3.  Drop-Safe Logging With dup-to and to.

     Until now, we've been using the filter to drop packets.
Instead  of dropping them, let's consider passing them on to
another system that can do something useful with this infor-
mation  beyond  the logging we can perform with ipmon.   Our
firewall system, be it a bridge or a  router,  can  have  as
many  interfaces as we can cram into the system.  We can use
this information to create a "drop-safe" for our packets.  A
good  example  of  a  use  for this would be to implement an
intrusion detection network.   For  starters,  it  might  be
desirable  to  hide  the presence of our intrusion detection
systems from our real network so that we can keep them  from
being detected.

     Before we get started, there are some operational char-
acteristics that we need to make note of.  If  we  are  only
going to deal with blocked packets, we can use either the to
keyword or the fastroute keyword. (We'll cover  the  differ-
ences  between  these two later)  If we're going to pass the
packets like we normally would, we need to make  a  copy  of
the packet for our drop-safe log with the dup-to keyword.

9.3.1.  The dup-to Method

     If, for example, we wanted to send a copy of everything
going out the xl3 interface off to our drop-safe network  on
ed0, we would use this rule in our filter list:

     pass out on xl3 dup-to ed0 from any to any










                            -46-


You  might also have a need to send the packet directly to a
specific IP address on your  drop-safe  network  instead  of
just  making  a  copy of the packet out there and hoping for
the best.  To do this, we modify our rule slightly:

     pass out on xl3 dup-to ed0:192.168.254.2 from any to any

But be  warned  that  this  method  will  alter  the  copied
packet's  destination address, and may thus destroy the use-
fulness of the log.  For  this  reason,  we  recommend  only
using  the  known  address method of logging when you can be
certain that the address that you're logging to  corresponds
in  some  way  to  what  you're logging for (e.g.: don't use
"192.168.254.2" for logging for both  your  web  server  and
your mail server, since you'll have a hard time later trying
to figure out which system was the target of a specific  set
of packets.)

     This  technique  can  be  used quite effectively if you
treat an IP Address on your drop-safe network  in  much  the
same  way that you would treat a Multicast Group on the real
internet. (e.g.: "192.168.254.2" could be  the  channel  for
your  http  traffic  analysis system, "23.23.23.23" could be
your channel for telnet sessions, and so on.)     You  don't
even need to actually have this address set as an address or
alias on any  of  your  analysis  systems.   Normally,  your
ipfilter  machine  would need to ARP for the new destination
address (using dup-to ed0:192.168.254.2  style,  of  course)
but  we  can avoid that issue by creating a static arp entry
for this "channel" on our ipfilter system.

     In general, though, dup-to ed0 is all that is  required
to  get  a new copy of the packet over to our drop-safe net-
work for logging and examination.

9.3.2.  The to Method

     The dup-to method  does  have  an  immediate  drawback,
though.   Since  it  has  to  make  a copy of the packet and
optionally modify it for its new destination, it's going  to
take  a while to complete all this work and be ready to deal
with the next packet coming in to the ipfilter system.

     If we don't care about passing the packet to its normal
destination  and  we  were  going to block it anyway, we can
just use the to keyword to push this packet past the  normal
routing  table  and force it to go out a different interface
than it would normally go out.

     block in quick on xl0 to ed0 proto tcp from any to any port < 1024

we use block quick for to interface  routing,  because  like
fastroute,  the  to  interface code will generate two packet
paths through ipfilter when used with pass, and likely cause









                            -47-


your system to panic.



10.   Bogus Network Filtering, the ultimate in current anti-
spoofing technology.

     We've spent a little bit of time tracking down the cur-
rent vast tracts of IP address space that have been reserved
by the IANA for various reasons, or are otherwise  not  cur-
rently in use at the time this document was written.   Since
none of these address ranges should  be  in  use  currently,
there  should  be no legitimate reason to ever see them as a
source address, or to send them  traffic  as  a  destination
address, right?   Right!

     So without further ado, the complete list of bogus net-
works:

     #
     # s/OUTSIDE/outside-interface (eg: fxp0)
     # s/MYNET/network-cidr-address (eg: 1.2.3.0/24)
     #
     block in on OUTSIDE all
     block in quick on OUTSIDE from 0.0.0.0/7 to any
     block in quick on OUTSIDE from 2.0.0.0/8 to any
     block in quick on OUTSIDE from 5.0.0.0/8 to any
     block in quick on OUTSIDE from 10.0.0.0/8 to any
     block in quick on OUTSIDE from 23.0.0.0/8 to any
     block in quick on OUTSIDE from 27.0.0.0/8 to any
     block in quick on OUTSIDE from 31.0.0.0/8 to any
     block in quick on OUTSIDE from 67.0.0.0/8 to any
     block in quick on OUTSIDE from 68.0.0.0/6 to any
     block in quick on OUTSIDE from 72.0.0.0/5 to any
     block in quick on OUTSIDE from 80.0.0.0/4 to any
     block in quick on OUTSIDE from 96.0.0.0/3 to any
     block in quick on OUTSIDE from 127.0.0.0/8 to any
     block in quick on OUTSIDE from 128.0.0.0/16 to any
     block in quick on OUTSIDE from 128.66.0.0/16 to any
     block in quick on OUTSIDE from 169.254.0.0/16 to any
     block in quick on OUTSIDE from 172.16.0.0/12 to any
     block in quick on OUTSIDE from 191.255.0.0/16 to any
     block in quick on OUTSIDE from 192.0.0.0/16 to any
     block in quick on OUTSIDE from 192.168.0.0/16 to any
     block in quick on OUTSIDE from 197.0.0.0/8 to any
     block in quick on OUTSIDE from 201.0.0.0/8 to any
     block in quick on OUTSIDE from 204.152.64.0/23 to any
     block in quick on OUTSIDE from 224.0.0.0/3 to any
     block in quick on OUTSIDE from MYNET to any
     # Your pass rules come here...

     block out on OUTSIDE all
     block out quick on OUTSIDE from !MYNET to any
     block out quick on OUTSIDE from MYNET to 0.0.0.0/7









                            -48-


     block out quick on OUTSIDE from MYNET to 2.0.0.0/8
     block out quick on OUTSIDE from MYNET to 5.0.0.0/8
     block out quick on OUTSIDE from MYNET to 10.0.0.0/8
     block out quick on OUTSIDE from MYNET to 23.0.0.0/8
     block out quick on OUTSIDE from MYNET to 27.0.0.0/8
     block out quick on OUTSIDE from MYNET to 31.0.0.0/8
     block out quick on OUTSIDE from MYNET to 67.0.0.0/8
     block out quick on OUTSIDE from MYNET to 68.0.0.0/6
     block out quick on OUTSIDE from MYNET to 72.0.0.0/5
     block out quick on OUTSIDE from MYNET to 80.0.0.0/4
     block out quick on OUTSIDE from MYNET to 96.0.0.0/3
     block out quick on OUTSIDE from MYNET to 127.0.0.0/8
     block out quick on OUTSIDE from MYNET to 128.0.0.0/16
     block out quick on OUTSIDE from MYNET to 128.66.0.0/16
     block out quick on OUTSIDE from MYNET to 169.254.0.0/16
     block out quick on OUTSIDE from MYNET to 172.16.0.0/12
     block out quick on OUTSIDE from MYNET to 191.255.0.0/16
     block out quick on OUTSIDE from MYNET to 192.0.0.0/16
     block out quick on OUTSIDE from MYNET to 192.168.0.0/16
     block out quick on OUTSIDE from MYNET to 197.0.0.0/8
     block out quick on OUTSIDE from MYNET to 201.0.0.0/8
     block out quick on OUTSIDE from MYNET to 204.152.64.0/23
     block out quick on OUTSIDE from MYNET to 224.0.0.0/3
     # Your pass rules come here...

If you're going to use these, we  suggest  that  you  become
familiar  with  whois.arin.net and keep an occasional eye on
these, as the IANA isn't going to notify you when they allo-
cate  one  of  these to a new corporation or something.  You
have been warned.

     We'd also like to thank  Frank  DiGennaro  <fsd@server-
vault.com> for greatly contributing to this filter list.