re: ipfw Configuration (Newbie Question)

[Mike Hoskins <mike () adept org>]

I've used ipfw for awhile, but on FreeBSD...  I'll try to answer what I
can.  According to,

  http://developer.apple.com/internet/macosx/securityintro.html

you can configure OS X' ipfw via GUI or CLI.  I'm familiar with BSD's CLI,
so will explain that option.  You may want to read 'man ipfw' from a
console if you haven't already.  So you have,

                    _____
Internet -----(en0)| OSX |(en1)----- LAN (10/24)
                    -----

Date: Mon, 28 Apr 2003 09:23:41 -0500
From: Donald Tyler <dtyler () frazerbilt com>
> # Allow all loopback traffic.
> IPFW add 1000 allow all from any to any via lo0
> # Allow all outgoing from server
> IPFW add 1000 allow all from me to any out via en1
> IPFW add 1000 allow all from me to any out via en0
> # Allow access for administrator to all ports
> IPFW add allow all from 10.0.0.70 to any in via en1
> # Deny all other packets
> IPFW add 65534 deny all from any to any=20

Each rule needs a unique number.  (Perhaps you know that, I wasn't
sure if you'd simply retyped your rules quickly for the list...)  Also,
outbound packets would go 'out via en0' but 'in via en1'.  (Into the
gateway...)

> 1. The server must allow outgoing requests from my LAN for websites &
> email.
> 2. The server must obviously allow the replies to these requests back
> into the LAN.
> 3. The server is hosting websites, so must allow anyone access to port
> 80.
> 4. The server should allow the administrator (Assume his/her IP is
> 10.0.0.70) full access to the server via [en1] only.

First, I'd like to point out that requiring an internal RFC1918 address
space to access the 'Net through a gateway of this sort generally involves
NAT.  On FreeBSD, ipfw handles firewalling and natd handles NAT.  (NAT
translates internal addresses to the address of your gateway so your
privately-addressed clients can access the global Internet.)  Do you
require NAT, and is it configured?  My FreeBSD boxes use ipfw and natd, so
I will give ipfw advice here and assume NAT is already working.

A snippet pulled from my rulesets that utilize stateful rules and ipfw
lifetimes is more leniant but may give some useful examples...

notes:

lo0     == loopback interface, localhost/127.0.0.1
fxp0    == my internal interface, your "en1"
fxp1    == my external interface, your "en0"
${OIP}  == outside IP address, i.e. 1.2.3.4
${LAN}  == LAN subnet, i.e. 10.0.0.0/24

rules:

# allow local loopback communication
add 0100 allow ip from any to any via lo0
# divert outbound traffic to natd for address translation
add 0200 divert natd ip from any to any via fxp0
# check state table for each observed packet
add 0300 check-state
# allow anything outbound - i trust my home network
add 0400 allow ip from ${OIP} to any keep-state out
# inside LAN
add 0500 allow tcp from ${LAN} to any keep-state lifetime 300 via fxp1
add 0501 allow udp from ${LAN} to any keep-state via fxp1
# allowed inbound connections - what we let the public Internet see
add 0600 allow tcp from any to ${OIP} 22 in keep-state lifetime 3600
add 0601 allow tcp from any to ${OIP} 25,80,443,53 setup
add 0602 allow udp from any to ${OIP} 53
# allow safe/useful icmp
add 1000 allow log logamount 0 icmp from any to any icmptypes 0,3,8,11,12
# deny and log all others
add 9999 deny log logamount 0 ip from any to any

Again, I'm not sure what handles NAT on OSX...  So I'll leave that up to
you.  The ruleset above would let internal clients on the trusted LAN
access anything on the Internet or the gateway.  It would allow clients on
the untrusted external network to access SSH (22), SMTP (25), HTTP/HTTPS
(80/443) and DNS (UDP and TCP ports 53).

The lifetime and keep-state/check-state options may not be available in
your ipfw implementation.  If that is the case, I've tried to throw
together a quick ruleset that should do what you ask without state (and
without divert/natd concerns):

# allow local loopback communication
add 0100 allow ip from any to any via lo0
# make sure only valid subnets are allowed to traverse their
# respective interfaces -- "spoof check"
add 0101 deny all from not 10.0.0.0/24 in via en1
# let any packets from established connections pass
add 0200 allow tcp from any to any established
# we need to allow UDP fragments or large UDP packets
# (including some DNS responses) will be discarded
add 0300 allow udp from any to any frag
# outbound allows - web, email, dns
add 0400 allow tcp from 10.0.0.0/24 to any 80,443 via en1
add 0401 allow tcp from 10.0.0.0/24 to any 25,110,143,993,995 via en1
add 0402 allow udp from 10.0.0.0/24 to any 53 via en1
# inbound allows - http
add 0500 allow tcp from any to any http
# trust management station, 10.0.0.70
add 0600 allow ip from 10.0.0.70 to any in via en1
# allow safe/useful icmp
add 1000 allow log logamount 0 icmp from any to any icmptypes 0,3,8,11,12
# deny/log everything else
add 9999 deny log logamount 0 ip from any to any

"Safe/useful ICMP" -- Seen in the rule chains as "icmptypes 0,3,8,11,12"
-- are ICMP types that need to be allowed for the Internet to work as
intended.  These include,

0       Echo Reply
3       Destination Unreachable (used by TCP's MTU discovery)
8       Echo
11      Time Exceeded
12      Parameter Problem

Note that despite being allowed, large volumes of ICMP or other abuses
should still be noted...  So I log all accepted ICMP packets in my
examples.  The keyword 'logamount 0' means to always log packets matching
this rule.  It could also be 'logamount 256' meaning only the first 256
packets matching the rule would be logged.  Adjust as needed.  There is
also usually a system setting that controls how many packets are logged by
default.

Your requirement [1] above indicated "must allow outgoing requests from my
LAN for websites & email."  In my example, I defined "email" as SMTP (25),
POP3 (110), POP3S (POP3 over SSL, 995), IMAP (443) and IMAPS (IMAP over
SSL, 993).  Adjust as needed.

> I read that rule 65535 can be changed from allow to deny, but ipfw
> would never let me do it. That is why I had to use rule 65534.

On BSD, rule 65535 is a "special" system rule.  That is, you compile your
kernel (adjust your system) to either default to allow everything or to
deny everything...  And 65535 is set automagically based upon that
setting.  There may be a way to adjust the rule on your system through
some GUI tool or elsewhere, but it's best to deny everything  -- then
there's more incentive to get a correct rulechain pieced together. ;)
It's also a well-established security adage to only allow what's
explicitly needed.

I'm not sure how much OS X' and *BSD's ipfw implementations differ, but
hopefully something here will point you in the right direction.  If
not, I'm sure someone more OS X savvy will step up to the soapbox.  Also,
don't neglect system documentation if it is available ('man ipfw', 'man
firewall' if that made it into OSX...).  It will give you the most
accurate picture of your specific ipfw implementation.

-mrh

--
From: "Spam Catcher" <spam-catcher () adept org>
To: spam-catcher () adept org
Do NOT send email to the address listed above or
you will be added to a blacklist!
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards