Blog - Author Posts

Chris Pepper, Editor

Chris has worked as a Systems Administrator in New York City for the past 12 years, at a variety of non-profit and startup organizations, as well as a brief stint in the financial field. Chris is particularly interested in Linux (and more generally in open source), networking, and security. As a writer (particularly for TidBITS), Chris seeks to make complex subjects – such as OpenSSH and SSL – approachable to a wider audience. He blogs at Extra Pepperoni.

ipfw Rules, v2007/12/12

By reppep
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

ipfw Rules, 2007/11/15 revision

By reppep
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 >

When Community Is Bad: Community and Commerce—Don’t Cross the Streams!

By reppep
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

HTTP Authentication: a Primer

By reppep
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

Just a Spoonful of Obscurity Makes the DefCon Level Go down!

By reppep
Rich, It feels heretical, but I can agree that obscurity can provide some security. The problem comes when people count on secrecy as their only or primary security. Jim: “Oh, we don’t have to encrypt passwords. Sniffing is hard!” Bob: “Hey, thank you for those credit card numbers!” Jim: “What?” Bob: “Ha ha, my friend Joe got a job at your ISP about a year ago, and started looking for goodies.” Vendor: “Nobody will ever bother looking in the MySQL DB for the passwords.” Cracker: “0WNED! Thank you, and let’s see how many of your users use the