[ Image: Computer Throne ]

For anyone who dislikes complex mail configurations on their Linux mail server, I have a solution other than amavis* for filtering your email.

As with most things *nix, there are many ways to go about this; my way uses Maildrop and my .mailfilter file in my home directory. The punchline is that incoming mail to my account gets:

1. Scanned by Google (Gmail)
2. Scanned by Spamassassin
3. Run through ClamAV
4. Processed by my filtering rules

…and the beauty of it is that, using Debian, this only takes like 5 minutes to setup. And yes, that includes the installation and configuration of Postfix and Courier-Imap. Essentially, all you need is a single apt-get command and some basic configuration of Postfix and Courier-Imap.

apt-get install postfix courier-imap maildrop spamassassin clamav

That’s it for the packages. From there just set up mail as you normally would. Also, don’t forget to add your clamav user:

groupadd clamav useradd -g clamav -s /bin/false clamav

From there just fire up your editor and edit/create your .mailfilter to include the following content: ---------------------------------------------------

# Run all mail through ClamAV if (/usr/bin/clamscan --no-summary --stdout - | grep -c 'FOUND' == 1) { VSCANNER=/usr/bin/clamscan -V VIRUSID=/usr/bin/clamscan --no-summary --stdout - | grep FOUND | cut -d" " -f2 xfilter "reformail -A 'X-Virus-Checker: $VSCANNER'" xfilter "reformail -A 'X-Virus-Infected: Yes'" xfilter "reformail -A 'X-Virus-Identification: $VIRUSID'" to "Maildir/.Infected"; } else { xfilter "reformail -A 'X-Virus-Checker: $VSCANNER'" xfilter "reformail -A 'X-Virus-Infected: No'" } # Run all mail through Spamassassin xfilter "/usr/bin/spamc -u $user"

if ( /^X-Spam-Flag: YES/ ) { to “Maildir/.Junk” }

---------------------------------------------------

So the cool thing about this setup for me is that it doesn’t require you to hack up your /etc/postfix/main.cf file or anything. You keep Postfix processing pretty much as normal (with the exception of the mailbox_command = /usr/bin/maildrop addition).

Once you hand delivered mail off to Maildrop, your .mailfilter file handles the rest. Spam, Viruses, and standard filtering based on content. The bits I added above will add headers to virus infected emails saying the version of clamscan you’re running, what the message was infected with, etc. Cool stuff.

Now, I’m sure there are plenty of advantages to using amavis — large environments, more complex configurations, etc. But for me, with just a few users and the need to sanitize and process mail, using this method is most excellent. For me, simplicity is golden.

Anyway, that’s pretty much it. If you have any questions feel free to drop me an email.:

I’ve already blogged about helping this project in the recent past, but my buddies at ATU have come together with a more organized effort. So once again I ask you, my fellow geeks, if you enjoy what OpenSSH offers and have a few bucks to spare, please go ahead and give what you can. This is one of the core projects in the security community and they need our help.

Link: OpenSSH Donation Pledge Drive

Well, it’s been nearly a month now since I received my new MacBookPro. As a few of you may know, I had to return my first unit due to a borked optical drive. I was quite upset about it at the time, but was – and am – ultimately happy with the overall experience due to the way that Apple handled it.

Now that I’ve had a few weeks to gauge the overal performance and sftability of the box, I wanted to document the problems that I’m having with the system in an organized fashion. Hell, I’ll probably forward this post to Apple support to save time.

1. Processor “Whine” : This is the often-complained-about issue where the MBP will make a very annoying sound when not being pushed very hard. It’s almost as if it’s complaining about not being used to its potential. This particular problem I’m willing to wait to have fixed, i.e. I’ll give it a few weeks for things to settle down at Apple with the new release before asking for a solution. No biggie, but I’m damn sure not leaving it this way for the life of the system.
2. Wireless Card Issues : I actually just found out tonight that I have this problem. I can’t stay connected to my Linksys wireless access point. Other Windows and *nix machines work perfectly with the AP, as does my old 12″ PowerBook G4. This is unacceptable. I need this fixed immediately. How could they ship a wireless system that won’t stay connected for more than 5 minutes at a time to the most commonly deployed AP in the country? Bad form indeed.
3. Heat Issues : Well, I wouldn’t call it an issue. The systems are just hot. I mean nuclear hot. As in, “Don’t touch it because it’ll hurt you.” hot. This I’m actually not too worried about. It doesn’t effect performance as far as I can tell, and I am going to just chalk it up to having so much going on in such a thin case. I’ll label this an “almost non-issue”.
4. Sleep Recovery : For some reason, I’ve come out of sleep a few times and been prompted for my password (I’ve set it up to do that), only to be prompted for my password again like 2 seconds into my recovered session. It’s like it didn’t register that I had already re-authenticated or something. Bad form. It’s just an annoyance, to be sure, but it lends support to the whole, “This product’s not quite ready” sentiment. I’d like to see a fix for this in the next month or so. No rush, but I don’t want to live with it forever.

What I’ve Learned

The moral of the story here is very simple — it’s true that version A products are buggy.

Millions of people already knew that, and some of them even tried to warn me, but now I know, based on first-hand experience, that it’s true. Don’t ever doubt it. Some launches may be better than others, but as a whole it’s probably going to be the case.

It’s not that I doubted it either, actually; I understood the logic behind the claim as much as the next guy. But I didn’t think the issues would be this major. I didn’t think I’d be unable to read CDs, or that my wireless would drop connection every five minutes. Those are issues that I would have bet against — and lost money.

Why I’m Still Happy

But I’m still happy. Why? Because in all of my conversations with Apple thus far I’ve heard a consistent, overriding message.

“We’ll get it taken care of. We’ll make sure you’re happy.”

This is precisely what I want to hear, and it’s what I should be hearing. What it means to me as a consumer is that I can worry less about flaws with my system. I can relax, enjoy my computer, and have faith that the company I bought it from will make things right. If it takes a few weeks then that’s cool. If there are a few glitches in the process, then that’s cool too. As long as they don’t say, “Well, you bought the first version so that’s on you.”, I’m ok with having a few problems.

Lessons

Ultimately I’ve learned two things from this ordeal thus far.

1. Be wary of version A products. They really do have issues.
2. You can trust Apple to treat you right — even if you do buy a version A product.

Anyway, I’ll keep this post updated as I work to get these issues resolved. Hopefully everything will go smoothly from here on out, and if you have any similar or related MacBookPro stories I’d love to hear them.:

http://flickr.com/photos/visualseed/86410009/in/pool-tuawrigs/

Many people are familiar with the concept of a mnemonic [nəˈmɑnɪk] — a memory device that uses a phrase based on the first letter of words in a list. Perhaps the most popular of these in the field of networking is the one for the OSI Model. The mnemonic is:

All People Seem To Need Data Processing.

Well, for those that deal with TCP a lot, I thought it might be helpful to have a mnemonic for the TCP flags as well. What I’ve come up with is:

Unskilled Attackers Pester Real Security Folks

Unskilled = URG Attackers = ACK Pester = PSH Real = RST Security = SYN Folks = FIN

The way this helps me the most is when isolating traffic to capture using Tcpdump. It’s possible, for example, to capture only SYNs (new connection requests), only RSTs (immediate session teardowns), or any combination of the six flags really. As noted in my own little Tcpdump tutorial, you can capture these various flags like so:

Find all SYN packets tcpdump 'tcp[13] & 2 != 0'

Find all RST packets tcpdump 'tcp[13] & 4 != 0'

Find all ACK packets tcpdump 'tcp[13] & 16 != 0'

Notice the SYN example has the number 2 in it, the RST the number 4, and the ACK the number 16. These numbers correspond to where the TCP flags fall on the binary scale. So when you write out:

U A P R S F

…that corresponds to:

32 16 8 4 2 1

So as you read the SYN capture tcpdump 'tcp[13] & 2 != 0', you’re saying find the 13th byte in the TCP header, and only grab packets where the flag in the 2nd bit is not zero. Well if you go from right to left in the UAPRSF string, you see that the spot where 2 falls is where the S is, and that’s how why you’re capturing only SYN packets when you apply that filter.

Remembering these flags and how to isolate them can go a long way in helping low-level network troubleshooting/security work by isolating what it is you want to see and/or capture. And of course the more you can isolate what you want to see, the faster you can solve the problem. I encourage anyone not making use of this powerful feature already to go ahead and add it to their repertoire.

Many of us are familiar with a concept know as Security by Obscurity. The term has quite negative connotations within the security community — often for the wrong reasons.

There’s little debate about whether security by obscurity is bad; this is true because it means the secret being hidden is the key to the entire system’s security. Obscurity itself, however, when added to a system that already has decent controls in place, is not necessarily a bad thing. In fact, when done right, obscurity can be a strong addition to an overall approach.

So what’s the difference?

Security *Through* Obscurity

An example of security by obscurity is when someone has an expensive house outfitted with the latest alarm system, but they keep the key and alarm code in the planter box next to the front door. This is security by obscurity because if anyone knows the secret, i.e. that the key and code are stored in the planter, then the security of the system is compromised.

That’s security by obscurity: if the secret ever gets out, it’s game over. The concept comes from cryptography, where it’s utterly sacrilegious to base the security of a system on the secrecy of the algorithm.

Obscurity As A Layer

Obscurity as a layer, however, can be used to enhance security that already exists. One excellent example of this is Portknocking.

Portknocking allows one to hide their network services behind an additional layer of quasi-authentication. Using the technology you can have an SSH server sitting live on the Internet that portscanners literally can’t find. This works because your firewall sits between the Internet and your listening SSH server.

Your firewall listens to the incoming requests and ignores all standard SSH attempts to your box. If, however, you ask in a very specific way, i.e. using the secret “knock”, it’ll open access to the server for your source IP.

The part that most people miss is that you still have to authenticate to SSH. You didn’t replace SSH’s security with portknocking, you simply added it as a layer. Remember, the NSA most likely has great algorithms but they still don’t publish them.

So the next time the subject comes up, remember a simple concept: security by obscurity is bad, but obscurity itself — when added as a layer on top of existing security — can be quite useful. Those who dismiss obscurity out of hand are regurgitating something they’ve heard rather than thinking through the concepts themselves.: