Search Results

Looks like the ipfw rules project that Chris is leading is pretty popular. We’ve set up a permanent link that we’ll redirect to the latest version as we keep refining this thing. You can find it here. Thanks again to everyone who has helped on this project: windexh8er: http://www.slash32.com/ Rob Lee: http://thnetos.wordpress.com/ Josh Chris Pepper http://www.extrapepperoni.com/

Based on extensive feedback, these rules are now much improved over the initial draft. Thanks, all! All the versions of this post are getting out of hand, so Rich has provided a permanent URL for the current Leopard ipfw post for future reference. Please use that link, so future visitors get the latest and greatest. Chris DO NOT USE THESE RULES without customizing them first! Version: 2007/12/12 For more information, see http://securosis.com/2007/11/15/ipfw-rules/ & http://securosis.com/2007/11/16/ipfw-rules-20071116-revision/#comments 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; duplicate rules with different ranges, if use use this computer on multiple networks. Additionally, allow only ports you actually use; block unused ports. Thanks to: Rich Mogull http://securosis.com windexh8er: http://www.slash32.com/ Rob Lee: http://thnetos.wordpress.com/ Josh 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 traffic on a ‘real’ interface is bogus. add 300 deny log logamount 1000 ip from any to 127.0.0.0/8 Block multicast unless you need it. add 400 deny log logamount 1000 ip from 224.0.0.0/4 to any in If we let a conversation begin, let it continue. Let my clients go! add 500 allow tcp from any to any out keep-state add 510 allow udp from any to any out keep-state Block replies, if we don’t recall initiating the conversation. add 520 deny log tcp from any to any established in Allow DHCP responses (keep-state can’t handle DHCP broadcasts). add 600 allow udp from any to any src-port 67 dst-port 68 in Do you never need fragmented packets? add 700 deny udp from any to any in frag Let yourself ping. add 1000 allow icmp from 10.42.24.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 ssh – should be restricted to trusted networks if at all possible; if open to the Internet, make sure you don’t have “PermitRootLogin yes” in sshd_config (at least use PermitRootLogin without-password”, please!) 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 – is this complete? 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 – uncommon 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 outbound 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

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

Updated: See https://securosis.com/wp-content/uploads/2007/11/ipfw-securosis.txt. I need to completely thank and acknowledge windexh8er for suggesting this post in the comments on the Leopard firewall post, and providing the starting content. In his (or her) own words: So how about everyone constantly complaining about the crap-tastic new implementation of the Leopard firewall we baseline a good IPFW config? Here’s for starters: 00100 allow ip from any to any via lo* 00110 deny ip from 127.0.0.0/8 to any in 00120 deny ip from any to 127.0.0.0/8 in 00500 check-state 00501 deny log ip from any to any frag 00502 deny log tcp from any to any established in 01500 allow udp from 10.100.0.0/24 5353 to any dst-port 1024-65535 in 01700 allow icmp from any to any icmptypes 3 01701 allow icmp from any to any icmptypes 4 01702 allow icmp from any to any icmptypes 8 out 01703 allow icmp from any to any icmptypes 0 in 01704 allow icmp from any to any icmptypes 11 in 65500 allow tcp from me to any keep-state 65501 allow udp from me to any keep-state 65534 deny log ip from any to any 65535 allow ip from any to any this firewall configuration will do a number of things. First of all line 500 is key to checking the state table before we block any poser incoming connections. Line 502 blocks connections coming in that pretend they were established, but really weren’t. Line 501 is pretty self explanatory, blocking fragmented packets in. I know nothing I’m using is fragmenting, so YMMV. Line 1500 is an example. Since Bonjour services cannot be tracked correctly in the state table we need to allow things back to 5353/UDP on the box (that is if you want to use it). But my example shows that I’m only allowing those services on my local network. Anytime I head to Panera or Starbucks I don’t have to worry about 5353 being ‘open’, unless of course those networks are using 10.100.0.0/24. Most of the time they’re not. But if I noticed that I would disable that rule for the time being. Next we get to ICMP. What do these let us do? ICMP type 3 let’s path MTU in and out (i.e. PMTU – Path MTU Discovery). Many people don’t realize the advantages of PMTU, because they think ICMP is inherently evil. Try doing some performance engineering and PMTU becomes a great resource. Anyway, type 3 is not evil. Next, type 8 is source quench. It will tell my upstream gateway to “slow down” if need be. Again, not evil for the most part. The pros outweigh the cons anyway. Types 8 and 0 rely on each other. 8 lets me ping out and 0 lets that back in. BUT – people will not be able to ping me. Sneaky sneaky The last one, type 11, will let me run traceroute. So now 65500 and 65501 basically let my computer open any port out. In the essence of keeping this ruleset “set it and forget it” style this can be done better. Like specifying everything you need to let out and blocking everything else. But I can’t delve into that for ‘every’ user, so this makes it a little more convenient. 65534 is our deny. Notice all the denies I setup have logging statements. I always have a terminal running tailing my firewall log. Then again, for those who don’t know how to respond maybe just keep that on the down low – you might get sick if you saw all of the traffic hitting your box depending on the network you’re connected to. Rich – you should start a thread for whittling down the best default ruleset for IPFW on Tiger/Leopard and let’s do a writeup on how to implement it Ask and ye shall receive- I’ll be putting together some of my own suggestions, but this is a heck of a great start and I’m having trouble thinking of any good additions right now. Let’s all pile on- once we get consensus I’ll do another post with the results.

I am thinking about writing a guide to secure open source databases, including verification queries. Do you all think that would be useful? For the most part, when I write about database security, I write about generic approaches that apply to all database platforms. I think this is helpful for database managers, as well as security and IT professionals who have projects that span multiple database types. When writing the Database Security Fundamentals series, my goal was to provide a universal checklist of the database security basics that anyone with basic DBA skills could accomplish in a week. DBAs who work in large enterprise may have established guidelines, but small and medium sized firms generally don’t, and I wanted the series to provide an awareness on what to look for and what to do. I also find that mainstream Oracle DBAs tune out because I don’t provide specific queries or discuss native features. The downside is that the series covers what to do, but not how to do it. By taking a more abstract look at the problems to be solved across security and compliance, I cannot provide specific details that will help with Oracle, Sybase, Teradata, PostgreSQL, or others – there are simply too many policies for too many platforms for me to sufficiently cover. Most DBAs know how to write the queries to fulfill the policies I outlined. For the non-DBA security or IT professional, I recognize that what I wrote leaves a gap between what you should do and how to do it. To close this gap you have a couple of options: Acquire tools like DAM, encryption, and assessment from commercial vendors Participate on database chat boards and ask questions RTFM Make friends with a good DBA Yes, there are free tools out there for assessment, auditing, and monitoring. They provide limited value, and that may be sufficient for you. I find that the free assessment tools are pretty bad because they usually only work for one database, and their policies are miserably out of date. Further, if you try to get assessment from a commercial vendor, they don’t cover open source databases like Derby, PostgreSQL, MySQL, and Open Ingres. These platforms are totally underserved by the security community but most have very large installed user bases. But you have to dig for information, and cobble together stuff for anything that is not a large commercial platform. So here is what I am thinking: through the remainder of the year I am going to write a security guide to open source databases. I will create an overview for each of the platforms (PostgreSQL, Derby, Ingres and MySQL), and cover the basics for passwords, communications security, encryption options, and so forth, including specific assessment polices and rules for baselining the databases. Every week I’ll provide a couple new rules for one platform, and I will write some specific assessment policies as well. This is going to take a little resourcefulness on my part, as I am not even sure my test server boots at this point, and I have never used Derby, but what the heck – I think it will be fun. We will post the assessment rules much like Rich and Chris did for the ipfw Firewall Rule Set. So what do you think? Should I include other databases? Should I include under-served but non-open-source such as MS Access and Teradata? Anyone out there want to volunteer to test scripts (because frankly I suck at query execution plans and optimization nowdays)? Let me know because I have been kicking this idea around for a while, but it’s not fully fleshed out, and I would appreciate your input.

Popular perception of endpoint security revolves around anti-malware. But they are called suites for a reason – other security components ship in these packages, which provide additional layers of protection for the endpoint. Here we’ll talk about firewalls, host intrusion prevention, and USB device control. Firewalls We know what firewalls do on the perimeter of the network: selectively block traffic that goes through gateways by port and protocol. The functionality of a host firewall on an endpoint is similar. They allow an organization to enforce a policy governing what traffic the device can accept (ingress filtering) and transmit (egress filtering). Managing the traffic to and from each endpoint serves a number of purposes, including hiding the device from reconnaissance efforts, notifying the user or administrators when applications attempt to access the Internet, and monitoring exactly what the endpoints are doing. Many of these capabilities are available separately on the corporate network, but when traveling or at home and not behind the corporate perimeter, the host firewall is the first defense against attacks. Of course, a host firewall (like everything else that runs on an endpoint) takes up resources, which can be a problem on older or undersized machines. It also bears consideration that alerts multiply, especially when you have a couple thousand endpoints forwarding them to a central console, so some kind of automated alert monitoring becomes critical. Although pretty much every vendor bundles a host firewall with their endpoint suite nowadays, the major operating systems also provide firewall options. Windows has included a firewall since XP, but keep in mind that the XP firewall does not provide egress (outbound) filtering – remedied in Windows Vista. Mac OS X 10.5 Leopard added a ‘socket’ firewall to manage application listeners (ingress), and deprecated the classic ipfw network firewall, which is still available. As with all endpoint capabilities, just having the feature isn’t enough, since the number of endpoints to be managed puts a real focus on managing the policies. This makes policy management more important than firewall engine details. Host Intrusion Prevention Systems (HIPS) We know what network intrusion detection/prevention products do, in terms of inspecting network traffic and looking for attacks. Similarly, host intrusion detection/prevention capabilities look for attacks by monitoring what’s happening on the endpoint. This can include application behavior, activity logs, endpoint network traffic, system file changes, Windows registry changes, processes and/or threads, memory allocation, and pretty much anything else. The art of making host intrusion prevention work is to set up the policies to prevent malware infection, without badly impacting the user experience or destroying the signal-to-noise ratio of alerts coming into the management console. Yes, this involves tuning, so you start with the product’s default settings (hopefully on a test group) and see what works and what doesn’t. You should be able to quickly optimize the policy. Given the number of applications and activities at each endpoint, you can go nuts trying to manage these policies, which highlights the importance of the standard builds (as described in Controls: Secure Configurations). Starting with 3-4 different policies, and then you can manage others by exception. Keep in mind that tuning the product for servers is totally different, as the policies will need to be tailored for very different applications running on servers. Currently, all the major endpoint suites include simple HIPS capabilities. Some vendors also offer a more capable HIPS product – typically targeting server devices, which are higher profile targets and subject to different attacks. USB Device Control Another key attack vector for both data compromise and malware proliferation is the USB ports on endpoint devices. In the old days, you’d typically know when someone brought in a huge external drive to pilfer data. Nowadays many of us carry a 16GB+ drive at all times (yes, your smartphone is a big drive), so we’ve got to control USB ports to address this exposure. Moreover, we’ve all heard stories of social engineers dropping USB sticks in the parking lot and waiting for unsuspecting employees to pick them up and plug them in. Instant pwnage 4U! So another important aspect of protecting endpoints includes defining which devices can connect to a USB port and what those devices can do. This has been a niche space, but as more disclosure is required for data loss, organizations are getting more serious about managing their USB ports. As with all other endpoint technologies, device control adds significant management overhead for keeping track of all the mobile devices and USB sticks, etc. The products in the space include management consoles to ease the burden, but managing thousands of anything is non-trivial. Right now device control is a discrete function, but we believe these niche products will also be subsumed into the endpoint suites over the next two years. In the meantime, you may be able to gain some leverage by picking a device control vendor partnered with your endpoint suite provider. Then you should at least be able centralize the alerts, even if you don’t get deeper management integration. Management Leverage Though we probably sound like a broken record at this point, keep in mind that each additional security application/capability (control) implemented on the endpoint devices increases the management burden. So when evaluating technology for implementation, be sure to assess the additional management required and the level of integration with your existing endpoint management workflow. We’ll wrap up our discussion of Endpoint Controls in the next post, as we discuss full disk encryption, which disclosure laws have shifted from nice-to-have to something you need deployed – immediately. Other posts in the Endpoint Security Fundamentals Series Introduction Prioritize: Finding the Leaky Buckets Triage: Fixing the Leaky Buckets Controls: Update and Patch Controls: Secure Configurations Controls: Anti-Malware

When Mike was reviewing the latest Pragmatic Data Security post he nailed me on being too apologetic for telling people they need to spend money on data-security specific tools. (The line isn’t in the published post). Just so you don’t think Mike treats me any nicer in private than he does in public, here’s what he said: Don’t apologize for the fact that data discovery needs tools. It is what it is. They can be like almost everyone else and do nothing, or they can get some tools to do the job. Now helping to determine which tools they need (which you do later in the post) is a good thing. I just don’t like the apologetic tone. As someone who is often a proponent for tools that aren’t in the typical security arsenal, I’ve found myself apologizing for telling people to spend money. Partially, it’s because it isn’t my money… and I think analysts all too often forget that real people have budget constraints. Partially it’s because certain users complain or look at me like I’m an idiot for recommending something like DLP. I have a new answer next time someone asks me if there’s a free tool to replace whatever data security tool I recommend: Did you build your own Linux box running ipfw to protect your network, or did you buy a firewall? The important part is that I only recommend these purchases when they will provide you with clear value in terms of improving your security over alternatives. Yep, this is going to stay a tough sell until some regulation or PCI-like standard requires them. Thus I’m saying, here and now, that if you need to protect data you likely need DLP (the real thing, not merely a feature of some other product) and Database Activity Monitoring. I haven’t found any reasonable alternatives that provide the same value. There. I said it. No more apologies – if you have the need, spend the money. Just make sure you really have the need, and the tool you are looking at really delivers the value, since not all solutions are created equal.

A little over a month ago we decided to try opening up an intern and Contributing Analyst program. Somewhat to our surprise, we ended up with a bunch of competitive submissions, and we’ve been spending the past few weeks performing interviews and running candidates through the ringer. We got all mean and even made them present some research on a nebulous topic, just to see what they’d come up with. It was a really tough decision, but we decided to go with one intern and one Contributing Analyst. David Meier, better known to most of you as Windexh8r, starts today as the very first Securosis intern. Dave was a very early commenter on the blog, has an excellent IT background, and helped us create the ipfw firewall rule set that’s been somewhat popular. He blogs over at Security Stallions, and we’re pretty darn excited he decided to join us. He’s definitely a no-BS kind of guy who loves poking holes in things and looking for unique angles of analysis. We’re going to start hazing him as soon as he sends the last paperwork over (with that liability waver). We’re hoping he’s not really as good as we think, or we’ll have to promote him and find another intern to beat. David Mortman, the CSO-in-Residence of Echelon One, and a past contributor to this blog, is joining us as our first Contributing Analyst. David’s been a friend for years now, and we even split a room at DefCon. Since I owed David a serious favor after he covered the blog for me while I was out last year for my shoulder surgery, he was sort of a shoe-in for the position. He has an impressive track record in the industry, and we are extremely lucky to have him. You might also know David as the man behind the DefCon Security Jam, and he’s a heck of a bread baker (and cooker of other things, but I’ve only ever tried his bread). Dave and David (yeah, we know) can be reached at dmeier@securosis.com, and dmortman@securosis.com (and all their other email/Twitter/etc. addresses). You’ll start seeing them blogging and participating in research over the next few weeks. We’ve gone ahead and updated their bios on our About page, and listed any conflicts of interest there. (Interns and Contributing Analysts are included under our existing NDAs and confidentiality agreements, but will be restricted from activities, materials, and coverage of areas where they have conflicts of interest).

Apple just released an update to Leopard, version 10.5.1. The support document says the following: Addresses a code signing issue; third-party applications can now run when included in the Application Firewall or when whitelisted in Parental Controls. In Security preferences’ Firewall tab, the “Block All” option is now called “Allow Only essential services” Well, I suppose that’s some kind of progress. At least it’s labelled accurately. I’ve been really slammed this week, but Chris and I should have the instructions for using WaterRoof in combination with our template ipfw rule set and the Application Firewall soon (hopefully today). I’ve tested the update and the application firewall still signs applications, but instead of just failing to launch modified applications, we’re now prompted to allow access manually again if they change. Code signing can be rough because of issues like this, and I think the prompt is a reasonable solution. However, I would prefer it to say, “This application has been modified since its last use; please click to allow network access” so we know that it’s a real change to the application and not just a random prompt to approve again. In a separate document, Apple details some additional security updates to the application firewall. Most notably, the firewall will now block processes running as root if you specify them in the application firewall. Based on these updates I’m now running the application firewall with ipfw, and will try and get those instructions posted soon. Not that any of this matters much since there are no network attacks on Macs in the wild right now, but we all know that can’t last…

Updated: See http://securosis.com/2007/11/15/ipfw-rules/. Thanks to an email from John Baxter via MacInTouch, it looks like Apple posted some documentation on the new firewall that contains some really good news: The Application Firewall does not overrule rule set with ipfw, because ipfw operates on packets at a lower level in the networking stack. If true, this is some seriously good news. It means we can run ipfw rule sets in conjunction with the new firewall. Why would you want to do that? I plan on writing an ipfw rule set that allows file sharing, web, and ssh through and will use the GUI in the application firewall to allow or deny those services I sometimes want to open up without manually changing firewall rule sets. sigh if only I’d known this earlier! I won’t have a chance to test today, so please let me know in the comments if the application firewall overrides your ipfw rule sets. This should help us create the best Leopard ipfw rule set…