[The following is wholesale included; at some point it'll
probably be editted a bit and reformatted... -jhawk ]

                    Frequently Asked Questions
                    contributed by Howard C. Berkowitz
                    PSC International
                    hcb@world.std.com
                       @clark.net   [probably will be my permanent 
                                     personal account]
                    PSC's domain is in mid-setup

Where in the router are access lists applied?

    
    In general, Basic access lists are executed as filters on
outgoing interfaces.  Newer releases of the cisco code, such as
9.21 and 10, do have increased ability to filter on incoming ports.
Certain special cases, such as broadcasts and bridged traffic,
can be filtered on incoming interfaces in earlier releases.
There are also special cases involving console access.

Rules, written as ACCESS-LIST statements, are global for the entire
cisco box; they are activated on individual outgoing interfaces by
ACCESS-GROUP subcommands of the INTERFACE major command.
    Filters are applied after traffic has entered on an incoming
interface and gone through a routing process; traffic that originates in
a router (e.g., telnets from the console port) is not subject to
filtering.

             +-------------------+
             |     GLOBAL        |
             |                   |
             | Routing           |
             | ^  v       Access |
             | ^  v       Lists  |
             +-^--v--------^---v-+
             | ^  v        ^   v |
             | ^  v        ^   v |
A----------->|-|  |>>>>Access  >>----------->B
             |1        Group   2 |
<------------|                   |<-----------
             |                   |
             |                   |
             +-------------------+

    Some types of ``filter,'' using ``filter'' as a broader class than
ACCESS-LIST, can operate on incoming traffic.  For example, the INPUT-
SAP-FILTER used for Novell networks is applied to Service Advertisement
Packets (SAP) seen at incoming interfaces.  In general, incoming
filtering can only be done for ``system'' rather than user traffic.

Rules of thumb in defining access lists.

    First, define what you want to do and in which directions.  An
informal drawing is a good first step.  As opposed to the usual
connectivity drawings among routers, it's often convenient to draw
unidirectional links between routers.
    Second, informally write out your filtering rules.  In general, it
is best to go from most specific to least specific. Modify the order of
writing things to minimize the number of rules needed.
    Third, determine which rules need to be on which routers.
Explicitly consider the direction of flow, and the possible existence of
additional paths that could inadvertently bypass a filter.

Can a cisco router be a ``true'' firewall?

    This depends on the definition of firewall.  Some writers (e.g.,
Gene Spafford in _Practical UNIX Security_) define a firewall as a
host on which an ``inside'' and/or an ``outside'' application process run,
with application-level code linking the two.  For example, a firewall
might provide FTP access to the outside world, but it would not also
provide direct FTP service to the inside world.  To place a file on
the FTP external server, a designated user would explicitly log onto
the FTP server, transfer a file to the server, and log off.  The
firewall prevents direct FTP connectivity between the inside and
outside networks; only indirect, application-level connectivity is
allowed.
   Firewalls of this sort are complemented by chokes, which filter on
network addresses and/or port numbers.  Cisco routers cannot do
application-level control with access control lists.
   Other authors do not distinguish between chokes and filters.  Using
the loose definition that a firewall is anything that selectively blocks
access from the inside to the outside, routers can be firewalls.


IP Specific
-----------

Can the ``operand'' field be used with a protocol keyword of IP to filter
on protocol ID?

    No.  Operand filtering only works for TCP and UDP port numbers.

How can I prevent traffic for a certain Internet application to flow in
one direction but not the other?

    Remember that Internet applications flow from client port to server
port.  Denying traffic from port 23, for example, blocks flow from the
client to the server.

             +-------------------+
             |                   |
A----------->|                   |----------->B
             |1                 2|
<------------|                   |<-----------
             |                   |
             +-------------------+

    If we deny traffic to Port 23 of address B by placing a filter at
interface 2, we have blocked A's ability to telnet to B, but not B's
ability to telnet to A.  A second filter at interface A would be needed
to block telnet in both directions.
    Assume that we only have the filter at interface 2.  Telnets to A
from B will not be affected because the filter at 2 does not check
incoming traffic.
-------

With the arrival of in-bound access lists in 9.21, it should be noted
that both inbound and access lists are about equally efficient, in
case any of you were wondering.


It's worth remembering that there are some kinds of problems
that packet-filtering firewalls are not best suited for. There's
reasonably good information in:

	"Network (in)security through packet filtering"
	ftp://ftp.greatcircle.com/pub/firewalls/pkt_filtering.ps.Z