[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    RE: Key references on ipfilter rules
From:       Joseph Judge <joej () joesmac ! ultranet ! com>
Date:       1997-07-25 22:59:10
[Download RAW message or body]


Robert -

I'll post my rulesets (stripped of actual LAN/host addresses) this 
weekend if it will help. I just have no idea how good/bad they are
... but it can act as a straw man, I guess.

Here is the basic concept of what I have and how I wrote the rules:

Internet comes into a router via a T3 ... that router has nothing
on it in terms of access lists and is managed by some network
group or the ISP. Beneath that router is my perimeter packet
filter (ip filter 3.1.11ish).  This top-side packet filter restricts
access farther in ... but allows unrestricted connections up
towards the Internet from my cluster. The rules are written 
with no packet filtering "out" of an interface ...but with 
all the rules being done "in"  This packet filter has 3 interfaces:
something like le0 down towards the firewall cluster, le1 up
towards the Internet and le2 down to a protected LAN where
web servers, ftp archives, real-audio servers, etc live.

(I also have an ip-filter machine on the inside of my firewall
cluster, protecting it from the company and protecting the
company from it -- not discussed here. It uses different
rule sets and philosophy).

The rules start at the top with some "block in log quick" 
rules that ditch options, short frags, loose and strict 
source routing  ... and a chunk of rules that do the
anti-spoofing. These anti-spoofing rules list all my 
company nets as "block in quick log" on that Internet
interface (I NEVER expect my inside nets to be on the
outside of this perimeter filter). I also have rules that say
the loopback address (127.0.0.0/8) is not supposed to
be coming in a real interface.

I've also had to handle ident and netbios silliness up 
here with quick rules. With ident/auth, I send back 
a return-rst so the auth checks don't just time-out.
With netbios, I just "block in quick" w/o a log since
they flood my logs (down below in the "block in 
log from any to any" rule) if I don't.

There is one rule for the support of established packets
"pass in proto tcp from any to any flags A/A"

The next major section of my rules set the basic "stance"
with "block in log from any to any" and "pass out from any
to any" (yes I know that the pass is the default, but I like
the rules to explicitly mention these things). These are  followed 
by specific rules to support the stance for that packet filter. 
These would be:
"pass out from any to any" (I don't filter outbound on interfaces)
"pass in on le0 from untrusted_lan/24 to any" (my firewall lan
can go through w/o filtering
"pass in on le2 from protected_lan/24 to any" (web server lan can
also go through to anywhere since I control those endpoints)

I have a long section following that listing all the "pass" rules.
I support some basic ICMP:
pass in on le1 proto icmp from any to any icmp-type echorep (like that)
I used to be more anal about what ICMP I let through ... but am
getting less so these days.

There is a section for supported services on the protected lan:
"pass in on le1 proto tcp from any to protected_lan/24 port = http"
"pass in on le1 proto tcp from any to protected_lan/24 port = realaudio"
... etc, etc, 

There are not many services that I support directly *at* the firewall 
(application level firewall) except some encrypted services (Smart
Gate) and some proprietary company client-server app:
"pass in on le1 proto tcp from any to untrusted_lan/24 port = sgate"

I do have to put supporting rules there for ntp, dns, and some others,
I think.

As you can see ... I don't do much with stateful-ness. I used to, but
I want to run 2 ip-filter machines in parallel (async) --- but have no
way to share state information (there is a programming project!)
between the 2 filters.

I really don't write my rules for the whole LAN ... like I explained above.
I have switched ethernet hubs that have IP addresses, packet filters and
other infrastructure equiptment on the untrusted_lan and protected_lan.
One might be a centralized authentication server that only chats with 
the web servers, ftp servers, firewall gateway, etc.  So, I place my
servers in IP address ranges. This helps a LOT when writing rules.
For example: 
my untrusted lan has etherswitches and net components from
IP address 1 to 31, 
security auth servers, etc are from 32-63
firewall gateways (gauntlets?) are from 64-127
web servers, etc may be from 128-254

Soooo... I can write my "let smartgate through" to ONLY hit the
gateways with 
"pass in on le1 proto tcp from any to aaa.bbb.ccc.64/26 port = smartgate"
and the web servers with:
"pass in on le1 proto tcp from any to xxx.yyy.zzz.128/25 port = http"

I use a netmask calculator at the first link off of the:
http://www.aetc.af.mil/AETC-NetMgmt/bncc-tools.html 
page.

Is there a need for me to post the rulesets ?

	---joe



----------
From: 	Robert Nelson[SMTP:robert.nelson@heartlab.com]
Sent: 	Friday, July 25, 1997 10:44 AM
To: 	IPfilter Mailing List
Subject: 	Key references on ipfilter rules

Hello:

I hate to ask such a question to the list, but I have been unable to
find an answer anywhere else.  I was wondering if anyone could point me
to helpful references for creating one's rule set.  I have read all the
man pages and through all the examples that come with ipfilter.  Rather
I am looking for the definitive document that not only lists the myriad
of rules available and there use, but gives one a sense of why and in
what situations you would want such a rule set.

I am looking for something more in the spirit of:

	"When setting up a bastion host that has two interface, one on the
protected network and one on the internet, on which you want to disallow
access from any host on the internet, but allow full access from
internal hosts to the internet you will want to think about using a rule
set similar to this... because... with the caveats..."

Does any such work exist?

Regards,

Rob
-- 

Robert Nelson
Email: Robert.Nelson@heartlab.com




[prev in list] [next in list] [prev in thread] [next in thread]