Rrg. More trackback spam, which is causing both server problems and problems using the trackback system to begin with.
Have started playing, again, with renaming the trackback CGI file. Also have implemented the AutoBan plugin, which grabs IP addresses from junk trackbacks and puts them into .htaccess to keep them accessing MT files in the first place.
We’ll see how well (or how long) that works.
51 view(s)
Although the specifics are no longer valid, due mostly to changes in OS security features, a friend of mine used to use a cool trackback that would send a variant of the CIH virus to spammers. I know that on at least one occasion it was successful with pleasantly infuriating (to the spammer) results. Ah, for the days of yore.
Had to rename the TB script again, since I saw some clusters of submissions showing up in the Junk list.
Ideally, stuff never gets to the Junk list. If it’s on the Junk list, it means that the MT process has had to do execute it and throw it into Junk, which is good because it never gets to my blog, but bad because it impacts the servers.
My hope, with Autoban, was to keep folks from getting there in the first place. Ditto with renaming the TB script. I need to look at my system logs (can’t do from the office, annoyingly) so that I can see if folks are failing to find the scripts (a good thing). Other than that, I can only watch for clusters of Junked TBs.
Looking at those junked ones, they are mostly coming from just one Bad Guy. The sites they are pointing at are all in the same IP cluster, but the IPs they are posted from are all over the map. (Are they spoofing their IPs, or just have access to a wide array of IP addresses?).
Indeed, it’s that difference between the source link and the posting link is part of what’s turning them into Junk, thanks to SpamFilter.
In theory, someone could be harvesting the revised TB script name since it’s posted on the comments pages (so that folks can manually submit them). But, then, since I have the trackback discovery code inside the posts, it can be harvested from there, too.
Of course, I could resolve the problem by turning off TB … but I decline to do that. Rrg.
Holy crap. Looking at my error logs, someone is hitting mt-tb.cgi every 1-5 seconds — and getting a “does not have execute rights” error.
I wish I knew if it was cheaper for that error to feed back or if a 404 would be better. Better yet, I wish there was a way to hold back the response for several seconds, to further tie up the bastards’ machines.
Hey, let me know if it helps you out. Typical numbers I have from my various weblogs are from 2,000 to 12,000 junk entries (I use a 60 day setting for culling junk). The largest set of unique addresses I have seen is around 7200, although around 6000 is more typical. I ran with a threshold of 1 for a while, but I think the default of 2 is actually better. It reduces the number of banned addresses to the 1000~2000 range but seems to be just as effective in blocking repeat offenders. Based on these results, I do not believe that the junkers are spoofing IP addresses but instead have access to zombie networks.
If you really want to live on the edge, you could try this. It changes the trackback interface in a way that makes it much harder for the junkers to guess URLs without interfering with legimate trackbacks. Plus, if you have individual archives, you can set up human computable trackback URLs. Still a bit experimental, however.
When I initially installed AutoBan, I set it to a threshold of 1 and ended up with 6000-odd IP addresses banned.
As you note, zombie addresses are a significant problem in tackling this issue.
I’ll have to take a look at that code. I’m usually reluctant to screw around with actual MT modules, but …
Hrm. Having to rename the script every day or two. Not good.
I’m not having problems with junk stuff getting through (I’m ending up with 5-15 junk TBs showing up in “junk” each day), it’s the server burden that worries me. I.e., that my hosting company is eventually going to take action more drastic than disabling my trackback script.
I really hate this. I hate having folks abusing the system preventing me from using something I find useful.
There’s an interesting approach here for renaming the TB script to something random on a chron-job-based schedule. Unfortunately, it’s about a year old, and the config structure in MT has changes since then, and I don’t know nearly enough to screw around with the proposed solution to make it work with my installation.
If you’re only getting order of 10 junk trackbacks per day, that’s undetectable from the hosting company point of view. I doubt it would be noticeable at anything less than 1000 / day, if those are all getting junked (during one rush I was getting around 2000 / day and it didn’t impact the server). Is there something else you think would be burdening the server? Keep in mind that junking a trackback is about as expensive as plotting one page in the MT interface, i.e. you burden the server as much every time you hit a link in the MT interface as a junked trackback does.
Well, among other things I’ve discovered has been a lot of bandwidth theft. And I’ve been seeing a huge amount of hits to mt-tb.cgi since I’ve been tracking it (and since it’s been blocked, thus creating an error message). The Autoban plugin has helped me see that a lot better. 🙂