From Firewalls-Owner  Fri Jan 15 10:43:15 1993
Return-Path: Firewalls-Owner 
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA03460; Fri, 15 Jan 93 10:43:15 PST
Received: from norman.li.cubic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA03453; Fri, 15 Jan 93 10:42:58 PST
Received: by norman.li.cubic.com (5.67/1.34a)
	id AA01395; Fri, 15 Jan 93 13:43:19 -0500
Date: Fri, 15 Jan 93 13:43:19 -0500
From: mischler@Cubic.COM (Dave Mischler)
Message-Id: <9301151843.AA01395@norman.li.cubic.com>
To: mischler@Cubic.COM, FireWalls@GreatCircle.COM
Subject: Cheap Packet Filtering
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk

I have added a packet filtering implementation to Phil Karn's KA9Q
software (930104 version) based on many of the ideas in Brent
Chapman's paper, "Network (In)Security Through IP Packet Filtering".
I want to make this software generally available both because I think
it is useful and because I want beta testers and/or better ideas.  I
will place no restrictions on the code, but the copyrights of Phil
Karn and other authors of the KA9Q software may not be infringed.  The
last time I looked the shareware fee for commercial sites was $50 for
the KA9Q package (it is free to schools and ham radio operators, or
for evaluation purposes).

I would like an anonymous FTP site on which to put the source and
executables, as well as some feedback from testers.

I use this software to provide a demand-dial router between an
extended LAN and an Internet service provider on a SLIP link with a
V.32bis/V.42bis modem at a DTE speed of 57600 Kbps.  My target
hardware is a PC clone with a 16 MHz 286 CPU, a serial card with
NS16550As, and an ethernet card.  I compiled the software with Borland
C++ V3.1.

I have tested the code and it seems to behave.  I am using it for my
Internet connection right now.  There may be bugs, and it may be
possible to improve the performance by coding changes.  I WILL NOT BE
RESPONSIBLE FOR ANY PROBLEMS YOU MAY HAVE WITH THIS SOFTWARE, OR AS A
CONSEQUENCE OF USING THIS SOFTWARE, NOR WILL I BE RESPONSIBLE FOR
FIXING OR IMPROVING THE SOFTWARE.

The forms of the IP filter command are

  ip filter <interface> delete
  ip filter <interface> list
  ip filter <interface> deny <in/out> <type> <source> <destination>
  ip filter <interface> permit <in/out> <type> <source> <destination>

The <interface> is the name of the interface that was assigned when it
was attached.

The "delete" command will delete the entire filter set for an
interface.

The "list" command will display the entire filter set for an
interface.

The "deny" command will append a filter entry to the filter set for an
interface.  The direction of the packet to be disallowed is from the
perspective of the router running the filtering process (i.e. "in"
implies that the packet arrived on the specified interface).  The type
field specifies the packet category to be disallowed.  The source and
destination allow IP addresses, address masks, and ports to be
specified.

The "permit" command is identical to the "deny" command except that it
causes packets that meet the specified criteria to be allowed.

The legal packet types are shown in the following table.

   TYPE		MEANING

   *		Any IP packet.

   icmp		Any ICMP packet.

   icmprd	An ICMP REDIRECT packet.

   icmpxrd	Any ICMP packet except a REDIRECT.

   tcp		Any TCP packet.

   tcpsyn	A TCP packet with the SYN bit set and the ACK bit
		clear.  This implies an attempt to open a new TCP
		connection.

   tcpxsyn	Any TCP packet that has the SYN bit clear or the
		ACK bit set.  This implies a packet on an existing
		connection.

   udp		Any UDP packet.


A source or destination specification takes the form
[!]address[/bits][:port], where address is an IP address in dotted
octet form, or a resolvable domain name, or "*".  The use of "*" for
the address implies both an address and address mask of all zeroes.
If you specify "/bits" on an address you are specifying how many of
the high order bits of the address are significant.  For example, to
compare only the network part of a class B address one could use /16.
The use of "!" before an address means that all addresses except those
specified by the address and mask match the specification. Finally, if
a port number is specified then the filter entry will only match
packets with the appropriate port numbers (this is only meaningful if
one of the tcp, tcpsyn, tcpxsyn or udp packet types is specified).

The list of filter entries is scanned in the order they were entered
until a match is reached, then the action specified in the filter
entry (i.e. deny or permit) will be taken.  If a packet does not match
any filter entries then it will be denied by default.  Note that the
input and output filter sets are independent and that, for example, if
no output entries exist, then all outgoing packets would be permitted.

If an IP datagram is fragmented then filters only apply to the first
fragment (all subsequent fragments are permitted).  Incoming and
outgoing filters are checked even if source routing is specified.

Here is a filter set that I made up for a SLIP link to the Internet
from my company's class B network.  The line numbers are only for
reference purposes.

1 ip filter sl0 permit in tcpxsyn !cubic.com/16 cubic.com/16
2 ip filter sl0 permit in tcpsyn  !cubic.com/16 cubic.com/16:25
3 ip filter sl0 permit in tcpsyn  ns2.psi.net   ns.cubic.com:53
4 ip filter sl0 permit in tcpsyn  !cubic.com/16 cubic.com:79
5 ip filter sl0 permit in udp !cubic.com/16:53  cubic.com/16:53
6 ip filter sl0 permit in udp !cubic.com/16:123 cubic.com/16:123
7 ip filter sl0 permit in icmpxrd !cubic.com/16 cubic.com/16
8 ip filter sl0 permit out *      cubic.com/16  !cubic.com/16

Line 1 permits TCP packets for established connections.  It disallows
attempts to spoof internal addresses from outside (the other filter
entries that allow arbitrary hosts also do this).  There is probably
a performance benefit from putting this rule first.

Line 2 permits new SMTP connections to be opened on any internal
machine.

Line 3 permits ns2.psi.net to perform DNS zone transfers from
ns.cubic.com.

Line 4 permits new FINGER connections to cubic.com.

Line 5 permits UDP packets for DNS.

Line 6 permits UDP packets for NTP.

Line 7 permits ICMP packets except redirects.

Line 8 prevents packets destined to subnets for which there are no
routes from cycling between our router and the Internet provider's
until the time-to-live expires.


Dave Mischler
mischler@cubic.com

From Firewalls-Owner  Mon Jan 18 16:11:27 1993
Return-Path: Firewalls-Owner 
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA08689; Mon, 18 Jan 93 16:11:27 PST
Received: from norman.li.cubic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA08666; Mon, 18 Jan 93 16:11:05 PST
Received: by norman.li.cubic.com (5.67/1.34a)
	id AA01235; Mon, 18 Jan 93 19:11:04 -0500
Date: Mon, 18 Jan 93 19:11:04 -0500
From: mischler@Cubic.COM (Dave Mischler)
Message-Id: <9301190011.AA01235@norman.li.cubic.com>
To: FireWalls@GreatCircle.COM, mischler@Cubic.COM
Subject: Re: Cheap Packet Filtering
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk

Thanks to Jim Stine, my packet filtering modifications to KA9Q are
available for anonymous FTP from stealth.logiconultra.com in
/pub/dm930118.*.  An updated description, an executable, and a zip
file with all needed sources are included.  I would love to receive
bug reports, success stories, questions and constructive criticism.

Dave Mischler
mischler@cubic.com

From Firewalls-Owner  Fri Feb 12 16:46:59 1993
Return-Path: Firewalls-Owner 
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA28772; Fri, 12 Feb 93 16:46:59 GMT
Received: from shiva1.cac.washington.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA28763; Fri, 12 Feb 93 08:46:40 PST
Received: by shiva1.cac.washington.edu
	(5.65/UW-NDC Revision: 2.27 ) id AA15568; Fri, 12 Feb 93 08:46:50 -0800
Date: Fri, 12 Feb 1993 08:44:54 -0800 (PST)
From: Bob Williams <bobw@cac.washington.edu>
Subject: Re: IP encapsulation in IP
To: enge@almaden.ibm.com
Cc: firewalls@GreatCircle.COM
In-Reply-To: <9302110244.AA18183@mycroft.GreatCircle.COM>
Message-Id: <Pine.3.81.9302120853.G12786-9100000@shiva1.cac.washington.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk

On Wed, 10 Feb 1993 enge@almaden.ibm.com wrote:
> I am looking for products that will encapsulate IP in IP thus making a
> secure IP link over another unsecure network.  I think the Karl Bridge
> does this but am also looking for others.

Phil Karn's KA9Q NOS supports ip encapsulation aka tunneling. 

--Bob



From Firewalls-Owner  Sat Feb 13 23:03:29 1993
Return-Path: Firewalls-Owner 
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA02575; Sat, 13 Feb 93 23:03:29 GMT
Received: from ic.co.at by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA02568; Sat, 13 Feb 93 15:03:03 PST
Received: by ic.co.at id AA04638
  (5.65c/hp4at for firewalls@greatcircle.com); Sun, 14 Feb 1993 00:02:45 +0100
Message-Id: <199302132302.AA04638@ic.co.at>
Subject: Re: IP encapsulation in IP
To: bobw@cac.washington.edu (Bob Williams)
Date: Sun, 14 Feb 1993 00:02:33 +0100 (MET)
Cc: enge@almaden.ibm.com, firewalls@GreatCircle.COM
In-Reply-To: <Pine.3.81.9302120853.G12786-9100000@shiva1.cac.washington.edu> from "Bob Williams" at b 12, 93 08:44:54 am
From: Michael Haberler <mah@ic.co.at>
Reply-To: mah@ic.co.at
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 680       
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk

> 
> On Wed, 10 Feb 1993 enge@almaden.ibm.com wrote:
> > I am looking for products that will encapsulate IP in IP thus making a
> > secure IP link over another unsecure network.  I think the Karl Bridge
> > does this but am also looking for others.
> 
> Phil Karn's KA9Q NOS supports ip encapsulation aka tunneling. 
> 

There is such a pseudo interface for SunOS by Francis.Dupont@inria.fr. 

Note that the KA9Q tunnel device is not compatible with the RFC124? method
which the Sun driver implements.

-michael

-- 
Michael Haberler 			mah@eunet.co.at
EUnet Austria Ltd
A-1010 Vienna, Austria, Schottenring 33
Tel: +43 (1) 346184                             fax: +43 (1) 3104462

From Firewalls-Owner  Mon May 31 01:28:27 1993
Return-Path: Firewalls-Owner 
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA16710; Mon, 31 May 93 01:28:27 GMT
Received: from norman.li.Cubic.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA16699; Sun, 30 May 93 18:28:16 PDT
Received: by norman.li.Cubic.COM (5.67/1.34a)
	id AA19542; Sun, 30 May 93 21:29:46 -0400
Date: Sun, 30 May 93 21:29:46 -0400
From: mischler@Cubic.COM (Dave Mischler)
Message-Id: <9305310129.AA19542@norman.li.Cubic.COM>
To: uworld!uucp@uunet.uu.net
Cc: firewalls@GreatCircle.COM, mischler@Cubic.COM
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk

In message <9305291711.AA01382@crow.spirit.com> Rik Farrow quoted part
of my initial message announcing the availability of my packet
filtering modifications to KA9Q, and notes that no site name was
provided.

This package now supports filtering by packet type (any, icmp, icmp
redirect, icmp except redirect, tcp, tcp with syn, tcp except with
syn, udp) source and destination address, and source and destination
port ranges.  Filter entry matches are counted, and messages that can
be easily logged by Unix syslogd can be generated based upon filter
entries for permitted and/or denied packets.

At present, the best site to get this software from is ftp.demon.co.uk
in directory /pub/ibmpc/dm930319.  The file dm930319.doc describes the
commands added to KA9Q, and provides sample configuration files.  I
would be interested in hearing from any sites that may want to provide
anonymous FTP access to this software, or anyone who wishes to apply
my changes to another version of KA9Q.

I have never used this package with 2 ethernet cards, but I would be
interested in hearing from anybody who wants to use it that way.  I
know of no technical reasons why it shouldn't work.

Dave Mischler
mischler@cubic.com

From Firewalls-Owner  Tue Jun  1 15:09:25 1993
Return-Path: Firewalls-Owner 
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA22180; Tue, 1 Jun 93 15:09:25 GMT
Received: from norman.li.Cubic.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA22173; Tue, 1 Jun 93 08:09:16 PDT
Received: by norman.li.Cubic.COM (5.67/1.34a)
	id AA22109; Tue, 1 Jun 93 11:10:46 -0400
Date: Tue, 1 Jun 93 11:10:46 -0400
From: mischler@Cubic.COM (Dave Mischler)
Message-Id: <9306011510.AA22109@norman.li.Cubic.COM>
To: Firewalls@GreatCircle.COM
Subject: Re: (none)
Cc: mischler@Cubic.COM
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk

In message <199306010212.AA15494@ns.oar.net> Kannan Varadhan <kannan@oar.net>
writes:

> I have never been convinced of a lot of these filtering implementations,
> because a lot of these implementations filter on the *assumed* *syntax*
> of the packet, not the *defined* *semantics* of the packet.  They
> assume, for instance, that an IP packet header will always be 20 octets
> long, and the upper layer protocol headers will follow immediately
> afterwards.

Phil Karn's KA9Q package parses and processes all of the IP options
before my filtering extension gets hold of the packet, and leaves a
pointer to the start of the datagram.  The code looks right, but I
can't say that I've tested it much.

> I have never been able to convince myself that one could not construct a
> legal packet and trace with IP options, that could circumvent such an
> implementation, which my gut feeling tells me is very possible.

The only way to settle this is to test the various implementations and
report on them separately (instead of lumping them all in the
untrustworthy category).

Dave Mischler
mischler@cubic.com

From Firewalls-Owner  Wed Jun 16 20:41:14 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA07720; Wed, 16 Jun 93 20:41:14 GMT
Received: from norman.li.Cubic.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
	id AA07713; Wed, 16 Jun 93 13:41:02 PDT
Received: by norman.li.Cubic.COM (5.67/1.34a)
	id AA00357; Wed, 16 Jun 93 16:42:58 -0400
Date: Wed, 16 Jun 93 16:42:58 -0400
From: mischler@Cubic.COM (Dave Mischler)
Message-Id: <9306162042.AA00357@norman.li.Cubic.COM>
To: Firewalls-Digest@GreatCircle.COM, wyatt@dt.wdc.com
Subject: Re: Monitoring outgoing Internet traffic
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk

> Basically, what we would like to do is monitor outgoing packets from our
> local domain going out on the internet.  Does anyone currently do anything
> like the?  Or can someone suggest ways we might monitor such activity?

I am doing something like this using a KA9Q-based router that logs
packets based on filter entries.  I am currently logging all in and
outbound TCP SYN packets (the ones that open connections), as well as
all denied packets, to the system log on a nearby Unix box.  This is
fine for my needs, but I only have a V.32bis/V.42bis dialup
connection.  I have experimented with the software running between two
ethernets, but it was not as robust, nor as fast, as I would have
liked (this is apparently a KA9Q problem).

You can get KA9Q with my packet filtering changes from ftp.demon.co.uk
in /pub/ibmpc/dm930319/dm930319.{doc,exe,zip}.  The doc file includes
sample configuration files.

Dave Mischler
mischler@cubic.com


X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
 Another file downloaded from:                                NIRVANAnet(tm)

 &TOTSE                510/935-5845   Walnut Creek, CA         Taipan Enigma
 Burn This Flag        408/363-9766       San Jose, CA                Zardoz
 realitycheck          415/666-0339  San Francisco, CA    Poindexter Fortran
 Governed Anarchy      510/226-6656        Fremont, CA             Eightball
 New Dork Sublime      805/823-1346      Tehachapi, CA               Biffnix
 Lies Unlimited        801/278-2699 Salt Lake City, UT            Mick Freen
 Atomic Books          410/669-4179      Baltimore, MD               Baywolf
 Sea of Noise          203/886-1441        Norwich, CT             Mr. Noise
 The Dojo              713/997-6351       Pearland, TX               Yojimbo
 Frayed Ends of Sanity 503/965-6747     Cloverdale, OR              Flatline
 The Ether Room        510/228-1146       Martinez, CA Tiny Little Super Guy
 Hacker Heaven         860/456-9266        Lebanon, CT         The Visionary
 The Shaven Yak        510/672-6570        Clayton, CA             Magic Man
 El Observador         408/372-9054        Salinas, CA         El Observador
 Cool Beans!           415/648-7865  San Francisco, CA        G.A. Ellsworth
 DUSK Til Dawn         604/746-5383   Cowichan Bay, BC         Cyber Trollis
 The Great Abyss       510/482-5813        Oakland, CA             Keymaster

                          "Raw Data for Raw Nerves"
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
