Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: hosting

  • Spam / Splog Wars

    Spam / Splog Wars

    If you run a blog where anyone can comment, no matter what the software du jour is, you’ve had spammers. There’s really no way around it. As soon as someone comes up with a great, easy, way for you to share content and open discussion with other people, the door opens for people to use that great, easy, way to spam you.

    A lot of people take spam for granted. We get junk mail, we get telemarketers, we get spam. It’s a constant of life. And spam is just like junk mail and telemarketers. They want to get your attention, they want you to click on their links, and they want your money. Some spammers link to actual products (usually sex products) and others link to sites that will infect your computer with a virus. The end result, oddly enough, is the same. They want you, and your visitors, to click on their links and somehow make a profit. The cost overhead is so low that even if just one of my visitors clicks on a link and buys something, they’ve made a huge profit. (By the way, if a post looks like spam, don’t click on their links. Only give your money to reliable companies. Research them, ask around. Be smart.)

    A spammer posts spam comments or uses your site to propagate their crap. A splogger is a spam-blog. A blog that only exists to pimp the same crap. If you have an open-registration CMS site where anyone can make a blog, you will get sploggers. Some people will argue that WordPress is less secure because it gets more splogs than Joomla. I would disagree. More people use WordPress’s built in ‘anyone can make a blog!’ feature than Joomla, so it’s a better target if you’re a spammer. You’re going to get more bang for your spam-buck, so you aim for the biggest target.

    No matter what type of tool you use for spam-trapping, remember that the best tool you have is your eyes, your brain, and your common sense. YOU are the number one, best defense, against spammers. Yes, this means you have to give up of your free time to maintain the site, to monitor the new blogs, to monitor the new comments and users, and stop them. While some posts can be hard to determine if their spam, if you check the email, the URLs and the context, usually you can sort them out.

    Unless you have a dedicated team of people monitoring your site for trouble, it’s hard to keep up. This is where I start throwing in tools to help my site. There are three levels of defense: Server, Account and Application. I’m not linking to many tools, since a lot of this is preference. I like certain tools, other people like other tools. At the end of the day, no matter how good your tools are, the human element is required to be attentive and aware of the site. I’ve blogged before on the dangers of an unchecked multisite, and they remain true. Running a website is work. If you’re not willing to put the time in to maintain, monitor, and defend your site, something bad will happen to your site.

    Server Level

    Set up a good firewall. I use ConfigServer Security & Firewall, which checks against Mod Security and bans people who hit it too hard. This prevents a lot of automated spammers and also stops them, once they GET in, from being able to send out spam emails. A good firewall does wonders for other reasons too, but only if you configure it correctly. ConfigServer has a test it can run to see if your setup is good or middlin’ or poor, and I check it every time I upgrade. Oh yeah, keep current with your firewall tool, too!

    Account Level

    I hesitate on this one, but .htaccess can be used to ban IPs. I don’t like to do this and, generally speaking, don’t do this. If someone skirts by my firewall, I’m not going to block them at the IP level, since there are probably some legit users. Also, the firewall is automated, whereas my .htaccess I’d have to manually update. The point of a good tool is that you don’t have to fiddle-fart around manually too much! That said, there are ways you can kill spammers and sploggers via the .htaccess.

    D’Arcy Norman came up with this awesome way to stop them on WordPress Multisite:

    # BEGIN ANTISPAMBLOG REGISTRATION
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} .wp-signup.php*
    RewriteCond %{HTTP_REFERER} !.yourdomain.tld. [OR]
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteRule (.*) http://someotherpage.tld/ [R=301,L]
    

    Credit: D’arcy Norman.net

    The part I like best is that if you change wp-signup.php to where ever it is your site has a signup page, you can make this work with just about anything. What it does is check the POST requests (which is the server request when you submit a form) for the page wp-signup.php. If those requests do not come from your domain (which if you click on the sign-up button, they must), then it sends them to http://someotherpage.tld/. I send them to a page that says they’ve been caught as a spammer, and to behave better.

    If you must use an .htaccess blacklist, I would strongly suggest you follow D’Arcy’s advice and block them from accessing your registration page only. His thermonuclear option is above and beyond what I need, but I can see it being useful.

    Application Level

    Once you’ve set up your server and account as best you can, you have to start modifying your application. Thankfully, any modern CMS has a good plugin or extension system, and you can leverage that. Sadly, most modern CMS have the same problem of keeping up with the spammers. The tools used are pretty much the same.

    Most CMS have a limited array of built-in tools. WordPress has a way to make all first-time posts require approval for example, but really when you get down to it, you want to throw in some plugins/extensions/modules that are designed to help.

    Content Moderation

    Blacklists are simple. Here is a list of people I don’t want to have access my site. Done. There are the usual caveats for this and the same warning applies as with .htaccess IP blocking: you may block legit users. Personally I prefer moderation lists versus delete blacklists. They put the possible spammer into a bin for me to review and approve or not. Blacklists and mod lists work best, I’ve found, for spam comments rather than splogs. I know, normally, no one on my site will be talking about viagra, but what happens if they have a question about it? The term is on my moderation list. (Funny but true story. I had the word ‘sex’ on a mod filter on another site. Suddenly people were talking about how sexy someone was, and all the posts hit my mod filter. Sometimes these terms are great to block out, but sometimes you forget how they’re really used.)

    That said. There are good, reliable, blacklists. Stop Forum Spam and Project Honey Pot both are blacklists maintained by the community, and get enough information that they can be use reliably. There’s also Spamhaus, but that’s mostly email. You can use these on most applications as well.

    Behavior

    There’s actually a plugin called Bad Behavior, which is a great example of what I mean. Bad Behavior the app analyzes the HTTP headers, IP address, and other metadata regarding the request to determine if it is spammy or malicious. What I mean by the term is simply ‘Is the visitor coming to my site from a legit browser?’ See, spammers don’t use the normal browsers that you and I use, so if someone comes from a special method to my site, they’re probably not a good person.

    Behavioral monitors learn as they go, or as they’re updated, and can be pretty effective. Sometimes people on archaic browsers (IE 6, for example) will get nailed by false positives. There’s not a whole lot I worry about with those, since any browser since 2005 is usually safe to go. There are two people who hit my sites regularly who’ve run into this problem, and once I sorted out what they were doing (Netscape Navigator 4 came out in 1998 and IE 6 came out in 2001), I told them ‘Look, the site will look like crap anyway. Upgrade.’ One guy couldn’t, the other switched to FireFox and admitted to being much happier anyway. (I don’t believe in supporting browsers pre-2005 at this point. I monitor my site stats for them, but realistically, it’s not going to happen. Upgrade, people. You’ll be happier.)

    CAPTCHA

    Personally I hate these. CAPTCHA is named after ‘capture’ and is a contrived acronym for “Completely Automated Public Turing test to tell Computers and Humans Apart.” It looks like this:

    The idea behind CAPTCHA is that it should provide a problem easy enough for all humans to solve while, at the same time, prevent standard auto-fill software from filling out the form. Sounds great, but the problem is people have created software to read the CAPTCHA files. Personally, I love the fact that we’re making AIs smart enough to parse this stuff, but it hurts CAPTCHA because in order to defeat the AIs, they tend to become harder and harder to read for real people. Also, most CAPTCHAs are not friendly to people with limited accessibility. If you have dyslexia or glaucoma, they’re of the devil. I would never consider using one on my site unless forced to.

    Human vs Computer Test

    Originally CAPTCHA just meant any challenge/response to stop automated form fillers. Since it now is used, almost exclusively, to refer to those images, I’m pulling out Human Tests. A human test is when you have a question, or form, that requires thought to answer. Like ‘Who’s buried in Grant’s Tomb?’ We all know the answer is ‘Grant’ so you type that into a text field when you register or comment, and magically you have access. I’m fond of simple math questions like ‘What is 12 + 8?’ but also good are site specific questions. One on my friend’s site is about Marg Helgenberger, and they use questions about Marg (like ‘what’s the last name of her character on CSI?’).

    The reverse is to trick the computer. Put a hidden checkbox on your site, that is NOT human readable, and if that box is checked, aha! Spammer! That’s a pretty cool trick if you can make it work.


    Do you have tips and tricks you use?

  • What is Cloud Hosting?

    This came up because I’m considering moving to cloud hosting. I don’t have to, yet, and since it’d cost me an extra $25 to $30 a month, I’m not planning on it just yet. (Actually, it would be pretty much WHAT I pay now, if I drop cPanel, which is an extra. But for the extra $20 I get ‘cPanel + Fantastico as well complete support of base operating system and all cPanel services. Proactive service restoration is provided.’ I don’t care about Fantastico (and tend to uninstall it), but the base OS support is useful and cPanel just makes life easier for me. Yes, I’m lazy.) But wrapping my head around the ideas behind cloud computing was a weird trip.

    A few years ago, I had a job as a Citrix tech, which meant my job was to take software normally installed on your PC, install it on a server, and somehow trick the PC into thinking ‘When I run Word, it’s actually running on this distant server, and not my desktop, but everything pretends it’s on the desktop.’ This was called a thin-client deployment, because the client (i.e. the PC), only has to have a very little bit of processing power to run things like Adobe Photoshop. By the way, fat-client means ‘everything runs on your desktop.’

    For the really old hands at this, you’ll remember when all PCs were just dumb terminals that connected to the mainframes, and you ran everything off the mainframe. Guess what? Thin-client stuff is kind of the same thing. The programs you run via thin-client basically only exist when you run them. The rest of the time, they’re not available on your PC. This is good and bad. It’s good, because a company can save millions by pushing out low-end, weefy desktops to everyone. It’s bad, because they then have to turn around and spend the millions on the servers and the network. If the server or network goes down, no one gets to work.

    What does that have to do with cloud computing? Cloud computing takes the thin-client idea of ‘on demand’ usage to a new level. Right now, ipstenu.org lives on a server (a VPS to be specific) with four other domains. I pay a flat fee for the server space, a specified amount of bandwidth, a limit of CPU, and some IP addresses. With cloud computing, I would pay a flat rate for hosting, but if I need more CPU, I can easily get more by clicking a button. And when I don’t need more? It goes away.

    Suddenly my server is able to adapt! It scales up and down on an as-need basis. Think of it like your heating bill. In the summer, when you don’t need it, the cost per month goes down. In the winter, it goes up. And unlike the gas company, you don’t pay more during winter because it’s a set, year-round rate. Woo! Or, as the video I’ve linked to below would say, it’s like a Tax. The meter keeps running at stoplights, but it runs slower, so you pay less.

    Now I will say the math for all how much all this costs, sorting out what you need, is a bit heinous. I ended up chatting with my webhost about what I would need, based on my current usage. They have their own traditional webhosting setup as well as a cloud service, and since I adore them to no end, I decided it would be smartest to just ask them about it. Yes, it would be a hassle to move everything, and likely my subversion stuff would break and need to be re-installed, but it’s definitely a better bang for my buck than to use something like a dedicated server.

    There are downsides to all this. The biggest one is security, which panics a lot of people. On cloud computing, you’re back to the same sort of place you were for shared hosting. When you need more CPU, you get another ‘slice’ of the cloud (it’s a mixed metaphor, sorry). The slices still need servers to run on, obviously, and each webhost has the option of slapping together a bunch of servers quickly and poorly, or doing it the right way. And, sadly, a lot of webhosts are leaping into the cloud without looking, shoving servers together, and not thinking about security. To those people who worry, I remind them that cloud or not, your server’s security has always been about your webhost.

    In August of 2010, it was determined that Network Solutions (a big webhost) had over 500,000 compromised websites. Reported on by Armorize Blog, they proved that any time you made a parked domain, Network Solutions put a widget on your site that served up malware and could infect PCs. This was a default widget, something that showed up if you didn’t check any boxes, on newly registered domains.

    From the horses’ mouth, Network Solutions spokeswoman Susan Wade provided this statement when asked for comment: “Regarding the widget incident from the weekend, our security team was alerted this past weekend to a malicious code that was added to a widget housed on our small business blog, growsmartbusiness.com. This widget was used to provide small business tips on Network Solutions’ under construction pages. We have removed the widget from those pages and continue to check and monitor to ensure security. Reports of the number of pages affected are not accurate. We’re still investigating to determine the number impacted.”

    Basically, Network Solutions own website was hacked and shot a ton of other sites.

    You want to complain about cloud being insecure, go ahead, but remember that your security depends on your host being a good soldier, same as always. WHich is why I recommend LiquidWeb and their Storm On Demand Hosting.

    The other thing people complain about with cloud is they can’t touch their physical server. Personally, I don’t care. The virtualization of data is a big thing, and most people actually never see their server. Mine’s somewhere in Michigan I think. Making backups isn’t easier or harder with a cloud, so you can still have a good backup of your data for emergencies. Everyone should have a backup.

    Should you move to cloud? If you’re on a VPS and starting to get too big for it, then yes. The cost is a good reason but also you’re just going to get more flexibility. If my server needs grow (which is to say, if I start crashing the server again), I’ll be moving to cloud for sure.

    Still confused? Watch this video and it will explain it in a very straightforward, amusing, manner:

  • The Latest Malware Malfeasance

    I preface this with I really don’t have time to de-malware everyone’s site who emailed me, so please don’t ask for help right now, I’m not a freelancer for a reason and I’m booked till … Uh, August at this rate. So, no. I’m not going to be able to help you. I am going to post HOW to fix it, but if you need serious help after that, at the bottom are links of people to help you.

    If you find this helpful, great! There’s a donate link to the right on my site, but personally I feel it’s more important people get the right information!

    So you logged into your site and the admin side looked something like this:

    The odds are that you’ve been hacked by the latest malware. Malware is short for “malicious software” and basically it’s someone screwing with you. Why? Because they can. I’m not going to get into why, it doesn’t matter. What matters are two things:

    1. How can I fix it?
    2. How can I stop it from happening again?

    Before we go any further, though, go run the Sucuri Scan. That will tell you if you’ve really been hacked, or if it’s something else. For the rest of this post, I’m assuming you’ve been hacked.

    How can I fix it?
    Make a fresh backup of everything on your site. Download it all. Yes, it’s probably got the virus in it, but that’s okay. It won’t hurt your desktop. Also backup your database to your desktop computer. The hack doesn’t seem to have affected your database, but you should always make a good backup before you try this stuff. Make note of your theme name (and where you got it from), as well as all your plugins. You’ll need this in a moment.

    Put a copy of the following files/folders in a safe place, separate from the rest of your backup:

    /public_html/.htaccess
    /public_html/wp-config.php
    /public_html/wp-content/uploads (and ALL files and folders under this)

    Now, delete everything from public_html on your server. Yeah, everything. This is why I said make a backup, folks!

    Once the server is naked, change your passwords for FTP/SSH. If you’re using a non-Secure method of accessing your server, stop and get something like WinSCP or CyberDuck or anything that allows SECURE FTP access. SFTP should be the ONLY way you FTP to your site.

    Download, from WordPress.org a new copy of the latest and greatest core WordPress files (at this posting, it’s 2.9.2, but 3.0 is in beta, so that may change shortly). Install from that, NOT from your site’s automated installer. You should be able to copy all the files up and then add those files I told you to put aside. Remember them? The .htaccess, the wp-config.php and the uploads folders all go back up.

    Under no circumstance should you upload anything else from your backup at this time! Also don’t bother visiting your site, it’ll look weird.

    Once your files are back, go to http://wordpress.org/extend/plugins/ and download all your plugins. One at a time.

    Repeat with your themes, going to http://wordpress.org/extend/themes/ or wherever you got your theme from in the first place.

    If you made your own theme, it’s a little harder, since you’ll need to go over every single PHP file in your theme and look for ‘weird’ code. Sucuri has a cleanup script, but pretty much open them all up, look for encoded information that will look something like this post from Sucuri. If you see that in a file, kill it with fire.

    Finally, go into your /public_html/cgi-bin folder. If there’s a file called php.ini in there, delete it. There may not be, so don’t worry about it too much if not.

    How can I stop it from happening again?

    I’ve got some advice, but right now, if you’ve been told ‘Just upgrade WordPress’, well, that’s not enough. Yes, I know that GoDaddy was claiming for a LONG time that’s what you needed to do. I’m here to tell you this: GoDaddy is incorrect when they tell you ‘Just Upgrade.’

    That doesn’t mean you shouldn’t upgrade, in fact, you may note I said to get the latest and greatest WordPress version (again, 2.9.2 as I write this). That’s because it’s going to have every security fix they’ve come up with to date. It’s almost always best to use the latest version of software. For most of you, it’s always better.

    You may want to look into something like WordPress File Monitor, which emails you if files are changed. Just turn it off when you plan on making a lot of changes!

    By deleting your files, getting a secure FTP client and changing passwords, you’ve closed the biggest security hole: You. I hate to say it, but every time I’ve ever been hacked it’s been right after I opted not to follow security protocol that I know damn well. And here’s my protocol: Always use secure connections to your website when editing data or accessing sensitive areas.

    And that’s really simple. If I use cPanel or WebHost Manager, I connect via HTTPS, which is secure. If I use shell, I’m using SSH (secure!). If I’m FTPing, I’m using SFTP. You see the trend? I’m also only using software I know and trust. My browsers of choice are Chrome, Firefox and Safari. The last time I used IE 8, I got hacked. My SSH terminal is the Mac Terminal or PuTTY for Windows (which I only download from http://www.chiark.greenend.org.uk/~sgtatham/putty/ – there are other, fake, PuTTY sites). My FTP clients are (for Macintosh) Transmit and CyberDuck. For Windows… Well I actually don’t FTP much from Windows. I have been known to use WinSCP, but I’m not comfortable recommending it, as I haven’t had time to really look into it’s security. In addition, I don’t connect to my site’s back end from non-secure WiFi. That means I don’t go in on my laptop in StarBucks. Anyone can jimmy my connection!

    Now that you’re being secure, go to talk to your web host. Tell them what happened. Since you have a backup of your files, you can even show them the hack! Any decent web host will sit up and pay attention. Sometimes they’ll be a bit shady, but pay attention. If they say ‘We’re going to look into this, but in the meantime, please upgrade and change passwords.’ then they’re okay. If they just say ‘Yeah, its’ your fault, upgrade.’ then you’re in trouble. When I was hacked, my host helped me sort out what it was, admonished me appropriately where I’d screwed up, and pointed out ‘Here’s when and where it happened.’ To which I said ‘Shoot! That was all on me!’ But they took the time to work with me.

    If you’re on GoDaddy, LEAVE. GoDaddy Doesn’t Give A Damn, or at least they’re acting like they don’t. A user found the code used to inject malware and it’s not a WordPress specific file. In fact, this annoyance is attacking multiple servers, multiple hosts, and multiple PHP based apps.

    Besides, Go Daddy is telling people to upgrade to fix the issue, but they’re running an old version of WordPress on http://community.godaddy.com (which is where they happen to be telling people to upgrade).

    It’s 2010, and apps like WordPress are here to stay. Mark Jaquith wrote a deft admonishment to web hosts, telling them to adapt:

    WordPress is the number one user-installed web app, and its growth is showing no signs of slowing. If you are a web host, and you don’t have a specific strategy for WordPress, you’re likely operating your service inefficiently, and may be opening yourself up to security issues. This is the year to adapt, or be left behind by nimbler upstarts.

    As a side note, GoDaddy has contacted Sucuri, saying they are looking into it, but they’ve taken weeks from when this issue first sprung, Athenaesque, into the spotlight. The full-grown goddess has a spear, guys. Pay attention. If they had said, from the get go, “Gosh, this is weird, we’re looking into it!” or asked for information, or not dismissed willing technical users, they might not be on my shit-list right now. As it stands, I cannot recommend them as a host.

    GoDaddy has a special contact form just for these security issues. If you were infected, use it.

    Me? I use LiquidWeb
    Dedicated Servers by Liquid Web

    So you still need help?

    Ask your host for help. If they can’t (or won’t), try to get them to do a restore from backup. But some hosts are better than others about this.

    Your next step is to open your wallet:

    Those are three people I ‘know’ (as much as you can know anyone on the net). Plugged In is the only one who, up front, says she’ll remove malware, but the other two are savvy enough that I suspect they may as well. If not, they’ll tell me. Kim Woodbridge assured me that she does indeed remove malware (thanks, Kim!). and I’m fairly sure WP Turnkey might, but if not, based on his services listed, he can get you up on a new server that isn’t GoDaddy. Chip, of WP-Turnkey also said he does this, so there you have it! Ask them, and please feel free to tell them ‘Ipstenu sent me!’

    And yes, these are going to cost you money. Well, running a website costs money. Welcome to the costs. I’ve paid out the nose to bail myself out of these situations before, which is why I’ve learned what to do. And even then, I pay a good host a lot of money a month to help when I’m in over my head.

  • Hack’n’Slash Security

    I was intending on a totally different post, but, well, this came up instead.

    Recently, WordPress, my preferred blogging software, has been under attack by both hackers and critics. There were actually three attcks that all got lumped into one so I’ll try and break this down. If you’re of the ‘Too long! Didn’t Read!’ variety today, you can get by with knowing this: If your WordPress install is not secure and if your web host is not secure and if YOU do not follow security practices, then you will be hacked. Period. Security relies on you, your web host and your web apps all being sensible about the whole thing to be effective. Remember, it’s okay to ask for help!

    Also go read Hardening WordPress right now.

    Okay, so security.

    Back in Feburary/March, there was a sudden influx of users complaining their sites had been hacked by inii.info, whereby the hack was to edit the wp-blog-header.php and change it so any time a search engine bots visited your site, they went to inii instead. This matters because search engine bots collect information about your site and use it to rank your website against all the other sites about a given topic. There was a second hack where a file named ... (yes, three periods) had even more redirect code in it. And it was heavily encoded so you couldn’t read it without decoding.

    The reason I call this a Media Temple hack was that it seemed to be prevalent to Media Temple installs. While at first people jumped the gun and said ‘It’s WordPress!’ Media Temple came out with a detailed Q&A about the matter and the attack appeared to affect ALL webapps via compromised passwords. If Media Temple ever revealed what happened, I’m not aware of it, but it wasn’t just WordPress that was affected. They ended up changing DB passwords for every webapp, from Drupal to vBulletin.

    In early April, there was another rash of hacks, this time targeting Network Solutions. This time, it looked like a clear cut case of database changes. WordPress, like most PHP/SQL apps out there, uses a database to store all its information. In this instance, the database entry for the site’s URL was changed from (for example) https://ipstenu.org to an iframe link I’m not reproducing here.

    At the same time, there was a ‘Pharma’ hack, where links with ‘pharma’ in them were slipped into your site, in a rather genius fashion. Chris Pearson has a decent explanation on the matter, but I feel he’s barking at the wrong car for part of it.

    Chris and Media Temple and Network Solutions and a horde of people on Twitter and forums every where jumped up and said “AHA! It’s a WordPress hack!!!111!” Which … well, yes, but not exactly. As the very wise Andrea_r put it, there’s a difference between attacking WordPress installs and targeting WordPress installs.

    An analogy if you please. There’s a rash of break-ins in a small town. The houses that are broken into are all bungalows. People shout ‘Aha! It’s a problem with bungalows not being secure!’ The police look into the matter and find out that in every house broken into, the bathroom window was left open. Now, is this the fault of the builder, who designed bungalows to have a window people could fit in through or is this the fault of the residents who didn’t close and lock their windows?

    If you said ‘It’s a little of each!’ then thank you, you can stay after class and clean the erasers.

    Security depends on many things, but to the topic at hand, server security is a tripod, and relies primarily on these three legs:

    • The Web Host is responsible for making sure the sever itself is up to date with the latest patches etc, and that the server is configured in a safe way.
    • Web-apps are responsible for not unleashing needless insecurities to the system.
    • The end-user we pray to the flying spaghetti monster that they’ve not done something to violate security out of ignorance.

    To understand how these hacks all worked, yes all of them, you have to look at the perfect storm. This is what had to happen in order for all these accounts to be compromised:

    1. Someone saved their wp-config.php file in a way that it was readable by the free world.
    2. Someone scanned for and found that file.
    3. The user was using their ID and Password, rather than creating a DB user just for the blog.
    4. That account had read access to other accounts on the same server
    5. The malicious user used the account to scan for other wp-config.php files, even if they were saved securely and compromised their accounts/databases as well.

    That’s a lot of wrong on one box. With most webhosts, you’re on what’s called ‘Shared Hosting’ which means a whole mess of people are on the same server, each with their own ID and password. Much like if multiple people have IDs on a desktop PC, the inherent security of the server does not allow Joe to look at Jane’s files, unless she saves them in a public space. Alas, one a couple sites, this was not the case. SO Joe, who saved his wp-config.php file with 777, and used his server ID and password to access his database in that file, was compromised. And once the hacker had Joe’s information, he scanned the entire server and hurt everyone.

    Ouch.

    But wait, doesn’t that mean it’s WordPress’ fault for saving passwords in the wp-config.php file in a way a hacker can read them!? Well, yes, it’s certainly WordPress’ ‘fault’ but you have to realize that doing so is an accepted risk of most PHP/SQL webapps, in that for the SQL DB to be read, the password to that database must be kept in clear text (i.e. not encrypted). This is in the wp-config.php file.

    Okay, so it’s Joe’s fault for saving his file in a readable fashion? Somewhat. By having their wp-config.php file set so that anyone can read it (bad permissions – 777 for example), Joe put himself at risk. This IS NOT a flaw in web-app or the ISP, it’s just … well, ignorant (unless the ISP is forcing the file to be 777 to run WordPress, at which point it’s their fault, and yes, there’s an ISP that does that!). In addition, I know a lot of people who, instead of making a DB user for their blog, will put their server ID and password in that file, which means once it’s been read, ANYONE can log into that server as them. I suspect this is done from ignorance as well. By the way, your server ID and password is the same as your FTP user ID and password in most cases.

    Back to WordPress, shouldn’t they check for that? Maybe. But it’s not that easy, since there are a lot of different ‘acceptable’ security settings for that file, and it all depends on the server. Maybe one day WordPress will figure that out, but right now they tell you to make it secure.

    What about the web server? They are responsible for making sure that if Joe User set his WP config file to 777, and put their server ID/Password in there, the worst they can do is shoot themselves in the foot by preventing them from reading anyone else’s user directory. Limit the destruction on a per-user basis. There are a lot of Shared Hosts out there with lax security policies, which makes this more prevalent than I’d like.

    Hopefully that made sense.

    All of these hacks seem to be looking for people with wp-config files that can be read, logging into the account as the user (or the database user), and either adding files that edit the database, editing the database, or both editing the database and adding the fake plugin files.

    Once your server is insecure, because of compromised IDs and Passwords, you have to go back to zero, reset ALL your passwords, scan your PC for viruses, and be careful. Remember, if they have your password, they can do everything you can do.

    Good luck out there. Be smart, be secure, be safe.

    Edited to add…
    Also check out Mark’s well written post about how your security? Is your responsibility. Because dude, is SO is.

  • But If, Baby, I’m The Bottom, You’re The TOP

    Earlier this month I talked about how my server was acting wonky and how I fixed it using, among other tools, TOP.

    This week I was chatting with a fellow about CPU usage and his site. He runs a rather large WordPress blog and the database is about 500 megs. As a comparison, this site, with about 500 posts, is under 5 megs, and my big site, with thousands of posts, comments, and a forum, is 10 megs. The biggest site I run on my server is 850 megs (just down from 910 after some clean up). The difference between his site and mine is that his is slow and he knows it. As we discussed ways to speed it up, I had some thoughts on WordPress and how, at a certain point, you’re going to need to dig into the guts of your server and learn TOP.

    The ‘problem’ with most ‘How do I make my WordPress site run faster?’ tutorials, as I’ve seen it, is they address surviving the digg effect. That is, they talk about how to deal with having a high volume of traffic on your site and, for the most part, you can make it with just adding caching plugins.

    Once your site gets ‘big’ or ‘popular’ you’re going to have to move off shared/cloud hosting and over to your own server. For most of us, the first step is a VPS (Virtual Private Server). Shared Hosting means ‘You have an account on a server with a hundred other people.’ It’s great for small sites, inexpensive and easy to use. The problem is you could have terrible neighbors, who use up all the CPU. Think of it like those old New York apartments where someone’s a jerk at 5am and uses up the hot water so you, at 7am, have none. Yeah, it’s kind of like that. That’s the day you think ‘I want a house!’

    Only, well, we’re not all up for houses just yet. A house would be a dedicated server, where it’s just you. Cloud hosting, which I touched on earlier, would be the college dorms of webhosting. It has a lot of benefits for the really small sites, and actually some for large sites, but I’m not sold of their overall usefullness yet, so I’ll talk about them some other time. What I want to talk about are Virtual Private Servers, the condo-sub-leasing (or rent-to-own maybe) of website hosting, and how the new VPS user should really get on TOP of things (sorry, bad pun) to make their lives easier.

    TOP. Well ‘top’ really. Unix commands are generally all lower case like that.

    The top command is a system monitor tool that outputs a list of processes. Have you ever seen Task Manager in Windows? It’s kind of like that tab for ‘Processes’ that you look at and run away from. The default view of top is by percentage of CPU usage and the “top” CPU users are listed. See? The name made sense. You can also see how much processing power is being used, memory hogs and other cool things. Most modern Unix-systems let you sort the list, colorize it, etc, though you have to be command line savvy.

    Here’s what top looked like for me about an hour ago.

    top - 12:44:44 up 126 days, 23:13,  1 user,  load average: 0.12, 0.17, 0.17
    Tasks:  91 total,   1 running,  90 sleeping,   0 stopped,   0 zombie
    Cpu(s):  0.0% us,  0.0% sy,  0.0% ni, 100.0% id,  0.0% wa,  0.0% hi,  0.0% si
    Mem:    524288k total,   358248k used,   166040k free,        0k buffers
    Swap:        0k total,        0k used,        0k free,        0k cached
    
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    15616 nobody    15   0 94540  65m  20m S  1.0 12.8   0:00.27 httpd
    12261 ipstenu   16   0  1908 1012  780 R  0.4  0.2   0:00.30 top
    [...]
    28630 root      16   0  107m  86m 1096 S  0.0 16.8   1:06.30 /usr/sbin/clamd

    I wanted to point out clamd, which has been the bane of my existance. Thing won’t DIE. I ended up going in to /etc/exim.conf and manually commended out the clamd line (and restarted the service) to finally get it gone.

    But top, as you can see, has a freakishly large amount of information. My server is doing fine, at this point, so I don’t have a whole lot to show you. What you can see right away is that I can tell, with a glance, what’s going on. I could see, though and at this point I have a ‘nobody’ process. That just means someone’s accessing my website. No, really! That’s good! The CPU and memory usage seem high, but they vanish in a second. Basically, someone rang my doorbell and for that brief moment, electricity was used. The next thing I see is the top command, which is run by me (hi!) and down the line is that idiot, clamd.

    I actually scan top a lot at work these days, trying to understand what’s causing issues. It’s good for ‘right now!’ things, but not so much if I want to see what started a strange spike a couple hours (weeks) ago. For that you need a whole mess of tools.

  • You’re not the boss of me

    After having my domains on three different servers for a long time, I mathed it out that it’d cost me the same to put ’em all on one VPS (virtual private server). After calling up my ISP (the fanfreakintastic LiquidWeb) they had me all moved over without me having to fuss! Combine two shared accounts into one VPS? Sure, done. I suspect my next bill will look … weird, but that’s okay. I’m sure that even if it’s all messed up, I can call them and get it sorted out.

    The first thing I did was make sure everything was running and then I left it alone for a day. Did anyone notice? No? Good, the fix was in!

    Then I started fiddling. I didn’t know a lot about VPS, having only mucked about with a RedHat distro before, and LiquidWeb provided me with cPanel and WHM, which I’d never used before. They also had the very familiar shell world for me to jump into. Google being what it is, I quickly found a VPS Optimization Guide that gave me some ideas to start.

    What I’ve Done So Far
    My memory usage, with one beefy site and two baby sites, was hitting 50% which, in my mind, was bad. Now the beefy site runs off WordPress which is known to have these issues. My CPU was barely passing 0.01 (yes, that’s right) though, so that was good. My first thought was to try WP-Super-Cache again, except last time I did that, CPU went through the roof and stayed there. Also, you lose dynamic feeds etc (unless you use AJAX) and I’ve heard great things about WP-Super-Cache but the fact that it’s not a locked in part of WP has always made me wonder as to it’s viability. If it really was that good, or the only solution, it would be built in. Not to knock it, but I consider it only one option.

    While I know I need to optimize WP, my first stab was to optimize the server. Except that I didn’t. I switched from Zend to APC. Now, I’m not really sure if that was the best thing to do. I find a lot of people clamoring that APC is better and since I’d had weird issues with Zend before (outright borking MediaWiki if not configured specially), I decided to give APC a shot. If someone has info on some benchmarks or a good link to why APC is better than other PHP cache tools, I’d like to see them.

    Then I removed Clamd (and ClamAV). Yes, I know it’s virus scan software, but I’ve never actually seen it catch anything. What I run on the server, and what my ONE (yes one) resold client will run, aren’t going to get caught by it. We run the same stuff. So call it a calculated risk. I also turned off EntropyChat (never gonna use it), MailMan (resource hog), Analog Stats and Webalizer (leaving AW stats, though personally I use Woorpa and Google for stats). Gave the server a bounce after all that and my memory dropped from the 50-th percentile to the 30s. I consider that a success.

    My only issue is that my phpinfo page looks weird… No idea what happened there.