This was done by Clee, my coworker. I tweaked it, prefacing things with dh to make it more portable and then slapping it into a shortcode so I could embed it here:
The code is as follows (you can see his original code at codepen):
Credit: Nivole Lorenz 2010. Pencil sketch on copy paper. Sometimes I draw unicorns. Sometimes they have jetpacks.WordPress Jetpack gets a lot of grief, and for an understandable reason. From some perspectives, it does everything we hate about plugins. But there are reasons and methods behind the madness. I’m going to hit them from my perspective as best I can, without ever considering the ‘Automattic sucks!’ arguments I’ve heard. I’m reasonably sure Automatic is neither trying to be a dick nor are they evil (egotistical maybe, but not evil). If you go in assuming there has to be a reason for all this, even if you don’t like it, you can understand it a little better.
Why one big plugin and not 20+ separate ones?
Actually I’m going to come back to this one, but there’s a reason, so hang on.
Why do I have to connect to WordPress.com?
This is a better place to start. You have to connect to WordPress.com because they’re providing a service. Not everything runs on your server, so in order for the modules to work, you have to let your server talk to WordPress.com. That one makes sense to just about everyone, I hope.
Less obvious is exactly how this benefits you. I’ll give you a real annoying example: Twitter’s API. You may not know, but Twitter throttles API usage based on IP address. So if you’re on a shared server, and everyone uses Twitter on their blogs, you may get your API cut off and no Twitter updates show on your site. Bummer! On the other hand, WordPress.com has a gimmie from Twitter, letting them post as much as they want.(Probably not unlimited, but enough for us.) This is also true of Highlander (aka the comments plugin), which transmits data between multiple hosts instead of you having to set up OAuth, which if you’ve tried, you’ll see why Jetpack Comments are way easier.
But why do I have to connect to use any of the modules?
This usually comes up when someone only wants to use one feature, let’s pick the contact form, which doesn’t need to communicate with WordPress.com to run. The best reason I had is ‘It’ll make it easier if you later decide to turn on the other features later.’ I tossed this around for a while, considering the users I work with every day, and I’ve finally agreed that for the common user, it’s better to have to do one setup, once, and be done.
After years of free support, and now doing this for a living, the common user doesn’t have the experience to understand that while I may need to connect to WordPress.com for the stats, why do I need it for a mobile theme? The problem comes up when the user wants to start with the items they don’t need to connect. Springing it on them later is an uphill battle I wish I didn’t have to make. So yes, it’s sensible for the average user. As Helen said, Jetpack is for users, not developers.
Anyway, if you know for sure you (or your client) will never want to connect to .com, then you can use the new development mode (as of version 2.2.1) and add define( 'JETPACK_DEV_DEBUG', true); to your wp-config.php file. Done.
If the .org repository doesn’t let people host marketplace plugins, what’s up with VaultPress?
VaultPress is selling a service, not a plugin. It’s hairsplitting, but look at Akismet (which also could be a pay-to-use product). It’s ‘free’ but you’re encouraged to pay. If they went pay-only, which I could easily see them doing if they started over, they would be a perfect candidate for Jetpack. Where VaultPress rubs the ‘Hey wait…’ button is when you remember that there is a separate plugin for it. So this is like if they let you signup for Akismet within Jetpack… Oh, wait, Akismet’s links are in the Jetpack menu now. Still, of all the questionable things Jetpack does, this is actually the only one that really makes me Spock the Eyebrow(Yes, that is what the favicon is.) because it’s just a little off.
Why the auto-activate?
Users won’t know otherwise. If you don’t turn things on, they’ll never see it. I don’t like it, especially when I’m using a plugin that got folded in (see CSS editor or Grunion), but they learned the Grunion lesson! When the CSS editor joined Jetpack and I upgraded, it turned off the old editor. That was smart, and takes away my User-Ipstenu complaint of auto activation. Remember! This is a user plugin. Not a developer one. Calm yourself.
Why is it one big plugin?
This needs some history.
A few years ago, the concept of ‘Canonical Plugins’ (or Core Plugins depending on if you asked a core contributor or anyone else) came up, and it was an idea for stuff that is (or used to be) in core, but wasn’t used all the time. Examples of this would be the content importer plugins which are used once or twice in a site’s lifetime. To quote the original poll and announcement:
Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution.
That was 2009, and here it’s 2013 and we don’t really have any yet. Jetpack certainly isn’t one, though in many ways it hits those ‘popular functionality’ feelers dead center. In a way it is a canonical plugin, but it also clearly illustrates why some of the most popular plugins would be very difficult to pull off without the infrastructure that Automattic already has. So while I wouldn’t call Jetpack a ‘Core Plugin’ (it’s not community developed), it’s sort of a great example of what a core plugin suite would look like and the issues with it.
Now, why is it a ton of plugins in one? Well why not? A lot of people hate installing six or seven plugins because “it makes their site slower” (not really), and the way Jetpack does it is remarkably elegant, in that you can turn off the parts you don’t use. The problem I have with Jetpack is it’s size. It’s big. It’s almost the size of WordPress and at 4.2 megs, it’s slow to install. I find that it’s way easier for me to run via wp-cli and upgrade, but not everyone has that option.(That said, I don’t have a problem upgrading on my smaller sites when they don’t get a ton of traffic. Upgrading on my busiest site while it’s busy is always stupid and I know it.) The size problem is also a hassle because WordPress doesn’t (yet?) do incremental updates for Plugins. When you have a series of upgrades then security fixes on a large plugin, it’s annoying.
More likely is the idea that these plugins can share APIs and features if you lump them together, making one big plugin smaller than twenty-odd separate ones.
What is this dev mode of which you speak?
Oh it’s neat. Put define( 'JETPACK_DEV_DEBUG', true); into your wp-config.php file and here’s what happens:
Everything defaults to OFF
You can only activate the following:
Carousel
Sharing
Gravatar Hovercards
Contact Form
Shortcodes
Custom CSS
Mobile Theme
Extra Sidebar Widgets
Infinite Scroll
The only ones missing that surprised me was LaTeX (I guess it phones home to parse…) and the new Tiled Galleries. Why is that cool? Well now you don’t need to connect to WordPress.com to run those things!
Are you drinking the kool-aid?
Oh. Probably. I honestly like Jetpack. I hate having to set it up for clients (I end up in an Incognito Window, creating a new WP.com account for them, and that whole hassle), but once it’s done, it’s really worthwhile. It does everything I need and while there are parts I don’t need, I’ll live with it. That said, having it set up for people like my father means there’s less I have to worry about with finding plugins for him. Most of what he needs is right there in Jetpack.
I hate Jetpack, I’m never going to use it!
Okay. Don’t use it.
I’m not defending it’s uses for all cases. If Jetpack doesn’t fit what you need, don’t use it! That’s totally fine. I just hate reinventing wheels. There are always alternatives to what Jetpack’s got (Contact Form 7, Google Analytics, and so on), so you can use any tool you like. There are pros and cons with everything, and it’s up to you to decide where your own break point is.
I had a need. A need for timezones. I happened to post about an event happening at 2pm ET, under the mistaken assumption that people knew how to convert timezones, or at least go to a website for it. Instead, after a weekend full of emails and me snapping at them for being under educated (don’t schools teach this stuff anymore?) I linked them to a page.
Then I thought “Well heck, they won’t click that. Why not embed it.” Alas, TimeAndDate.com didn’t let you embed, but worldtimebuddy.com does. With a hat tip to Rarst for the link, I pulled this shortcode out:
// World Time Buddy Event Time
// Usage: [eventtime time="14:00" length="1" date="2/20/2013" tz="ET"]
function eventtime_func( $atts ) {
extract( shortcode_atts( array(
'time' => '14:00',
'length' => '1',
'date' => '2/20/2013',
'tz' => 'ET',
), $atts ) );
if ( $tz == 'ET') $timezone = '5128581';
if ( $tz == 'PT') $timezone = '5368361';
return '<span class="wtb-ew-v1" style="width: 560px; display:inline-block;padding-bottom:5px;"><script src="http://www.worldtimebuddy.com/event_widget.js?h='.$timezone.'&md='.$date.'&mt='.$time.'&ml='.$length.'&sts=0&sln=0&wt=ew-lt"></script><i><a target="_blank" href="http://www.worldtimebuddy.com/">Time converter</a> at worldtimebuddy.com</i><noscript><a href="http://www.worldtimebuddy.com/">Time converter</a> at worldtimebuddy.com</noscript><script>window[wtb_event_widgets.pop()].init()</script></span>';
}
add_shortcode( 'eventtime', 'eventtime_func' );
I can’t make this a plugin because it has a powered-by link, and while I could remove it, I won’t. If the link was put in by the script itself and not my return, it’d be fine for the repo, but since I’m only going to use this a few times, I’m leaving it be.
This is something that Tony Perez and Sam “Otto” Wood both recommend, so you know I have to look at it seriously!
I think I need to point out that I’m willing to accept that I’m wrong about things. After all, I can’t know everything, and I am well aware of that. But one of the things I work hard to do is learn, adapt, grown and get better at all this. The whole reason I started talking about tech on this site was I was trying to understand cloud hosting back in August of 2010(A lot of tech posts were ported over from Ipstenu.org after the fact.).
The point is I do this site because I want to learn, and when I learn, even if I don’t understand all of a thing, I want to share what I’ve learned specifically because I know people will come and correct me. Next to answering people’s questions, this is the fastest way I know of to really understand things.
So.
I didn’t mention Two Factor Authentication in my security post. Using it certainly would have mitigated the brute-force attack, though not the DDoS implications of it, and that remains why I am a fan of ModSecurity. That doesn’t mean I didn’t just add another tool to my arsenal, or that I’m not willing to try something out.
I am now using Two Factor Authentication.
Two-factor authentication (aka multi-factor authentication, or TFA, T-FA, or 2FA) is a way to verify your authenticity by providing two (ore more) of the following factors:
Something the user has – aka a possession factor
Something the user knows – aka a knowledge factor
Something the user is – aka an inherence factor
For most of us, we authenticate only via knowledge – that would be your standard username and password. You “know” your password, thus you pass the knowledge factor. A PIN (like for your bank card) is the same thing. This is simple, it’s easy, and most of us can remember a password.
Something you have is easy to explain if you’ve ever worked for a company and had a RSA ID or a keyfob with a random generated string. That’s the possession factor at work. In fact, your bank card (again!) is one of these too! It’s something else, something physical that you must have to prove you are actually you.
Inherence factors are things like biometrics, so a fingerprint or retina scan. That’s all you need to know about that. Arguably it’s something you have, but it’s a part of you, something you always have with you, so it’s inherent or innate to your very person. Latin. You’re welcome.
It’s pretty obvious that a strong password only goes so far. If I can’t log into my laptop without a USB keyfob, then my site is super secure. This is better than using the picture and keyphrase that a lot of banks use right now, but it’s also harder. It’s very easy for a company to have you pick a photo, a sentence, and a password and make you verify them when you log in. But to instead make sure you have a specific device with you that verifies who you are and that you’re you in this very second?
How, exactly, they work depend on which methods your using. There are myriad different methods of possession factors you could use, and how each one works is a little different. But we like multiple factors because if you needed (say) my retina scan and a password to log in and a titanium ring, and another person with those three items, then I’ve just described the plot of Charlie’s Angels: Full Throttle. I’ve also described a pretty tough nut to crack if you’re not Drew Barrymore.
The issue with these methods is they’re not (yet) practical for the common man, and that’s really a large part of why I don’t like TFA very much.
The knowledge factor is the most easiest to hack. We’ve see that. That’s the whole reason we want to use two or more factors to authenticate. I’m not arguing that. The possession factor is the easiest to break (lose your keyfob or be out of cell phone range). Unless there’s some backup to let me in even if I don’t have the second factor, I’m SOL in a lot of ways. Of course, once you have a backup method, then that’s vulnerable. The inherence factor is the least reliable so far and the hardest to implement correctly. There’s a whole Mythbusters on how easy it is to make a fake fingerprint. It’s not that this is easy to hack, it’s that it’s hard to protect.
The plugin uses open source code for Google Authenticator, which is not something Google really invented so much as perfected. In fact, my old keyfob at work did the same thing.
Here’s how it works. The site you visit generates a string of characters called your Secret Key. This key can be a string (like hE337tusCFxE) or a QR code embedded with all the information from your site (like site name and so on). You enter the data into the app on your phone, and that uses secret string plugins the date and current time, to generate another random number string you use when you log into the phone.
It’s like a password that always changes, and since your phone and your (say) blog have clocks running, they know what time it is, parse the math on login, and off you go. So yes, this will work if you’ve got no cell reception. But no, it won’t work if you’ve lost your phone (which remains an issue for me). Since each site has a unique key and time is always changing, the code is never the same twice. No two users or sites will have the same key either. There’s more math to it, and you can read what Otto commented about it.
Now to log in to my blog I need the username and password, plus a random number I can only get at if I have my cellphone and know the passcode there too. In my case, if I lose my phone, I can’t get into my site. This is, most of the time, okay. If I’m on a strange computer, I need the phone anyway to get the password out of 1Password, and I tend not to log on when I’m not on my own computer or my iPad (which requires the use of an app password, less secure all around, but needed).
To me, it’s not risk versus reliability, or even risk versus vulnerability. It’s risk verus risk. So far, the risk of losing my phone is less than the risk of what happens if I lose my website. After all, my website is my life.
Credit: Grafitti Verite I wrote this months before the botnet attack of April 2013, but I kept putting off posting it. Clearly now is the time! So since people often ask me if I do certain things to protect my site, here’s what I don’t and do do.
What I don’t do
• Hide the WP version in my HTML
• Remove readme.html
• Hide login error messages
• IP blocking*
• Use a different prefix for your DB
• Move wp-config.php*
I don’t bother with the readme or the WP version because it doesn’t matter. People don’t actually search for ‘Who’s using WP 3.4.2? I’ll attack them!’ They let slip their dogs of kiddie cracker war and bury us in traffic. I learned that lesson with the TimThumb debacle. My server got slaughtered by people not searching for TimThumb, but slinging attacks at me as if I had it installed! Even better? They didn’t bother to differentiate where my install where WP was in a subfolder (domain.com/wp/) and just attacked domain.com/wp-content/themes directly. The same thing happened with the recent botnet attacks. Basically people are going to attack me, assuming I’m vulnerable. It’s only when I’ve pissed someone off directly that I’d worry about having a specific version being an issue. And since I keep up to date with upgrades and patches, I don’t worry so much at all.
The error messages thing stems from people worrying that failed logins to WP will tell you that you got the username or password wrong. So if I login as Lpstenu, it’ll say ‘ERROR: Incorrect username.’ That apparently spooks people, thinking that if you know that you’ve gotten a right username, you’ll hammer that. Do me a favor. Go to yourdomain.com/?author=1 and what happens?(This doesn’t work on this domain because I created it back when WP defaulted your first user to ‘admin.’ I made a second ID and deleted that one.) That’s how much effort it takes to find your username, folks. It’s even easier when you look at this post and see the author name, and a link to it, right there in front of you. Your username isn’t a secret. It’s dead easy to get. I’m not wasting time hiding something that easy to find.
That’s not really a valid “security” improvement, anyway. It’s irrelevant whether the attacker knows what he got wrong, as it provides no extra information that would help him to get in. Furthermore, the usernames are exposed in dozens of other places already as I showed you before. I often argue that you can’t remove doors: everyone has to be able to get into a house, so we put locks on our doors as deterrents, and signs up to say we’re watched by ATD or whomever. All of those can be circumvented, and you still have a door. Most crime is prevented by deterrents, however (a sufficiently motivated and skilled person will work around anything), so really all we do is make things inconvenient enough that they go somewhere else.
Part of security is knowing where to spend your time. Make a better mousetrap and you get smarter mice, true, but if you still want to get rid of the mice where do you start? I start with not hiding the obvious. Here’s my username, here’s my login location. They’re standard on most websites, because people have to be able to log in. Now when I really have a locked down site where I want no one but me to log in, I use .htaccess to limit login to just my IPs. This is a (minor) problem when I’m on the road, but I can always SSH in to fix that. Most of the time, though, I trust in my firewall, my server, and the basic security of WP to be enough.
IP blocking is totally useless to me. With a caveat. I use CSF and ModSecurity on my server which will block by IP if you hit very specific abuse parameters, including my newer ModSec rules for protecting logins. However I don’t pay much attention to it, save to whitelist my commonly used IPs. The point of the firewall is not to stop people I know are bad, but to dynamically catch them in the act, block them on the fly, and then let that IP gracefully expire after a certain amount of time. Years ago I may have had to use .htaccess for that, manually updating it to block specific IPs, but software’s come a long way, and letting the right tool do that job is huge. If you only have .htaccess, well, you can use some .htaccess protection of logins, or you can use Perishable Press’s 5G Blacklist. As I tell people frequently, you never know where legit traffic is coming from, don’t be foolhardy.(True story. A customer at work insisted he did too know better, and blocked China and India traffic. Then he went there on vacation and was pissed he couldn’t log in. Yes, I mentioned I had warned him before.)
Curiously controversially, I don’t mess with the DB prefix. I use wp_ much for the same reason I never move my wp-content folder unless I’m using CDN (and even then…) : Poorly written plugins and themes will kill me, and people can view my source code or use DB insertion calls in their code. They don’t have to know my prefix, and in fact, best coding practices are intended to work no matter where the folder is or what you use as a prefix. The other reason is I’m exceptionally lazy, and the less I have to remember that I did ‘differently’ in case of an emergency, the easier my life is. This is important when I’m ever hacked (yes, when), because I can restore faster from scratch if I didn’t go nuts reinventing the wheels or moving things around. Rebuilding a wp-config.php is very easy if I only have to change passwords and user IDs, after all.
Similarly, I don’t move my wp-config.php in most cases. I do on my localhost instance (so I can wipe the folder and DB and start over easily), but really it’s impractical in other situations for me. I think it would be safer to move it out of a web-accessible folder, and when possible I do that (sometimes I have WP in a subfolder) but I have other things I can do to protect that file.
What I Do
Besides a massive amount of work keeping my server up to date and tuning my firewall, I do some things that anyone using WordPress can do:
• .htaccess protect wp-config.php
• Lock file permissions
• Prevent plugins from writing to wp-config.php and .htaccess
• Prevent folder content browsing (for images mostly, but also plugins)
• Use strong passwords for WP/FTP/SQL accounts
• Use one-time passwords for WP/SQL/FTP/SSH accounts
I protect my wp-config.php from direct access with a really simple .htaccess directive:
<files wp-config.php>
order allow,deny
deny from all
</files>
I think nginx is this:
location ~* wp-config.php {
deny all;
}
This means you can’t see https://halfelf.org/wp-config.php in your browser. It’s pretty minor, in so far as things go.
I lock down my file permissions as tight as I possibly can. Nothing is set to 777, and my .htaccess isn’t writable. This means if I use a plugin that wants to edit my .htaccess (or wp-config), I have to do it manually. This is good, in my opinion. I always know exactly what I’m doing. In my .htaccess I also have Options -Indexes, which stops people from being able to browse empty folders (this is important for plugins that don’t have an index.php file). Since I’m using SVN and Git, I also prevent people from seeing those:
My passwords are stupid complex. I haven’t the foggiest idea what they are thanks to 1Password. I also don’t reuse passwords. This is very important for how my server is setup, as DSO requires you to enter in passwords to upgrade WordPress. While I can use my main account, I actually created an FTP only account for each and every website on my server, and then I hard coded that (and it’s password) into my wp-config file. So yes, I have a DB password (each account is used once for each DB) and an FTP password (again, one account for each account) in my config. And no, I’m not worried about that. Sometimes I have a generic SQL ID for all DBs under one account, though that’s a tiny bit more risky.
But, most importantly, I try to cure myself of being stupid. I don’t log in to my site via non-secure ways (SSH & SFTP only). The passwords I use for my login (which is not SSL protected on WP) are one-account/one-use. I try never to log in on someone else’s computer. I don’t do admin work on potentially unsafe wifi. You see, the greatest security risk in the world isn’t the software you’re using, it’s you. You do stupid things, like recite your credit card info (or password) over your cellphone while on a train trying to get your host to reboot a server. You use Starbucks’s wifi to pay your bills. You talk about how your mother changed her name.
Social engineering is way more dangerous than any server hack, and when it’s down to the wire, that’s what I’m more worried about. After all, I have good backups of my files.
The Brute Force attack on WordPress and other CMS apps is getting worse and worse right now. Some people don’t have Mod Security (or can’t get it to work on their server), and asked me if there was anything to be done. Yes, you can still protect your site from those brute forcers via .htaccess.
To be honest, I worried about posting this, since the last thing I want to do is to inspire hackers to do even more inventive things, but I can’t think of another way to get the word out. I want to say this: If your site is being hammered hard by these attacks, CONTACT YOUR WEBHOST RIGHT NOW. The best protections will be done on their end, because using WP to try and stop this still means people are hammering WP.
So okay, what can you do with .htaccess? Well, taking into account the ages old .htaccess block that has been posted up at WordPress.org, you can block comments made by people with out a Referrer Request, I made the logical extension!
### Blocking Spammers Section ###
# Stop protected folders from being narked. Also helps with spammers
ErrorDocument 401 /401.html
# Stop spam attack logins and comments
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
RewriteCond %{HTTP_REFERER} !.*(ipstenu.org|halfelf.org).* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L]
</ifModule>
So the rule does the following:
Detects when a POST is being made
Check to see if the post is on wp-comments-post.php or wp-login.php
Check if the referrer is in your domain or if no referrer
Send the spam-bot BACK to its originating server’s IP address.
The reason my referrer line has (ipstenu.org|halfelf.org) is because … well I have multiple domains on my multisite! If you don’t, you can just have it be one domain, but this lets me have one line instead of eight (yes, eight, you heard me). Not all of them are .org, but if they were, that line would look like this:
Edit: If you’re using Jetpack for comments, you should also add in jetpack.wordpress.com as a referrer.
Above that, though, you saw the 401 rule, right? The 401 takes any errors, which can be abused by this, out of the hands of WP. However for this to work best, you have to actually make a 401.html file.
Here’s mine:
<html>
<head>
<title>401 Error - Authentication Failed</title>
</head>
<body>
<h1>401 - Authentication Failed</h1>
<p>Through a series of highly sophisticated and complex algorithms, this system has determined that you are not presently authorized to use this system function. It could be that you simply mistyped a password, or, it could be that you are some sort of interplanetary alien-being that has no hands and, thus, cannot type. If I were a gambler, I would bet that a cat (an orange tabby named Sierra or Harley) somehow jumped onto your keyboard and forgot some of the more important pointers from those typing lessons you paid for. Based on the actual error encountered, I would guess that the feline in question simply forgot to place one or both paws on the appropriate home keys before starting. Then again, I suppose it could have been a keyboard error caused by some form of cosmic radiation; this would fit nicely with my interplanetary alien-being theory. If you think this might be the cause, perhaps you could create some sort of underground bunker to help shield yourself from it. I don't know that it will work, but, you will probably feel better if you try something.</p>
</body>
</html>
There are more WordPress specific tips and tricks on the WordPress Codex Brute Force Attacks which we Forum Volunteers have been working on all morning. If you want to do even more, then you’ll want to password protect your wp-login.php page, or perhaps whitelist it so only your IPs have access. Personally, I’m not doing that (I have ModSec working) and I’m not using any plugins. While the plugins are great, they still require WordPress to process something, which means that while they can, and will, prevent people from getting in, they won’t stop the traffic on your server.
I wish I knew more about nginx, but if someone can translate all those things to nginx, please post a link and share it! We need to know!
At a last gasp, CloudFlare and Sucuri CloudProxy both claim to stop this before it hits you. I don’t use either, as you may know, so I can’t speak for them, but if your host is unable of doing anything, and you can’t make anything work, you may as well try it.
We use cookies to personalize content and ads, to provide social media features, and to analyze our traffic. We also share information about your use of our site with our social media, advertising, and analytics partners.