I’m not sure. I’ll have to think about it a bit more.
The pingbacks system is too open and easily abused, so should it have been included as a feature in the first place? I don’t see much use for it. I can see perhaps someone wanting this feature, but it just opens too many opportunities for abuse.
In my case though, I had pingbacks disabled in the control panel.
Under Discussion settings, there are two settings.
Attempt to notify any blogs linked to from the article
Allow link notifications from other blogs (pingbacks and trackbacks) on new articles
Both of these are unchecked (disabled). Yet, when I was being attacked, even with these settings disabled, my server load was off the charts. Perhaps we could store these settings in a file so they are easily retrieved quickly? If these settings are disabled, we don’t process the request at all? Currently, it seems that with these settings unchecked, there’s still some kind of logic / database initialization going on which isn’t very efficient.
The Disable XML-RPC Pingbacks Plugin removes this logic entirely, but why doesn’t disabling the settings have the same effect? It doesn’t need to remove the function, it merely needs to not process the requests which is inefficient for the server.
With that being said, has anyone come up with an iptables rule to rate limit specifically pingback requests? If not, maybe this is what I’ll work on next.
Since the pingbacks system has no way to prevent abuse, maybe pingbacks should be disabled by default when WordPress is first installed?
Another possible solution would be to the write a file when a pingback request is received with the name of {IP_ADDRESS}.txt which contains a timestamp. {IP_ADDRESS} being the IP address from the client sending the request (PHP can grab this easily). When a pingback request is received, we check to see if the file exists, and if it does, we check to see if the current timestamp is greater than the old timestamp + 60 seconds. If it’s not, we discard this request because not enough time has passed. If it is, we process the post back and write the new timestamp to the file. If the file doesn’t exist, we create the file with the current timestamp and process the request. Then, WordPress could run a “cron” like function like it does for updating WordPress to delete these files to cleanup every once in a while. This will limit a source to one pingback request per minute, which seems more than fair. Thoughts on this potential solution? Seriously, file system operations are very fast and so are timestamp operations, so I could see this working. This would also prevent a single attacker or multiple attackers from having a noticeable impact on the server.
There’s gotta be someway to prevent the abuse from hammering the server.
EDIT: Also, would it be possible to unlock the old forum thread and merge the majority of the posts in this thread to it? I think it’s an ongoing issue that needs to be discussed or addressed. At the very least, post a link in that closed thread to here? And maybe this post needs to move? Just thinking out loud here.
