ipfw Rules, 2007/11/15 revision



Rules revised.

As suggested by windexh8er, here’s a set of ipfw rules to customize for your own Macs or FreeBSD systems. Note that your private home network should have a non-standard IP range, both to support VPN across standard IP ranges, and for improved security, so your personal allow rules don’t match other networks you may find yourself wandering through.

The rules are below, but you’ll probably have an easier time if you download the rule file from http://securosis.com/wp-content/uploads/2007/11/ipfw-securosis.txt.

In WaterRoof, you can import these rules with “Tools > Rules Configuration > Import rules from file..”. To check your ipfw rules, use “sudo ipfw list“. When you’re satisfied with your rules, install them for future reboots with “Tools > Rules Configuration > Save to startup configuration” and “Tools > Startup Script > Install Startup Script”.

# DO NOT USE THESE RULES without customizing them first!
# Version: 2007/11/15

# For more information, see http://securosis.com/2007/11/15/ipfw-rules/

# These rules *MUST* be customized to your requirements.
# In particular, if you have a private home network (behind an AirPort
# Base Station, Linksys WRT54G, etc.), change "10.42.24.0/24" below to
# your private network range.
# Additionally, allow only ports you actually use; other ports should be
# blocked by the ipfw firewall.

# Thanks to:
# Rich Mogull http://securosis.com
# windexh8er: http://www.slash32.com/
# Lee: http://thnetos.wordpress.com/
# Chris Pepper http://www.extrapepperoni.com/
# Apple (Server Admin is a good way to create an ipfw ruleset)
#   http://www.apple.com/server/macosx/
# FreeBSD (where Apple got ipfw) http://www.freebsd.org/

# We don't really want this, but it's unavoidable on Mac OS X Server, so
# document it here (serialnumberd)
# 100 allow udp from any 626 to any dst-port 626 

# Let me talk to myself over the loopback
add 200 allow ip from any to any via lo0 

# Loopback addresses on non-loopback interfaces are bogus
add 300 deny log logamount 1000 ip from any to 127.0.0.0/8
add 310 deny log logamount 1000 ip from 224.0.0.0/4 to any in 

# Block multicast if you don't use it
# add 400 deny log ip from 224.0.0.0/4 to any in 

# Accept responses to my client programs
add 500 check-state 

# If we let the conversation begin, let it continue
add 600 allow tcp from any to any established 

# Let my programs get out.
add 700 allow tcp from any to any out keep-state
add 710 allow udp from any to any out keep-state 

# Change this to DENY fragments if you don't need them.
add 800 allow udp from any to any in frag 

# Block bogus inbounds that claim they were established
# add 900 deny log tcp from any to any established in 

# add 1000 allow icmp from 10.9.7.0/24 to any icmptypes 8 

# Server Admin provides these by default
add 1100 allow icmp from any to any icmptypes 0
add 1110 allow igmp from any to any 

# mDNS (Bonjour) from trusted local networks (fill in your own,
# preferably non-standard, networks after 'from')
# For Back to My Mac, you might need this from 'any'
# add 5000 allow udp from 10.42.24.0/24 to any dst-port 5353
# add 5010 allow udp from 10.42.24.0/24 5353 to any dst-port 1024-65535 in

# DNS (note TCP is required, but this one should scare you -- much
# better to only allow packets from your trusted nameservers, if you
# always use the same ones)
add 5100 allow tcp from any to any dst-port 53
add 5110 allow udp from any to any dst-port 53
add 5120 allow tcp from any to any dst-port 53 out keep-state
add 5130 allow udp from any to any dst-port 53 out keep-state 

# ssh
add 5200 allow tcp from any to any dst-port 22 

# iTunes music sharing
#add 5300 allow tcp from 10.42.24.0/24 to any dst-port 3689 

# AFP
#add 5400 allow tcp from 10.42.24.0/24 to any dst-port 548 

# HTTP (Apache); HTTPS
# add 5500 allow tcp from any to any dst-port 80
# add 5510 allow tcp from any to any dst-port 443 

# L2TP VPN
# add 5600 allow udp from any to any dst-port 1701
# add 5610 allow esp from any to any
# add 5620 allow udp from any to any dst-port 500
# add 5630 allow udp from any to any dst-port 4500 

# iChat: local
#add 5700 allow tcp from 10.42.24.0/24 to any dst-port 5298
#add 5710 allow udp from 10.42.24.0/24 to any dst-port 5298
#add 5720 allow udp from 10.42.24.0/24 to any dst-port 5297,5678 

# Server Admin SSL (Mac OS X Server only)
# add 5800 allow tcp from 10.42.24.0/24 to any dst-port 311
# add 5810 allow tcp from 10.42.24.0/24 to any dst-port 427
# add 5820 allow udp from 10.42.24.0/24 to any dst-port 427 

# syslog
# add 5900 allow udp from 10.42.24.0/24 to any dst-port 514 

# ipp (CUPS printing) 

# add 6000 allow tcp from 10.42.24.0/24 to any dst-port 631 

# MTU discovery
add 10000 allow icmp from any to any icmptypes 3 

# Source quench
add 10100 allow icmp from any to any icmptypes 4 

# Ping out; accept ping answers
add 10200 allow icmp from any to any icmptypes 8 out
add 10210 allow icmp from any to any icmptypes 0 in 

# Allow me to traceroute
add 10300 allow icmp from any to any icmptypes 11 in 

# My default policy: log and drop anything that hasn't matched an allow
# rule above
add 65534 deny log logamount 1000 ip from any to any

# Hard-coded default allow rule (compiled into Darwin kernel)
add 65535 allow ip from any to any

Posted on

18 comments

  1. windexh8er Nov 15

    Nice Rich! :)

    One thing I might comment on is that TCP is not truly required for DNS unless the response from the server is greater than 1024bytes. Usually this results from a zone transfer, but for normal browsing DNS via TCP is not required. I’ve actually looked through my deny logs over weeks and never see anything from 53 TCP being blocked… But, just a personal preference!

    Again, wonderfully put together and nicely commented.
    –windexh8er

  2. rob Nov 16

    Is 900 not mooted by 600? I realize it’s commented out here, but I’m unclear why you included it. And, I thought the point check-state and keep-state was to keep track of established connections dynamically, which would make 600 redundant, and 900 worth having.

    I’m confused. :)

  3. rob Nov 16

    Oh yeah, and aren’t 5100-5130 redundant, with 700 and 710 in place?

  4. Pepper Nov 16

    @windexh8er,

    I’ve seen problems with blocking 53/tcp, although they may have been only because I was poking around manually; I’m told 53/tcp broke a lot of things when responses from AOL (I don’t know for which resource type) exceeded the UDP payload. I leave 53/tcp open because it should be, not because I’ve verified it needs to be.

    @rob,

    These are assembled from a variety of sources, and I don’t recall exactly how I got here, but as I read it, if an inbound packet doesn’t match rule 700 but has the established flag set, it’s spoofed.

    51×0 is for Internet clients to connect to BIND on our Mac. Thanks for pointing that out, though, as it’s not at all clear. I’ll cluster 600, 700, & 900 together for clarity and revise; let’s see if there’s more feedback first, though.

  5. diem Dec 5

    I’ve used this ruleset as a basis for my ipfw config and all is well save one thing - SMB/CIFS. Here are my rules (one set per interface):

    add 4009 allow tcp from any to any 137-139,445 setup keep-state in via en0
    add 4010 allow udp from any to any 137-139,445,65534,65535 keep-state in via en0

    I have reduced the all the rule numbers in your suggested set except for 65534, such that all my per-protocol rules appear after the DNS rules (and the ICMP ones whose numbers I reduced) but before 65534.

    Whilst Windows boxen show up in Servers in Finder (using that ghosted icon) when I attempt to Connect I get told that ‘the original item cannot be found’. nmblookup -T does not find them either, though the remote boxes ping just fine. If I remove the 65534 deny all rule then the protocol immediately starts working. I’m sure I have the right ports open (no?), so can anyone suggest where the problem lies?

    Many thanks for any enlightenment.

  6. rob Dec 5

    diem,

    are you seeing the rejects in the log? That should give you an idea of where the problem lies.

  7. diem Dec 6

    Thanks for the rapid response Rob.

    I’m not seeing any rejects in ipfw.log, but Iv’e a sneaking feeling that Panther is configured to route ipfw logging to system.log, so I’ll go check there (and re-route my logging methinks). Will report back what I find.

  8. rob Dec 6

    diem,

    Panther doesn’t have firewall logging turned on by default, so you’ll need to enable it first. sysctl -w net.inet.ip.fw.verbose=2 should do it, I think.

  9. Curby Feb 21

    600 shouldn’t be necessary because 500 already allows valid established traffic and 600 just allows unwanted/spoofed traffic, and the 51?0 rules assume we are running a DNS server, which even if true is not something that a workstation should advertise. The question is, what type of machine is this ruleset for?

    Continuing, 5120 should never match because of 5100, and anyway 5120 is redundant with 700. According to the freebsd-ipfw mailing list, there is no fragment reassembly before traffic hits ipfw, so using ipfw to drop frags may actually drop desired traffic if something’s fragmenting packets outside your control.

    In general, servers and “user machines” have wildly different security requirements and you cannot realistically design a ruleset for both without a lot of inapplicable rules (note all the commented out lines in the original post here).

    My IPFW work on OS X can be accessed by clicking on the heading of this comment. I’ve focused on user machines, which in general do not advertise services but instead make use of external services.

  1. Help Build The Best IPFW Firewall Rules Sets Ever | securosis.com
  2. Extra Pepperoni » Securosis: ipfw ruleset
  3. Investigating the Leopard Firewall | securosis.com
  4. For all ya’ll Mac Zealots That Want a Better Leopard Firewall
  5. A good set of baseline ipfw firewall rules for Mac OSX « :wq
  6. ipfw Rules, 2007/11/16 revision | securosis.com
  7. 101 FreeBSD Ipfw resources | Learning On Demand
  8. ipfw Rules, v2007/12/12 | securosis.com
  9. links for 2008-02-15 « Where Is All This Leading To?

Leave a reply

Related Posts

Leopard Firewall- Apple Documents And Potentially Good News
Permanent Link For ipfw Rules
ipfw Rules, v2007/12/12