The BFC Computing Weblog

This is a neat enhancement to postfix for reducing spam by attacking its economics: making sure it speaks SMTP properly.

A spammer gets paid by the message delivered. So, it's in his interest to flood them out as quickly as possible. Because of this, they rarely implement mailers which negotiate the SMTP connection politely - they simply open the TCP connection and start sending.

When an SMTP client doesn't respect the proper-back-and forth postfix expects, it'll flag it as unauthorized 'pipelining' - for example when multiple messages are sent in succession, but which would otherwise be OK.

We can take advantage of this by forcing the issue, and increasing the odds a spammer will make this mistake by waiting just a second between establishing the TCP connection and telling the spammer we're ready to take mail. A loaded mail server may behave this way anyway, so it's not outside the norm and the resource consumption is minimal, but it attacks the economics of spamming.

In your main.cf file, you would add to smtpd_client_restrictions something like this:

          smtpd_client_restrictions =
                  permit_sasl_authenticated,
                  permit_mynetworks,
                  check_client_access hash:/etc/postfix/access-client,
                  sleep 1,
                  reject_unauth_pipelining
          
          

We accept all of our own users' connections (interactive ones, perhaps) right away, and if the sender is totally unknown to us, we wait for just a second. Then we reject any unauthorized pipelining. The log will show something like this:

May 6 10:49:00 mailhub postfix/smtpd[8965]: NOQUEUE: reject: RCPT from unknown[10.1.2.3]: 403 4.5.0 spamtarget@example.com: Recipient address rejected: Improper use of SMTP command pipelining

when the spammer attempts to just send.

It's worth noting that this method may not scale to very large installations, as those one second delays may be too much. But for the average-sized postfix install, it can make yet another dent in the spam deluge. Where it does consume 'too many' resources, one must weight the cost of computing resources vs. the time cost of dealing with yet another spam.

A Mac user might want to export his Keychain passwords and notes for several reasons - using a third-party password manager on Mac OS X, creating a time-resistant backup of passwords, printouts of passwords for the safe-deposit box or attorney, or switching to another operating system.

There's no easy way to do this. Keychain Access only allows you to export certificates, and Apple recommends backing up the Keychain database files, which accomplishes none of the above goals and promotes lock-in.

The keychain code is itself open source, but I couldn't find it compiled for another platform anywhere. I assume that enough of the OSX toolchain is required to make this infeasible, though likely not impossible. Still, it's not there.

Fortunately, I ran across an Applescript that uses Keychain Scripting to create a text file from a user's login Keychain. Unfortunately, it didn't do a bunch of things I thought were required for moving my passwords to a Linux machine, so here's the delta:

version 2009030201:

• handle all keychains
• handle all key types
• handle comments and descriptions
• handle errors
• trim dangling whitespace
• write to tab delimited format
• unlock all keychains first, so the mad tapping won't hit 'cancel'
• add username to filename
• replace carriage returns/newlines in text fields with spaces
• use unix line endings in output file

and some general code cleanup. I'm assuming the sample code is in the public domain and releasing this version under GPLv2+. Please improve this and comment here when you do or send changes back. If you own the original code and feel this is improperly licensed, let me know ASAP.

I've run this out of Script Editor - the advantage there is it's easy; the disadvantage is double-confirming every keychain access, one for Script Editor, one for Keychain Scripting. Terribly time consuming. I suspect if you compile this it'll eliminate the first half.

I've set this to open all the keychains first. Otherwise when hitting "allow, allow, allow" you might hit 'cancel' if it asks to unlock a keychain. If your keychain is big enough you might not get through the whole thing before the keychain unlock times out, so be careful.

Your minutes of tapping on the mouse button like a human waiting for a treat will be rewarded with a ~/Desktop/Passwords-yourusername file. It'll be easy to then process with other scripts, importable into databases or spreadsheets for further manipulation. I'll leave it up to you to be smart and not leave this password file sitting around in some unencrypted/unprotected location for any longer than absolutely necessary. If it gets stolen you're probably up a creek, right? So, be careful, only aim at what you intend to kill.

Download KeychainExport.

I got a National Cyber Alert System alert today about the Microsoft Internet Explorer security vulnerability, now that Microsoft has a patch out. The trouble is, everybody has known about this since last week, and anybody finding out about it today is already hopelessly in trouble.

There's nothing wrong with a notification, "hey, you should ensure this patch is applied," but that's not the purported purpose of the Cyber Alert System.

Thank goodness for the ISC which is group of volunteers doing a much better job than the large government bureaucracy charged with the task.

To verify the Fedora 10 package downloads, you need the new key they're signing the Fedora 10 packages with, but it's only included in the -release rpm which you don't want to install on some other machines, say your repository mirror.

This works:

rpm --import 'http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0xBF226FCC4EBFC273'

I wonder why this is different than the -newkey key. Anyway, don't take my word for it, check the signatures to prove it for yourself.

Saw this train car at Clark’s Trading Post:

and it made me think of SSL certificates. I think that qualifies me as certifiably hopeless.

Some e-mail systems, notably Earthlink, employ a challenge-response system whereby when you send a user an e-mail you get a response asking you to fill out a form to allow your e-mail to go through.

This is improper behavior because spam filtering is your problem (just like I filter my spam) and you’re pushing your work back on me.

It becomes an n^2 problem if everybody employes this kind of system, so it’s not a scalable behavior. Supporting this kind of system creates a moral hazard, so, if you’re using one of these systems you’re not going to get mail from me.

There’s been much made of the revelation that Diebold voting machines run an install of McAfee Anti-Virus, and that it’s caused trouble with the voting software.

The arguments against it typically boil down to:

• Your voting machines shouldn’t be use for anything else
• Your voting machines should be secured against anybody installing software on it
• You can’t verify the operation of MAV so it could possibly tamper with votes
• You should be running an operating system which is not so easily infected

Those arguments all have merit, but skip the fundamentals - the software image on a voting machine should not be running on read/write media, that is hard drives. If that basic criteria isn’t met, AV software might actually be a good idea, but missing the fundamentals is no excuse for dirty hacks.

I build my first appliance computer that could run from a CD in a CD-ROM drive in 2002. It’s neither new nor a difficult concept. When you need things to be secure, in that case under HIPAA regs, in this case for votes, you mount your media device (hard drive, flash memory, etc) with the ‘noexec’ flag, and then no software installed on the read/write media can be run from that media. Since you can’t write to the CD, software can’t be run from there either. You provide a stripped down OS image to make doing any more than the minimum very difficult, certainly requiring physical access to the machine.

This isn’t to say your machine shouldn’t be kept secure - of course it should, and the BIOS needs to be correctly configured (many of you know the security problems with certain BIOS configurations) - but read-only media and a good Q/A process obviates the need for anti-virus software. Certainly some software selection choices can make this difficult, but any good architecture starts with the requirements and works towards software selection, not the other way around. Assuming good security is a requirement.

I’ve written before about the limited usefulness of plausible deniability, especially in relation to software like TrueCrypt, a hard drive encryption program.

The gist of plausible deniability with TrueCrypt is this: You have multiple encrypted hard drive partitions. When your enemy forces you to reveal your keys, you reveal the low-cost key, and the enemy sees some data that he doesn’t care about and sends you on your merry way. The ‘real’ stuff you want to hide is still hidden.

This works if two conditions are true:

• The enemy doesn’t know you employ a product with plausible deniability
• The enemy can merely detain you

If those conditions aren’t true, you’re in big trouble. Say a violent group gets you and your data. They know TrueCrypt has plausible deniability, and they really want your data. You’re going to be tortured until they get what they want, it’s that simple, and ugly.

Now, the worst possible scenario is that you can’t give up ‘your data’ because it doesn’t exist. But only you know that. The bad guys think you have it and they know you have plausible deniability. You’re completely screwed.

For this reason I’ve been against plausible deniability systems for defending against all threats (yes, TrueCrypt would still be fine from hiding that porn you have stashed away on your home PC).

This changed when Cal Harding introduced the concept of Complete Deniability. That is, you can prove that you have no more plausible deniability.

Here’s how it can work: With TrueCrypt, you could have a utility that, once inside a locked data set, could be given a set of keys and ensure that those keys account for all readable data and all blocks of the storage device. Because TrueCrypt is open source, the bad guys can trust this utility to verify that you’re no longer hiding anything. They can review the source and compile it themselves, if they wish.

But, good news for you, you get to go home. Because even bad guys don’t like to waste their time and you’re not otherwise terribly interesting. Odds are you’re not getting your laptop back once the bad guys find your porn bank, though.

After reading about Barracuda moving to invalidate a bogus patent Trend Micro filed for on virus-scanning at an e-mail gateway (many of my clients depend on this technology) in January, I sent Barracuda the following note:

          -----Original Message-----
          From: Bill McGonigle [mailto:bill@bfccomputing.com] 
          Sent: Tuesday, January 29, 2008 12:24 PM
          To: legal@barracuda.com
          Subject: possible SMTP prior art - TFS
          
          From:
          
          http://groups.google.com/group/comp.mail.sendmail/
          browse_frm/thread/3cee3dc93ea81690/a8cd75d669fbd6b7?lnk=st&q=smtp+virus+scan#a8cd75d669fbd6b7
          
          Its pretty functional - gateways between any/all MS/MAIL,
          WP-OFFICE, CC:MAIL, SMTP, UUCP, MCI-MAIL. It does uuencode
          and MIME attachments (configurable per address or domain
          wildcard) and international characters. It can also virus
          scan attachments on the way through the gateway, and access
          can be controlled on a user by user basis!
          
          (message dated July 25th, 1995).
          
          It looks like it's still around in some form from foxT:
             http://www.tfstech.com/
          
          Good luck,
          -Bill
          

I never heard back more than a quick “thanks!” from Dean Drako, CEO of Barracuda, but today, I read they’ve moved ahead with this strategy and Goran Fransson, developer on TFS, is a new open source ally.

Dean writes of Goran, “We greatly appreciate the time that Goran Fransson took in coming forward to share this very important piece of prior art,” Drako says. “We believe that his testimony is instrumental in our case against what we believe is an unjust patent claim by Trend Micro against Barracuda Networks and the open source ClamAV project. In our view, Goran is an open source hero.”

Full disclosure: I’ve sold completely open solutions, based on postfix/MailScanner/clamav/sqlgrey against Barracuda’a blackbox appliances, but I’m glad they’re fighting against Trend Micro’s abuse of the system.

Apple has gone and done something really wrong in terms of security: they released a critical security update wrapped in a feature update.

So, Quicktime 7.5 is required to be protected from the most recently disclosed vulnerabilities. Problem is, as with every other n.X release of Quicktime, it’s buggy. No doubt 7.5.1 and 7.5.2 will be along in a few weeks’ and months’ time, but until then your only choices are to run with miserable choppy playback or to stay vulnerable to disclosed security problems.

This is a really bad idea. There should have been a 7.4.x rev for security as well as a 7.5 with those security fixes.