Extra Pepperoni

To content | To menu | To search

Thursday, March 21 2013

iptables: connlimit

Today we were effectively subjected to a DDoS attack by a badly behaved client raiding one of our web servers. We decided to rate-limit HTTP connections, which turned out to be pleasantly simple.

I replaced our old iptables rule to allow HTTP connections:

-A INPUT -j ACCEPT -p tcp --dport    22

with 2 new rules:

-A INPUT -j ACCEPT -p tcp --dport    80 -s xxx.yyy.0.0/16 --syn -m connlimit ! --connlimit-above 20
-A INPUT -j ACCEPT -p tcp --dport    80                   --syn -m connlimit ! --connlimit-above 5 --connlimit-mask 24

The first rule allows any on-campus user to make 20 simultaneous connections. The second rule prevents external clients from making more than 5 at a time. They can make as many connections as they want in series, but if a web crawler attempts to open 6 connections without closing any, the 6th will time out. Slick!

Thanks to nixcraft for the details!

Tuesday, August 17 2010

Sending a Mac away

I have to send my MacBook Pro to Apple for service again, so it's time to review my list of Sensitive Data: Things to Delete and other preparation for giving up physical control of a Mac. Unfortunately last month my MacBook Pro completely died, and I didn't have a chance to do any of this. The Genius asked for my password, and I just laughed at her. She explained they'd probably replace the hard drive with a new install if they couldn't get in, and I said I'd deal with that, but suggested they just use the installer to reset the password to something they liked. As it turned out, they apparently decided not to bother -- I got the MBP back with some security settings changed, so perhaps Apple techs have a different tool that grants them access.

Before Shipment

  1. Make a backup. I use SuperDuper for these, in addition to automatic CrashPlan & Time Capsule backups.
  2. Test the backup!
  3. Log out of any sensitive services, such as MobileMe & Dropbox.
  4. Sign out of & deauthorize iTunes (don't forget Audible & Home Sharing).
  5. For each browser/user: clear history, cookies, & cache. Clear any saved passwords in browsers & email clients.
  6. Create an apple user, and make it an administrator. Give it a simple password (don't forget to write it on a note for the tech -- you don't want to wait a couple extra days while they ask for the password!).
  7. Set autologin for the apple account.
  8. Remove sensitive files for all active accounts, (including root if relevant):
    • ~/Library/Keychains/
    • ~/.ssh/ (except authorized_keys)
    • Password wallets (assuming you're not using something like 1Password on Dropbox)
    • Any sensitive email (location depends on client -- might be ~/Library/Mail/; I don't do this -- I have a lot of mail, and it's not generally sensitive)
  9. Change any passwords, if worried Apple might decrypt them (don't forget sudo passwd root).

After Return

If the motherboard has changed, the serial number & MACs will change.

  1. Log out of the apple account.
  2. Log back into your regular account, and hold the Shift key down to avoid launching all your standard applications (and prompting for a bunch of passwords which are in the removed keychain).
  3. Reverse all the above.
  4. Re-enable MobileMe sync.
  5. Update any static DHCP assignments if MAC changed.
  6. Re-pair Remote.app or other paired devices if Bluetooth changed.
  7. Re-pair anything else confused by changed MAC.
  8. Reboot and make sure everything works as expected.

Tuesday, November 4 2008

Flash: Broken, Not Just Evil

Flash sucks even worse than I thought. The Never Ask Again checkbox is not honored in Flash 9.0 r124 (under 10.5.5/Safari 3.1.2), which breaks Flash videos (pretty much Flash's only real reason for being, aside from advertising spyware). I reported this to Adobe, but don't expect much.

Note that I end up with dozens of stacked dialogs, and they pop back up about one per second, so hulu clearly won't work until Adobe fixes this bug, or I give up and turn on Flash cookies (which I have no intention of doing).


Concise problem statement: Flash does not honor setting to not store cookies or local data.

Steps to reproduce bug:

  1. Visit http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html
  2. Set Global Storage Settings to None.
  3. Check Never Ask Again.
  4. Uncheck "Allow third-party Flash content to store data on your computer".
  5. Restart Safari.
  6. Visit http://www.hulu.com/, or http://widgets.nbc.com/cscallback/urlexchange/ (a Sarah Palin SNL clip), or http://www.nytimes.com/interactive/2008/11/04/us/politics/20081104_ELECTION_WORDTRAIN.html

Results: Many many annoying Flash dialogs asking for permission to store data (1 on NYTimes; many on the videos, which interrupt playback).

Expected results: When I check Never Ask Again, I should get NO dialogs asking to store Flash cookies, and no Flash cookies should be stored.

In addition, I unchecked "Store common Flash components to reduce download times." But when I relaunched Safari, it was unchecked. I relaunched a second time, and this setting stayed checked. Never Ask Again was still correctly checked, but I still kept getting obnoxious cookie prompts from hulu.

Update: Leonard Rosenthol informed me that Flash 10 is out. It's a bit hard to find, but does appear to solve the problem. I upgraded, relaunched Safari, reset the option, relaunched Safari, and no longer get those stupid prompts. Hooray! It's odd that Adobe hides it so effectively (it's not even on Adobe's main update page), and the built-in Flash updater doesn't offer it; unfortunately Apple hasn't delivered it to Mac OS X users yet.

Update 2 -- 2008/12/25: Disabling local data (cookies and local caching) prevents Flash videos at Flickr and other sites from playing (I just get a black rectangle of the right size -- no change or controls). YouTube/Google video is not affected, though. I'm not re-enabling Flash cookies, though.

Sunday, October 19 2008

Flash Suckage: Eat Your Cookies!

Update 2004/11/08 (Obama Day): It's worse thane I thought. Not only are these features and controls hidden and almost impossible to find, but the controls don't actually work.

Flash Cookies: The Silent Privacy Killer disturbed me. Then I visited the Flash Player Manager page, saw all the sites that were tracking me via Flash cookies, and felt really freaked. I disabled Flash cookies, and encourage you to do so as well. I'm not yet sure how well it worked, as I just checked and saw an unwelcome Yahoo cookie, apparently added after I attempted to disable them.

While people are aware of HTTP cookies, I had never heard of Flash cookies before. HTTP cookies are legitimately required by various sites, but I don't believe Flash cookies serve any user purpose, and they don't seem to be required for any reason I care about, so I don't expect problems from clearing and disabling them.

Friday, March 7 2008

I really was compromised

DreamHost wrote back, and the news isn't good. Someone sent them a list which is apparently circulating, of username/password pairs for "FTP" accounts; one was mine. I had hoped that if a password leaked it was my old password, which I replaced back in June (on my birthday) when DreamHost told me they got hacked. No joy, though -- the password they received was active on Extra Pepperoni (and chrispepper.com) until they sent me mail yesterday; I don't use it elsewhere and changed it last night, but that means someone had access to EP very recently. It looks like nobody ever used the account, but methinks it's time to install MySQL and WordPress on www.reppep.com, and probably Mailman too.

Crud on a cracker!


And I still have no idea how they got me.

Thursday, March 6 2008

Bad News from DreamHost

I got a message from DreamHost tonight which both confused and disturbed me.

Telling me there's evidence that I have been intruded upon is scary -- but what was the evidence?? Without more information, this is upsetting but not helpful.

I only access this account from fully patched Macs under my direct control. None of them were running Windows spyware, and I know there hasn't been a hardware keylogger in operation on my equipment recently (I don't believe every, but I've been doing lots of work on my equipment lately, so I know not recently). It's certainly possible I got hacked by some brand-new Mac OS X exploit, but (especially given my understanding of DreamHost's security model, which entails emailing plaintext passwords at the drop of a hat) I consider it considerably more likely this is a false alarm or miscommunication.

Especially given that, despite "we have reset your password", the affected account's password was NOT changed. I logged in normally and changed it myself. This makes me very glad that I created a brand-new password only for DreamHost last time they got hacked. On the other hand, I could have been sniffed logging in over the Internet (most of their access is unprotected); I only set up SSL for administration of Extra Pepperoni a month ago...

We'll see how they respond to my request for clarification.

In the meantime, I am worried and aggravated.

It's also somewhat suspicious that the timezone is UTC, considering that DreamHost is in Los Angeles. If it wasn't the right panel.dreamhost.com hostname, I'd think this was an attempt to get me to submit my DH account information to a spammer, but that information isn't worth much.

To: "Chris Pepper" <---->
From: DreamHost Support <support@---->
Subject: [reppep ----] Account Concerns...
Date: Fri,  7 Mar 2008 02:20:34 +0000 (UTC)

Dear DreamHost customer,

We have found evidence indicating that your 'reppep' web server account
may have been subject to intrusion by a malicious 3rd party. As a
precautionary measure, we have reset your password and ask that you
change it, here:


At this time we have found no evidence to suggest that there has been a
breach of our internal security. We believe that the passwords in
question were likely obtained through the use of
spyware/keyloggers/malware, possibly installed on your personal

In order to secure your account, we ask that you immediately follow the
recommendations provided in the DreamHost AbuseCenter - particularly
those involving the removal of malware. You may visit the AbuseCenter,


If you have any questions or concerns, please let us know.

- DreamHost Abuse/Security Team

Sunday, February 10 2008

Extra Pepperoni Is Now SSL Protected

I've been thinking about using SSL to protect logins to this blog for a while, but thought it would be too complicated. This weekend, I took the time, and thanks to Haris' Admin-SSL plug-in, it was very easy. First I used cert.command to create a certificate for www.extrapepperoni.com, then I configured my DreamHost account to provide SSL (https://secure.reppep.com/ep/) in addition to the existing http scheme; this took a while to go through. Then I installed Admin-SSL, and after a few loading errors, all authentication and authenticated access is now SSL only, while reading anonymously is non-SSL.

Note that I'm using a certificate signed by my private certificate authority, ca.reppep.com, so you'll get a warning from your browser that it's not trusted; this is normal. You can continue past the warning and get full 128-bit SSL encryption; you just don't have the assurance of a public CA that I am who I say I am.

Thanks to Rich & Sam for encouraging me to do this.

Thursday, January 24 2008

Keychain Sync without .Mac

After getting burned too many times, I dropped my .Mac subscription. I never trusted my Apple keychains to iDisk anyway, but this means I have different subsets of passwords on different machines, and no good way to keep them in sync. I thought of a solution for manual sync last week: One keychain per Mac. Say I have 3 systems: work, home, and other. Each system has 3 Apple keychains: work.keychain, home.keychain, and other.keychain, with each host using its own as the default. Then I can rsync work.keychain to home.keychain & other.keychain, etc. This is awkward with rsync because it's inherently unidirectional, but keychains are small so it's quite feasible to script.

In Tiger, I know the keychain is actually stored in memory once it's unlocked, so it's good to lock (unload) all keychains with "security lock-keychain -a" before updating the files -- this goes in the same script. I also set mine to lock after 2 hours of inactivity, or (on those systems where I run SSHKeychain) when sleeping or activating the (locking) screen saver.

Friday, November 16 2007

Securosis: ipfw ruleset

Update: After revising more than once, the permanent link to the latest ipfw ruleset is http://securosis.com/publications/ipfw.html.

Over at Securosis, Rich and I posted a piece on using ipfw to increase your security. Leopard's new 'firewall' isn't a network firewall at all. It restricts applications' ability to listen on ports, rather than working at the level of the network stack, which means it cannot do things like allow ssh from home but not from the rest of the Internet. If you want classic packet filtering, it makes sense to use ipfw as well. We cooked up a starter ruleset for people to customize, with instructions on installing it using WaterRoof.

Saturday, November 10 2007

Leopard's "socket firewall"

The new "firewall" in Leopard is called socketfilterfw, but as far as I can tell it doesn't actually do any packet filtering, which is how ipfw and classic packet filtering firewalls work. Instead, it restricts the ability of programs to "bind" a port so they can receive all traffic for that port. This discrimination is not novel -- UNIX systems (including Mac OS X) will not allow any program to bind ports 0-1023 unless they're running as root (UID 0). Normal users get an error when they attempt to take over low ports like this.

In recent years, many operating systems have made adjustments to this restriction, in an attempt to make permissions more granular. Apple, however, has added an entirely different (and much more sophisticated) test to the process of binding a port: does socketfilterfw trust it? socketfilterfw can even cryptographically 'seal' a binary (program), to make sure that if it is changed in the future, it automatically loses its authorization to listen on the network. Unfortunately, Apple seems to have gotten a bit carried away, and signed some tools that are as likely to be used by crackers who have just broken into a system as legitimate Mac users (netcat, I'm looking at you)

If socketfilterfw allows the request, the port is bound and the program receives traffic that reaches the port; if socketfilterfw denies the request, the port is not bound to the requesting program, and it doesn't get any traffic. Ironically, this is very much more like a Windows firewall (e.g., ZoneAlarm), of restricting and allowing individual applications, rather than working at a network level that has little or nothing to do with individual programs.

Anyway, here's the help message for socketfilterfw. Note the reference to firewallapp, which does not exist on my system. Presumably it is an unreleased CLI tool to manage the firewall, like the ipfw command manges the kernel firewall, or iptables on Linux. Note that the FreeBSD-derived ipfw is still available in Mac OS X Leopard (user), but not activated or used by the system -- it just passes all traffic through unless manually configured. On the other hand, Mac OS X Leopard Server's Server Admin (used in Advanced mode, but unavailable in favor of Server Preferences in Standard mode) still uses ipfw. Over at Securosis, I'm working on an example ipfw ruleset to get people dissatisfied with socketfilterfw started, but before we post any rules, we need to decide upon a suitable (easy) way for people to use them without delving into writing custom rc boot scripts.

$ sudo /usr/libexec/ApplicationFirewall/socketfilterfw -h
usage: /usr/libexec/ApplicationFirewall/socketfilterfw [-c] [-w] [-d] [-l] [-T] [-U] [-B] [-L] [-a listen or accept] [-s file to sign] [-v file to verify] [-p pid to write] 
firewallapp is used to control Application Firewall socket filter.
The command takes the following options that are evaluated in order, 
and several options may be combined:
 -h        display this help and exit
 -t app    set trusted app, e.g. -t app1 app2 app3
 -i        dump socket filter internal data info
 -d        turn on debugging
 -l        do logging and run in daemon mode
 -k        kill daemon
 -a        ask when listen or accept, ask "accept" or ask "listen"
 -s file   sign file
 -v file   verify file
 -c        check file

Note that sudo /usr/libexec/ApplicationFirewall/socketfilterfw -d dumps out a list of allowed programs; there's some other junk in the output that looks like the signatures checked against the binaries, and a bunch of references to "ALF", which could stand for "Application Level Firewall".

Thursday, November 1 2007

Leopard: Turn "Allow guests to connect to shared folders" off

Setting up new Leopard (user) and Leopard Server systems, I was shocked to discover that, in System Preferences:Accounts:Guest, "Allow guests to connect to shared folders" is enabled by default. This is lousy security. Fortunately file sharing is off by default, but I turned file sharing on a day or two before I noticed guest access was enabled. I don't want guest access enabled, and it shouldn't be on without a conscious decision.

Sunday, October 28 2007

OpenSSL: Handy Commands

I needed a place to keep openssl commands for reference. See http://www.reppep.com/~pepper/writing/tidbits/ssl-article/ for much more depth.

Read a cert (I use this to build all my .crt files, so I can easily tell what I'm working with later):

openssl x509 -text -fingerprint -sha1 -in certificate.crt

Read a CSR (most fields should match the account with your CA, or your private CA cert):

openssl req -text -in request.csr

The classic, for testing availability of an SSL server, is:

openssl s_client -connect server:port -- e.g., openssl s_client -connect www:443

For web sites, I generally use a browser to review the certificate, but for other protocols openssl is invaluable. Apple's /System/Library/CoreServices/Certificate\ Assistant.app/ (available from Keychain Access' Keychain menu) is also good for verifying SSL status of arbitrary SSL servers.

For traffic analysis, ssldump can (with the server's private key) decrypt tcpdump captures or live traffic.

From a Windows admin, requesting a cert for IIS (I have not tested):

I need for you to combine the crt with the key to make a pfx file.

openssl pkcs12 -export -out canonicalName.pfx -inkey canonicalName.key -in canonicalName.crt

Thursday, October 4 2007

New uses for passwords

I was walking down the street this morning, burning a piece of paper with some old passwords on it, and holding the box of matches I had used to light it. A woman saw me, and said "Hi. Gimme a match?" I got out a match and prepared to light it for her. Before I could strike flame, the woman leaned over to my burning password paper and lit a cigarette from it, then said "Thank you."

There I was, standing on the street, thinking "Smoking's bad, mm-kay," and wondering why she asked for a match when she wanted a light (yes, I know, I cannot turn off being an editor), and thinking this was probably actually not the first time someone's lit a cigarette from a burning password, but it's still unusual.

Friday, September 21 2007

Undercover: Cool & Creepy

Daring Fireball mentioned Orbicule's Undercover, and so did TUAW. After reading Orbicule's recovery stories, I'm a bit creeped out, though.

Undercover is spyware. It records your IP, takes screenshots, and (if an iSight is available) takes photos (presumably the green activity LED on built-in iSights flashes in use -- I don't think they can defeat it in software); sending all this across the Internet to Orbicule. It reminds me a lot of location tracking tools for cellphones, initially developed to track commercial fleets, but also useful to keep tabs on children, spy on spouses, and track government targets.

All that said, it's undoubtedly cool technology and a useful service, but I'm too uncomfortable to use it -- Orbicule's How it works page says "Undercover can not be disabled by the thief.", which raises my suspicions further.

Orbicule promises that Undercover doesn't emit any information unless the Mac is logged as stolen. This assumes you trust Orbicule's assurance, you and Orbicule trust Orbicule's programmers, and that your Mac doesn't get accidentally added to their list of stolen computers.

I hope no plain criminals get the source (or just the inspiration) and use it to spy on Mac users more effectively...

Monday, September 10 2007

FIPS 140-2 for Mac OS X

I got a very interesting (and unexpected) email today. Apparently Apple is in the process of certifying Mac OS X to Federal Information Processing Standard 140, which is used to validate encryption and security technologies -- it's commonly associated with SSL/TLS hardware and software; I know OpenSSL was being validated against FIPS too, but haven't kept track of that progress. I had no idea Apple was working on this, but if and when it's completed, it should be a useful credential for Apple in security-sensitive environments. Note that I make no claims as to the meaning of FIPS certification, but it will be used as a simple checkbox for trustworthiness, so can't hurt Apple to have this particular tick-mark.

From: "Shawn A. Geddis" <geddis@>
To: Fed Talk <fed-talk@lists.apple.com>
Date: Mon, 10 Sep 2007 04:57:51 -0400
Subject: [FIPS 140-2] Mac OS X - Implementation Under Test (IUT)

It's Official -- Mac OS X is now in "Pre-Validation" for FIPS 140-2 Level 1 (Software) Conformance Validation

Everyone has been eager to know the status of FIPS 140-2 Conformance Validation for Apple's Mac OS X and we are happy to finally announce that as of Friday September 7, 2007 the Apple Cryptographic Service Provider (CSP) Module is officially now in "Pre-Validation".

Listed on NIST (CMVP) Pre-Validation List

You will now find the Apple "Cryptographic Service Provider (CSP)" on line 5 of page 2 on the Pre-Validation List (PDF) posted on the NIST CMVP website. To view that list now or reference it in the future, use the following link to download the PDF document:


What will be covered by this validation

A Cryptography Architecture is built into Mac OS X and is the foundation for services critical to the protection and privacy of data. The key Apple Cryptographic Services which will be covered by this validation are:

FileVault (Encrypted Container - User's Home Directory)

Encrypted Disk Images (Encrypted Container - Stored on any accessible media)

Keychains (Credential Storage)

The FIPS 140-2 Conformance Validation Process

For those who are not familiar with the process and requirements, they can be found on the NIST website at:


  1. Implementation Under Test (IUT)
  2. Validation Review Pending
  3. Validation Review
  4. Validation Coordination
  5. Validation Finalization

When it will be done

Many have asked when Mac OS X's cryptographic algorithms and cryptography conformance validation against FIPS 140-2 Level 1 will be complete. Apple is unable to provide you with a more specific timeframe than the first half of 2008 due to the extensiveness of the process. Apple will make every effort to post status updates on the Federal website [ http://www.apple.com/itpro/federal/] as well as occasional updates posted to the Fed-Talk Mailing list [ http://lists.apple.com/mailman/listinfo/fed-talk ].

Meeting OMB Recommendations (M-06-16)

To assist Federal Agency IT Staff in understanding how Apple's Mac OS X Operating System can help them meet OMB guidelines, the Apple Enterprise Team had developed and presented the "Meeting OMB Encryption Guidelines with Mac OS X Today" briefing to a large Federal IT Staff on August 17, 2006. Many additional Federal Staff had indicated that they were unable to attend the all day briefing and technical discussion due to scheduling conflicts, but said they were extremely interested in getting access to the presentation.

"Meeting OMB Encryption Guidelines"


Background on FileVault

FileVault provides full 128-bit AES encryption of the User's Home Directory where the user has full, direct access to read and write their data. The underlying Encrypted Disk Image architecture also provides services to create, manage and store the encrypted containers on any accessible storage media. This storage includes external volumes such as thumb drives, CDs/DVDs, USB/FireWire HDs and even network accessible volumes.

Background on Apple's Cryptographic Architecture

The Cryptography and PKI Services within Mac OS X and Mac OS X Server are provided through the CDSA - Common Data Security Architecture . The CDSA architecture is the core part of Apple's Security framework which is available from The Open Group and available as open source for review, use and modification.

Open Group - CDSA: http://www.opengroup.org/security/l2-cdsa.htm

Apple source can be found at: http://developer.apple.com/opensource/security/

If you have any additional questions at this time regarding the FIPS 140-2 Level 1 Conformance Validation of Mac OS X , please contact me directly via email at: geddis@

Tuesday, August 21 2007

SSHKeychain Is Unsafe

Eric Warnke has discovered that, if asked nicely, SSHKeychain will print out the passphrase used to encrypt a loaded private key. This is bad, as the whole point of an ssh agent/keychain is to provide secure access to encrypted keys, meaning you cannot get the passphrases or plaintext keys out.


Crud on a cracker, Batman!

Verified in the latest (v0.8.1) -- hopefully there will be a patch soon, but this just shouldn't be possible.


Friday, August 3 2007

Laptops in Hostile Environments

The Register has an interesting article on how to "safely" take your computer to Defcon, with the very wise suggestion that you're safer if your laptop does not go to Defcon. Cellular phones without 802.11 are probably okay for this year at least. They refer back to a much more hard-core SANS post on the same topic.

The exercise is more involved for the fully paranoid, or generally when preparing to enter a truly hostile network. I assume that someone at Black Hat/Defcon has an unannounced exploit that I'd be vulnerable to. This implies you shouldn't have any sensitive data or access to sensitive machines. Since you wouldn't need a laptop without data or access, you probably need to mitigate the consequences of getting hacked.

  1. Make up a couple disposable passwords just to use at the conference, one for this machine and one for outside accounts. Destroy them later.
  2. Bring an empty USB thumb drive.
  3. Create a new email account, so you can send yourself notes/presentations for later.
  4. Forward your important email accounts to the new one (keep copies on the normal accounts), so you don't have to check them.
  5. Note that if you have a hosting plan like DreamHost's, you can create brand-new ssh and email accounts free. I believe DH offers SSL webmail, if you can ignore the certificate warnings.
  6. Get a cheap monthly VPN account, as suggested by Glenn Fleishmann; this is much simpler than establishing a trusted Squid proxy on a non-sensitive box, as originally suggested by SANS; note that you are then trusting the VPN provider.
  7. If you have any untrusted protocols, try to access them from your temporary shell account via ssh, or though an ssh tunnel.
  8. Back up your data (image the drive -- you will need it later, and a full image is fastest to restore).
  9. Wipe your laptop.
  10. Install your OS, creating a new account with your new local password.
  11. If you have a built-in webcam with an independently software-controlled active light, tape over it. If you feel comfortable opening up your laptop, disconnect its internal microphone.
  12. Create a new ssh keypair. If you know the netblock, only allow access from Defcon machines and your own personal host(s); I have some info on doing this in authorized_keys in Take Control of SSH, Draft Excerpt: Public Key Authentication. Make sure your laptop trusts your other (home) machines.
  13. Only as needed, trust this new key on your other systems.
  14. In your local firewall, block outbound access except to the ports you intend to use; this is easy in Linux, but a bit more complicated on Macs, where you need to write your own startup script (or .command script in Login Items). This is obviously overridable, but an effective way to make sure you don't accidentally connect without encryption, either from habit or because a website redirects you to unencrypted HTTP to save encryption cycles (common). For services where you know what host you'll be connecting to, embed that. Here's a sample of what you might add to add Apple's ipfw. Note that it's easy to shoot your own foot off with outbound firewall restrictions.

    ipfw add 01010 allow tcp from any to dst-port 53 out
    ipfw add 01020 allow udp from any to dst-port 53 out
    ipfw add 01030 allow tcp from any to dst-port 53 out
    ipfw add 01040 allow udp from any to dst-port 53 out
    ipfw add 01110 allow tcp from any to any dst-port 22 out
    ipfw add 01120 allow tcp from any to any dst-port 443 out
    ipfw add 01030 allow tcp from any to smtp.dreamhost.com dst-port 587 out
    ipfw add 01040 allow tcp from any to mail.dreamhost.com dst-port 993 out
    ipfw add 01900 deny tcp from any to any out
  15. Restore only required information to your laptop.

Enjoy the conference. Hi, Rich!

When you're back home, connect from your home machines to the untrusted laptop, rather than the other way around, retrieve any data on it, and then boot from CD/DVD/PXE and reinstall, or restore from your image if you can do that without using the untrusted OS on the laptop's hard drive.

Monday, June 25 2007

Securing Communications with SSL/TLS: A High-Level Overview

I wrote a long article for TidBITS about SSL/TLS, attempting to explain it to a lay audience. I wrote another piece for admins on how to use CA.pl, which TidBITS didn't pick up, and a third piece about a couple shell scripts I wrote to help run a Certificate Authority, called cert.command & sign.command. I hope you find them interesting and useful.

Saturday, June 23 2007

Cool Tool: ssldump

We were trying to figure out what was wrong with communications between our load balancers and Oracle Application Server this week, and the F5 rep whipped out ssldump. With the SSL key, ssldump can decrypt captured traffic from tcpdump just like wireshark (ethereal) does for unencrypted traffic; apparently it can also do live display of SSL traffic like wireshark, but I haven't tried.

Good stuff!

Wednesday, June 6 2007

DreamHost Screwed the Pooch

This sucks, Beavis!

I had to change the school's panel password (which will only be changed again in 24 days when I hand over the reins to my successor, who will change it again), plus my personal panel password, 3 shell passwords, 12 list passwords, this blog's password, and possibly the Analog passswords, and what will I forget?

Crud. Crud. Crud.

DreamHost's next failure is not telling us what the spam links look like. I can't read the source of every page on the site, but if they would tell us what to look for, I could grep for the suspect sites quite easily. I actually found them elsewhere (see the Andy Hagan link below) -- no thanks to DH, whose screw-up I'm now attempting to fix.

Adding injury to injury, I just got the cheery/goofy montly DreamHost email, with no mention of the hack, even though they must have been dealing with the break-in when the message was sent.

To make things worse, the status page where they promise to post updates on this incident doesn't even mention it! This is 2 1/2 hours after they sent me email, and they still haven't come clean in public. On the other hand, oscandy.com had a posting about it a couple days earlier http://www.oscandy.com/hacking/454-dreamhost-hosting-platform-hacked.

From a couple other blogs, this may have shown up a week ago:

To: "Chris Pepper"
From: DreamHost Security Team
Subject: [reppep 11988754] URGENT: FTP Account Security Concerns...
Date: Tue,  5 Jun 2007 18:52:42 -0700 (PDT)

Hello -

This email is regarding a potential security concern related to your  
'reppep' FTP account.

We have detected what appears to be the exploit of a number of  
accounts belonging to DreamHost customers, and it appears that your  
account was one of those affected.

We're still working to determine how this occurred, but it appears  
that a 3rd party found a way to obtain the password information  
associated with approximately 3,500 separate FTP accounts and has  
used that information to append data to the index files of customer  
sites using automated scripts (primarily for search engine  
optimization purposes).

Our records indicate that only roughly 20% of the accounts accessed -  
less than 0.15% of the total accounts that we host - actually had  
any changes made to them. Most accounts were untouched.

We ask that you do the following as soon as possible:

1. Immediately change your FTP password, as well as that of any other  
accounts that may share the same password. We recommend the use of  
passwords containing 8 or more random letters and numbers. You may  
change your FTP password from the web panel ("Users" section, "Manage  
Users" sub-section).

2. Review your hosted accounts/sites and ensure that nothing has been  
uploaded or changed that you did not do yourself. Many of the  
unauthorized logins did not result in changes at all (the intruder  
logged in, obtained a directory listing and quickly logged back out)  
but to be sure you should carefully review the full contents of your  

Again, only about 20% of the exploited accounts showed any  
modifications, and of those the only known changes have been to site  
index documents (ie. 'index.php', 'index.html', etc - though we  
recommend looking for other changes as well).

It appears that the same intruder also attempted to gain direct  
access to our internal customer information database, but this was  
thwarted by protections we have in place to prevent such access.  
Similarly, we have seen no indication that the intruder accessed  
other customer account services such as email or MySQL databases.

In the last 24 hours we have made numerous significant behind-the- 
scenes changes to improve internal security, including the discovery  
and patching to prevent a handful of possible exploits.

We will, of course, continue to investigate the source of this  
particular security breach and keep customers apprised of what we  
find. Once we learn more, we will be sure to post updates as they  
become available to our status weblog:


Thank you for your patience. If you have any questions or concerns,  
please let us know.

- DreamHost Security Team

- page 1 of 2