Someone or something is trying to login the the admin part of the blog. As some recall, way back in 2009 an unauthorized visitor actually broke into Real Climate. I’ll take this opportunity to remind self-hosting bloggers to implement measure that make it more difficult for ‘bots or honest to goodness crackers to break into your blog. (Mind you, I suspect nothing can prevent a determined cracker from getting in. But you can at least make it harder.)
- Learn the IP address of all authorized users, write a small text file, call it ‘.htaccess’ and upload that to the file called ‘wp-admin’ for your blog. The text file should read something like this:
Order deny,allow
deny from all
# lucia
Allow from xx.xxx.xxx.
# Zeke
Allow from xx.xxxx.xxx.
# SteveF
Allow from xx.xxxx.xxx.xx
where ‘xx.xxx.xxx.xx’ is the IP address for the authorized user. By including this file, you don’t exclude ‘bots from the /login.php page. But you do prevent those that manage to crack /login.php from accessing /wp-admin.php, which prevents them from writing posts, uploading, editing your theme to insert malicious scripts or do all sorts of other things that motivate ‘bots or people to crack blogs.Note: If someone’s IP is dynamically generated often convenient to truncate these to permit a range of IP’s through. If someone has a very stable IP address, it’s safer to use the full IP address. Either way, even if you’ve let in quite a few IP addresses, you’ve at least excluded a huge number of IP addresses.
Downside: Zeke periodically emails to report he’s locked out. I determine his new IP address and add it to the .htaccess file. I also need to go through and prune some of his old IP’s from time to time, particularly those in New York where he no longer lives.
This protection is pretty good, but obviously not perfect. A dedicated cracker could tail Zeke, discover his IP address, either spoof that IP address or just figure out how to connect from that IP address, learn one of the co-bloggers user/password combinations and “voila!” they are in!
- Use a plugin like limit login attempts. This plugin monitors failed attempts to enter “user/password” combinations on the /login.php page. It locks out IP’s that try to often, and also sends the administrator a message like this:
From: wordpress@rankexploits.com
Subject: [The Blackboard] Too many failed login attempts
Date: June 18, 2011 2:15:29 AM CDT
To: xxxx@youcanguessthispart.com8 failed login attempts (2 lockout(s)) from IP: 109.230.220.51
Last user attempted: downloadfromyoutube
IP was blocked for 20 minutes
I told ‘limit login attempts’ to send me an email after an IP got locked out twice. This week I received 3 emails alerting me that “Zeke”, “SteveF” and “downloadfromyoutube” this week failed to login when trying to access the blog from IPs in Europe.
The main purpose of this plugin is to slow down cracking bots. ‘Bots or people on a fixed IP address can only guess a few name/password combinations every so many minutes.
As an additional benefit, it keeps track of all failed logins and IP addresses. Examining the log, I discovered ‘lucia” supposedly experienced a login failure. Evidently, I was in Florida at the time. Who’d a thunk? Other usernames that have failed to login include: “admin”, “mickeystoney”, “Fraurikally” , Myfaceporn.com, and my personal favorite “#_nonempty_subject;_subject;_[….]user_subject;user_theme;user_titre;vraag;wpcf_subject;your-subject (4 lockouts)”.
None of these usernames exist at my blog. Any blogger who doesn’t delete ‘admin’ from the usernames is a fool. When you create your blog, pick a new name, make that user name ‘administrator’ privileges and delete admin.
IP 91.224.160.77 has tried to log in as Zeke, Paul_K and SteveF. That’s either a person or a ‘bot that’s smart enough to read the ‘author’ names for posts.
For those wondering: I’ve then added the IP 91.224.160.77 to the .htaccess block for the entire domain. This can slow down ‘bots a little more, but most crackers will just try using a new IP.
- Try a little obscurity. That is: once you become aware of this issue, give authors “usernmames” that do not match their display names. It may surprise people that the ‘bots attempt to login as SteveF was doomed to failure. SteveF’s user name is not SteveF. This means even if a ‘bot is smart enough to read the user SteveF, that information doesn’t help it log in more quickly.
Mind you: Obscurity is not a very good defense against crackers– but it does slow down ‘bots and people. (It would also be nice for the plugin to notice anything that tries to log in with a non-existent screen name especially if it matches an author name! Maybe I’ll hack write a companion plugin to check that. But first: google to see if the plugin already exists! )
- If you permit guest posts, change the ‘status’ of currently inactive contributors to “no role for this site”. This gives ‘bots fewer possible avenues into the blog. If those contributors want to write a new post, they can email you. Right now, Chip, DeWitt, George are all on ‘no role’ status.
- Now for the obvious: Don’t ever tell people your username/password combination. Never! Heh.
The fact is: I can’t really make sure guest posters don’t do things like blog in front of an open window permitting a dedicated cracker with binoculars from watching their fingers as they type in their username/password combination. I can’t be sure someone might not accidentally respond to a phishing attack that gets them to enter their username/password combination at a fake site. Oddly, I can’t be sure I’ll never do something horrifically stupid. That’s why I back up the database regularly (this permits me to recover if someone deletes the whole blog!) That’s also why I use .htaccess, limit login attempts and anything else that might slow down a ‘bot or cracker. 🙂
If any of you have other tips, please volunteer them. I like to slow these ‘bots down, preferably using methods that aren’t a big hassle for the bloggers, co-bloggers or people writing guest posts.
Quick! Hide the decline before they find it!
Tom–
Well… I just changed my ‘username’ from ‘lucia’ to….. obscure name. It turned out to be ridiculously easy. Monday, I’ll write the plugin monitor additional things about logins. (One feature will let me identify Zeke’s IP’s when he really does fail to log in. He always emails me and then I hunt for his most recent comment and add that to htaccess. (Always checking the commenter used Zeke’s real email and did not seem to be commenting from outer-slobovia. But… that’s not all that efficient. )
Uck. I hate access lists that use exception-approaches. It means the server has to go through the entire list every time. A better approach is to have a “first-come first serve” approach. In that approach, the server goes through your list until it reaches any rule that applies and stops there. It cuts back on processing demands. It probably has no impact on you, but as a matter of principle…
A couple other comments. Most bots aren’t going to be smart enough to read posters’ names and use them. On the other hand, the bot’s controller is. Most likely, someone looked at your blog and gave their bot the names to try. This means you have to assume a bot will know anything a reader could know. I haven’t seen anything you should be concerned about, but it’s an important thing to remember.
Next, in case you didn’t already know, your favorite attempted username wasn’t actually trying to log in with that name. It was hoping to trigger a bug caused by “unusual” input not being handled properly.
Lastly, physical security is the biggest weakness in any system. Even if you aren’t worried someone may access your server in person, you need to remember how effective a baseball bat can be. I suspect Zeke would give up his password pretty quickly if someone applied one to him!
Oh, one final remark. In computer security, the goal isn’t to be “safe.” It’s to be safe enough that it isn’t worth someone’s time to break in. It sounds like you’ve more than accomplished that.
Two other things to do with CMS systems like wordpress to enhance security of the admin/editor/contributor access:
1) change the name of admin directory to something fairly obscure
2) add an .htaccess rule to enforce basic authentication (this will force a double login to get into it). This can be done on a per user basis.
There are sites that maintain a list of all IP address blocks in China and Russia. It’s a good idea to block these address ranges since a large number of hackers are out of these countries. It might be inconvenient to block all of those address blocks in the .htaccess file though.
Bill Jamison, it’s also bad because it can alienate readers. It’s usually bad to shut out entire countries.
Brandon
I’d love a translation for a no-programmer with examples of what you don’t like vs. what would be better. Then if it’s not too difficult I can try to implement things in a better way.
I really don’t care if there is overhead on access to wp-admin. Other than ‘bots and a few authors it’s not visited a lot. Blog visitors have no business trying to go to wp-admin. But if there is some reason I should worried, let me know.
This is why I am obscuring usernames. Up until this morning, my user name was… lucia. Yep. it matched my ‘nicenickname’ and my author name. I changed it!
I don’t want anyone’s user name to match the author names nor the “nicenickname” in wordpress. I know most ‘bots are dumb, but something wants to try to log in as “Zeke”, “SteveF” and “lucia”. All are author names and the same IP address tired all three. So either a human read the author’s names or they coded a bot to read the authors’s names. (That wouldn’t be very difficult.)
Yep. 🙂
Yep. Me too.
Kan
Yes. But the first is a nuisance for people using free wordpress software because WordPress needs to know the name of the folder. Getting in there to program? Not many bloggers are going to do that– particularly since things might suddenly change when you upgrade.
I’ve considered #2, but that does start being a PITA for the bloggers/co-bloggers/ authors. I’d do it if I needed much, much greater security.
Brandon/Bill–
The other difficulty with trying to block all nasty chinese and Russian IP ranges is the spammers are always moving. Some spam filters used to try to keep track of lists, but I found lots those spam filters stopped working because the groups who maintained the lists either stopped letting the spam filter tools look up constantly or the lists just stopped being maintained.
Sorry about not being clear on that topic Lucia. It’s a simple issue to understand, but most people never have to deal with it. Basically, there are two approaches to access control lists (ACLs). A “first-come first serve” approach has the list read one line at a time, and as soon as a matching rule is found, it’s applied, and you’re done. A worse option is what seems to be used here, and that’s where you can have exceptions to rules. If you look at your document, it first denies access to everyone, then makes exceptions. If you were using the other approach, that first denial would block everything, and all the lines that follow would be ignored.
If you have a lengthy list, this becomes important. Imagine you have a hundred rules. If your first rule covers 80% of your traffic, most of your decisions can be made while only looking at a portion of your ACL. You don’t need to look any farther. However, if you allow exceptions, the server can’t just look at one rule. It has to process more of the ACL so it can compare your contradictory rules. You might have to process a hundred lines when a single line could suffice.
Now then, I doubt this matters in your case. You only have a couple rules, and they aren’t applied often. Moreover, I don’t know the software you’re using, so I could be mistaken. It is possible your list is interpreted to translate it into a “first-come first serve” approach (I doubt it though). Even more importantly, you may not have a way to change it depending on what your server allows.
Basically, I’m just annoyed at the idea of having to process a rule, then having to look farther to see if that rule is contradicted at a later point. It is much simpler and faster to just apply the first matching rule, and stop there.
I kind of suck at giving simple explanations. I’ll try a more direct approach. Suppose you have a list of rules. You read the first rule and check to see if it applies in your situation. If it does, you apply the rule and stop. If it doesn’t, you move on to the next rule.
Now then, imagine you have a list of rules. You read the first rule and check to see if it applies in your situation. If it does, you make a note of it and move on. You then check each following rule to see if any contradict the first rule you checked.
Basically, those are the two approaches.
Brandon–
Oddly, you explained precisely the wrong bit. I understand the concept. Not being a programmer, what I am clueless about is how to implement that in .htaccess.
Sure. But the difficulty is that I can’t list all the IP addresses to block from wp-admin. There are zillions and zillions. So, I want to deny a very small subset. If there is a more efficient way to do his in .htaccess, I’d love to know it. But I’m just imitating discussions of how to do this. My ‘functional design criterion’ is to only allow Zeke, SteveF, PaulK, me and a finite number of people in.
Oh, I see. I didn’t explain that part because it’s the easy part (in theory). You’d use the exact same rules. Your allow rules would just come before the deny all rule. You’d have an allow rule corresponding to each user you want to grant access, and after that, you’d deny all. You would have no need to deny individual IP addresses since you’d be denying access to all those you hadn’t specifically allowed.
Unfortunately, I know little about WordPress, so I can only speak to the theory behind this. It may or may not be an issue you can make use of due to the limitations of what you’re working with.
Ok… but you are still explaining the theory. The theory part is easy. It’s the other part I’d like explained. .htaccess has nothing to do with wordpress. It’s apache — nothing else.
If you can give an example .htaccess file that would implement the theory, that would be helpful. I get the theory. I don’t know how to implement it. So… even if you think that’s the easy part, it’s the party I don’t know how to do. So, if you could provide an example .htaccess file that allows, say, 3 IP addresses and then denies all others in the order you think is more efficient, that would help me.
Otherwise, I’ll keep doing it the way I am doing it because, while I understand the theory you are explaining, I have no idea how to turn that into a .htacess code.
Curses… foiled this time, but I’ll be back. And I can add!
feabqtcqy–
I will foil you every time!
That was no hacker at Real Climate, it was a whistle blower wasn’t it?
I didn’t realize that was just an Apache file (I should have) because it had been a couple years since I last managed a web server. I went ahead and checked the Apache documentation, and I refreshed myself on things. As far as I can tell, there is no real meaningful change you can make.
The most important part is the first line, “Order deny,allow.” This means the system will check first for deny directives and then check or allow exceptions. If neither is found, it defaults to allow (hence why the first line denies any). Unfortunately, reversing it to “allow, deny” requires you specifically deny all addresses you want to block (a horrible idea).
Most firewalls use a one-pass system (how many times it reads the rule list). Apache uses a three-pass system. As far as I can tell, you’re stuck with the approach you’re using now. It’s a poor design, but it is how Apache works.
I’m sorry so much focus got put on an issue you can’t do anything about. It is much easier for me to discuss theoretical issues than to track down specific cases. I really didn’t know the details offhand.
I disagree with how Apache handles the issue, but obviously that doesn’t help you any.
Brandon–
Thanks. At least now I know.
bugs– I think “unauthorized visitor actually broke into Real Climate.” fits into either theory. Of course I could be mistaken. For all I know RC authorizes all sorts of visitors and someone authorized uploaded files. I have a strong impression to the contrary.
An alternative to disabling the Admin account is to reconfigure it to have no privileges. Have it run a script when it logs in to notify you and try and trace the access. You might also try and force a malware download to the login. People with more time on their hands have also set up sand boxes for the Admin account that look like a system keeping the hacker busy while tracers or other bots are running. This can also be done with the names that are being used to try and access your system. Oh, and don’t make the password TOO hard! 8>)
The “break-in” at RC was always an interesting piece of ClimateGate. At least one of the e-mails actually contained an admin account and password for the site so it should have been a rather easy “break-in!!” It may be why that site was chosen.
With so few attacks on the Believer sites I have to wonder where all the Koch Bros and Corporate Oil money is being spent!! 8>)
Access lists are easy to get wrong. You will pick it up when you block a friend but will you pick it up if you leave it too open? When it works you do not want to mess with it. Your IP address scheme seems to come with heavy maintenance.
Would it not be easier to use SSL certicates, either for the admin accounts, or both admin and regular posters, (not the same certficate). Of course if the PC with an admin certificate gets stolen, you need to revock the certificate,otherwise done once.
Would allow YOU admin access when away from home, via your hotel or coffee shop offering WiFi.
Sean
No. I wouldn’t. The maintenance on the IP list isn’t very heavy. Every now and then Zeke emails me and I add an IP address.
I don’t know. Describe the nuts and bolts of how it’s done and then I might be able to answer.
When I am away from home, I lot into my server host, figure out my IP and add it to the htaccess file. This has never caused me any problems. I can do the same thing for coffee shops. I’ve done the same thing for Zeke.
But if SSL was easier — both on my side and on the side of any guest posters who I might have to “train”, I’d do it. So…. suggest the “how” bit and I can figure out if it’s actually easier.
kuhnkat–
I agree that realclimate may have been easy to break in. But the fact is, wordpress’s ‘forgot password’ system used to send both the username and email address in a single email. So it’s likely that lots of sites would have been vulnerable if someone got access to authors emails. That’s where .htaccess helps.
Oddly… while limit log in shows lots of attempts to get in last week, after I posted this… it… stopped. I’m going to watch over the next week to see what’s up. But stopping after a post appears discussing the security of my WP configuration is an “interesting” sign.
Well Lucia, this post proves you aren’t a bad person. I was going to warn you about your post with ‘usernames’ and addresses. It wouldn’t take much to start a free climateblog and entice e.g. Zeke to comment and snag the IP.
I hacked a mainstream program for fun about 10 years ago after only one day of reading, just to see if I could. Turns out that a bit of machine/assembly language and it doesn’t take much. No the program or hack weren’t distributed and I owned legal copies, but the losers who do these things for the public to prove their abilities make far too big a deal of it.
Jeff —
Of course some people can learn Zeke’s IP; it’s even easier to learn mine! So if someone really wants to break in and is patient, they probably can or they know someone who can. But that’s why I have the pile up of stuff, trying to make sure none really gets in the way of any authors.
WordPress has historically had quite a few holes. It’s been pretty bad and users just can’t be sure new updates won’t have new holes that crackers will quickly identify.
The thing to remember is that most of the hacking and spamming today is done for PROFIT. It isn’t the nerdy teenage boy alone in his room doing for kicks anymore.
Bill– Yes. Most want to insert links to boost SEO of their sites, harvest emails etc. That’s why I do think about a ‘bot reading the ‘author’ name and using that to try to break in. The crackers also share scripts, so once someone adds a feature, they all soon have it.
Very, very few for profit crackers would be trying to dupe one of the authors into revealing their IP so they could break into my specific blog. They just move on to other easier sites. But as JeffId points out– the latter is possible. (I don’t really know why anyone would specifically want to break into my site, but there are people with unusual desires out there.)
If you are away from home, it is hard to know what your Ip will be.
The certificates / Https idea, is that the PC has an encrypted secret that is only give out to trusted folks, issued either by you of a trusted commercial company. You enable HTTPS admin option on wordpress and it checks you are who you say you are by checking you have access to the encrypted secret. If you have bought over the internet using a credit card you will have used https. The question is how do you actual do it on wordpress? There are articles on the workpress.org site. I have never done it myself on wordpress. I do use us it to administrate communications equipment.
Sean–
I never write blog posts when I’m on travel. I suspect Zeke doesn’t either. People are usually busy on travel. So, the issue of needing to post while on travel is a bit moot.
I think to use https I would have to spend $$ on a certificate. Not sure… but I think so.