Reducing Spam with SMTP Validation on Postfix 2

Posted by Bill McGonigle Wed, 06 May 2009 14:50:00 GMT

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.

del.icio.us:Reducing Spam with SMTP Validation on Postfix digg:Reducing Spam with SMTP Validation on Postfix reddit:Reducing Spam with SMTP Validation on Postfix spurl:Reducing Spam with SMTP Validation on Postfix wists:Reducing Spam with SMTP Validation on Postfix simpy:Reducing Spam with SMTP Validation on Postfix newsvine:Reducing Spam with SMTP Validation on Postfix blinklist:Reducing Spam with SMTP Validation on Postfix furl:Reducing Spam with SMTP Validation on Postfix fark:Reducing Spam with SMTP Validation on Postfix blogmarks:Reducing Spam with SMTP Validation on Postfix Y!:Reducing Spam with SMTP Validation on Postfix smarking:Reducing Spam with SMTP Validation on Postfix magnolia:Reducing Spam with SMTP Validation on Postfix segnalo:Reducing Spam with SMTP Validation on Postfix

Mac OS X Keychain Export Tool

Posted by Bill McGonigle Tue, 03 Mar 2009 04:34:00 GMT

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.

del.icio.us:Mac OS X Keychain Export Tool digg:Mac OS X Keychain Export Tool reddit:Mac OS X Keychain Export Tool spurl:Mac OS X Keychain Export Tool wists:Mac OS X Keychain Export Tool simpy:Mac OS X Keychain Export Tool newsvine:Mac OS X Keychain Export Tool blinklist:Mac OS X Keychain Export Tool furl:Mac OS X Keychain Export Tool fark:Mac OS X Keychain Export Tool blogmarks:Mac OS X Keychain Export Tool Y!:Mac OS X Keychain Export Tool smarking:Mac OS X Keychain Export Tool magnolia:Mac OS X Keychain Export Tool segnalo:Mac OS X Keychain Export Tool

Cyber Alert System Failure

Posted by Bill McGonigle Thu, 18 Dec 2008 23:28:00 GMT

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.

del.icio.us:Cyber Alert System Failure digg:Cyber Alert System Failure reddit:Cyber Alert System Failure spurl:Cyber Alert System Failure wists:Cyber Alert System Failure simpy:Cyber Alert System Failure newsvine:Cyber Alert System Failure blinklist:Cyber Alert System Failure furl:Cyber Alert System Failure fark:Cyber Alert System Failure blogmarks:Cyber Alert System Failure Y!:Cyber Alert System Failure smarking:Cyber Alert System Failure magnolia:Cyber Alert System Failure segnalo:Cyber Alert System Failure

Fedora 10 GPG Key

Posted by Bill McGonigle Thu, 04 Dec 2008 08:21:00 GMT

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.

del.icio.us:Fedora 10 GPG Key digg:Fedora 10 GPG Key reddit:Fedora 10 GPG Key spurl:Fedora 10 GPG Key wists:Fedora 10 GPG Key simpy:Fedora 10 GPG Key newsvine:Fedora 10 GPG Key blinklist:Fedora 10 GPG Key furl:Fedora 10 GPG Key fark:Fedora 10 GPG Key blogmarks:Fedora 10 GPG Key Y!:Fedora 10 GPG Key smarking:Fedora 10 GPG Key magnolia:Fedora 10 GPG Key segnalo:Fedora 10 GPG Key

Geek

Posted by Bill McGonigle Wed, 15 Oct 2008 03:08:00 GMT

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.

del.icio.us:Geek digg:Geek reddit:Geek spurl:Geek wists:Geek simpy:Geek newsvine:Geek blinklist:Geek furl:Geek fark:Geek blogmarks:Geek Y!:Geek smarking:Geek magnolia:Geek segnalo:Geek

I'm Not E-mailing You

Posted by Bill McGonigle Tue, 16 Sep 2008 03:10:00 GMT

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.

del.icio.us:I'm Not E-mailing You digg:I'm Not E-mailing You reddit:I'm Not E-mailing You spurl:I'm Not E-mailing You wists:I'm Not E-mailing You simpy:I'm Not E-mailing You newsvine:I'm Not E-mailing You blinklist:I'm Not E-mailing You furl:I'm Not E-mailing You fark:I'm Not E-mailing You blogmarks:I'm Not E-mailing You Y!:I'm Not E-mailing You smarking:I'm Not E-mailing You magnolia:I'm Not E-mailing You segnalo:I'm Not E-mailing You

Anti-Virus on Voting Machines

Posted by Bill McGonigle Tue, 26 Aug 2008 01:10:00 GMT

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.

del.icio.us:Anti-Virus on Voting Machines digg:Anti-Virus on Voting Machines reddit:Anti-Virus on Voting Machines spurl:Anti-Virus on Voting Machines wists:Anti-Virus on Voting Machines simpy:Anti-Virus on Voting Machines newsvine:Anti-Virus on Voting Machines blinklist:Anti-Virus on Voting Machines furl:Anti-Virus on Voting Machines fark:Anti-Virus on Voting Machines blogmarks:Anti-Virus on Voting Machines Y!:Anti-Virus on Voting Machines smarking:Anti-Virus on Voting Machines magnolia:Anti-Virus on Voting Machines segnalo:Anti-Virus on Voting Machines

Complete Deniability

Posted by Bill McGonigle Thu, 10 Jul 2008 23:51:00 GMT

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.

del.icio.us:Complete Deniability digg:Complete Deniability reddit:Complete Deniability spurl:Complete Deniability wists:Complete Deniability simpy:Complete Deniability newsvine:Complete Deniability blinklist:Complete Deniability furl:Complete Deniability fark:Complete Deniability blogmarks:Complete Deniability Y!:Complete Deniability smarking:Complete Deniability magnolia:Complete Deniability segnalo:Complete Deniability

Barracuda Moves Against Trend Micro Bogus Patent

Posted by Bill McGonigle Tue, 24 Jun 2008 22:44:00 GMT

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.

del.icio.us:Barracuda Moves Against Trend Micro Bogus Patent digg:Barracuda Moves Against Trend Micro Bogus Patent reddit:Barracuda Moves Against Trend Micro Bogus Patent spurl:Barracuda Moves Against Trend Micro Bogus Patent wists:Barracuda Moves Against Trend Micro Bogus Patent simpy:Barracuda Moves Against Trend Micro Bogus Patent newsvine:Barracuda Moves Against Trend Micro Bogus Patent blinklist:Barracuda Moves Against Trend Micro Bogus Patent furl:Barracuda Moves Against Trend Micro Bogus Patent fark:Barracuda Moves Against Trend Micro Bogus Patent blogmarks:Barracuda Moves Against Trend Micro Bogus Patent Y!:Barracuda Moves Against Trend Micro Bogus Patent smarking:Barracuda Moves Against Trend Micro Bogus Patent magnolia:Barracuda Moves Against Trend Micro Bogus Patent segnalo:Barracuda Moves Against Trend Micro Bogus Patent

Quicktime 7.5 Update Dangerous Precedent

Posted by Bill McGonigle Thu, 12 Jun 2008 00:48:00 GMT

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.

del.icio.us:Quicktime 7.5 Update Dangerous Precedent digg:Quicktime 7.5 Update Dangerous Precedent reddit:Quicktime 7.5 Update Dangerous Precedent spurl:Quicktime 7.5 Update Dangerous Precedent wists:Quicktime 7.5 Update Dangerous Precedent simpy:Quicktime 7.5 Update Dangerous Precedent newsvine:Quicktime 7.5 Update Dangerous Precedent blinklist:Quicktime 7.5 Update Dangerous Precedent furl:Quicktime 7.5 Update Dangerous Precedent fark:Quicktime 7.5 Update Dangerous Precedent blogmarks:Quicktime 7.5 Update Dangerous Precedent Y!:Quicktime 7.5 Update Dangerous Precedent smarking:Quicktime 7.5 Update Dangerous Precedent magnolia:Quicktime 7.5 Update Dangerous Precedent segnalo:Quicktime 7.5 Update Dangerous Precedent

Older posts: 1 2 3 ... 9