Weekly spam summary on October 21st, 2006
This week, we:
- got 14,794 messages from 260 different IP addresses.
- handled 20,016 sessions from 1,207 different IP addresses.
- received 186,129 connections from at least 47,733 different IP addresses.
- hit a highwater of 37 connections being checked at once.
Volume is around that of last week; I don't know what to make of the increasing highwater. The volume doesn't fluctuate too much from day to day:
Kernel level packet filtering top ten:
Host/Mask Packets Bytes 188.8.131.52 34927 1816K 184.108.40.206 17256 807K 220.127.116.11 12822 652K 18.104.22.168 4877 293K 22.214.171.124/10 4649 250K 126.96.36.199 4357 209K 188.8.131.52/24 3930 196K 184.108.40.206 3483 209K 220.127.116.11 3481 177K 18.104.22.168/11 3452 170K
Apart from our leading dislike maybe finally giving up, volume is clearly significantly up from last week.
- 22.214.171.124 and 126.96.36.199 return from last week, and are also the only two returning IP addresses.
- 188.8.131.52 kept trying to send us stuff that had already hit our spamtraps.
- 184.108.40.206, 220.127.116.11, and 18.104.22.168 all APNIC IPs with
no reverse DNS (by now I am perilously close to recognizing APNIC
IP ranges on sight). The first is on
bl.spamcop.net, the latter two are in the NJABL.
- 22.214.171.124 is a wanadoo.fr dialup; two big strikes against it for the price of one.
Connection time rejection stats:
37843 total 18462 dynamic IP 15326 bad or no reverse DNS 2162 class bl-cbl 326 class bl-dsbl 325 class bl-sdul 252 class bl-njabl 188 class bl-spews 76 class bl-sbl 66 class bl-ordb
There was only one IP address out of the top 30 most rejected IP addresses that was rejected 100 times or more; 126.96.36.199 (a Verizon DSL line that is also in the CBL et al) at 118 times. 18 of the 30 most rejected IP addresses are currently in the CBL and 3 are currently in bl.spamcop.net.
The SBL picture:
|16||SBL45324||'Lucky Solution', a US spammer||03 Sep 2006|
|15||SBL42599||'Lucky Solution' again||13 Oct 2006|
|9||SBL36016||Polish spam? outfit||Dec 2005|
|7||SBL47519||US spam source||17 Oct 2006|
|7||SBL47482||Polish spam source||16 Oct 2006|
|7||SBL41338||Russian advanced fee fraud source||4 May 2006|
|6||SBL39631||Czech spam source (compromised machine)||29 Mar 2006|
In summary: many 'real' spammers, and you have to go fairly far down before you find an advance fee fraud or phish spam. Most of the SBL listings for spammers are relatively new, with only a few old ones.
This week, what we got from Hotmail was:
- 2 messages accepted, one of them definitely legitimate.
- 1 message rejected because it came from a non-Hotmail email address; unfortunately it was from 'theroyalpeakraffledraw.com', so it looks like Hotmail may be backsliding to old habits.
- 29 messages sent to our spamtraps.
- 2 messages refused because their sender addresses had already hit our spamtraps.
- 2 messages refused due to their origin IP address (one for being from Nigeria, one for being in the CBL).
About an average week, I suppose.
And the final numbers:
|what||# this week||(distinct IPs)||# last week||(distinct IPs)|
One trend is good, the other trend is bad; that's sort of how it goes
in general. The leading source of bad
HELOs was 188.8.131.52, with
93; no one else came close. The least amusing was 184.108.40.206, with
HELO name of 'mail-test.gbxsc.friendster.com', and it
does indeed seem to be a friendster.com machine.
The bad bounces continue to be pretty much like last week, although this time around there were no hex strings.
An irritating iptables limitation
I have a machine that runs both a caching DNS server (to answer local queries) and an authoritative DNS server; the caching server is bound to localhost:53, and the authoritative server to my-IP:53. Recently I wanted to let another machine use the caching DNS server.
The obvious general approach is to remap queries from the specific IP so that they hit the caching nameserver instead of the authoritative one. I can see two ways of doing this with Linux iptables: DNAT and REDIRECT. Unfortunately neither work:
- REDIRECT redirection doesn't work because it 'redirects the packet to the machine itself by changing the destination IP to the primary address of the incoming interface' (emphasis mine), not to localhost. In effect REDIRECT is a no-op here.
- DNAT redirection to localhost doesn't work at all, apparently because the kernel discards outside packets to localhost as 'martians', which matches the behavior I saw. Nor can you combine the DNAT rule with a SNAT rule to rewrite the source address to 127.0.0.1 to get around it, as far as I can tell.
Now, there are hacky ways around this. One of them would be to give the machine an additional completely private IP address, have the caching DNS server listen on it too, and use DNAT to reroute packets to that instead of localhost. But the need for that sort of workaround irritates me.
(The one useful thing to come out of this is that I had it pointed out to me that REDIRECT doesn't have to change the destination port; for some reason I had had the impression that it did.)