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
Reader interactions
10 Replies to “ipfw Rules, 2007/11/15 revision”
So, as I upgrade the hard drive on my Macbook I’ve decided to completely re-install everything (in the spirit of Rich’s Mac Pro installation).
Any IPF geniuses out there that can comment on whether these are still “good” IPFW rules?
Thanks.. Rob
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.
[…] ipfw Rules, 2007/11/15 revision | securosis.com (tags: firewall ipfw osx security leopard macosx apple mac sysadmin) […]
[…] on extensive feedback, these rules are now much improved over the initial draft. Thanks, […]
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.
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.
diem,
are you seeing the rejects in the log? That should give you an idea of where the problem lies.
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.
[…] ipfw Rules, a set of ipfw rules to customize for your own Macs or FreeBSD systems […]
[…] to the feedback, I’ve tweaked these rules a bit. I realized I was blocking DHCP, so I added that as […]