I have some preliminary code to require MT comments be manually unscreened before they're viewable. The next step is to allow certain comments be automatically unscreened, like comments from logged-in users, or comments signed by whitelisted PGP keys. (I was going to work through an infrastructure for general pre- and post-preview and -post plugins, but that was bogging me down; I'll have to go back and factor that out, if I can care that hard. It's neat though because finally you'll be able to show the user a "Your comment was posted" message.)
Right now I'm stuck on how the authors should edit the new comments data; at the moment you use sqlite (or phpMyAdmin if I'd bothered to make table schemas for anything but sqlite yet) to run the SQL to unscreen the comments. I was hoping to make it totally supplemental to Movable Type, by using a separate MT::Comment::Security object to hold the new data. The problem is MT::App::CMS has no idea to offer you that to edit, and even if it did, it wouldn't know how. I'd be willing to break down and require a modified cms/edit_comment.tmpl template, but I don't see how I can give MT the MT::Comment::Security data to edit without mucking in lib/MT/App/CMS.pm, and that's no good.
At the moment I'm looking at a mode for my MT::App::CommentSecurity program to edit the comment and security bits, and replacing all the links to MT::App::CMS with __mode=view&_type=comment with links to the new comment CGI. Hmm.
It'll be pretty cool if I can figure it out, but no panacea. You could still attack a weblog fortified so by:
- Spamming the screening queue. Besides making it possible, about which I nattered above, comments should be easy to edit in wide swaths, like the "Edit Entries" and power entry editing screens. Still, if I display 100 comments and you can post 1000...
- Server load attack. The above is only on my test server now, but one of the changes I made here is if you assume my setup is the normal, you get added to the MT IP banlist, so even if you figure how to do it "right" you (or those proxies you used, anyway) are already banned. However, MT still has to run to identify that; it'd be nice to make MT write the list to an .htaccess control. (Actually, with a plugin to iterate the banlist and an .htaccess Index Template, that'd be pretty easy...)
- Good old TCP/IP DOS, about which you can do utterly nothing but have your ISP filter it out before your pipe narrows at the end.
Comments
comment
It makes for a heavy install, but have you seen the way that James Seng’s MT-Bayesian slips its links into the interface? If I had a little more faith in it actually working, I’d just rename mt-bayesian.cgi to mt.cgi and let it take over.
Using the IP banlist: don’t.
Oh, you want more detail than just an order? Among the things that people use for spam/crapflood proxies are the cache farms for major ISPs. If I automatically banned IPs that I’ve detected attempting to attack my comments, among other things most of the UK wouldn’t be able to comment on my weblog. Ethiopia, Kuala Lumpur, several large swaths of Russia, I could live with, but I’m not willing to block the whole UK.
comment
I haven’t looked at MT-Bayesian yet, no. From its instructions, it looks like I made something just about exactly like that so far!
Yeah, re banning, I didn’t think of that. Are those actually open proxies, or do you think they have compromised machines on those ISPs they’re reflecting off? I guess it doesn’t matter, unless you’re willing to categorically ban open proxies, and check against lists or actively. I certainly don’t know that I am.
comment
Well, I don’t really know, since pre-FloodMT I didn’t have any need to know, but I’m assuming proxies since that’s the way the FloodMT code’s written. Open proxy server in the cache farm or owned box behind the cache farm really wouldn’t make much difference as far as your concerned, anyway, since all you see is NTL’s cache server. All I actually know is that one of my crapflooders usually sends most of his attempts through cachN-XXXX.server.ntli.net, though others will come in during the same attack from various things that appear in every open proxy list ever published. I do know that I also get what appear to be real requests through the same IPs, with various browsers looking for non-crapflood related stuff (yeah, oops, I banned them in .htaccess for what was going to be just a few minutes, and got called away and forgot for several hours).