Setting Up SPF, SenderId, Domain Keys, and DKIM

If you run a mail server, and if you hate spam, you should setup your mail server to make use of all the best anti-spam tools available. There are two sides to spam, sending and receiving.

On the receiving side, you have things like blacklists, spamassassin, bayesian filtering, and lots more. I’ll probably cover this side of things in greater depth in another post.

On the sending side, first and foremost, you have to ensure your server is not acting as an open relay, and allowing spam to be sent through it. After that’s done, you want to be sure that e-mail you send isn’t flagged as spam by people receiving it. And, being a good e-mail citizen, you you want to support the anti-spam standards that are out there.

There are four primary standards for verifying senders and servers.

Sender Policy Framework (SPF) – from their FAQ:

Sender Policy Framework (SPF) is an attempt to control forged e-mail. SPF is not directly about stopping spam – junk email. It is about giving domain owners a way to say which mail sources are legitimate for their domain and which ones aren’t. While not all spam is forged, virtually all forgeries are spam. SPF is not anti-spam in the same way that flour is not food: it is part of the solution.

SenderId – a Microsoft technology which is very similar to SPF:

The Sender ID framework, developed jointly by Microsoft and industry partners, addresses a key part of the spam problem: the difficulty of verifying a sender’s identity.

DomainKeys – from Wikipedia:

DomainKeys is an e-mail authentication system designed to verify the DNS domain of an e-mail sender and the message integrity.

DKIM – an evolved form of DomainKeys, from Wikipedia:

DKIM uses public-key cryptography to allow the sender to electronically sign legitimate emails in a way that can be verified by recipients. Prominent email service providers implementing DKIM (or its slightly different predecessor, DomainKeys) include Yahoo and Gmail. Any mail from these domains should carry a DKIM signature, and if the recipient knows this, they can discard mail that hasn’t been signed, or that has an invalid signature.

SenderId is primarily used by Microsoft mail services like Hotmail/MSN, while DomainKeys and DKIM are primarily used by Yahoo. SPF is used by many mail services.

I’m going to walk you through setting up these anti-spam technologies. I will be setting them up for my domain, digitalsanctuary.com, and using my mail server, which is postfix running on Debian. Your setup and requirements may vary.
Continue reading

Why I love Debian (and PostgreSQL)

I woke up this morning, got online through my new UMTS/HSPDA modem, and discovered that one of my servers had a load average of 239+

Not the best way to start the day.

Turns out an rsync backup job between two servers had gone nuts and was spinning them up through the roof. A couple

sudo killall rsync

commands, and everything started settling down.

What’s important to note is that while the CPU was pegged, and the load average was over 200, I was still able ssh in, run top, ps, netstat, and navigate around looking at log files, with very little delay. It was just a little slow, but no more than a second wait for anything.

Also, all of my apps which used MySQL as their backend were all dead, with “database refused connection” errors. All of my apps which used PostgreSQL as their backend were a little slow, but were all still up and functioning without errors.

So, Debian and PostgreSQL for the win!

Using IPTables to Prevent SSH Brute Force Attacks

If you have a server with a world facing ssh server, you’ve probably seen brute force attacks in your logs. Some machine starts hammering your ssh server, trying all sorts of logins (staff, root, a, admin, etc…) over and over and over again.

This is bad on a lot of fronts.

I use two simple iptables rules to block any IP address who has made more than 3 ssh connections or attempted connections within the past 3 minutes. So your would-be brute force attacker, gets three tries, and then is locked out for a minimum of three minutes. However, since 99% of the attacks are run by an automated bot, it will either: give up after the connection is refused multiple times, or it will keep hammering away on the closed door, which keeps the running count of attempted connections in the past 3 minutes over 3, keeping the door closed.

First:

iptables -I INPUT -i eth1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource

Then run:

iptables -I INPUT -i eth1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name DEFAULT --rsource -j DROP

I’d also recommend using the script in my post on blocking IP addresses using iptables to deal with any persistent folks, or people poking too hard on your web site, or other services.

13 Steps to peace of mind

If you’re uptight about uptime, if you’re anxious about availability, if you nervously watching Nagios, have I got the program for you. Forget 12 step programs, mine has 13!

First let’s talk load balancing. Load balancing is basically distributing some type of load across multiple servers or resources. For the sake of simplicity, we’ll assume that it’s web requests to web servers that we’re talking about, but it’s all equally applicable to databases, mail servers, or just about any other network accessed computing resource (assuming you can handle the back-end synchronization if required, such as with a database).

There are two primary reasons to load balance:

  1. Capacity: one server may not have enough power or resources to handle all of the requests, so you need to break the load out across multiple servers.
  2. Redundancy: relying on a single server means that if it fails, everything is down. A single point of failure can bring down your critical application. Servers fail; both hardware and software. A blown power supply, bad RAM, a dead NIC, eventually something will go out. No software is 100% bulletproof either. If you have two or more servers handling the load, then even if one fails, the other(s) can take over without your application or users seeing any difficulties.

A load balancer sits between your users (human or machine) and your servers. It typically passes requests through to multiple servers and returns the responses to the end user, acting like a transparent proxy. It can distribute load in many different ways, randomly, round-robin, or in more complex ways. It usually monitors the servers so that if a server dies it is removed from the pool and no user requests are sent there.

Load Balancing Diagram

Continue reading

How to identify the process listening on a port

This is mostly for own use, but: If you’ve ever had a server which netstat showed was listening on one or more ports you weren’t expecting, you can use this command to find out which process is listening there:

fuser -vn tcp 4444

Which in this case happens to be owned by JBoss, and not some linux version of a windows worm:)

For more info on fuser, check out the man page, or the simple help below:

Usage: fuser [ -a | -s | -c ] [ -n SPACE ] [ -SIGNAL ] [ -kimuv ] NAME...
[ - ] [ -n SPACE ] [ -SIGNAL ] [ -kimuv ] NAME...
fuser -l
fuser -V
Show which processes use the named files, sockets, or filesystems.
-a display unused files too
-c mounted FS
-f silently ignored (for POSIX compatibility)
-i ask before killing (ignored without -k)
-k kill processes accessing the named file
-l list available signal names
-m show all processes using the named filesystems
-n SPACE search in this name space (file, udp, or tcp)
-s silent operation
-SIGNAL send this signal instead of SIGKILL
-u display user IDs
-v verbose output
-V display version information
-4 search IPv4 sockets only
-6 search IPv6 sockets only
- reset options
udp/tcp names: [local_port][,[rmt_host][,[rmt_port]]]