Wandering Thoughts archives

2006-10-21

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:

Day Connections different IPs
Sunday 25,762 +7,003
Monday 27,945 +6,735
Tuesday 29,442 +7,764
Wednesday 26,593 +6,847
Thursday 28,700 +6,709
Friday 25,001 +6,578
Saturday 22,686 +6,097

Kernel level packet filtering top ten:

Host/Mask           Packets   Bytes
213.4.149.12          34927   1816K
72.244.103.210        17256    807K
194.109.24.30         12822    652K
212.175.13.25          4877    293K
61.128.0.0/10          4649    250K
212.184.12.130         4357    209K
212.216.176.0/24       3930    196K
219.94.131.171         3483    209K
80.13.134.100          3481    177K
84.160.0.0/11          3452    170K

Apart from our leading dislike maybe finally giving up, volume is clearly significantly up from last week.

  • 213.4.149.12 and 72.244.103.210 return from last week, and are also the only two returning IP addresses.
  • 194.109.24.30 kept trying to send us stuff that had already hit our spamtraps.
  • 212.175.13.25, 212.184.12.130, and 219.94.131.171 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.
  • 80.13.134.100 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; 71.101.253.74 (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)
Bad HELOs 335 52 640 68
Bad bounces 255 169 172 140

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 65.23.46.163, with 93; no one else came close. The least amusing was 209.11.168.39, with the claimed 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.

spam/SpamSummary-2006-10-21 written at 23:28:49; Add Comment

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.)

linux/IptablesLimitation written at 22:01:27; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.