Defending against SPAM and dictionary attack SPAM (?)

How exactly does defending against spam work with InterWorx? Does InterWorx refuse SMTP connection for certain types of SPAM sources?

Does InterWorx use any RBLs such as www.spamhaus.org to aid in blocking spam? I suppose this can be manually added into qmail’s config if not already done by InterWorx as a CP option.

How about defending against dictionary spam attacks? Those types of attacks can cause lots of problems, especially if the sender is one of the bot net type – it can cause server loads to skyrocket and leave qmail dealing with many tens or hundreds of thousands of bounced emails to deal with.

There is a patch available for qmail that can block various types of spam before it even enters the server, by simply refusing/closing the connection. That enables the server to avoid the load of processing many messages through qmail, qmailscanner, clamav & spamassassin when it is unnecessary. For example, the receiving email address is checked immediately upon the SMTP connection and if the domain does not exist on the email server or if the domain does exist but the specific email address does not - then qmail refuses the message (no further processing) and closes the SMTP connection. Taking it a step further, the patch also will keep track of how many times a connecting server tried to email bad addresses and after a certain limit (I think I set mine to 10) then qmail denies further connections from that SMTP server for a period of time – effectively blocking dictionary type spam attacks.

Does InterWorx block connecting spam SMTP servers in this way? If not, can the patch be added to the InterWorx install of qmail without botching things up and/or without causing problems during InterWorx updates? Would it work with InterWorx clustering?

In the past I have had a number of dictionary spam attacks that really crippled my (old) server and required me to turn off qmail until all the spam bot servers went away. Now that I have qmail setup on my new server with this patch, all of that is no problem to deal with automatically.

In NodeWorx, the server administrator can configure the SMTP servere to reject mail determined to be a virus by the ClamAV scanner, and to reject SPAM over a certain score as determined by SpamAssassin. The “simscan” program is used to handle these checks, as opposed to qmailscanner.

Does InterWorx use any RBLs such as www.spamhaus.org to aid in blocking spam? I suppose this can be manually added into qmail’s config if not already done by InterWorx as a CP option.

The spamcop rbl is configured to block spam at the SMTP level by default, and the rbl list can be altered via the control panel interface in NodeWorx.

How about defending against dictionary spam attacks? Those types of attacks can cause lots of problems, especially if the sender is one of the bot net type – it can cause server loads to skyrocket and leave qmail dealing with many tens or hundreds of thousands of bounced emails to deal with.

The chkuser patch is applied to the qmail install, which will reject invalid recipients at the SMTP level, avoiding the “bounced email hell” problem you’re referring to. This is enabled by default for each SiteWorx account created.

There is a patch available for qmail that can block various types of spam before it even enters the server, by simply refusing/closing the connection. That enables the server to avoid the load of processing many messages through qmail, qmailscanner, clamav & spamassassin when it is unnecessary. For example, the receiving email address is checked immediately upon the SMTP connection and if the domain does not exist on the email server or if the domain does exist but the specific email address does not - then qmail refuses the message (no further processing) and closes the SMTP connection.

The chkuser patch mentioned above does this.

Taking it a step further, the patch also will keep track of how many times a connecting server tried to email bad addresses and after a certain limit (I think I set mine to 10) then qmail denies further connections from that SMTP server for a period of time – effectively blocking dictionary type spam attacks.

Off the top of my head, I don’t believe the chkuser patch does this.

Does InterWorx block connecting spam SMTP servers in this way? If not, can the patch be added to the InterWorx install of qmail without botching things up and/or without causing problems during InterWorx updates? Would it work with InterWorx clustering?

I can’t say for certain without investigating the patch. It sounds like a good thing, and assuming it’s possible, we would have no problem adding it. What’s the patch called? I see no reason it wouldn’t work with InterWorx clustering.

In the past I have had a number of dictionary spam attacks that really crippled my (old) server and required me to turn off qmail until all the spam bot servers went away. Now that I have qmail setup on my new server with this patch, all of that is no problem to deal with automatically.

We’re already most of the way there John, it’s just the the “denying connections for a period of time” part I’m not certain about.

Paul

How cna add to spamassassin rules for filer somple things like viagra, rolex, enlarge penis, etc etc et ?

PLEASE !

Do you know how chkuser checks for valid recipients? Does it scan the entire system each time, wherever email addresses would be configured, or does chkuser maintain a master list of all email addresses on the server and update that master list whenever addresses are added/deleted?

I didn’t see any info on the chkuser website that details how they go about it. I just wonder if their method is the most efficient.

[quote=IWorx-Paul;14695]I can’t say for certain without investigating the patch. It sounds like a good thing, and assuming it’s possible, we would have no problem adding it. What’s the patch called? I see no reason it wouldn’t work with InterWorx clustering.

We’re already most of the way there John, it’s just the the “denying connections for a period of time” part I’m not certain about.[/quote]

On my current server’s qmail install I use one of the combined qmail patches from qmail Patches The maintainer/author of the combined qmail patch appears to be very active in maintaining and updating it. I recall reading on that site a while ago about the author being very experienced with qmail use in busy ISP environments.

The validrcptto.cdb patch listed on that page is the one that includes the feature to stop listening to and block the SMTP servers that are sending the dictionary attacks. On that site the feature is mentioned as defending against “harvesting attacks,” although I’m sure it’s helpful for both that as well as simply cutting off spammers from using more server resources.

As explained on that site:

The validrcptto.cdb patch modifies qmail-smtpd so that it verifies all RCPT TO arguments against a cdb file which contains every valid email address on the server. This was based on an earlier patch which used a text file, but I changed it to use a cdb file so that it scales better, and I have added a cut-off counter to prevent (or at least slow down) harvesting attacks.
In that quote it also mentioned verifying recipients against a file that contains all valid email addresses on the server. It’s a cdb file, which I believe is some sort of compiled database file using a tool from qmail’s author at http://cr.yp.to/cdb.html in order to create it.

vpopmail is also patched in a way so that any time email addresses are added or deleted from the server the cdb file is immediately automatically updated. It may not make much difference for setups with less traffic, but I’m sure maintaining the master list of server-wide email addresses in a cdb file is a very efficient way of doing it (probably was necessary to do this for some of the patch author’s ISP clients/employers).

Let me know if you need any other info from me regarding all those patches, etc. It’s not all fresh in my mind, as I did my install approx 6 months ago (after spending a lot of time studying all the info on the site), but I did take detailed notes in case I need to do this again at some point.