Wandering Thoughts archives

2007-01-06

Weekly spam summary on Janury 6th, 2007

This week, we:

  • got 12,487 messages from 217 different IP addresses.
  • handled 16,802 sessions from 997 different IP addresses.
  • received 224,173 connections from at least 71,302 different IP addresses.
  • hit a highwater of 23 connections being checked at once.

The university came back from vacation this past Thursday, and of course the spammers never went on much of one to start with. I suspect that volume is up somewhat from last week, but given that this is the first time in a couple of weeks that we have full stats it's hard to be sure.

Day Connections different IPs
Sunday 31,473 +11,976
Monday 30,086 +10,263
Tuesday 36,900 +11,800
Wednesday 33,074 +10,070
Thursday 33,327 +9,978
Friday 34,889 +9,865
Saturday 24,424 +7,350

Kernel level packet filtering top ten:

Host/Mask           Packets   Bytes
213.4.149.12          24349   1266K
193.70.192.0/24       11208    505K
213.29.7.0/24         10387    623K
69.15.68.98            7857    367K
212.43.241.13          7615    418K
66.7.28.46             4040    205K
193.252.22.158         3383    203K
69.15.6.139            3252    156K
212.175.13.129         2470    148K
212.184.12.130         2289    110K
  • 213.4.149.12, 212.43.241.13, and 193.252.22.158 all return from last week, although they've shuffled their order this time around.
  • 193.70.192.0/24 is iol.it aka tin.it, who we haven't talked to for a long time.
  • 213.29.7.0/24 is centrum.cz, with their volume surging back up from last week's temporary drop.
  • 69.15.68.98 and 212.175.13.129 (last heard from in September) had too many bad HELOs.
  • 66.7.28.46 is in the NJABL.
  • 69.15.6.139 kept trying to send us phish spam that had already hit our spamtraps.
  • 212.184.12.130 reappears from October and still has no reverse DNS information.

Overall volume here is up somewhat from last week.

Connection time rejection stats:

  61627 total
  38124 dynamic IP
  17309 bad or no reverse DNS
   4543 class bl-cbl
    378 class bl-dsbl
    316 class bl-sdul
    166 class bl-sbl
     84 cuttingedgemedia.com
     49 class bl-njabl
     24 class bl-spews
     21 'fairgamemail.us'

Only one out of the top 30 most rejected IP addresses was rejected 100 times or more: 64.166.14.222 (941 times, a Pacbell DSL line). 20 of the top 30 are currently in the CBL, 10 are currently in bl.spamcop.net, and one is in the SBL: 209.205.236.245, which also did this last week.

The leading actual SBL rejections this week are:

97 SBL43537 a /19 escalation listing against SWIFT VENTURES Inc for spammer hosting (31-Dec-2006)
19 SBL42599 a /24 ROKSO listing for Brian Kramer / Expedite Media Group (08-Dec-2006)
14 SBL49046, SBL37655, SBL38413 an escalating series of listings for ServerFlo, which Spamhaus suspects is a spammer front (23-Nov-2006 for the SBL38413 /20 listing)

This week Hotmail brought us:

  • 4 messages accepted.
  • no messages rejected because they came from non-Hotmail email addresses.
  • 19 messages sent to our spamtraps.
  • 2 messages refused because their sender addresses had already hit our spamtraps.
  • 1 message refused due to its origin IP address being inside telkom.co.za.

And the final numbers:

what # this week (distinct IPs) # last week (distinct IPs)
Bad HELOs 332 130 594 87
Bad bounces 16 11 72 60

Now that's the kind of change I like to see compared to last week. As you might expect, there are no really big sources of bad HELOs, and there are so few bad bounces that I can put the usernames in a handy table:

4 markf
4 ijiefuurmcl
3 wtn-editors
2 noreply
1 user
1 morgaine
1 ctn-editors

This is pretty atypical; four of these are actual usernames that used to exist here, and only one is an alphabetical jumble.

spam/SpamSummary-2007-01-06 written at 23:25:20; Add Comment

Fixing up .rpmnew files

For some reason, rpm in Fedora Core 6 (and I believe Fedora Core 5 too) has become overly twitchy about replacing configuration files; a lot of the time it will write .rpmnew files instead of just replacing the old version of the file even if the old file is unchanged and the new and the old file are completely identical.

While I think this is multiarch stuff in action, I still have to clean it up every so often. I use a little scriptlet for this, usually typed at the command line:

for i in *.rpmnew; do
  n=$(basename $i .rpmnew)
  if cmp -s $i $n; then
    mv -f $i $n
  else
    diff -u $n $i
  fi
done

(Yes, this can be done on one line if you're crazy enough. I admit that I usually turn the if block into either 'diff -u $n $i' or, once that's shown me nothing important, 'cmp -s $i $n && mv -f $i $n'. And if it was an actual script, I would have to start making it more elaborate, with features like a dryrun option.)

At first I thought I had an idea why this was happening, but the more I look at the rpm source code and the RPMs involved in my most recent case, the more confused I get. As far as I can decode from the rpm source code, this can't happen unless either the actual file on disk has been changed (which it hasn't), or there's an existing config file before the package is installed for the first time (not applicable for package upgrades). It does seem to only involve things that have RPMs for more than one architecture installed, though, although I haven't tested that extensively.

linux/RpmnewFixup written at 00:17:16; 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.