Tag: wordpress

where the wild (spammy) things are

Wordfence automatically blocks IP addresses that repeatedly attempt to brute-force logins on UCalgaryBlogs. After a few attempts, they aren’t able to try again for a few minutes (in case it’s a legitimate person trying to log in, it doesn’t banish them entirely right away). If they knock it off, the ban gets lifted. If they keep hammering, the ban gets escalated, eventually putting them in a permanent penalty box (identified by their IP address – not perfect, but it’s all we have).

wordfence-countries-report
Blocked logins by country, August 8-22, 2016

I was half tempted to just drop the ban-hammer on the entire country of Russia, but we have students there (and I wouldn’t want to anger Putin or his tiny-handed American mouthpiece). The US? Buffalo appears to be one of the biggest sources of spam bots – colocated servers (compromised? rented by spammers?) are a big chunk of the attacks we get.

Updating my WordPress plugins

I’ve cobbled a few WordPress plugins together, primarily to do stuff on UCalgaryBlogs by exposing built-in WordPress functionality through shortcodes so that people don’t have to manually edit themes.

And then I basically ignored the plugins for a few years, because they don’t actually do anything, so there’s not much to update or fix. But it looks bad if a plugin hasn’t been tested with recent versions of WordPress, so I just did some testing of them all. They all work on WP 4.4.2, and I’ll re-test after 4.5 drops. I did find some funkiness in one of the plugins, and that’s been taken care of (and I made it a bit more generalizable, so yay progress). I’m hoping to give the plugins some more love – I definitely need to spend more time actually building things instead of just talking about the stuff that people do with the things I made a few years ago…

Post Revision Display may become more active – a new developer was just added to the project, which means some new energy and ideas…

wordpress-plugins-update

Source: WordPress › Profiles » D’Arcy Norman

Mobile photoblogging with iOS and WordPress

I’ve been photoblogging here on my blog for a few years now. This blog serves as the single point of publishing for my photos – they get posted here, then pushed to Flickr, Twitter, and Facebook. I’ve posted over 4,000 photos here (with the most recent shown as thumbnails on the Photos page). Almost all of them have been done through the WordPress iOS app on my phone (and some published from the desktop, through the browser or MarsEdit).

I’ve made a few tweaks to streamline the process – the default category for posts is “Ephemera” – and unless I intervene to set another category (and remove Ephemera), posts don’t get displayed on the front page of this site, nor in the main RSS feeds. This way, I don’t have to worry about spamming the 3 RSS subscribers when I post a bunch of puppy photos.

The process works pretty well, but man, there are a lot of clicks. I did a quick recording to show what it took to post this photo – the process of mobile photoblogging from a phone to WordPress could use some streamlining…

blocking distributed botnet attacks against WordPress (multisite)

I checked the Activity Monitor page1 for UCalgaryBlogs this morning, and noticed that there had been several thousand attempts by people (or “people”) to login using the usernames “admin” (the default WordPress admin account, which isn’t what’s used on UCalgaryBlogs) and “siteadmin” (which is the username for our server – scripts must have sniffed it from blog posts on the main site…)

Curious. I’d installed the fantastic Limit Login Attempts plugin to prevent people from brute-forcing logins, but that plugin only kicks in if the same IP address hits the login form repeatedly. This botnet attack was different – each request had a different IP address, and a different user-agent string. So Limit Login Attempts wasn’t blocking them, and my htaccess user-agent filter wasn’t catching them because they were either valid user-agents, or close enough to get through.

Looks like they were using a dictionary attack, starting at aardvark and working through zyzzyva. Thankfully, I don’t use actual words for passwords, but I decided to change the password to use something stronger than I’d been using. Thanks to 1Password for making that trivial. I don’t actually know the password now. And it has nothing to do with any word found in a dictionary (except that it might use some of the same ascii characters).

Some quick googling for “wordpress distributed botnet protect” turned up a new (to me) plugin called Botnet Attack Blocker. Sounds interesting. It was written in response to some recent distributed botnet attacks, and handles logins spread across different IP addresses.

Installed. Activated on the main blog site. And the attack stopped instantly. I can still login from the campus network even if the plugin kicks in and blocks admin logins. But the botnets can’t continue to brute-force passwords.

Screen Shot 2013 10 16 at 11 48 40 AM

So, now it’s been over 3 hours since activating the plugin. And the attack has (for now) been blocked.

Lessons learned:

  1. Do not (ever) use actual words in passwords. Ever. Generate something secure, and use a tool to store/retrieve them.
  2. Keep up to date on the security environment for the tools – including WordPress. I hadn’t been aware of a distributed botnet attack problem recently, nor of a plugin developed specifically to block that.
  3. Install Limit Login Attempts to stop single-IP-address attacks.
  4. Install Botnet Attack Blocker to stop distributed botnet attacks.
  1. using an old version of the WPMUDev Blog Activity plugin [↩]

Custom “Press This” — Pixel Envy

Nick Heer (another Calgarian WordPress user!) posted a modified WordPress press-this.php file to enable Markdown syntax: Custom “Press This” — Pixel Envy.

custom press-this.php file has been updated to work with WordPress 3.4.

It really just modifies the core WordPress wp-admin/press-this.php file to use Markdown syntax, rather than raw HTML. Not elegant, and will need to be updated if that file changes in future versions of WordPress. But it works, and that’s all that counts.

What it does is around line 600, changing the $content string that’s pushed to the editor:

$content = '';
if ( $url ) 
    $content .= sprintf( "via [%s](%s).\n\n", esc_html( $title ), esc_url( $url ) );
if ( $selection ) {
    $content .=  $selection;
}

Easy peasy. Now, to try modifying it some more, so the great Markdown QuickTags plugin can do its thing on the Press This editor…

Self-hosting video with WordPress and Hippie Hosting Co-op

I’ve been messing around with hosting my own videos, but that’s one area where the third party services have the functionality nailed. They magically transcode video file formats. They create thumbnails. They provided embeds to make it easy to use the video. But, Jim posted about how he’s having to take on some copyfighting, because YouTube is bending over for some pretty outrageous false copyright claims. The only way to prevent a third party from misusing your content is to not use a third party.

So… I took another look for a decent, fully-featured video hosting plugin for WordPress. And, I found one that looks pretty decent – the creatively named Video Embed & Thumbnail Generator plugin. It integrates with the WordPress media library, uses ffmpeg for transcoding and thumbnail generation, and provides a flash- and HTML5- embed for easy use of the videos.

It looks like ffmpeg doesn’t understand the “up” orientation flag on videos shot with an iPhone (and probably other devices), so the only caveat is that you have to be careful to hold the device so that it’s facing “up” (I actually had to figure out what’s the “proper” way to hold an iPhone – turns out, with the volume buttons on the bottom. oops.). Windows seems to have trouble with this, as well, showing photos and videos upside down…

all along the watchtower
[FMP poster=”http://www.darcynorman.net/wp-content/uploads/2012/06/20120616-214038_thumb1.jpg” width=”840″ height=”473″]http://www.darcynorman.net/wp-content/uploads/2012/06/20120616-214038.mov[/FMP]
Right-click or ctrl-click this link to download.

If you’re using the Hippie Hosting Co-op, ffmpeg is now available. After installing the plugin, set your “path to ffmpeg” setting to point to “/usr/bin”, and you’re off and running. Adjust the default settings however you like (I set mine to embed video 840px wide).

[FMP poster=”http://www.darcynorman.net/wp-content/uploads/2012/06/Screen-Recording_thumb4.jpg” width=”840″ height=”525″]http://www.darcynorman.net/wp-content/uploads/2012/06/Screen-Recording.mov[/FMP]

on a blog as a deadman’s switch

I’ve been thinking about what would happen to my online stuff, when I eventually kick off (hopefully not for several decades, but still…). This whole Reclaim stuff would mean that my online artifacts would disappear rather abruptly. That’s partially mitigated through things like the newly-minted Hippie Hosting Co-op, but what happens to my various account info? How would I hand that off, and send a message after, well, you know…

That’s where the idea of the internet deadman’s switch comes in. A bit of code that monitors for signs of life from me, and after I stop doing stuff it assumes I’ve kicked off, waits a predetermined period of time, tries to nudge me by email, and then sends off an email to my family.

It’s the kind of thing that probably used to be done through a hopefully-updated piece of paper filed with a will or stored in a safety deposit box. But it feels like it’s something that could be done rather trivially with some code.

Alan posted something along these lines this morning:

and that’s not a unique service – there’s also Dead Man’s Switch and likely a few others. But I’d rather not put that kind of info on someone else’s server – who knows if their server will still be running in a year, or 5, or 20. And who knows how many people would have access to the information on their server in the meantime.

That’s where the Next of Kin WordPress plugin comes in. It uses my blog as the deadman’s switch. If I haven’t done something on my blog in 3 weeks, it’ll send me an email to ask if I’m still around. It’ll wait a week, then send another, as well as one to a family member. After another week, it’ll assume that something rather dire has happened, and will send an email that I will have prepared in advance. Rather tidy. No fuss. All self contained here.

Of course, this assumes that I’ll still be using WordPress sometime in the future, and hosting my own blog. Safe assumptions for the near future, but who knows what happens if the plugin becomes abandonware and WordPress moves on without it. Or I move away from WordPress. Or this whole internet thing turns out to be just a fad after all…

protecting wp-login.php

I noticed a rather severe spike in CPU usage on my Mediatemple server, and dug in to see what was causing it. For an hour, someone was hammering the login form for my blog, accounting for 98% of all CPU usage for my account during the “attack”. That’s not OK (I have lots of CPU/bandwidth left, but it’s silly to leave a login form exposed to some kind of sustained script-kiddie “attack”).

Guess where the login form “attacks” are… I’m still only using 15% of my allotted CPU time overall, but wanted to stop this before it grew into something else.

I modified my .htaccess file to block all access to the wp-login.php file, unless you are referred to it by a super-top-secret page somewhere on the internet. I combined this tip with a bit adapted from this tip (which is something I already use to protect the University’s Feed2JS install from stupid casino spammers).

Anyway, here’s the trick to locking down your WordPress login form, without having to mess things up too badly.

# protect wp-login.php
<Files wp-login.php>
    Order deny,allow
    RewriteEngine  on
    RewriteCond %{HTTP_REFERER} !^http://secret-server.com/secret-login-page.html$ [NC]
    RewriteRule .* - [F]
</Files>

You’ll want to change the bit that says “secret-server.com/secret-login-page.html” with a URL that holds a file you’ve created. That file will contain a hyperlink to the wp-login.php file on your blog. All attempts to access the login form will be refused, unless someone has followed the link from your secret login page first. Security through obscurity, sure. But the stupid script kiddies will be blocked, and it’s trivial to implement.

There are other tricks that block logins except for those coming from known IP addresses, but that assumes you don’t move around much. This works from any computer, as long as you remember your super-top-secret login link page…

ephemeral photostream

I’ve been tweaking how I manage the ephemeral media here on my blog. Today, I added a page that shows the most recent 50 images uploaded to the site, with links to the post about each image. It’s a bit more like a photostream view, and the page includes links to the larger bloggish photostream view, as well as the RSS feed for ephemeral stuff.

Screen Shot 2011 10 23 at 9 27 47 PM

To do this, I’m just using the native WordPress media manager to handle the images (which happens automagically), and the YD Recent Images plugin and Widgets on Pages plugin to embed the photo/imagestream on the page. This is pretty close to how I imagined displaying images here. Now, to think more about how to better replace the missing community features from Flickr’s Contacts page…