Research

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 Share:

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 Share:

The HTTP protocol includes encryption features, such as “Basic HTTP Authentication” and “Digest HTTP Authentication”, which are well supported by current browsers. Using either, every time you log your browser into a website with a username & password, the browser stores three pieces of information: the site’s hostname, your username, and your password. From then on, until you quit your browser, every time you visit any page on that site, your browser sends that username & password to the server. This is the same via both HTTP & HTTPS, but doesn’t apply to custom login code, such as forms and cookies; normally the easiest way to recognize Basic or Digest authentication is the separate window that pops up over the web page, prompting for username and password, and possibly “realm”; if it has logos or is inside a web page, it isn’t basic or digest authentication. There are a lot of tricks, including scripting techniques to grab passwords from other sites, or fool a password manager (built into the browser or a separate program) into providing a password with little or no human confirmation, but it’s simply not possible to completely prevent people from sending their passwords for any site to ‘rogue’ pages on the same. In the simplest case, someone could copy the official Site X login page, make a private copy, and store the passwords entered or send them to a remote server. For bonus points, forward the credentials to the real login page, so the user gets logged in successfully and doesn’t notice anything is wrong. For a long and interesting review of the issues, see the Firefox bug for a specific MySpace password capturing attack: https://bugzilla.mozilla.org/show_bug.cgi?id=360493. A shorter page by the original reporter is at http://www.info-svc.com/news/11-21-2006/. Note how difficult it is to solve a specific problem in a specific browser, and keep in mind that many browsers are in use (Firefox, IE6, IE7, Safari, Opera, Lynx, Konqueror, Nokia’s new browser, IE Mobile, the Palm browser, etc.). There will always be attacks that get past many of these browsers – the possibilities are too wide open, and there’s too much human desire for quick and convenient access to the web (otherwise password managers wouldn’t exist, and we’d use a different password for every site). The same issues apply to cookies, although they are more flexible and thus more complicated. Share:

Note: For some background on HTTP authentication and username/password caching, see HTTP Authentication: a Primer. I was reading Schneier yesterday, and it reminded me of all those MySpace and similar worms going around. Why are they so bad? How will they get worse in the future? Their biggest problem is that they welcome everyone, making it easy for bad people to establish themselves. The second is that even though the sites themselves are not high-security, they have security implications for other sites, including high-security sites. MySpace is scary because it enables a very large number of people to post content your browser will parse and possibly execute. Further, they’re casual sites, so don’t have the same level of security urgency or corporate paranoia as a bank obviously needs (the reality of bank security is a different matter, but the expectation is higher for Citibank than MySpace). The other concern is that people and their browsers (often on auto-pilot, for both people and browsers) enter login information routinely to access these sites. This makes community sites a rich target for attackers – especially since many people use the same username & password for MySpace and electronic banking (and everything else)! Those people who get hacked on MySpace, and then immediately on their electronic banking sites, are screwed. But at least everybody can say “You should have known better.” It doesn’t help much, but is important to both MySpace and the banks for liability reasons. And it’s true – in 2006 you’re asking for trouble if you use the same password for your bank as a low-security site like MySpace. This isn’t to confuse the victim with the perpetrator, but we have to expect more self-defense than that. We can’t provide all the security everybody needs – they have to help! But site developers must make the assumption that every user has exactly one username and password, which they use everywhere, and make every effort to protect that password (this means not storing accounts in a plaintext MySQL table, not showing passwords to customer service/support staff, and not emailing passwords on request – reset them and email the new random password to the address on file). Crossing the Line So there are high-security sites, and low-security sites, and people can understand that banks are better guarded (physically and electronically) than lots of other places (perhaps not as well as sports & concert venues, though). When this line is erased or faded, risk increases. For example, Apple hosts user web pages through its .Mac online service. Amazon encourages people to post reviews of books and other products. Do these have security implications? Of course (everything does, actually). Scenario: Harry the Hacker gets a free .Mac trial account, posts an evil JavaScript that records username, password, and all cookies, to his new disposable site on Apple’s .Mac servers, and starts collecting data. Community sites often attempt to block JavaScript, but it’s an ongoing struggle. What does Harry get? With a working JavaScript, it’s easy to capture usernames & passwords from all the .Mac subscribers who logged into their own sites or just auto-enter credentials (disclaimer: I don’t know how .Mac uses cookies). Some substantial percentage of these passwords work on banks, as we’ve already discussed. Can Harry grab people’s store.apple.com accounts this way, to order a brand new Mac Pro? Not directly, at least, because store.apple.com and homepage.mac.com are different domain names, so their account information is stored and accessed separately; the same goes for the iTunes Store. Naturally, Apple’s doesn’t give .Mac users posting access to store.apple.com. So Apple’s okay here. Not great, but I don’t see a solution aside from not authenticating to .Mac at all, and that wouldn’t work. Note that the problem is made worse by the fact that Apple pushes people towards using a single “Apple ID” for all Apple services, and further requires 1-click ordering to be enabled for at least iPhoto print orders, which makes .Mac password compromises more severe, by linking them to active credit cards. There’s an ongoing dynamic tension between making the site richer and more capable, and limiting it to prevent ‘mischief’. MySpace is clearly possible partially because it’s so flexible. Every security restriction is necessarily weighed as a potential detractor from ease of use, power, and popularity. What about Amazon? They put user content on the main amazon.com shopping site! But I believe what they allow is much more restricted HTML, and there’s at least some editorial review, so they’re probably okay. I’m sure more problems will appear over time, as people add community functionality to more and more sites, for feedback, documentation, etc. I recently had to think long and hard about sending a financial document to an ISP based on a publicly-editable wiki page (it’s no longer editable, but there’s still plenty of potential for mischief there). It’s a wiki – I didn’t even have a guarantee that the offer on the page was real. I eventually decided the page and fax number were almost certainly legitimate (they were), and the risk was very small, but that doesn’t mean the next such page will be copacetic. People have asked me a couple times to add CMS-type functionality to the website for our 31-student co-operative pre-school, so it’s clear that interactive “community” features are not stuck in a MySpace-type-only ghetto. This is an issue that all web developers must keep in mind as they consider user contributions and interactivity or their sites: What does it do to our existing security model? Do we need to draw a stronger line between official/ecommerce/corporate and public/collaborative/non-binding/untrusted? Note that this isn’t a Web 2.0 issue. Various companies have been mixing employee and customer email domains for years. I believe Netscape used to provide @netscape.com email addresses to subscribers. What a great opportunity for spam! From: update-service@netscape.com Subject: Urgent Netscape Upgrade Please go to update-service.netscrape.com to get an important security patch for your Netscape browser! It’s quaint now, but 5 years ago lots of people used