die ewige Zier

Zombies are impossible to avoid in this day and age, even (maybe especially) online. Anyone who maintains a publicly accessible server and pays even passing attention to their security logs can attest to the repeated brute force login attempts for everything from SSH to WordPress admin panels. Having a strong SSH password, disabling root logins, and changing the default port works wonders, but doesn't help with my WordPress installation, which is where I most often get hit these days.

In the past, these naive attacks were fairly easy to block using tools like fail2ban or using plugins like Limit Login Attempts, which put IP addresses on a blacklist for too many failed login attempts. Unfortunately, of late it seems like the crackers have caught on, and are now bringing the full force of the zombie hordes to bear: each zombie computer only tries logging in to a particular website once, preventing an IP blacklist from having any effect.

Thus, I've had to resort to more drastic action: IP whitelists by placing the following code in the .htaccess file of my WordPress directory:

<Files wp-login.php>
order deny,allow
deny from all
allow from 127.0.0.1
</Files>

127.0.0.1 should obviously be replaced with your IP address unless you only access WordPress Admin from the server itself (either directly or through a proxy like Socks5). I have a dynamic IP address, but now use a Socks5 SSH tunnel for working on WordPress. Anyone else trying to login will now get a 403 forbidden page, not only adding to my peace of mind, but also saving me the processing time and bandwidth of serving up the login page to would-be crackers. 😀

My school webmail uses Outlook Web Access (OWA) by default to access Microsoft Exchange 2010. Although this is clearly suboptimal, I do find myself using OWA occasionally when I'm not in my office and need to quickly send an email (I don't particularly like drafting emails on my phone).

Unfortunately, I would randomly get the error message "The action couldn't be completed. You might have updated the item on another computer or a mobile phone."

It usually only happened for longer messages, but would occasionally pop up nearly immediately after I began composing. I'd then have to copy and paste the entire message and start up a new message, hoping that I'd have enough time to hit send. A cursory Google search wasn't too helpful, and since I only rarely used OWA, I didn't bother to actually troubleshoot the issue.

Since I've had a little more time after finals, a little testing quickly revealed that the problem is trivially solved by telling my phone not to access the "Drafts" folder. Turns out that I'd enabled push synchronisation on K9-Mail on my Android phone for the Drafts folder. When OWA saved the draft for the message in composition, K9-Mail would automatically download the message; even without any editing, that seemed to be sufficient to make OWA unhappy.

My quick hack has been to create a Drafts-Mobile folder for my phone email client to use, so that it never tries to access in-progress compositions from OWA. However, it still seems just a bit strange that OWA would be so sensitive to syncing from a mobile phone without any modification of the draft. After all, I didn't actually "update" the item on another computer or phone, and it seems to me like the target audience for Microsoft Exchange is fairly likely to have smartphones. Easy enough to work around, I suppose, but here's to hoping Microsoft fixes this in a future release!